[cRIO-9054] [LV 2022 Q3] Non-diagram component FPGA Timing Violation

[Chris_97]

I am working on my first LabVIEW project and I have ran into a timing violation issue that I struggle to troubleshoot and resolve. The project is a PID controller for a MagLev pump that I am porting over from Matlab Simulink to LabVIEW.

In my first attempts (FPGA-level code versions 1.0-1.3) I have played with manually replicating existing Simulink PID controller with mixed results (derivative filters work fine in non-FPGA test versions of the program, but for FPGA code they seem to output erroneous results), but despite those issues I got the program to compile nearly always without issues and with around 60% FPGA resource utilization. Since debugging that issue seemed too time consuming I have decided to change my approach and use the PID block from the FPGA Math and Analysis/Control palette.

Upon implementing that change in version 1.4 my resource utilization went way up (as expected with floating point variables those blocks use) to around 100% and I have started getting consistent non-diagram component timing violations, with the one shown below (referencing /dio18_IBUF_inst/O) being the most consistent, although I've had some other violations referencing dio14 and dio28 (some of those with requirement of 0.00ns missed by 0.03ns), as well as one that seemed to reference one of the DMA FIFOs. It is also worth noting that those timing violations appear at the very end of the compilation process after the Final Timing (routing) has completed and the clock requirements were met.

I am really unsure of what could be causing it. I have tried deleting or disabling some of the components from the block diagram (versions 1.4.1 and 1.4.2), reducing the resource utilization to 85-90%, but that did not seem to have an effect. Changing the implementation strategy to the one shown below has yielded one successful compilation of one of the leaner versions of the program, but unfortunately I did not save that attempt and I have not managed to replicate it.

If any of you have any idea on what could be causing it please let me know.

Chris

[Chris_97]

[UPDATE]

I went back to version 1.4 and recompiled it with the directives shown in the above post (as previously I used "Optimize Performance" implementation strategy, which resulted in the same timing violations) and quite unexpectedly, it compiled fine. So clearly it's not an issue that's tied to the utilization of FPGA resources on its own. Despite the fact that I currently have a compiled version, I would still appreciate any help or insight into the issue, as I'm almost certain it will start popping up whenever I make any changes to the code.

[ZYOng]

Here is how I would try

1. Resource reduction with PID: Use the low level FXP version of PID controller. You can copy it from the shipping example CompactRIO\FPGA Fundamentals\FPGA Math and Analysis\PID Toolkit\PID Control (FPGA).vi
2. Timing violation usually happens with the SCTL. You can implement some pipelining using feedback nodes. For more details, see Optimizing your LabVIEW FPGA VIs: Parallel Execution and Pipelining

[Chris_97]

Thank you so much! I was completely unaware of the existence of that PID block. Makes you wonder why NI did not include it in the palettes. It doesn't solve the original error, but at least I'm able to progress. I redid my program with these blocks and for now I am able to compile every time with no errors. I am still working on verifying that it'll work for my use case, but it seems like it should do the job. My only issue with it is the I16 integer casting, as I feel I'm somewhat limited by the -32768 to +32767 range in terms of control granularity. Do you think that if I were to change all of the internal references from I16 to I32 it would break the functionality of the block? I'm somewhat wary of editing those blocks nestled within blocks nestled within blocks.

[Chris_97]

Scratch that. After spending half a day compiling more than a dozen times with no issues I have just got identical error.

So the single-precision float PID blocks were not the culprit in and of themselves. I still feel like it's loosely related to the total utilization of the FPGA resources. I will look into pipelining techniques, although it seems to me like the problem might lie somewhere else, as all of the references seem to point to some serial communication issue (e.g. SpiEngine in the screenshot above), either between I/O modules and FPGA or FPGA and Chassis.