DRAM initialization in FPGA

[xl600]

In testing my FPGA (FlexRIO 7966), I was trying to test recovery from errors.  Typically, the error would be caused by an overflow in the DMA FIFO process (EX: The host VI not reading fast enough causing the FPGA DMA fifo to fill then causing my DRAM FIFOs to fill).  When this happens, simply reloading the bitfile doesn't seem to clear the condition.  The memory is still in the full state.  Even rebooting the controller doesn't seem to clear the error.  Cycling power does work, but that's no way to recover from errors.

There's no way to probe which memory is in trouble so I ask:

1.  When the bitfile is loaded and run, is the DMA FIFO reset?  What about the DRAMs (Configured as FIFOs)?  Or general FPGA memory FIFOs (Blockram, registers, etc)?

2.  Would it be of any use to manually clear the DRAM during FPGA initialization (EX: Pass data_available to read in an initialization SCTL until data_available is false and ignore the actual data)?

The help files and users guides are very light on how FPGA initialization works.

Thanks,

xl600

[xl600]

It appears that the DRAM isn't fully reset while using the interactive front panel.  This is where my problem lies.  When I reset the FPGA programatically, everything seems to work properly.  Is there a discussion on FPGA interactive mode which could shed light here?

[David-A]

Are you running in simulation or on hardware?

In simulation you may see values persist in a way that won't happen on hardware. There are  elegant ways to clear data from previous runs of a simulated FPGA vi, but I usually just close it and open it back up. 

If you're running on hardware, you either need to power cycle to remove remove all values from the DRAM, or you need to write a value of zero to every address that has been accessed since power up. 

What version of labview are you using? In labview 2014 and later there are some libraries that provide access to DRAM in a way that makes reseting all values in DRAM without a power cycle fairly easy. Specifically I'm referring to the memory library that exists in the <LabVIEW>\instr.lib\_niInstr\Memory directory. 

[xl600]

In hardware.  In simulation, I use co-sim mode so re-running already clears everything out.

I did notice that a board reset will clear the DRAM FIFO effectively.  But re-running in interactive front panel mode does not seem to fully reset the FPGA.  All I need it to do is reset the DRAM FIFO so that it doesn't think there's elements needing to be dequeued.  Primarily for debugging with the interactive mode.  I'm thinking there should be a 'reset FPGA on run' feature for interactive execution on hardware, but there doesn't seem to be.

I did look at that memory library, but there's no documentation so I'm not sure how it would be used with DRAM defined as FIFOs.

[Matt-Bob]

Hello,

To my knowledge, resetting the FPGA is different than clearing the DRAM. On the hardware level, the DRAM and the FPGA are two different components; they are independent from one another.  If you reset the FPGA, nothing happens to data being stored in the DRAM. Resetting the DRAM can only be done by the methods already suggested in the post above. I myself was not aware of last method suggested (using the LabVIEW 2014 libraries), and as you mentioned there is not much documentation on it. I’m just curious, is there a particular reason you are using the DRAM as a FIFO for your application?

[xl600]

The DRAM as FIFO was a carry over from the Camera Link examples NI provides with the NI-1483.  It works well and I believe the FIFO aspect of it is actually implemented in the FPGA, not the DRAM.  So resetting the FPGA would naturally have the effect of 'clearing' the FIFO by initializing whatever pointers are being used to address the DRAM itself.

[Matt-Bob]

I’m not sure if when you set up the DRAM as a FIFO, if it is truly is just an FPGA implementation. However, I’ll try doing some more digging and perhaps take a closer look at that example to confirm. 

[xl600]

Thanks.  I am quite sure the FIFO is reset with an FPGA reset, just not with a re-run of the FPGA in interactive mode (Which is the issue really...).  Re-running the FPGA to me seems like it should reset the FPGA before the run is started.

Robert

[David-A]

Have you tried it? My guess is that reseting the fpga doesn't reset the data already written to the DRAM. I'd be interested to know if that does work. If it doesn't I can point you to a DRAM FIFO that has reset functionality built into it.

[xl600]

I wouldn't be able to tell.  Since it's configured as a FIFO, the only interfaces I have access to are:

• Inputs
• Write data upper
• Write data lower
• Write
• Read
• Outputs
• Full
• Read data upper
• read data lower
• Data Available

After reset, nothing is available for read (Data available resets to '0').  That doesn't mean the DRAM itself has been cleared I'm sure, but the FIFO has effectively been initialized.