MIG (Memory Interface Generator)

[roger_j]

Hi!

Im trying to get as high bandwidth as possible towards a DDR3 memory by writing continously to the interface. The way I'm implemented it is by using BL8 and set app_en high and issue a write command together with the address every second clock cycle and write 64 bit of data on every clock cycle with wdf_en toggling  on every clock cycle. Commands are issued when app_rdy is high and data is provided when app_wdf_rdy is high. I've attached an waveform showing the behaviour. The problem I'm having is that both app_rdy and app_wdf_rdy are low quite a large part of the time. Is the implementation of the write command incorrect or is the problem laying somewhere else?

I have run the example design and it finishes without errors. 

[gszakacs]

In the waveform you posted, I can see a long period of write activity with no gaps (looking

at the DQS waveforms).  Then there is a gap and a read (CAS# low, WE# high CS# low).

I don't see the read instruction pushed into the application interface.  Do you have some

sort of scrubbing ECC implemented that might be causing the MIG controller to read

the memory without being asked?  Or if you go back before the beginning of the window

of simulation you posted do you see a read command pushed into the application queue?

-- Gabor

[jschmitz_dup2]

Note that the V6 DDR3 controller from MIG will force periodic reads to keep its internal clock synched with the DQS.  The rate at which this occurs is controlled by a parameter, tPRDI, I believe.  You need these periodic reads if you want to read your data reliably which I assume is the case.  (Otherwise why bother storing it!)  But for simulation you can set it to 0 to see if this is causing the unexpected read.  Do return it to the correct value for your hardware.  Otherwise you may suffer from data corruption.