LabVIEW FPGA Idea Exchange

About LabVIEW FPGA Idea Exchange

Have a LabVIEW FPGA Idea?

  1. Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
  2. Browse by label or search in the LabVIEW FPGA Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  3. If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW FPGA Idea Exchange. Be sure to submit a separate post for each idea.
  4. Watch as the community gives your idea kudos and adds their input.
  5. As NI R&D considers the idea, they will change the idea status.
  6. Give kudos to other ideas that you would like to see in a future version of LabVIEW FPGA!
Top Kudoed Authors
User Kudos Count
Showing results for 
Search instead for 
Did you mean: 

Enable Auto Indexing for LabVIEW FPGA


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:

Auto-Indexing LV FPGA



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.

Auto-Index Pop 


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.

Prashanth N
National Instruments
Active Participant

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?

Prashanth N
National Instruments
Active Participant

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


Active Participant

A picture is worth a thousand words. The following is from a real project.


Here's what I originally wrote:

FPGA Loop Yay.png


Here's what I was forced to write, after I realized my code won't compile:

FPGA Loop Ouch.png

Certified LabVIEW Developer

Knight of NI

JKSH, I don't see how that shows the issue of needing to autoindex out of While loops.  What you show looks like an issue with the Parallel FOR Loop.


EDIT:  Just a thought.  What would happen if you wired up the P?  By default, LabVIEW finds the number of parallel loops using the number of logical processors.  And FPGA does not have any processors.  So if you specified the number of parallel loops, would it work the way you want?

There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

The discussions from the Advanced User Track is not over. Join in the conversation: 2016 Advanced Users Track
Active Participant

The FPGA compiler does allow unrolling of loops containing state-less algorithms (e.g. clouds of logic with no feedback nodes, shift registers, etc.). However, it currently does not support unrolling loops containing VI calls which is what the example @JKSH shows above. That can certainly be made to work, it just hasn't been implemented. That feature would be a good candidate for the idea exchange on its own.

Active Participant
Oops... *feels sheepish*. You're right, my issue was a different one. I had left a (obviously mistaken) comment in my code last year complaining that auto-indexed for-loops weren't supported, and posted this without re-checking first. Anyway, I've found a very similar idea at . Dragis, would you still like me to post a new one? Or add to the linked idea?

Certified LabVIEW Developer