Occurrences (on FPGA) with Timeout = 0

[cbutcher]

I want to use an occurrence to stop a SCTL on FPGA based on another loop stopping.

These are both inside a standard While loop (the same loop, in a case structure).

Simulation seems to show a problem similar to that described on a standard desktop VI - the "Generate Occurrence" node creates a single reference regardless of how many times it is called, and then if I set Ignore Previous to "False" I get previous iterations' "Set Occurrence" triggering it, even if I have previously Waited on that occurrence (of the Occurrence).

Is there a good workaround for this?

I can try setting Ignore Previous to True, but then I suspect there exists some potential for timing problems. I don't know if using FPGA provides some improvement here, but I wouldn't bet on it not being a potential "race-like" condition.

A rough outline of the desired VI is below:

Some possible alternatives include a boolean Register or a Local Variable boolean indicator or control, or (more expensively, I think) some sort of VI-scoped FIFO (guess the register is a much better plan).

Can I use Occurrences here? Are they a good tool (and if not, when are they a good tool? Only when timeout != 0 and ignore previous is true?)

[Niatross]

I get similarly frustrated with occurrences when I am trying to do exactly the same as you, trying to stop more than one loop, admittedly only on desktop or RT so I don't know how it behaves on FPGA.

The LabVIEW Wiki was a good source of information on this.

https://labviewwiki.org/wiki/Occurrence

Highlights are, the generate occurrence acts like a constant, a new occurrence is only generated when the vi is unloaded and loaded back into memory.

Despite the problems you have described I still use them for stopping multiple loops by setting the timeout to 0 and ignore previous to false because I think they give you a much neater and space efficient method when compared to queues/notifiers. You have to be careful though.

I have attached a couple of examples.

Edit: I have reread your post, when doing what you are trying to do I would always set ignore previous to false to avoid missing an occurrence. With what you have posted unless you are incredibly lucky and you set the occurence when you were listening it won't work. I sometimes use the timeout of the occurence to time my loop...although I still set ignore previous to false normally 

[Terry_ALE]

There is no real benefit to stopping something on an FPGA.  The circuit or logic is always there so we typically enable (running) or disable (not running) logic.  This should give you similar capabilities.

[cbutcher]

---

@Terry_ALE wrote:

There is no real benefit to stopping something on an FPGA.  The circuit or logic is always there so we typically enable (running) or disable (not running) logic.  This should give you similar capabilities.

---

In this case I need to stop loops because they form the contents of one state in a state machine (whilst nesting their own state machines).

In principle I suppose it is possible to restructure nested state machines to produce a single, outer state machine, but managing parallel execution of two tasks using a single loop would be I suspect an exercise in frustration. As a result, I strongly prefer to use nested state machines in this case.

If I don't stop the loop, I can't go to the next case in the outer state machine.

As an aside, this seems to work problem-free with a Register. But I'm still peeved that this beautifully small icon, designed I would think for a similar task, cannot be used correctly. So if it can, please let me know...

@Niatross: I think this line from the wiki describes what I want to do:

"The occurrence has last been set before this WoO last executed and last time this WoO was called it waited on the *same* occurrence -> WoO will wait"

and gives me a pointer as to why it isn't working - if I attempt to clear the occurrence using a different WoO in the other case for the top loop, it is a different WoO - so the one I care about (in the top loop) still hasn't observed the set occurrence.

Whether I can make it work or not is unclear to me, but at least I can see why it doesn't (I think).

I wonder if setting "Ignore Previous" to "i = 0" would work...

[cbutcher]

---

@cbutcher wrote:

I wonder if setting "Ignore Previous" to "i = 0" would work...

---

In simulation at least, this seems to work.

It is of course dependent on the top loop finishing its first iteration before the bottom loop stops and manages to Set the occurrence, but I think that should be reliably true on FPGA.

For reference now, the "False" case is now empty (no use of the Occurrence needed).

That then brings me to "are occurrences cheaper on FPGA than registers?"

I guess both are fine, so now I can choose.

Wait on Occurrence is not supported in SCTLs (despite working in simulation, it fails at Intermediate Generation even with Timeout = 0).

So Registers it is! (I suppose I could have a While loop in the same VI (top loop) checking the occurrence, then setting a local variable, but that's a lot of extra blah blah blah... so no).

[mcduff]

---

@cbutcher wrote:

Can I use Occurrences here? Are they a good tool (and if not, when are they a good tool? Only when timeout != 0 and ignore previous is true?)

---

I have used occurrences on a FPGA to synchronize a DSA and SAR module. Get the clock from the DSA, count X pulses, fire an occurrence to take data from the SAR. That's one use case that I think is pretty useful.

mcduff

[Terry_ALE]

For messaging between loops, I recommend handshake items, see https://zone.ni.com/reference/en-XX/help/371599P-01/lvfpgaconcepts/fpga_storing_reentrant/.  They are supported in SCTLs.

One thing we do sometimes to keep a loop running but not doing anything is adding an Idle state where it is checking for a message or some kind of change to change to another state.

I would recommend registers over occurrences.  If you find yourself needing to go back and forth between two loops, handshake items help with that (e.g. you can read without acknowledge and then acknowledge later on when you want the writer to continue).