FPGA - SCTL programmed with derived clocks doesn't meet the required time

[Sicitronic]

Hello,

I have problems with SCTL programmed with derived clocks slower than the onboard clock (40MHz). Specifically, if I program the SCTL with a 5MHz or 10MHz derived clock, the application takes more than the expected ticks on execute the portion of code (you can see it on the attached pictures).

I have check it in various LabVIEW versions (2017 and 2019) and in various targets (cRIO-9049, sbRIO-9607 and sbRIO-9609) with the same result on all the tests.

 

Can you confirm you have the same strange behaviour? Have tou ever experiment the same issue?

Thanks for your help!

[benjamin-hinrichs]

I have used the 5MHz SCTL in the past when I had many cascaded sums that were taking more time than allowed by 40MHz SCTL.

My guess is that what you're seeing in 40MHz case is a compiler optimization: since you're not doing anything with the SCTL, the compiler may be removing it completely. I was stunned to find for loops with 1.000.000 iterations reduced to constants by the compiler (I was trying to benchmark that and was outsmarted by the compiler).

Try removing the 40MHz SCTL from your code and benchmark just the two remaining frames of sequence structure. I'd wager you'll see 1 tick as well. I'd also wager this SCTL compiler optimisation wasn't done for derived clocks or non-main-clocks (maybe it can't be done or doesn't make sense).

[Sicitronic]

Hi, the problem is with the 5MHZ SCTL. It takes 96 ticks when the expected ticks are 8 (40MHz/5MHz). The 40MHz (as main clock) SCTL behaviour is correct.

I tested the behaviour with and without code inside the SCTL with the same results. The pictures are without code to be more clear.

I have checked that the problem is extensible also to SCTL programmed with derived clocks faster than the main clock.

I suspect that is something related to clocks alignment between code portion synchronized with the the main clock and the rest, but it is not documented by NI.