Subtle trap I fell into with arrays in LabVIEW FPGA

[SuperDuperCooper]

Hi

Just reporting a problem I made for myself, where the LabVIEW IDE would allow me start FPGA compilation, but the Xilinx compiler would return an error.

I had created a FOR loop with 2 auto-indexed input arrays. One was a fixed length - no problem. The other was an output array from the FOR loop looped back through a feedback node as an input to the same FOR loop. Inspecting the wire it was not of fixed length. From the Xilinx error message, I think the array was being used before being instantiated - no default value.

The error had the phrase "formal <array_in> has no actual or default value".

The solution was to explicitly index the second array inside the FOR loop with 'index array'. Defining the number of iterations of the FOR may also have worked, and would save on FPGA resources.

Hopefully this helps someone in the future,

Cheers

[Dragis]

Can you post a VI snippet of your code? This sounds like it is a bug with the LabVIEW FPGA module as you should rarely get an error from Xilinx for something that is semantically invalid; the LabVIEW compiler should catch those things.

[crossrulz]

It might have also worked to globally initialize the feedback node.  The initialization array would have to be fixed size, forcing the data on the feedback node to be of fixed size.  You could likely be able to autoindex then.

[T-REX$]

What version of LabVIEW are you in? I tried to create a reproducing case, but couldn't get it to fail working from your description:

Any tips so I can move forward with the bug report would be appreciated 🙂

[ToeCutter]

Kudos all round- OP for sharing a tip, the rest of you for efforts to ID the problem with regard to potential LabVIEW bug fixes.

[SuperDuperCooper]

LV 2013 Full dev system v13.0, Win XP SP3, FPGA 2013

That diagram is almost exactly right. Sorry I can neither extract nor publish a clip.

Only differences are:

- the input array is fixed size, 2 elements, FXP <+/-, 16, 2>

- the output and feedback arrays are FXP <+/-, 18, 4>

- the input array sits within the while loop

Almost certainly not important but:

- In place of the increment & decrement blocks there are subVIs.

- these also have boolean controls on/off controls via a loop tunnel.

- the feedback node points the other way

- the feedback node implementation was set to 'auto'

[T-REX$]

Looks like I found a very simple reproducing case, just FYI for anyone seeing this in the future. It looks to be reated to the following design pattern (simplest case I could come up with):

Note the coercion dot!

I would also like to note that the following compiles just fine (the only difference is the diagram disable structure - feedback node is still enabled).

Also, removing the subVI, and replacing it with the contained code (a simple add in my case) compiled just fine.

I filed the bug report as CAR# 456271.

[T-REX$]

I'd also like to point out that the failure isn't specific to FXP types, as this also fails: