12-01-2023 04:05 AM
Hi there!
I have a subVI in my project with a SCTL. When I compile the subVI separately, I don't get any errors. However, when I compile the whole FPGA vi, I get a timing violation (only 0.41 ns)!! With such a small violation, I know that recompiling can sometimes solve the issue due to the non-deterministic mapping but the main vi takes 2 hours to compile which is why I tried troubleshooting the subvi compilation.
I saw here that
"If the FPGA VI uses a large area on the FPGA, the Xilinx compiler optimizations might map different single-cycle Timed Loops to different look-up tables (LUTs) in the same slice. If two different single-cycle Timed Loops map to the same slice and a timing error occurs in one of them, the Timing Violation Analysis window might indicate the wrong single-cycle Timed Loop has the timing violation."
I don't know for sure if this is the case. But my question is are there other ways to troubleshoot a timing violation if the analysis window is not providing good information? If the subvi in question compiles perfectly on its own, how can I find the source of the problem?
Thank you!
12-01-2023 04:09 AM
The source of the problem is routing, placement restrictions and usage of the FPGA target.
The only way to solve it is to, step by step, make routing of your design easier. The weird contradiction is that sometimes expending MORE resources in order to ease routing congestion can actually be very beneficial to your compilation success rate.
Without any type of code to go by, it's kid of hard to give any other feedback.
12-01-2023 11:14 AM
You can mitigate the timing violation using pipelining on non time-critical path.
FPGA Pipeline Example - NI Community
Optimizing your LabVIEW FPGA VIs: Parallel Execution and Pipelining
12-04-2023 11:12 AM
Solved it! I removed/pipelined some operations. I guess I was only off by a very small amount of time.
Still, it was very confusing that the timing violation window did not give more useful information. Since I could compile the subvi successfully on its own but not when part of the full FPGA vi, it made troubleshooting very difficult.
Thanks for the help!