Is there an obvious way to prevent an FPGA multiply from using DSPs?

[Thoric]

In FPGA coding a High Throughput Multiply function will take advantage of any available DSPs on your FPGA. This is great, unless you have more multipliers than available DSPs. My FPGA code is currently failing to fit, and although it's using just 50% of the Registers/Slices, it's trying to use more DSPs than are available (My Virtex 5 chip has 64 DSPs).

In the help I'm pretty sure it says the compiler will revert to using slices for multiplications in the absence of sufficient DSPs, but my experience is otherwise.

If I convert just one of the High Throughput Multiply functions to a standard LabVIEW Math multiply primitive I receive timing errors from the compiler (even though there are minimal timing constraints in my code), and it therefore still fails to compile.

So my question is: Is there a way to prevent a Multiply function in LabVIEW FPGA from using DSPs?

[.aCe.]

I'm guessing you have tried the Build Specification option already? http://zone.ni.com/reference/en-XX/help/371599G-01/lvfpgadialog/fpga_build_spec_xilinx_db/

[Thoric]

Hi aCe. Yes, I've tried playing with all of these settings. Nothing seems to convince the compiler to use FPGA slices for the remaining multiplications after the DSPs are used up. It keeps falling over no matter what I do

In fact, to test this I created from an empty VI 15 High Throughput Multiplers, and 1 primitive multiplier. This used up nearly all DSPs. I added one more primitive multiplier and it then fell over at compile. It just will not use FPGA slices for surplus multiplication! Even though the FPGA is at about 7% capacity (and therefore very able to host a multiplication!)

[Dragis]

Unfortunately, this is a bug/feature of the Xilinx tools. Once the tools have decided to choose DSP blocks for the multipliers, it will only use them and not place any in logic. There is a way to disable automatic usage of DSP blocks, you'll have to work with NI customer support to make that change. If you use this option, you'll have to manually drop the High Throughput Multiplier everywhere you want a DSP48 to be used.

[Thoric]

---

@Dragis wrote:

Unfortunately, this is a bug/feature of the Xilinx tools. Once the tools have decided to choose DSP blocks for the multipliers, it will only use them and not place any in logic. There is a way to disable automatic usage of DSP blocks, you'll have to work with NI customer support to make that change. If you use this option, you'll have to manually drop the High Throughput Multiplier everywhere you want a DSP48 to be used.

---

I've gone through Technical Support with this issue once before about a year ago and there was no mention of a 'solution', just the unhelpful suggestion to "use fewer multipliers". I'll raise another support case and link to this thread, maybe they'll need to speak with you directly to understand what this option is.

I'm perfectly happy, in fact I'd prefer, to be able to specifically select where a DSP is and isn't used for a multiplication. If reasonable, I'd suggest this option to disable automatic usage of DSPs be made public (either through the knowledgebase, or as an actual feature in the FPGA toolkit perhaps).

Thanks Dragis.

[T-REX$]

Just tell them to look at CAR #276311 (internal bug report). That should help them explain all of the available workarounds.

[J_Oneill]

Hi Thoric,

Just incase you miss the link from the CAR, here is a KB detailing how to make the compiler use resources other than DSP48E slices to implement multipliers

How Can I Work Around the "Too many comps of type 'DSP48E' found to fit this device" Compilation Err...

Does this allow you to compile your code?

Best regards,

James O'Neill - Applications Engineer - National Instruments

[nathand]

There should be some sort of filter in the forums code that prevents NI employees from posting links to ae.natinst.com, since that site is apparently only accessible on the internal NI network (or so I assume, I've never been an NI employee). This happens over and over again on this forum.

Fortunately you can usually find the same document by rewriting the URL to point to digital.ni.com instead, so in this case that would be http://digital.ni.com/public.nsf/webPreview/11F5845409E0DC02862579DD005B1C04.

EDIT: I rewrote the URL wrong in my initial reply, and edited the above paragraph based on the working URL that Dragis posted.

[Dragis]

Thanks nathand. Not sure why your link doesn't work. I did what you said and got to this link which did work. http://digital.ni.com/public.nsf/webPreview/11F5845409E0DC02862579DD005B1C04?OpenDocument

[nathand]

I rewrote the URL wrong (or maybe the URL scheme changed since the last time I tried) - I edited more of it than was necessary, replacing webPreview with allkb. I've edited and corrected my comment about the link.