FPGA Array of I/O References

[Hooovahh]

I have some code I need to perform on an I/O resource on the FPGA.  I need to perform this same code for several I/O resources.  So I thought I would be clever and create an array of references, (set array size of course) and then iterate over the array performing my code.  The problem with this is I get an error causing a broken arrow.  The error is Possibility of Dynamic Refnum not supported for the current target.  It states that Refnums must be constant references.  Looking at my code my reference are a constant.  I also tried taking the array of references into the for loop, and indexing them but this also caused the same error.

Why can I not index an array of I/O references? which are a constant?  Is it because I could potentially perform a replace array element, and now my I/O Item will be performed on another resource?  

At the moment the work around is to create 10 reference constants, and pass them into the for loop one at a time (similar to the case structure and booleans).  Thanks.

EDIT:  Actually my "work around" doesn't work either because the input still changes.  So I guess I'll need to duplicate my code in 10 places, unless anyone has any suggestion.

[Dragis]

Unfortunately this use case is not supported by LabVIEW FPGA (yet). Clusters of reference constants are supported if that makes the code cleaner as you pass values around. The compiler will not currently unroll a loop that has method or property nodes in it, so unfortunately your best bet right now is to put that code in a separate VI and then instantiate N copies of it for each reference/boolean array pair.

[GregFreeman]

One additional issue is that if you wire a control up to an IO node and set its value from the RT (ala a config file) the FPGA will not take it. I understand why this is difficult, you are essentially trying to dynamically change something that is already compiled which requires a change to the FPGAs instructions, but it should really result in a broken run arrow or not even allow the user to "set" the IO reference from RT. This caused a huge headache for me when learning FPGA and trying to understand why my config file wouldn't work.Now it's not a big deal becaues I know to just explicitly set the IO nodes channel, but I definitely think things like this being caught at compile time would make the IDE more user friendly.

[crossrulz]

This is the point at which I learned that FPGA development is not really software.  At my previous employer, there was a religious war about VHDL being hardware, not software.  I was on the side of it being software.  You edit it with a freakin' text file after all.  After doing LV FPGA, I sided with the VHDL people.  All the tricks I did in software to make coding so much easier was thrown out the window.  And you have to worry about how many processes you perform.  What the heck?  As an aside, there was a compromise out of the crusades by calling FPGA code "firmware".

[GregFreeman]

---

@crossrulz wrote:

  As an aside, there was a compromise out of the crusades by calling FPGA code "firmware".

---

I have seen this debated in many places also! All I know is, I don't know as much about low level computing as I thought, and that lack of knowledge was greatly exposed when using FPGA. Power of 2 for multiplication?! Fixed point numbers?! Bit Shifts!? WHAT!

[crossrulz]

---

for(imstuck) wrote:

I have seen this debated in many places also! All I know is, I don't know as much about low level computing as I thought, and that lack of knowledge was greatly exposed when using FPGA. Power of 2 for multiplication?! Fixed point numbers?! Bit Shifts!? WHAT!

---

Bit shifts and power of 2 didn't bother me at all.  I had been doing that in software for many years because of the way the VHDL programmers put messages together.  They can't waste any bits, so parameters are going across bytes and portions of bytes and all kinds of messes.  Nothing but a nightmare for those of us who only recieve bytes and can only work at the byte level (without jumping through hoops).