For Loop within Single Cyle Timed Loop

[Alex.T]

In current versions of LabVIEW FPGA, placing a For Loop inside an SCTL will result in code that cannot be compiled; this is because conventially For Loops work iteratively and therefore require multiple clock signals to drive each new iteration.

However, I think a logical implementation of a For Loop within an SCTL would be the generation of multiple parallelised instances of whatever code is inside the For Loop. This would greatly improve readability and flexibility by avoiding the user having to manually create multiple separate instances of the same critical code on the Block Diagram.

This would require the For Loop to execute a known maximum number of times.

[Manzolli]

Like the idea. A unremovable [P] terminal should automatically be placed in the loop making clear that it will only run in parallel mode. Kudos!

[brooksprumo]

A for loop _can_ be placed inside a SCTL if the input is a fixed-size (just as you suggested, Alex).  Here's an FPGA VI snippet that compiles just fine for me with LV FPGA 2012:

It's worth noting that I've set the array as a fixed size in its properties.  Without doing this, the VI will not compile.

[Alex.T]

I'm a little unsure about that example. I can't test at the moment because I'm not on my development machine, but I think there's a considerable chance that the diagram you've presented may be reduced at the compilation stage. Can you confirm that it results in separate concurrent VHDL instantiations for each iteration? Array constants were used in the example images but that was supposed to exaggerate fixed array lengths. In application, this input array would expect to have its child elements change; this would allow very little for the compilation stage to streamline. To demonstrate what I mean, you can place a Quotient & Remainder within an SCTL provided its inputs are constant, and have it compile successfully. However, we know a divide operation takes multiple clocks. The compiler is clever enough to avoid the instantiation of the divider if it can be avoided; I fear the same might be true for your example.

[brooksprumo]

Since the for-loop is insde a SCTL, it is executing all four `+1`s in parallel by instantiating four copies of the logic, just as you suspected.  However, not all the nodes are supported; some unsupported nodes include `divide` and `quotient & remainder`, also as you suspected.

[Manzolli]

@brooksprumo: Your example works fine when the vector constant is used only in one place. If that constant is used in several places, the idea is still valid, because it should be placed outside the loop.

[James_McN]

I had a similar idea, http://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Allow-Parallel-For-Loops-on-FPGA/idi-p/1599930

I need to try this, didn't think it was supported at all!

[James_McN]

Wow works! (in 2012) I have no idea when this was implemented but very happy that it has!

Although I do see what probably scuppered me before, no flip flops allowed. This would suggest something funny about the way it is implemented, if it was truely parallel theres not reason you shouldn't be able to save state. Will try pushing it and see what happens.

[Dragis]

LabVIEW FPGA 2012 introduced limited support for For Loops in the SCL. The compiler will only allow operations that are purely functional (i.e. no state, side effects, etc.) and can complete in a single cycle. It does not (yet) support subVI calls that would fall into this category. Shift registers (and loop init feedback nodes) are also not currently supported.

These limitations are required because the For Loop semantics require the compiler to complete all iterations of the For Loop in a single-cycle and produce identical results as though the loop iterations ran sequentially. In compiler terminology, this is implemented using loop unrolling. Unrolling a loop with shift registers would introduce a long sequential line of combinatorial logic and is one reason LabVIEW FPGA does not yet support them.

With these limitations, I think the idea should remain open as not yet implemented. However, it would be good to see real, tangible examples of what unsupported scenarios should be supported to help prioritize what features get implemented.

[EricLM]

While for loops are now supported inside SCTLs, they lack some of the basic support for bit manipulation and unsupported elements do not result in a broken run arrow. Instead you don't find out until compile that they are not supported.