Continuously passing values up from running FPGA subVI

[maherhome]

Hi,

We want to have multiple FPGA subVIs running simultaneously (imagine waveform generators) and be able to pass data in and out.

Below is a simplified model of what we want to do.  The top main VI (above) tries to get data from the running sub VI (below).   The subVI runs (and updates its indicator) but the 'x + 1' indicator in the main VI is never updated.  I understand the general model is a sub VI must finish before the data is passed up, but I expect (hope) there's a way around this.  I tried passing a (static) control RefNum for the "x+1" control to the sub VI but got an error ('not supported on FPGA target').  I don't want to pass data using queues or other buffering mechanism (I'll get into that if you want).

How do I achieve this?

Thanks,

Steve

[crossrulz]

Use feedback nodes to store your data in the FGV.  The value will update each time the subVI is ran.  The idea is to get away from constantly running while loops in the subVIs.  Your only other option is FIFOs.

[srm@viewpointusa.com]

if your sub-vis are designed as you describe then the effect you want can't happen the way you have it coded.

Either the sub-vi needs to execute one iteration of its execution and return or the generator VIs need to be in parallel.

if they are running in parallel, you can exchange data via globals, fifos or memory.

[maherhome]

I'm afraid my simple model misled you.  I know in this particular case yes, the best/easy solution is removing the loop in the subVI, having it perform an operation and returning the result to the mainVI, and have the mainVI keep track of state (eg., the previous value using a feedback node).  (What is FGV?)

However, my actual subVI is much more complicated.  It is continuously monitoring a 5 MHz digital signal and uses 4 or 5 feedback nodes to store "state".  I only need one piece of information returned back to the mainVI (the "state" is used to generate the results).  I plan to use an Occurance to signal the data is valid (that part works and was more difficult - I thought passing the basic data would be easy!).  Our system will be large and I want to compartmentalize this logic and not mess up the mainVI.  Is there really no other way to return this info?  I know global vars are frowned upon but there will be only one writer (and multiple readers).  Are they a reasonable solution here?

I'm intrigued by your comment of removing while loops from subVIs.  I come from the software engineering world and I think I need a paradigm shift.  I, perhaps naively, saw the FPGA as a zillion (cpu) cores - or threads - at my disposal.  I imagine dozens or hundreds of while loops running simultaneously - each in their own subVI.  If I instead imagine wires spreading data across a wide expanse of nodes - all being executed simultaneously - (is this the "combinatorial" view I hear about?) perhaps surrounded by a single while loop, then I envision a big rat's nest with hundreds of feedback nodes on the big while loop retaiing my state.  Terrible modularity and difficult to understand.   Can someone perhaps point me to a large, well-modularized project for an example?

Thanks,

Steve

[BillTür]

I think your best shot in this case are FIFOs.

[maherhome]

Well, I used a (target-scoped) "FPGA Memory" and it works beautifully.  The subVI writes and the mainVI (and future subVIs) reads.  I understand I'll have to coordinate things; I'm using Occurrances to do that.  Any caveats?

This is a nice link: https://www.ni.com/docs/en-US/bundle/labview-fpga-module/page/storing-data-on-an-fpga-target-fpga-mo...

[BillTür]

If you want to use block memory in single-cycle timed loops make sure you don't write the same time you read. You can use occurences so that's fine.
In addition, block memory is not the fastest read/write method out there so frequencies over 200 MHz might be a problem.
Should you have LabVIEW 2012 you might want to take a look at registers. Although I think block memory is a good choice, too. I have been using them for quite some time now and they seem trustworthy enough 😉

[maherhome]

"frequencies over 200 MHz might be a problem"

Was that a typo or is there a much faster NI device I'm not aware of?  My cRIO hums along at 40 MHz..

I stumbled on registers in my research; I will look at them more closely.

Thanks,

Steve

[srm@viewpointusa.com]

There are some paradigm shifts that happen when using LabVIEW FPGA.  What are acceptable (even suggested) practices in FPGA are different in FPGA than in LabVIEW.  For example, local variables are used extensively in FPGA by necessity.  

2012 registers will probably address this need and become the recommended practice.

Optimizing for space on an FPGA will also cause you to code your solution very differently than high level LabVIEW.

you will end up using a lot of feedback nodes etc in FPGA solutions.  at lease we do.

We end up with several parallel loops (< 20) in a typical FPGA app.  not 100's.  they communicate via locals, globals, fifos and use semiphores.

you are on the right track.

[BillTür]

cRIOs are capable of higher frequencies, as far as I know they go up to 400 MHz. You can add a derived clock by right-clicking the existing clock and clicking "new derived clock" or something like that. You can then select this clock for SCTLs.