How to use DSP48E Multipliers ? (FPGA)

[M.haefner]

Hi,

I'm currently trying to implement a high speed gauss function generator on a PXI-7841R. I need several fast multipliers to calculate the exponent, so I would like to make use of the DSP48E slices. I have limited the operands to less than 18 and 25 bits, but it seems like the DSP-slices are not used in any case. I have several integer and fixed-point-multipliers in my VI, but the compilation report only states 3 used DSP-slices. Can anybody tell how to make Labview using them. Thank.

Regards,

Matthias

[WillD]

It would be helpful if you post some of your code.

Are the multipliers used in a subVi?  If so, is the subVi reentrant?

[M.haefner]

Hi WillD,

see the attached code. The fixed point multipliers are 4 stage pipelined for sctl in this case. I've tried several configurations: with/without pipelining, inside/outside sctl, fixed point library, standard multiplier. The DSP-slices seem never to be used as expected. The code is executed in the toplevel VI. I use Labview 8.6.1, FPGA 8.6.1, Ni-Rio3.1.1, Fixed-point-library 8.6. 

Regards,

Matthias

[WillD · Accepted solution]

I am still playing around with the code but here is an update.

I compiled the code you provided.

I have experienced this issue as well with the XST reporting.  It does recognize using multipliers as show here:

======================

HDL Synthesis Report

Macro Statistics
# Multipliers                                          : 2
 25x18-bit multiplier                                  : 2
# Adders/Subtractors                                   : 53
 17-bit adder                                          : 1
 18-bit adder                                          : 1
 20-bit addsub                                         : 49
 27-bit subtractor                                     : 1
 34-bit subtractor                                     : 1
# Counters                                             : 7
 16-bit down counter                                   : 1

...

However, the final report doesn't show the multipliers being located within a DSP48 slice but they are, if they weren't it would take a stupid amount of fabric to implement them.

The multiply by (-1) constant is being replaced by logic, should be a negate anyways, that is why only 2 multipliers are being utilized instead of 3 as expected from the high level diagram. 

[Newton_Petersen]

As mentioned above, Xilinx is certainly optimizing the multiply by -1 (one bit) into logic and so is not using a DSP48 block for that multiply. I have seen others put the value (-1) on the front panel and make the datatype wider than a single bit (18 bits for the dsp 48) to ensure you get a DSP48. They put the whole operation in a sub VI to avoid host communication logic for the control. Its hard to say whether this is beneficial to do. Unless you run into an issue fitting or missing timing, it is probably best to just trust Xilinx's judgement...  

[M.haefner]

Hi,

I was playing around myself this week and now your remarks make sense to me. My main concern was, that I could only reach loop rates of around 160MHz which seemed to be very low since the DSP-slices should be able to run at up to 550MHz when fully pipelined. I created a new project from scratch and could reach loop rates around 250MHz for my Gauss function by optimising the pipelining. I guess for further optimization I'd have to write vhdl-code... Thanks a lot for your efforts.

Regards,

Matthias

[Newton_Petersen]

I would be happy to look at your latest code and see if there is anything that can be done to reach higher clock rates. What rate are you aiming for? 

In general, I would agree that around 250 MHz is the practical limit in current LabVIEW FPGA. There are two things that typically start getting in the critical path at these high rates:

1. FIFOs - These are the most convenient way to get data into/out of a loop and the current FIFOs in LabVIEW FPGA do not take advantage of the hardcore built in FIFOs in Virtex-5. You could instantiate one of these yourself in a CLIP to get around this issue.

2. In the single cycle Timed Loop, there is a clock enable line that fans out from the loop controller to all flip flops in the loop. This high fanout signal can have enough delay along it to cause issues at these high clock rates. The only work around is to use multiple loops and pipe data to the different loops.

An idea: you may be able to implement all your math in a large lookup table which may be able to give you a higher clock rate.

On a research note, I'm fascinated by a new FPGA recently introduced by Achronix, http://www.achronix.com/ that seems quite ideal for feedforward computations. Your application seems like it may be a good match. Feel free to comment if you agree or disagree and why.