DRAM initialization in FPGA

[David-A]

That makes more sense then. I guess it wouldn't return a value from an address it hadn't overwritten. 

If you install the instrument design libraries for the 5624R or the 5170R it'll place a memory fifo in its respective folder in instr.lib if you're curious what a DRAM FIFO based on that memory IDL looks like. It has reset functionality built into it. Though if reseting the fpga is a valid option it sounds like you're set with the socketed clip implementation. 

[xl600]

Would those be compatible with the FlexRIO-7966R?

Anyway, the real question is "Why doesn't interactive mode run (after a stop) reset the FPGA"?

[David-A]

The DRAM FIFOs that ship with the 5624R and the 5170R driver wouldn't support the 7966 without cracking it open and making a bunch of modifications. 

I'm not sure I understand your question though. 

[xl600]

So the suggestion to use that library really doesn't help me in any way.

The question... When debugging, I typically use the interactive run mode for  controlling the FPGA during hardware runs.  This has a lot of limitations, I know, but it works for many aspects of my design effort.

When I run the FPGA (Press the run button) everything works great.  When I stop the FPGA (Press the stop button) then re-run the FPGA in interactive mode (Press the run button without changing to a different bitfile), the FIFO is not reset as it would be from an initial execution or a true reset.

Why?

This is not something that I think would affect the design in normal operation, but it is a behavior I would like to understand the cause of.  I would have expected running the FPGA in any manner would reset the FPGA the same way (Interactive mode, Open FPGA reference, Open Dynamic FPGA reference, whatever).  So what's the difference with the FIFO behavior?

[Matt-Bob]

Can you elaborate on how you are stopping the code from interactive mode? Is the stop button you are referring to implemented in your code, how?

As you mentioned this is not exactly a “true reset” since the FPGA code is already flashed. I’m assuming if you did do an actual reset from communicating with the code via a host, you don’t encounter this issue, can you confirm?

Your question though is, why does a non-true reset cause you to encounter this issue. From the research I’ve done it seems to be related to how the FIFO is being implemented. You see, the code you are runing on the FPGA is separate from the code that is running the FIFO interface (CLIP) with the DRAM. A true reset of the FPGA should force the CLIP to also be reset, but I suspect when you are stopping and restarting the code with interactive mode, as you are currently doing, this is just stopping and starting your code over again and not actually reseting the CLIP. Please read more here.

[xl600]

The stop button is the normal stop.  It's the only option provided for FPGA (All my FPGA loops execute continuously)

And yes.  It works fine when sending a reset via the host.

I figures CLIP and the VI would be reset at the same time in any case.  Odd that it isn't... It sounds like there's no solution.

Thanks,

Robert

[David-A · Accepted solution]

Aborting an FPGA vi that is running in interactive mode just closes the connection that the front panel had to the hardware, it doesn't reset the fpga. You would need to explicitly run a reset command from the host like you mentioned.

Pressing the run button on the fpga vi is the same as executing the run method from the host, and pressing the abort button is the same as running the abort method on the host. 

[xl600]

Thanks.  That clears up the reasons behind the behavior I'm seeing.  It's too bad the FPGA can't reset itself in this situation.