How to clear feedback node memory between runs

[skaley]

I've got some (FPGA) code that is riddled with feedback nodes and I am trying to run the core logic on the host to troubleshoot some behavior. The issue is that I need the program to start in a consistent state every time I run it as I make small tweaks, add probes, etc. However, the feedback nodes are "remembering" their previous state from run 1 to run 2 and this is causing some undesirable behavior (counters not starting at 0, etc).

So far I have a couple options:

1 - Add reset logic to everything that gets set on i == 0. Initially I had this, however, it began adding so much noise routing that reset signal and extra logic throughout the program that I decided to get rid of it. The application is complex enough that it was adding too much noise and complexity for no real benefit since this won't be an issue once it's in a steady state on the FPGA.

2 - Close LabVIEW and reopen inbetween tests. Obviously this is increadibly tedious and is a huge overhead troubleshooting - readding probes, recontextualizing myself, opening the correct subVIs etc.

3 - Force recompile (recursive) Ctlr + Shift + Run will reset everything but this takes ~2-3 minutes every time I want to do a reset.

Any ideas?

[wiebe@CARYA]

We'd need to see some code.

This is usually how to do it but it seems what you described:

Have you considered:

1) a shift register

2) you can move the initializer to the loop (any loop actually) it's in:

That should give control on when the FBN is initialized.

[skaley]

Thanks for the reply wiebe!

Here's some examples of the code:

So as a simple example, if I put this "countup.vim" into a stand alone VI and then run that VI back to back (fully stopping any running VIs in between), I would love to see the count stay the same at "1" for both calls, as if the feedback node resets back to 0 (or whatever "type" is) when the VI is no longer running. Versus when its in an application, running in a loop, it should obviously remember the value from call to call.

I think what you are describing is essentially point 1) in my post. Where I add logic throughout the code to take in a "reset" (or "clear?") flag. But this essentially means that every single feedback node needs that logic you posted; which would be incredibly tedious because as you can see from this small example - they are everywhere.

Regarding your second recommendation, I'm actually not familiar with this. How do you associate the initialization of the feedback node to the loop?

This is the best I could come up with:

However, this has the same problem that on run to run the feedback node will not be reset. It is quite different than what you posted, though so maybe your logic has different behavior.

The issue with either of these solutions is that I will have to add new logic throughout the application. In the latter, I'm using quite a few subVIs so many feedback nodes don't even have direct access to the loop that they are in.

What I'm really hoping for is to find some sort of enviroment (or ini) setting that forces labview to "forget" in between calls. It's a tricky nuance how labview manages that sort of memory, when a VI is "in memory" versus when it's "first call".

For me, it is more intuitive that LabVIEW resets feedback nodes (and uninitialized shift registers) whenever a VI is no longer "locked" (ie not running in an active application) though I'm sure there are bigger design decisions at play here.

[UMASO]

When I implement FPGA on LabVIEW, every functional units on FPGA are SubVI-ed and "reset" terminal is placed so that it allows synchronous reset.  Below is a small peace of my development for an example.   When reset signal is asserted all SubVIs accept that reset signal and synchronously reset.  

If any of your logic requires multiple clock cycles to reset such as resetting clock-crossing FIFO, that unit (SubVI) may provide "in reset" output which indicates its on-going reset process.  Careful considerations for reset is especially important for FPGA.  

[skaley]

@umaso

Even in this example your "detect falling edge" is not actually being reset.

The trouble I'm facing is that, especially with all of the pipelining going on, there are too many things that "need" to be reset. 

"need" is in quotations because this isn't an actual problem on the FPGA. They are reset when the bitfile is loaded and ran and that is good enough to get into a steady state

My use case is just for running back to back tests (running the fpga logic the host) from a known stable-state.

Of course, I *could* add reset logic to every single feedback node but i'm really looking for a less intrusive way to accomplish this just for the purposes of testing.

[UMASO]

In that case you do not like to explicitly add reset logic for all the feedback nodes such as the ones with pipeline delay more than one, I would do the followings.  

1. calculate the longest clock cycles to push all the residual data inside those feedback nodes as well as any state-holding logics more than one clock cycles.  

2. Latch reset input and hold a reset signal until the number of clock cycles elapse which is calculated in step 1.  

as for the falling edge, it does not require reset.  I recommend you to first design before implementation.  Draw state machine diagram including resetting state.  

[UMASO]

By the way, you are talking in the situation in simulation.  Even if you find such a way for LabVIEW to somehow forget all the states such as your long pipelines, it does not apply for the actual behavior on compiled bitfile.  You may use FPGA reset method to asynchronously reset everything, but it’s not supported when implicit enable is removed to accomplish higher clock rate.  

Appropriate implementation of synchronous reset is very important even in simulation mode.  

[skaley]

@UMASO

I think we are not well aligned on the intent going on here.

I am happy with the reset behavior when it runs on the FPGA. The feedback nodes are appropriately pipelining and they are starting in a known initialized state. Places that require explicit resets have them. I do not need to, nor do I want to, add additional reset logic within the context of the FPGA.

To supply a bit more context: on the host tester, I am reading a file and loading in known data into the FPGA logic - essentially simulating raw data. I want to be able to run this data from a consistent, initialized state multiple times - strictly to debug/troubleshoot the logic, and nothing more. This can be achieved by closing LabVIEW and re-opening it, I am looking for an easier way to clear this memory.

To be clear: this is *not* an issue on the FPGA because it will have continuous data, rather than starting and stopping it mid run.

At the end of the day your suggestion is to add reset logic throughout the code, which I am aware of that solution (i listed that in option 1 of my original post) - I'm hoping there may be a less intrusive way to accomplish what I need, just for the purposes of testing without muddying the codebase. (example: force recompile, restart labview, maybe super secret hidden ini setting..?)

[UMASO]

You would like to set known states to your registers, but you do not want to implement logics for it and want LabVIEW to do that.  

In your first post, you say some registers remember some states and you hate that behavior.  But remembering states is what is expected for the registers as a software components.  Who is responsible to manage those states is programmer.  I can see from your block diagram, that you do not carefully manage states of each components, as you do not properly propagate reset signals through out each components, such as delay.vim.  Especially for embedded systems, reset sequences throughout subsystems should be carefully considered, though I cannot see your codes do not consider it at all, even for simulation.  

Again, pay much more attention for reset and do not be lazy enough to rely on LabVIEW or any ADE to manage states of the components.  

[UMASO]

oh and you say "so much noise" to implement reset logic for all components.  That should be the curve you make a wrong turn.  If you carefully design your logics on FPGA with drawing state machine, timing chart, etc, you may realize not having a reset mechanism for each unit is the worst thing especially when those units work in real compiled bitfile.  If every units are well designed and separated as a unit like SubVI in LabVIEW, implementing reset would never be "noise".  If you say application is already too complex to implement reset, that must be a warning for technical debt.