LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FPGA - Control wired to the count (N) terminal of a for loop

Is it a limitation of LabVIEW FPGA that does not allow you to wire a control to the count (N) terminal of a for loop?

 

When I wire a control to the count terminal of a for loop, the VI is broken. When I wire a constant to the count terminal of the same for loop, all is well.

 

I would really like to be able to control how many times the loop is run. Does anyone know of a way around this?

0 Kudos
Message 1 of 6
(2,475 Views)

Is the FOR loop building an array?  Remember that all arrays in FPGA must be fixed in size.  So if you are building an array with the autoindexing tunnel of a FOR loop, then the loop has to run a fixed number of times.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 6
(2,472 Views)

Crossrulz is correct.

If you place a control on the N input of an empty for loop you will see the VI is able to compile.  Now bring the iteration counter to the other side of the loop and create an auto-indexing array, you will see that the VI is broken since it cannot create a non fixed size array.  You can output the last value of your "dynamic iteration loop" but that will probably not solve your issue.  By changing the N input control to a constant and you have see the VI is no longer broken.

 

Maybe some more info on what you are trying to do will help think of another solution.

 

Best,


Adam Tishman

0 Kudos
Message 3 of 6
(2,463 Views)

Thanks for the replies crossrulz and A_Tish.

 

I overlooked the fact that arrays have to have a fixed size on the FPGA. Before, I had a control wired to the count terminal of thr FOR loop and used the auto-index feeature to output an array of variable size. It's now obvious to me why this cannot work. Here's a snippet showing the incorrect method I was trying to use:

 

 

That being said, what I would like to do is read a controllable amount of data from a FIFO. The loop that is writing to the FIFO is writing a variable amount of nibbles that form a full packet. The number of nibbles per packet is what I would like to have controllable.

 

I could either combine the nibbles into a single packet before writing them to the FIFO, read the FIFO once, and then split the data back up, or find a way to read a variable amount of nibbles to form a full packet. I would rather not combine the nibbles just to send them through the FIFO and then seperate them again after they are read.

 

Does anyone know of the best way to do this?

0 Kudos
Message 4 of 6
(2,445 Views)

Who's reading the Nibble Array terminal in that image?  Is it the output of a subVI, or is it a front-panel terminal on the top-level VI that is being read by a host VI?

 

If it's the host that reads it, use a DMA FIFO instead.  If that's not an option, instead of making the indicator an array, make it a single element and add a boolean for handshaking.  The host sets the boolean true, which causes the FPGA VI to read an item from the FIFO and write it to the element indicator.  It then sets the boolean to false.  When the host sees that the boolean is false, it reads the element indicator.  Repeat as many times as necessary.

 

If you're doing this inside a subVI, I'd have to see more of the entire structure of the FPGA code to suggest how you could work around it.

0 Kudos
Message 5 of 6
(2,441 Views)

I like the DMA FIFO option as well (again if available). 

Maybe another method you could do is simply first write the length of the nibble, then the nibble.  On the other side read in the length (1 element) and then have another FIFO read that has pulls out the nibble.  This simply requires the read to not get so far behind that the FIFO overflows but hopefully that is not an issue.  You also will not lose a packet this way (I think!).

 

Not anywhere near a development computer to create an example and as Nathan suggested still more info is needed for the best approach, but I think you have an idea of what can be done. 

 

Is the packet so dyanmic that building multiple nibbles and parsing on the other side is not effective?  Just a question.

Best,


Adam

0 Kudos
Message 6 of 6
(2,436 Views)