|
|||||||||||||
Problem:
Auto-Indexing of LabVIEW is extended to LabVIEW FPGA, only with one small caveat. You can easily auto-index into a loop, but not out of it. You will understand this better if you've already worked with LV FPGA.
In the FPGA paradigm, we enforce compile time resource determinism, by making sure all our arrays are of a fixed pre-determined size. In auto-indexing out of a loop, we may not know what the size of the array is, and hence it breaks the VI with the error "Arrays must be of fixed size". Try to write the following code in LV FPGA, for a better picture:
Solution:
The current workaround is that we have a fixed size Array which we then use in and out of the loop, replacing its
elements, as shown below.
However, an easier and much much more intuitive solution for users would be to just right click the auto-indexed tunnel and set the dimension size.
This definitely means that the number of data flowing out of the loop could be more than our fixed size. We handle that case by providing the user with the "In case of overflow" option.
This would ease our effort in coding LV FPGA as much as it would would improve intuitive coding. Vote for this idea if you think it would make your life a tad bit easier.
As a compiler guy, I like the idea. As a user, I can't say that I've had the need of this feature very often (if ever). Can you give a few examples of where you've needed this behavior? My guess is that the useful out-of-bounds behavior could include more things than just throw away the oldest or newest values, but maybe not. I'm on the fence right now, but I could be easily swayed for a Kudo with a bit more info : )
A user is faced with this situation everytime he collects data out of a loop. He is forced to use an existing array and modify it instead of using the auto-index option. Does that answer your question?
People collect data coming out of loops all the time, they just use a For Loop instead of a While Loop. I'm curious what particular cases can only be solved (elegantly?) with a While Loop, or even perhaps a For Loop with the Stop Condition shown.
Hi Dragis!
Right now I once again came across a situation where I need exact this feature in order to code elegantly. In FPGA there are SCTLs. An SCTL basically is a while loop with higher performance. There is no such high performance version of a while loop. A SCTL can use an input auto index tunnel. This is good. In LV2012 is is even possible to code an output auto index tunnel with enable terminal, which is fantastic, because it allows for an elegant way to code a very hardware efficient construct - only the compiler throws an error "only fixed size allowed...". Bummer. Sure it is possible to clumsily code around this problem and achieve the same thing with two times the block diagram, but I prefere elegant code from clumsy code. The meanest thing is the trap that the editor allows the user to first code the elegant way and only later sais "Sorry guy, make your code ugly...". I hate it.
Now the technical side. Sure an output index tunnel is meant to be dynamic in output size. But an array is, too. LV offers the solution for arrays by allowing them to be defined fixed size or limited size. Why not exactly the same way for output index tunnels? I dont see that this would be any violation of a paradigm.
For the implementation: A output index tunnel with enable terminal in an SCTL would be extremely efficient and handy whenever you want to use the power of SCTL to save FPGA space by increasing the number of loop iterations. Oftenly you can save multiplexers (case structures) by routing calculation results to many feedback nodes (or index tunnels) and use the enable terminals to disable all flipflops but the one who is meant to store the result of the current iteration. The current coding limitation just leads to code with case structures, which in turn waste multiplexers.
So you are right that in a non FPGA environment the for loop would be the solution, but inside an FPGA it's not. With FPGA we sometimes win greatly with fixed size output index tunnels with enable terminals.
Regards, RalfO
You must be a registered user to add a comment here. If you've already registered, please log in. If you haven't registered yet, please register and log in.
My Profile | Privacy |
Legal |
Contact NI
© 2011 National Instruments Corporation. All rights reserved. | E-Mail this Page
|
||

E-Mail this Page