Timing Violation with LabVIEW 2025 Q3

[Xonmyth]

Hello Reader, 

I am running into some strange timing violation specifically with LabVIEW 2025 Q3. If I look into Final Timing (routing), it says "Met" but timing fails when compilation is done. I believe in VIVADO equivalent terms, Synthesis and Implementation is okay done but routing is failing. 

But when I click on Investigate timing violation. It shows a 80 Mhz Clock used by non-diagram component on Path 1 missing by .18ns. I do have a derived 80Mhz clock but it is not used in the VIs that are failing. Triple checked it.

The code was originally made in LabVIEW 2019. If I compile the same VI there, it works fine. Board that I am using is sbRIO-9638 (Running updated 2025 software). This is happening to all the FPGA VIs I have (the ones using only 40 Mhz on board clock).

To make it compile in LV2025,I have to play with the implementation strategy under Xilinx Options. Just randomly go through all possible options and one of them ends up working. A strategy that has worked in the past is not guaranteed to work in next compilation.  

My resource utilization is also below 50%:

Any suggestions?

[Intaris]

non-diagram components can be a few different things

Coercion dots - where rounding of saturation  logic is implemented automatically behind-the-scenes by LabVIEW, this has no actual diagram component, so it can't show you where it happened in code.

It can also be some NI-internal stuff, although this is rare. LV uses many clocks internally which are not shown int he timing window. If any of these fail to meet timing, it can also give a "non-component" timing violation.

It can also have to do with FP elements in case your top-level clocks are somehow differently defined.

I would normally expect code which is unchanged to still compile in later versions since the Vivado toolchain is most likely the same.

To know more, code would be required.

-edit- there is one other chance: If you are inclined to do a deep dive, you can export the project to Vivado and then try to compile it there directly. It will show you very clearly where exactly the timing violations occur. This will require some knowledge of the internal VHDL workings of the code, so not for the faint-hearted but is an excellent debugging method once you've gotten a hang of the learning curve.

[Xonmyth]

Hi Intaris, 

Thank you for your reply. 

1) No Coercion dots in the code. (Tested with VI analyzer as well). 

2) Likely the reason but I am not sure how to pin point it as nothing has changed at my end. Only a new LabVIEW version. 

3) FP elements, how would this be? On the Block diagram, top level clock is the default 40Mhz clock. No derived clock is in use.

4) Not true in my case. I think there is an issue with version change.

5) All the codes handle proprietary protocols so I will not be able to share them. I am trying to make something simple/ sharable and that recreates the issue I am talking about. 

In the past, timing errors have made sense. If no error like coercion dots exists, you would simply pipeline the logic (reduce logic chain) to be finished in the defined clock period  (in this case 25ns) to resolve timing issues. I have not had issues with IO timing in LabVIEW (WNS, Hold time, input/output delays etc) so not considering them to be a problem. 

This is not what I am experiencing right now. I think there is something under the hood being misinterpreted by LabVIEW or VIVADO at some stage. Latest thing I tried, a classic one, open the failing code in LV2025, copy the failing code, create a new VI, paste the code and compile it. It works. I will keep testing to see if it is repeatable. But this is not a good solution, I have 20+ codes like that.

This is a good suggestion, my Export Utility license expired at the perfect time so I will test this as soon as I have it back. Although given the current situation, I am not sure if I will even be able to export the VHDL code.

[Intaris · Accepted solution]

I have had cases (in LV 2025 Q3) where LV searching for a Clock by name has led to loops being connected to the wrong clock. I had this happen today. I manually re-selected the clock on the affected clock constant and then it worked.

I had code that should have been running at 200MHz but was only running at 100MHz.

Clock wired to the loop was visibly set to 200MHz, but it needed a manual re-select to make the code ACTUALLY run at 200MHz.  YMMV.

[Xonmyth]

I will give it a try. Could very likely be happening in my case as I do have several derived clocks used in different VIs.

[Xonmyth]

This was it. In my case I had to delete and re-create the clock constant and it seems to be working fine now.

Thank you, Intaris.