Control in FPGA SCTL - Toplevel vs Subvi

[paulmw]

I have a SCTL (running at a different clock) in a top-level FPGA VI where I read an control value inside the loop and I wanted to refactor to put the SCTL it into a subvi.  However, when I compile I get an error stating that controls can't cross time domains.

Why can controls exist in top level SCTL's but not in subVI's?

The recommended solution to the compile error while in subVI is to:

"Move front panel control or indicator terminals outside the single-cycle Timed Loop. Use a wire to pass data into or out of the loop in the different clock domain."

If I do this, is the control only read once, like in non-FPGA code?  I want this control to come from the host read/write control.  How do I get this down to SCTL's inside subvi's?

[Jimmie_A.]

Hi "paulmw",

Would be valuable if you could share a screenshot of your SCTL code, since right now I am not sure what you are trying to achieve. You wrote that you had a SCTL where you read a control value inside the loop, if you would like to read that value from your top-level VI you would need to transfer data from your subVI to your top-level through block memory FIFOs.

When you have subVIs containing controls and indicators these get optimized i.e. they don't need to serve as a register item anymore between the FPGA and the host and therefor you reduce storage and address logic required.

Hope this helps!

[paulmw]

An SCTL with a control inside is not something requiring a screenshot...

I want to move it from the top level VI into a subVI.  I think your point that controls on top levels get translated into registers is why it works in the top level - i.e. it is reading a register.

I've changed the control to a global and then it works in the subVI, but I could use a register too.

Is it best/better practice to keep SCTL's (or any looping) on the top level VI?  Because I found that the better approach for refactoring this was to make the subVI be the contents of the SCTL (with feedback nodes) and not include the SCTL itself.

[nathand · Accepted solution]

---

@paulmw wrote:

Is it best/better practice to keep SCTL's (or any looping) on the top level VI?  Because I found that the better approach for refactoring this was to make the subVI be the contents of the SCTL (with feedback nodes) and not include the SCTL itself.

---

It depends on what your subVI does, how you would like to modularize your code, whether you'll have multiple instances of the subVI. If the SCTL is a separate task that doesn't need to read from the front panel then I would include the loop in the subVI, especially if you want to run multiple instances of it. Even if it does need to read from the front panel, you might consider a dedicated loop on the main VI that copies values constantly from the front panel into a register, and then using the register in the subVI, both to keep your main VI block diagram cleaner and to keep everything related to that SCTL together in a single VI.

---

@paulmw wrote:

An SCTL with a control inside is not something requiring a screenshot...

---

So, if I've understood correctly, you have a subVI, that contains a single-cycle timed loop, and you are reading a front-panel terminal inside that loop. On the VI that calls that subVI, you have a similar front-panel element, wired to an input of the subVI. Is that correct? On the main VI, is the front panel terminal read in a loop, or read just once? (This is why a screenshot would help.)

In any case, as with standard (non-FPGA) LabVIEW, even if this did compile, you would only read the front panel terminal from the main VI once; then you would enter the subVI - and stay there, due to the SCTL - so the terminal would never get updated with a new value. So moving it out of the SCTL would make no difference.

[paulmw]

Not to make too many excuses but I didn't include screenshots for a couple of reasons...  First, I have experienced people getting caught up in code and going way beyond what the actual question was (while I do appreciate the free code review), I wanted to keep it simple and thought that a screenshot of an SCTL with a control was elementary.  Second, it is not that easy to capture the code.  I don't have web or remote access at the test station that has the FPGA.  Anyway, you both did fine without it.

Nathan, your explanations made things a lot clearer.  Since I've started LabVIEW FPGA, I have been trying to conceive the FPGA hardware behind the LabVIEW code and that for some reason I was bending the LabVIEW code in my mind to fit (if that makes sense).  For some reason I was thinking that the controls inside subVI's of FPGA code would operate different than in normal LabVIEW code.

Anyway, I have taken a couple of screenshots for prosperity sake (I think I am set in my solution).  I don't have the original top level VI but this is what I was trying to make to a subVI.  Notice the global VI's.  Those used to be the controls and indicators that were throwing errors.  Going to globals got me past the error.  But, I had to have a loop that copied the top level to the globals (exactly like Nathan suggested) and I didn't like that too much either (worked but didn't sit right with me for some reason, probably would have kept it if I went with registers).

The second screenshot is my current solution and is the one I will stick with.  The subVI(s) code does not have any loops and is basically the top pic with the loops removed.

[Intaris]

Instead of using globals, think of using VI-defined Registers instead.  Behind-the-scenes it resolves to the same fabric, but you then no longer have a static dependency to your global on disk and the entire sub-VI becomes cloneable. You might feel like this is overkill for now, but it will serve you well in the long run.

Note that is you read a Register item in multiple places, LV will automatically make copies of it for you, just like it does behind the scenes with globals.  To eliminate this, try not to read globals or registers in multiple frames of case structures but read it before and route through.  It saves resources.