Honored Contributor
Honored Contributor--- 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'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't know why, because the DMA instantiation for both systems is exactly the same..
