LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FPGA SCTL clock

Hi,

 

I am using the PXI-7833R. I am trying to compile a piece of code which has a SCTL which runs at 20 MHz instead of the default 40MHz. I tried using a derived 20MHz wired to the SCTL. My code is too slow for a 40MHz SCTL. Any ideas?

 

Thanks.

0 Kudos
Message 1 of 10
(4,296 Views)
Do you get an error while compiling?  Is it also too slow for the 20 Mhz clock?
Regards,

Jeremy_B

Applications Engineer
National Instruments
0 Kudos
Message 2 of 10
(4,259 Views)
Yes. I do get an error while compiling. Just as a sanity check, I tried to compile a very simple code that worked for 40Mhz, but not for the 20MHz. I guess my main problem is how to implement something with SCTL of 20MHz.
0 Kudos
Message 3 of 10
(4,252 Views)

Hey,

 

I have a couple of questions for you.  What version of LabVIEW FPGA are you using?  What error do you get during compilation?  Can you post your VI?  I implemented an empty SCTL running off a 20 Mhz derived clock and it compiled just fine, I'm curious as to why you are getting an error.

Regards,

Jeremy_B

Applications Engineer
National Instruments
0 Kudos
Message 4 of 10
(4,239 Views)

Hi there,

 

I did some tests (with sbRIO-9612, LabVIEW FPGA 8.6) with multiple time domains. When running two identical SCTL in parallel, one loop is clocked by default (40 MHz) while second loop is clocked by derived clock (50 MHz), the result of loop I expecting to be faster is longer turnaround time than for the first loop. This I do not understand. Is it bug or "feature"? I can live with this (workaround it), but any hint is appreciated. Attached is whole project including test file (Tick Counter Test (FPGA).vi).

0 Kudos
Message 5 of 10
(4,121 Views)

Hi,

 

 Are you trying to benchmark the actual loop speed?  The SCTL will always complete in one cycle of the chosen clock, if it cannot, the compilation will fail.  Also, the tick count is returning the current tick of the 40 MHz clock, not the 50 MHz, so you can't really time it that way anyway.

Regards,

Jeremy_B

Applications Engineer
National Instruments
0 Kudos
Message 6 of 10
(4,109 Views)

Hello Jeremy,

 

thank you for the quick response. What you said is true, but my observation is following (if you open my example project I have attached last time it will help):

 

Running 2 identical While Loops in FPGA without any data dependency. Inside While Loops is empty SCTL running one cycle. One SCTL is clocked 40 MHz, the second one 50 MHz. Measuring duration time of one cycle of While Loop lead to the following result:

 

1st While Loop with SCTL on 40 MHz takes 200 nSec

2nd While Loop with SCTL on 50 MHz takes 525 nSec

 

I would expect that 2nd While Loop turnaround time should be shorter comparing to 1st While Loop. Isn't it? Why is it not so? What is the reason for longer turnaround of 2nd While Loop?

 

Thak you for you time in advance

 

Regards

 

    Martin Koutny 

 

 

0 Kudos
Message 7 of 10
(4,098 Views)

Hi,

 

Your assumption makes sense, but there is a problem with it.  You are not just measuring the time of the SCTL, you are measuring the time of the outer while loop as well.  However, you aren't specifying any timing, so the compiler has no idea how fast to make that loop run.  Therefore, it can run it as fast or as slow as it wants.  If you put a loop timing VI in each while loop and set it to something like 10 uS, all three loops will read exactly the same time.  This makes sense because now you are telling the compiler how fast to run the loop, but this still doesn't accomplish your goal.

 

The next problem is that the loop time VI returns the tick count of the 40 MHz clock.  As coded, even if the compiler tried to run the while loops as fast as possible, you would at best see the same time for the 40 MHz and the 50 MHz.  You can't measure something which happens in 20 ns with a clock which ticks every 25 ns.  However, timing over multiple iterations should give you a better idea of whats going on.  See the attached VI, which times 1000 iterations of the SCTL, you'll see the numbers make a bit more sense.

Regards,

Jeremy_B

Applications Engineer
National Instruments
0 Kudos
Message 8 of 10
(4,077 Views)

Hi,

 

thank you for the description and your time again. My original intention was to run code inside the while loop as fast as possible. So then I have to put some parts of the inside while loop code into SCTL to minimize the progress time. Dummy code I have previously presented was only for better understanding of code behaviour. I wanted to measure duration of one cycle of the outside while loop (not only SCTL), because this information is for me important - overall turnaround time. I was surprised with the result.

If the global closk is 40 MHz, so I suppose outside while loops should run at that clock, otherwise there is no determinism, which is for FPGA target pretty bad. If I mention again my example, if 1st loop takes 200 nSec, then the 2nd loop should take less or at least the same (I know that 1 tick = 25 nSec 😉 ) time ~200 nSec (not ~525 nSec!) and 3rd loop should take ~2000 nSec (not ~2750 nSec)...

I tried to put to the while loops loop timer, but the result is still the same (10 uSec loop time is not acceptable for me). So in the worst case, I can stay with the single time domain, so duration of the operations is predictable then.

 

I only wanted to discuss my observations, I have spare solution ready, so please do not spend on that topic so much time.  Thanks again.

 

Martin Koutny 

0 Kudos
Message 9 of 10
(4,065 Views)

Hi,

 

Actually it is deterministic (the rate will always be predictable), it just isn't the rate you wanted.  You need to specify the rate with a loop timer so the compiler knows how much it needs to try to optimize.  

 

How fast do you need to run your loops?  If you need the 50 MHz loop to actually run at that rate, it will need to run outside of a while loop anyway.

Regards,

Jeremy_B

Applications Engineer
National Instruments
0 Kudos
Message 10 of 10
(4,051 Views)