A way to determine cause of FPGA timing error for cRIO

[jlawley1969]

I get timing errors randomly when attempting to compile my code and place on to the FPGA.  They always are "non diagram" error and then it will list some issues but then it does not tell me the location or how to fix the errors.  Some times something as innocuous as moving blocks around can solve or cause the issue. This would not be a massive issue if it did not take 20+ minutes to compile my code for it to only tell me the error at the END. i have been working with the cRIO 8 months now and have a stable working code but if I want to change something it has been a huge hindrance to progress. As an example I wanted to add a simple switch to the working program now I am getting timing errors and removing the switch does not fix the issue. 

Essentially I would like to know how to actually fix the issues I get directly instead of just randomly moving blocks around or trying different build configurations until the timing error goes away.

I am using a cRIO 9054 chassis but I feel like this may be applicable to other chassis I am not sure.  [also I apologize if any of my terminology is incorrect I can provide more information as needed]

[ZYOng]

The Timing Violation Analysis Window will tell you the source of the issue but it takes some knowledge and experience to resolve it.

Here are some useful articles:

• Troubleshooting Timing Violations
• Testing and Debugging LabVIEW FPGA Code

Usually, I would just apply Pipelining for places where I can afford delay, e.g. writing to DMA FIFO.

[jlawley1969]

[jlawley1969]

Hi, sorry for the late example but it only happens randomly. But I have attached the issue I am having where it is "non diagram" components that are causing the issues and searching "internal name /dio28_IBUF_inst/O" (one of the aforementioned components) does not tell me anything.

[Intaris]

This reminds me that I should maybe do a post on how to debug "non-diagram" timing violations.

A lot of my non-diagram violations are automatic datatype coercions on the FPGA.

If you wire a +-16,1 to a +-8,1 datatype, a coercion dot will be present. This seems inocuous (it's only a few pixels) but it can be deadly for your code. By default, LabVIEW applied "Saturation and "round half even" operations for each and every coercion. This can lead to some significant logic being implemented behind the scenes. And because LV does not treat a coercion dot as part of the "diagram", it cannot assign the timing violation to anything in G.

Check the path of the internal name to see if it can give you any clues and scour your code for those pesky kids coercion dots.

If you find one that might be causing issues, there are alternatives.  You can use a "to FXP" node and then set the "saturation" vs "wrap" (i.e.handle extraneuos MSBs or not) and "round even", "round half even" vs "truncate" (i.e. handle the extraneous LSBs or not). This gives you control over your code and will actually be a diagram component. If timing then fails, LV can tell you. Of course, if the bits are irrelevant, you can choose "wrap" and "truncate" which essentially ignores all extra bits on the upper and lower stages of the original value.

[jlawley1969]

I wanted to follow up on this because I have the same error and it is STILL non-diagram error even though I have put FXP on (almost) everything

but the I did as was suggested and tried to get any information I could from the error describtion and the weird part is I am getting an error for the 9264 which I do not have in my set and the other two error pretain to "DIO18" which also none of my modules have a DIO 18.

I have attached my updated code which now has all FXP nodes, to the point of being excessive and wanted input as to what I should try next to stop getting the same non-diagram timing error every time

thanks

[Intaris]

Now that you show the actual location of the timing violation (cRIO SPI) it doesn't look like a coercion problem. These tend to have typical naming conventions.....

You'll have to ask someone familiar with cRIO for further insights, I've never used a cRIO.

[Intaris]

How does your resource utilisation look like?

How are the top-level clocks defined....?

There are so many questions which are important in trying to fix issues like this