LabVIEW
fpga : timing a loop
Hello zermelo,
In your first example all you need to change is to wire the tick count value directly to the shift register. Instead you have the output of the subtraction wired to the shift register. See the attached example. Notice that the output of the loop timer is the same as the tick count.
Unless you use some shared resources in your loop, the execution time of the loop should always be exactly as the time you specify on the loop timer, assuming the rest of your code does not take more time to run.
With regards to the timed loop, in LV FPGA the Single Cycle Timed Loop (SCTL) always executes in one clock cycle of the clock that you specify for the SCTL. by defualt thi is the 40 MHz FPGA clock, but LabVIEW does allow you to create derived clocks in your project with different clock frequencies which you can use as the source of the SCTL.
Message Edited by Christian L on 11-17-2006 09:37 AM
zermelo-
Timing can often be difficult to get right. One trick I use to figure timing out is to "unroll" the while loop. This means thinking about what happens in a stretch of 4 or 5 iterations rather than a single iteration. This often helps me better understand the results I'm getting.
Let's talk about your first example - the tick count and the loop timer are both going to begin executing at the same time. The tick counter returns immediately while the loop timer returns at the next interval of ticks**. So if we look at the way your code will execute. If FPGA Period TIcks is 1000, and tolerance is 50 you will get the following:
First iteration (Always a special case) - Shift register is uninitialized, so unknown value will be there. Tick count and loop timer return immediately. Tick count is going to be some random number as well (Lets say 300 for this example) . 300 - Random number - 1000 = Random number which may be greater or less then 50, so random time fault boolean.
Second iteration: Shift register now has 300. Loop timer will return 1000 ticks later than it did on the first iteration (tick count 1300). Tick count, though, again returns immediately, because loop timer returned immediately on the first iteration**, our tick count is now going to be ~304***. So, now we have 304 - 300 - 1000 = 4294966300 - U32 is an unsigned integer, so you get roll-over. Time fault is TRUE even though you loop only really took 4 ticks to execute.
Third iteration: Shift Register is 304. Loop timer returns 1000 ticks later (tick count 2300). Tick cound returns immediately, this time it is 1304 because the loop timer took 1000 ticks to complete (like it should). 1304 - 304 - 1000 = 0. Time Fault is FALSE. FInally what we expected... 🙂
OK. All following iterations should be the same, because your code is deterministic. Now lets throw in your Code in that second frame. If your code ALWAYS runs in the same amount of time you are still deterministic, and things should continue to work. If your code is not deterministic, things are going to behave weirdly. Here's why: The tick count always returns as soon as the loop begins. The loop begins right after it finishes, and it finishes whenever your code finishes. So tick count is really dependent on how long your code takes to execute rather than how fast the loop is running (In the image, down arrows are when loop timer returns, up arrows are when tick cound returns):
How to fix the problem: You need to measure tick count after loop timer returns and before your code executes. The simplest way to do that is to read the tick count from the output of the loop timer. You should also be careful with U32 math and watch out for rollovers. I would recommend adding your tolerance to your period tick and then comparing your calculated rate to that. This avoids the roll over problem assuming your tick count + tolerance is less then 2^32. One final note, the boolean for fault tolerance may blink on and off very quickly, if you are right on the edge. You might consider latching the boolean value so it stays TRUE once it has been true once.
Sorry for the long post, but I hope understanding your code a little better will help make you a better programmer in the long run. One final help 🙂 I have attached a VI I used in one of our shipping products (FPGA Wizard) to monitor the loop rate. If you drop it in the same frame as your code, it should do the job for you (note this is only available in 8.20).
**Note the first time loop timer is run it returns immediately because it is just setting a starting point. The next time it is run, it will return the specified number of ticks after the first time it was run.
*** There is a small overhead for running a loop, to avoid this you need to run a Single Cycle TImed Loop
Message Edited by Dustin W on 11-17-2006 09:52 AM
