FPGA timing violation tips?

[IhmeKyselijä]

Hi,

I made the below attached code (for my PXIe-5774) to calculate an fft and then store it until the host vi can retrieve. This version is just a test that more development will be made on but when I compiled it I got a timing violation (WNS=-1.32ns). The report can be seen below:

 

Path 5 is indicating the largest timed loop on the diagram and the particular feedback node is on the top of the loop coming from >=64 node. 

How can I improve timing on this (obviously terrible) code? VI and Xilinx log attached. 

Thanks:

Aarni

Picture of the block diagram that might not be very helpful. 🙂

[Hooovahh · Accepted solution]

From a high level the timing violation error is an error stating that the operations you want to do in a single loop, can't be done in the time that the FPGA needs.  There are a few ways to get past this error but all will require some kind of knowledge of what you are trying to do.

One solution might be to do some work in one iteration, then do the rest of the work in the next.  This can be thought of as pipelining and usually involves using a shift register to send some data to the next loop to get done then.

Sometimes you run out of other resources which requires using other things in a less efficient way.  I ran out of multiply functions on the FPGA once, and as a result the FPGA ended up using gates to perform the multiply in a way that took more time to accomplish.  For me I ended up putting a single multiply in a subVI, then set it to not inline.  This would cause the same multiply function to be used, but at the cost of having it potentially slow down other parts of the code.  For me this was fine because I didn't need dedicated multiply functions.  Creating subVIs and reusing code might help with this.

You might also get away with doing the same work, in a different way.  If you are doing some math on a set of numbers, it might be possible to precompile the results, based on a small set of inputs.  Then you can have a lookup table return the values, without having to do the actual work.

I believe there are compiler settings in the project that can prioritize different work loads.  Changing these settings and trying again might result in a proper build.  It's a bit of an art form that I never perfected.