LabVIEW FPGA Timing violation confusion

[IhmeKyselijä]

Hi I am writing LabVIEW FPGA programs to my FlexRIO PXIe-5774 with LabVIEW 2019 sp1 64-bit. I am using multiple FFT Express VIs which seem to be very tight on time and resources. Thus my compiles take 6-7 hours. 

My problem is the compilation process. The variations of my code seem to just sometimes cause ridiculous timing violations when compiled. This happened today:

It's hard to fit anything into 0 ns and even harder when you aren't even told what it is that you should be fitting to that time.

Another case:

I made a version 0.8 of my code and when it was compiling I built on top of that code and made version 0.9 and 0.9.1 where I only added more code to the existing code. The 0.8 version failed because of Timing violation that was equally as unhelpful as the one I showed you but the version 0.9 and 0.9.1 compiled fine and worked like they should. 

I understand that the compile process is a bit random but this is ridiculous and wasting my time. Is there any way I could try to avoid needing to make small changes to a 'Timing violation' code and recompiling again hoping that it won't fail again? Any tips on better FPGA development?

I am mostly compiling on the LabVIEW cloud compile service.

Thanks for any input:

Aarni 

[Intaris]

Click on the non.diagram component int he window and see what text is shows at the bottom of the window. This can give you a clue as to whether it's a coercion (rounding) or a clock-domain-crossing issue or something else.

I'll assume the infinite frequency clock is somehow an error.....

[crossrulz]

When I had issues like this, I eventually found that my problem was too large of DMA FIFOs.  Once I shrunk them down to the next possibly lower size, I never had another compile issue.

[Terry_ALE]

This is a tough one.  Besides what is mentioned above, I would check for other items that can be optimized from a timing standpoint such as adding pipelining.

Another thing is to backtrack to the changes that put this over the edge.  Those could be the culprit though it may be more broad.

[IhmeKyselijä]

The changes that put this over the hedge is the FFT express vi... Can't really do an FFT without it. The Xilinx IP version doesn't seem to support 16 samples per tick but I might be wrong. I wouldn't want to change to that anyways because this way works but wastes my time a little bit.

Thanks!

[Terry_ALE]

Most if not all of the NI blocks are based on the Xilinx IP.  Though going down that path may be very time consuming and I would want to check all other optimization options.

Do you need all of the FFTs?  Can some re-architecting be done to reduce some things.  Maybe use other resources to help alleviate.

Export to Vivado and compile may give you more insights into the things that you can optimize.

Are you at the end of the development?  If you have no more functions to add you can try running 5-10 compiles, if at least one passes you have a bitfile.  My view is that you may still be in trouble with this approach in case you need to add more functions at some point.

[Andrey_Dmitriev]

Got the same on my last project (and it was not extremely complicated BD and logic).

Was solved for me with this option:

try to change, may be will be helpful for you as well.

refer to https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kFu1SAE&l=de-DE

Regards,

Andrey.

[IhmeKyselijä]

Hi

Yes I am at the end of development for the first version and I have gotten it to compile and I can't and won't change the big picture. I guess I was just asking if there is something I was missing that would save my time in the future. I guess my code is just at the very limit of what can fit into my FPGA timing vise and some random chance plays a role here. I  guess I'll leave this thread unanswered as there wasn't one good answer but many smaller tips?

Thanks everyone for your input.

Aarni

[Terry_ALE]

The biggest thing is reviewing architecture.  I find that FPGA development has less code and more design/planning.  The code sometimes can be redone if a better approach is found.  There are tips like disabling this and setting that but I have not seen them make significant improvements.

Some of the NI FPGA IP (in the DSP) folder is made for 160 MHz (VST FPGA) and when it is used in the FlexRIO which may run at 200 MHz it will fit but then it does not fit.

Frequent builds - maybe not full CI/CD but something close to that.

[BertMcMahan]

I had some timing violations like this several years ago and never did track them down... I just wanted to say though, that 0.02 ns is 6 (six!) light millimeters, so I agree it's an absurd timing requirement, and it *feels* like a bug. I mean a limit is a limit, but the number of times I got timing violations that were less than the time it takes a signal to move through the chip (much less stabilize anywhere) made it feel like something else was going on.

I know very little about FPGA's at a low level, but I suspect it was trying to make two things happen simultaneously and it couldn't quite get there. That (IMHO) would still be an error in compilation, but a "timing violation" makes it seem like you just need to optimize a little better, when in reality I suspect it's something other than that. Maybe not, but again... I got a lot of timing violations, and they were almost never significant. Always in the picosecond range. The times I did have significant violations I was able to fix it with more optimization/pipelining/etc.

Hopefully someone else here can elucidate me... I do understand that the signals in fact have to propagate across the chip, but it seemed weird to get 17,000 ps (or whatever) sometimes, and 2 ps other times.