FPGA VIs Launch Parallel Loops

[tcapuano-aps]

Hey,

I am trying to figure out a method to nicely organize my FPGA VI's parallel loops, while still having access to all of the controls and indicators. Ideally each loop would be completely contained in a subVI, but this results in not having access to the C&Is.

On Windows, you can pass in a reference to the controls and indicators and have everything work out.

Has anyone come up with a solution to this problem?

Thanks,

Tom

[Terry_ALE]

In my experiences and in the advanced FPGA VIs that I have seen from NI the loop is not in a subVI.  The DSP/logic is in a subVI.

[Bob_Schor]

Having coming to FPGA after a decade (or more) of non-FPGA LabVIEW, it was a real shock!  Almost everything is a Parallel Loop!

My current FPGA routine is largely a mass of While Loops, each with "F" wired to the Stop indicator (so it is a "Run Forever" (parallel) loop.  Most of them are coded to "Do something" when the User sets a Boolean (in the FPGA's "Host").  For instance, one Loop handles SPI Write.  The Host sets the number of SPI Bits being sent (typically 8, but can be as many as 32), and the number of Data Bits (passed as a 32-bit Array of Booleans), then sets a boolean "SPI Write" to True.  The SPI Write While Loop has a Case Statement with SPI Write wired to the Case Selector.  The False Case is empty, but the True Case has a Sequence Structure (another paradox -- Sequence Structures are your Friend in FPGA-Land) that includes a For Loop that takes the Array of Data Bits and sequentially sends them to MOSI (and runs SCLK).  When all the bits are sent, SPI Write is reset to False and the Case Statement ends, returning us to waiting for SPI Write to be set True again by the Host.

Other Loops handle SPI Chips running A/D converters, DIO lines creating Digital Waveforms, and other Parallel Tasks, each in its own While Loop, most with a "controlling" Case Structure to "do this when I set the Case Input to True, resetting it to False when done".

Bob Schor

[tcapuano-aps]

Thanks everyone for your replies.

It just feels dirty having one massive diagram with a bunch a loops with a bunch of controls & indicators. It seems very unmaintainable. 

What are your thoughts on using VI defined registers to communicate into loops using their reference wire and handling all the Controls and indicators in a massive "UI" loop. I have a feeling that this would be even more unmaintainable.

Currently, I have a subVI in my project that is just a template that needs to be copied and pasted into my main diagram when it is changed.

Regards,

Tom

[Terry_ALE]

When first working with LabVIEW FPGA I too observed many parallel loops and my code also had many loops. https://www.ni.com/en-us/support/documentation/supplemental/13/the-ni-labview-high-performance-fpga-... has a good rundown on when to make a new loop (see page 75).

Too many loops can add to complexity without benefits.  These days we look to make new loops only if it is really needed.  The extra loops may force data transfer functions which add to latency.

Code bases which process multiple gigabytes per second (see https://forums.ni.com/t5/Examples-and-IP-for-Software/Aurora-64b-66b-Streaming-Example-for-the-PXIe-...) can do this in one or two loops.

@tcapuano-aps how many controls and indicators are we talking about?  I assume you have grouped things into clusters.

[tcapuano-aps]

Hi Terry,

I am working on a cRIO control system, not anything as performant as a GigE FPGA.

My goal behind the Controls and Indicators are to create a set of singleton libraries with Host Classes and FPGA VIs that abstract away the communications. This would be done through dynamic FPGA references and controls and indicators with pre defined magic names. I just need a method to managing these magic names. So my through was just to wrap everything up in subVIs, so nobody messes with the names at the top level.

I am only planning on running 2 clock domains, but the 4-5 subsystems are decoupled enough that they don't actually need to be in the same loop.

Thanks again for all your comments.

Regards,

Tom

[drjdpowell]

---

@tcapuano-aps wrote:

I am trying to figure out a method to nicely organize my FPGA VI's parallel loops, while still having access to all of the controls and indicators. Ideally each loop would be completely contained in a subVI, but this results in not having access to the C&Is.

---

I also noticed this weakness with LabVIEW FPGA.  

[Terry_ALE]

@justtcapuano-aps check out the Instruction Framework: https://zone.ni.com/reference/en-XX/help/372614J-01/target5devicehelp/idl_instfwk_overview/

It is meant to support this kind of thing. We have held off on using it because of the following issues:

My issues related to host interfacing have been posted:

https://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Instruction-Framework-simulation-mode-support/id...

https://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Instruction-Framework-examples-for-modular-devel...

https://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/LabVIEW-FPGA-Host-Interface/idi-p/4143746

I know that the VST2 FPGA (5840 etc) uses the Instruction Framework this so my guess is that it is a matter of more documentation.  The IFW tutorial is good but does not cover the modular approach.

[tcapuano-aps]

Hi Terry,

This is exactly was I was looking for. Thanks for letting me know the short comings up front. I think I will avoid it until it gets a little more mature.

-Tom

[Intaris]

---

@tcapuano-aps wrote:

What are your thoughts on using VI defined registers to communicate into loops using their reference wire and handling all the Controls and indicators in a massive "UI" loop. I have a feeling that this would be even more unmaintainable.

---

VI-defined registers are a decent solution to this. Passing in a reference to a sub-VI allows you to decouple the "UI" from the core functionality. It also has the great benefit of allowing instantiation of multiple sub-VIs for side-by-side testing.

I also use registers as debug indicators a lot. If I wire them in, they can be monitored in a debug VI, if I don't wire them, the code associated with that pathway gets compiled out of existence.