FPGA Horribly Simple Error-Producing Code (-61003)

[ForrestBarnes]

Can anyone tell me why this piece of code produces error -61003?

I am trying to write some code for a new FPGA, and the bothersome thing won't compile. This particular piece of code has absolutely nothing to do with the project, but it is the most simple code that produces the same error when I try to compile it. I have two theories about why it won't compile: 1. the FPGA physically can't shuttle data around in the manner I would like 2. I've found an edge case that the compiler isn't prepared to deal with. If there is a simple reason for this error that I can work around, please let me know. This is by far the worst time I have ever had trying to find the source of an error.

To attain error: download both files into the same directory, open FPGA2.lvproj, expand FPGA Target, expand Build Specifications (under FPGA Target), right click WhyDoesThisError, select Build.

[altenbach]

Sorry, I don't have access to the relevant tools, but what is the VI supposed to do ("shufle data around"?)

What is the point of the array with one element? The FOR loop? Why the data mismatch (I32 vs I16), etc.

It seems to me that the data in the array is never used anywhere.

Can you explain what you are trying to do?

[ForrestBarnes]

I guess ths question is more scientific than anything. The full project is here: https://github.com/IMPACT-Boulder/Accelerator/tree/Forrest_Branch/Device%20IO/FPGA2. The point of the rest of the code (which I did not include for clarity's sake) is to control which particles are allowed through a voltage gate on a dust particle accelerator.

My question is: why does this produce an error? In my real code, the only solution I've found requires replacing the for loop with 7 separate instances of the same code. I think that's unacceptable, unscaleable and unclean, so I at least want to know why I have to do it, if I really have to do it. If I can't compile code for an FPGA that runs n instances of the same code in parallel without manually copying that code n times in the vi... that's just horrible. Even if the only solution is to get rid of the for loop, I want to know whether it won't compile because the FPGA can't do it, or because the compiler is stupid.

[altenbach]

Well, the error is

"LabVIEW FPGA:  You cannot include this function in a For Loop when the For Loop is inside a single-cycle Timed Loop."

As you can read here, you cannot have certain structures and functions inside a SCTL,

(I won't sort through huge github hierarchies just to find the original code without really knowing where to look. My participation also reduces when the post contains too many loaded words (horribly, unacceptable, unscaleable and unclean, stupid, etc.). IThey tend to obscure the real issues.)

[ForrestBarnes]

I understand why you wouldn't want to search through a github unaided and I apologize for my previously loaded language.

Then why will this compile perfectly?

[altenbach]

Sorry, I cannont test because I don't have the hardware, but yes both VIs should work as long as you adhere to the limits of the single cycle loop.

(I guess the FOR loop whould get unrolled and parallelized....)

I'll try to do some test tomorrow, but maybe somebody from NI should look into it.

[JLewis]

I'd guess the local variable is the problem, rather than the loop. It implies arbitration to a shared resource, which is not supported in the SCTL. You can use a Register or FIFO to accomplish the inter-loop communication.

[ForrestBarnes]

Thank you for the suggestion JLewis, but it appears to make no difference if it's a variable or a register.

[JLewis · Accepted solution]

That's what I get for guessing. The arbitration thing applies to multiple accessors within the same loop.

What seems to work on my machine is getting rid of the coercion dot on the case structure output tunnel. It looks like loop unrolling analysis is getting tripped up by its presence, possibly in conjunction with the selector being sourced by a control (?).  This sounds like a bug to me, since your other VI works. At the very least it needs a better error message. If you can verify that you're seeing the same thing, I'll file a corrective action request on it.

Jim

[ForrestBarnes]

Thank you so much. It was, indeed, the coercion dot. Once I got rid of all those in my original code, it worked perfectly.