DMA SDRAM burst read not working

[Altera_Forum]

I just posted this as a support service request... 

 We are using a SOPC Builder-instantiated DMA controller to interface between the SDRAM and a small on-chip cache of 1600 bytes. The DMA is controlled by a module we've created to write in 800 bytes at a time to the cache, while the module reads the other half simultaneously (dual port access).  This configuration currently works on the Cyclone development kit and it used to work on our custom board with an EP2C8 and Micron SDRAM. Something changed, but we don't know what.  After probing around with SignalTap, we found that the cache was being written to approximately once every 14-15 clock cycles. In the working configuration, this occurs much faster. At this rate, it misses its timing constraints - it only gets through half of the write before it must start reading new data. As of now, we have traced the cause of this back to the burst downstream port, created for the DMA read operation, which shows the downstream_waitrequest as high for the same amount of time.  We are wondering what might have caused this change in behavior, and how to fix it (or what to look for).  The DMA we instantiated is set as follows:  DMA length register is 9 bits Burst transactions enabled Maximum burst size is 512 words Word transactions only enabled FIFO constructed from embedded memory blocks   The cache is instantiated as follows: RAM Dual-port access Width 32 bits Total size 1600 bytes Read latency 1 for s1 and s2  s1 connects to DMA write master s2 connects to our module's read master  The SDRAM module we are using is the Micron MT48LC4M32B2 - 6 SDRAM controller is: Width 32 bits CS1 Banks 4 12 Rows 8 Columns Not on a tristate bridge CAS Latency 2 2 Init refresh cycles 15.625us between refresh 100us delay after powerup t_rfc 60ns t_rp 18ns t_rcd 18ns t_ac 7.5ns t_wr 12ns  We are running the system at 50MHz, with a Nios II/f.

[Altera_Forum]

Check it: 

 http://www.yikes.com/~ptolemy/sopc_system.jpg (http://www.yikes.com/~ptolemy/sopc_system.jpg)  http://www.yikes.com/~ptolemy/signaltap_waveform.jpg (http://www.yikes.com/~ptolemy/signaltap_waveform.jpg)

[Altera_Forum]

--- Quote Start ---  originally posted by rhaikh@Mar 16 2006, 08:28 PM check it:  http://www.yikes.com/~ptolemy/sopc_system.jpg (http://www.yikes.com/~ptolemy/sopc_system.jpg)  http://www.yikes.com/~ptolemy/signaltap_waveform.jpg (http://www.yikes.com/~ptolemy/signaltap_waveform.jpg) <div align='right'><{post_snapback}> (index.php?act=findpost&pid=13516)  --- quote end ---    --- Quote End ---   SDRAM controller from SOPC builder does not work in burst modes. I have tried to read burst from sdram and I had same problems.

[Altera_Forum]

--- Quote Start ---  originally posted by slava+mar 17 2006, 12:21 am--><div class='quotetop'>quote (slava @ mar 17 2006, 12:21 am)</div>  --- quote start ---  <!--quotebegin-rhaikh@Mar 16 2006, 08:28 PM check it:  http://www.yikes.com/~ptolemy/sopc_system.jpg (http://www.yikes.com/~ptolemy/sopc_system.jpg)  http://www.yikes.com/~ptolemy/signaltap_waveform.jpg (http://www.yikes.com/~ptolemy/signaltap_waveform.jpg) <div align='right'><{post_snapback}> (index.php?act=findpost&pid=13516)  --- quote end ---    --- Quote End ---   SDRAM controller from SOPC builder does not work in burst modes. I have tried to read burst from sdram and I had same problems. <div align='right'><{post_snapback}> (index.php?act=findpost&pid=13539)</div> [/b]  --- Quote End ---     The exact same configuration works in other designs: it used to work on this board, and it continues to work on the devkit. You&#39;re right though, it is problematic.

[Altera_Forum]

--- Quote Start ---  originally posted by rhaikh@Mar 17 2006, 11:36 AM the exact same configuration works in other designs: it used to work on this board, and it continues to work on the devkit.  you&#39;re right though, it is problematic. <div align='right'><{post_snapback}> (index.php?act=findpost&pid=13540)  --- quote end ---    --- Quote End ---    It is not problematic if you would written your sdram controller with support burst read and write. opencores.org has similar sdram controller. It has burst mode and mode - "keep row open". Last mode has extremely fast access to sdram. Of course, if access is in one row only.

[Altera_Forum]

--- Quote Start ---  originally posted by slava+mar 17 2006, 01:03 am--><div class='quotetop'>quote (slava @ mar 17 2006, 01:03 am)</div>  --- quote start ---  <!--quotebegin-rhaikh@Mar 17 2006, 11:36 AM the exact same configuration works in other designs: it used to work on this board, and it continues to work on the devkit.  you&#39;re right though, it is problematic. <div align='right'><{post_snapback}> (index.php?act=findpost&pid=13540)  --- quote end ---    --- Quote End ---    It is not problematic if you would written your sdram controller with support burst read and write. opencores.org has similar sdram controller. It has burst mode and mode - "keep row open". Last mode has extremely fast access to sdram. Of course, if access is in one row only. <div align='right'><{post_snapback}> (index.php?act=findpost&pid=13542)</div> [/b]  --- Quote End ---     Here is what the signaltap looks like for the working configuration (devkit):  http://www.yikes.com/~ptolemy/good_behavior.jpg (http://www.yikes.com/~ptolemy/good_behavior.jpg)  The zoomed in cycle shows the controller switching rows in the middle of the transfer. Note CS_N=0 CAS_N=1 RAS_N=0 WE_N=0, these are the correct signals for truncating a burst transfer with the Precharge command (see: http://download.micron.com/pdf/datasheets/.../128msdram.pdf) (http://download.micron.com/pdf/datasheets/dram/sdram/128msdram.pdf)).  It has to use burst to get this performance, and I am counting on it to work. In   http://www.yikes.com/~ptolemy/signaltap_waveform.jpg (http://www.yikes.com/~ptolemy/signaltap_waveform.jpg)  it shows individual reads instead of burst. I don&#39;t know why, because the DMA instantiation for both systems is exactly the same..

[Altera_Forum]

I found the problem. I&#39;m an idiot. 

 It&#39;s staring me right in the face in the SOPC system configuration...  http://www.yikes.com/~ptolemy/sopc_system.jpg (http://www.yikes.com/~ptolemy/sopc_system.jpg)  I was giving the sdram controller the phase shifted clock!  Thanks everyone.