FPGA timing violation on sbRIO9638 Labview 2022 q3

[Larsstumpp]

I try to compile this VI (see attached jpeg) on the FPGA target of a sbRio9638 but I always get this timing error (see attached jpeg). With a 40MHz clock the requirement should be 25ns not 1.88ns. Strangely the requirement does not change if i use a different clock for the SCTL (4 or 10MHz derived clocks). So where does the 1.88ns requirement come from, and how to fix this ?

[Xonmyth]

Hi Larsstumpp,

1.88ns Requirement is for a certain logic path, no a requirement of your SCTL clock 25ns.

A simplified example:

Addition+ AND+ OR + Subtract + Array to number conversion = Requires 10 ns

Bit shift + AND + Addition etc+ etc+ = Requires 13.12 ns

Counter logic VI + Addition + Bit shift = Requires 1.88 ns

Total 25 ns. Above values are requirements to fit inside  a 25ns clock.

Compiler implemented first two logic chains (Paths) no issues, but when it tried to implement 3rd logic chain with requirement of 1.88ns, it experienced delays due to routing and how long that logic is taking to complete. 

FPGA logic are placed on actual physical fabrics.I think of it like a room with two doors on both ends, if the room is empty, you can just walk straight from door A to B. But if there is already a bunch of stuff/logic in the center, then you will have to walk around it to get from door A to B. That is what's happening with your code. 

This was explanation for the 1.88ns delay. 

Now it is interesting that timing error did not go away when you used 4 or 10Mhz derived clock. Maybe your code is too bulky to even fit inside a 4Mhz clock. If you can attach your code, I can better comment on that part. I work with sbRIO-9638 so I will be able  to give you an exact answer.

After you create a derived clock, are you actually selecting the new derived clock for SCTL before compilation? 

P.S. You have too much logic in place for an incremental encoder (Rube Goldberg machine). I can confirm that you can write code for incremental encoders that run on 9638 FPGA with much less logic.

[Larsstumpp]

Yes, the 10 or 5 MHz clock was selected for the SCTL. But there has to be a more fundamental error, since even when I turn the SCTL into a common while loop with 1us wait time and reduced the complexity of the logic (see attached jpgs), I still get the timing error saying the 1.88ns requirement is not met. But since there is no SCTL, there should be no timing requirement, right?

[Xonmyth]

Right! something is strange. 

Can you share actual VI and not the image files? It will be the .VI files. (Both main VI and the counter logic VI).

[Larsstumpp]

here they are

[Xonmyth]

Thanks, I could compile your code without any problem. 

Things I can point out:

1) Coercion dots. For the inputs of your Analog output, you have SGL connected to FXP. Add conversion function to fix this problem. (Probably the cause of failure) Resolve any other coercion dots that you may have. 

2) Delete your clock constant and re-create it.

Last option

3) Copy all of your BD and paste it into a new VI's BD, save it and try again.

[Chris_97]

Hey,

I'm not sure what specific timing violation you're getting, but I am encountering similar issue on LV 2022Q3 with cRIO-9054, which uses the exact same FPGA and CPU as your board. Despite the fact that I have not managed to conclusively identify the cause and solution, I had some success with using custom implementation strategy. Options shown below sometimes result in successful compilations.