LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

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

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?

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 1 of 37
(5,623 Views)

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/


CLA CTAChampionI'm attending the GLA Summit!
Subscribe to the Test Automation user group: UK Test Automation Group
0 Kudos
Message 2 of 37
(5,610 Views)

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 Smiley Sad

 

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!)

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 3 of 37
(5,597 Views)

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.

Message 4 of 37
(5,572 Views)

@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.

Thoric (CLA, CLED, CTD and LabVIEW Champion)


0 Kudos
Message 5 of 37
(5,559 Views)

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

Cheers!

TJ G
0 Kudos
Message 6 of 37
(5,540 Views)

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

Message 7 of 37
(5,528 Views)

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.

0 Kudos
Message 8 of 37
(5,511 Views)

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

0 Kudos
Message 9 of 37
(5,499 Views)

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.

0 Kudos
Message 10 of 37
(5,492 Views)