Resetting an FPGA vi emulated on the Dev Computer

[ZA1]

Hey,

I am working on a debugging a FlexRIO vi, using emulation on the Dev Computer with Simulated IO. I have a testbench vi that communicates with the emulated FPGA vi via DMA FIFO.

After each test run, I want to reinitialize all vi registers to their initial value, and clear DMA FIFOs.

I've had some success doing this by closing the emulated FPGA vi's front panel, and running the testbench, which concludes with a call to close the FPGA vi, with the "close and abort without Reference Counting" option selected.

Unfortunately, it seems that this only works some of the time, even with the FPGA vi completely closed; maybe the reference is still persisting in memory somehow?

In any event, doing this every time I do a debug/fix cycle is rather awkward, since it kills every probe I have on the emulated FPGA vi. I tried Edit-->"reinitialize values to default," but of course that didn't do it.

Could someone suggest a better procedure? Any suggestions would be greatly appreciated at this point.

[Smootastic]

Does calling the Reset method on the FPGA reference work?  It should be available by wiring your FPGA ref to an FPGA Invoke Method.

[ZA1]

I'm afraid not. I get:

Error -61167 occurred at Invoke Node: Reset in testbench.vi

Possible reason(s):

LabVIEW FPGA:  This function is not supported when the FPGA target is configured to execute on the development computer.

[Ben_S]

ZA1,

Hello! It sounds like you are seeing three different issues at the moment. Let's break them down indidivually.

1.) Reinitializing values to default doesn't seem to be working

Are you trying to do this when the VI is running? or has it stopped executing?

2.) "Close and abort without Reference Counting" works intermittendtly.

Using the "close and abort without Reference Counting" does work sometimes, is this correct? I want to make sure we fully understand the issue you are seeing.

You could try using this example to see if that VI is still in memory when you try to call the "close and abort..." on it. If it is, that explains why it doesn't work sometimes. If it isn't in memory, we'll have to dig a little deeper.

View All VI's in Memory and Their Execution State

https://decibel.ni.com/content/docs/DOC-18392

3.) Error -61167 when using Reset Method.

This is expected. That functionality is not supported when running the FPGA VI on the development computer.

See the LabVIEW Help file, "Communicating with an FPGA VI Running on a Development Computer (FPGA Interface)".

http://zone.ni.com/reference/en-XX/help/371599G-01/lvfpgahosthelp/comm_fpga_dev_comp//

[dklipec]

Which problem do you find most troublesome?  Resetting the DMA FIFO, resetting the controls/indictators on your VI, or actually resetting the logic inside of the FPGA VI (like shift registers/feedback nodes, which will also persist their data)?

Clearing out the DMA FIFO, you can accomplish by making your Host VI call "Stop" on the FIFO.

Resetting the controls to their initial condition you can do by Reinitialize to Default via the edit menu.  Alternatively, you can just load everything up before you "Run" the VI (brute force).  This works because you are normally allowed to write to controls and indicators before "Run" - as long as the device is in a state where that is possible.  If you use "Open and Run" in the open node, however, the VI will instantly start.

In simulation, there are no clocks to worry about.  However, with an adapter module, while the VI is in Reset, so is the CLIP.  So the CLIP will not execute the initialization sequence which turns on clocks from the FlexRIO Adapter Module (FAM).

Internal state is the more troublesome.  If a block doesn't have a reset terminal on it, then internal state can persist.  The only way to get rid of it is to force a recompile or exit/reload LabVIEW.

[ZA1]

Ben_S:

1. Reinitializing values to default

I can confirm that with the FPGA vi and the testbench host vi open, and both stopped, Edit --> Reinitialize Values to Default does not change the internal state of the vi, with respect to the value read out of a

VI-defined register, or with respect to clearing a DMA FIFO.

2.  "Close and abort without Reference Counting" works intermittently.

I ran the example vi provided in DOC-18392. After some experimentation, I found that it needed to be opened and then run in order to detect what other vi's were in memory, either idle, running, or bad, when the

detector example vi was run. I was able to detect that some of my existing vi's, and test untitled vi's, were in memory or not, and if they were running, idle, or bad.

Unfortunately, the detector example vi could not detect my vi targeted for FlexRIO emulated on the Dev Computer whether it was running or idle; it just didn't show up in the array indicator at all.

dklipec:

I actually have no controls or indicators on the front panel of the FPGA vi; all communication is done through DMA FIFOs. I am 95% convinced that making the testbench host VI call "Stop" on the FIFO does clear it reliably, though; thank you for pointing that out.

Unfortunately, I am most concerned with internal state. My FlexRIO code has a number of state machines with case structures taking input from shift registers and reads on register blocks. To test these state machines, I need everything to start in a clean initial state. I can confirm that just closing the FlexRIO targted vi and the host vi was not enough to reintialize a VI-defined register to its initial value; I had to completely close out of LabVIEW and reload.

You mentioned that an alternative is to "force a recompile." I tried force compiling by clicking the run button while holding down <ctl>, but that did not reintialize the register, either. Were you referring to some other

kind of force recompile? If so, how do I do it?

If not, is there really nothing besides reloading LabVIEW that I can do?

Message was edited by: ZA1; tried force recompile, updated post to describe results

[Patrick_P.]

Hey ZA1,

I'm really sorry but it looks like this was a bug introduced in 2012.  Prior to 2012, if you used "close and abort without Reference Counting" or "Close and reset if last reference" (depending on if you have the FPGA Interface configured for dynamic mode or not), and you did not have the FPGA VI front panel open, then it should be effectively a reset.  With 2012, I believe DMA FIFOs, memories, and registers do not reset properly.  Controls, indicators, feedback nodes, and shift registers should still reset properly. 

I believe your big problem is with registers in this case.  I have created a helper VI that can be connected up to the FPGA Interface wire that will clear the ones I listed above that do not reset properly.  I have a screenshot below showing how you can use the VI.  It will return an error if you aren't calling it from an Open node that was configured for executing the VI on the development computer so I used a case structure to avoid the error.  I'm also creating a request internally for us to fix this.  Let us know if this still doesn't solve your problem.

I'm not sure the best way to post this file, but I shared it from a dropbox link for now.  I'll edit my post next week with a more permanent place for the VI.  Download here.

[ZA1]

Patrick_P,

I've been working with your helper VI, and it looks like it does the trick. I can use it to reset the state of registers, FIFOs, etc., even when the FlexRIO vi it is targeting is still open.

That's exactly the behavior I wanted, since it allows me to reset without having to close out of the emulated FPGA vi and wipe out all my probes.

Thank you very much, this has really enhanced by debugging productivity.

[nanocyte]

The link is dead. Can you repost it? I'm seeing that the simulation behavior and real world behavior of close doesn't match up when the FPGA front panel is open. Specifically, I'm referring to resetting a feedback node that's configured for "On Compile or Load"

[thej178]

Hi Patrick_P,

I was wondering if it would be possible to see your helper VI again, the link is currently invalid. I am in a similar boat as the OP and am running a HOST testbench with the FPGA in a simulation mode. I also need to run the reset invoke node which I don't think is possible in a simulation mode. Let me know if you still have the files. Thank you