64-bit fixed point multiplication timing violation (LabVIEW FPGA)

[akarpilow]

Hello,

I am trying to program some high precision math in LabVIEW FPGA on a cRIO 9039 using the high-throughput multipliers. I was under the impression that it would be possible to multiply two 64-bit numbers. However, whenever I try to compile I get a timing error. The multiplications are performed in a regular while loop (not a SCTL) but I get a warning that the "requirement of 24.99 ns was missed by Xns".   I don't care how fast the operation is (yes, it still needs to run on the FPGA) but I am confused as to why it would be forcing the operation into a single tick. While I can explore reducing the bit size, I would still like to know why this is happening.

I've read that "64-bit fixed-point inputs to a multiplication function are likely candidates to fail timing in clock domains of 40 MHz or higher. DSP blocks on the FPGAs in National Instruments hardware typically use 18-bit multipliers. In the event of a 64-bit multiplication, several 18-bit multipliers must be chained together to execute the arithmetic, yielding longer logic and routing delays. " But if I'm not concerned with how many 18-bit multipliers are used or the logic delay, why would this prevent me from compiling?

Thank you for your insights!

[Yamaeda]

---

@akarpilow wrote:

1. I am confused as to why it would be forcing the operation into a single tick.

2. But if I'm not concerned with how many 18-bit multipliers are used or the logic delay, why would this prevent me from compiling?

---

1. Because FPGA

2. See 1, it must fit within the tick timing. Add a buffer node so it can split (pipeline) some work between 2 ticks.

3. If you don't use the timed loop the system is ok with a longer loop time, but that is generally not how people seem to use FPGAs.

[rolfk]

These high resolution arithmetic functions have a configuration dialog. In that dialog you can configure what the number of pipeline stages of the function is. If you set this to a number of 1, the function needs to be compilable into a single tick as a whole.

If you increase this number, it can be split across as many ticks as you configured pipeline stages. Consider this function to be basically almost like its own timed structure if you select it to run outside of a timed structure. If you select it to run inside a timed structure, LabVIEW will leave that extra code away as it is already taken care of by the explicit timed structure of your diagram.

[Intaris]

Given the datatypes you have configured, you not only need to perform a multiplication, but also truncation and rounding which can be expensive, time-wise.

I suggest you read the "High-performance FPGA" guide.

https://www.ni.com/de-de/support/documentation/supplemental/13/the-ni-labview-high-performance-fpga-...

[Terry_ALE]

The above comments cover some good specifics and the link to the developer's guide is also very good.

Additionally, FPGA compile failures sometimes should be analyzed in a broader sense.  The specific item that the compiler blames for failure could be what put you over the edge but the issue could be solved by changing something else that does not need to run as fast or optimally as before.

In this case, I would confirm the need for a 64-bit multiplication.  Test data typically does not have that many significant figures.  In other words, some of the bits in these kinds of calculations have low/no value to the project.  Imagine going through many math functions, where the bitness of the output data keeps growing.  It is good to trim the bits to ensure this growth is managed.  Also, it ends up costing resources which on an FPGA have hard limits.