Timothy Miller wrote:
I suspect you're referring to the fact that you can transfer data on
one bank while another is being precharged or activated. I did some
calculations on that (years ago), and especially for graphics, the
performance advantage is trivial. It's not worth the extra logic.
IIUC, we are *not* going to use page/row mode read/write access to the DRAM.
I tend to agree that the logic gets messy and there is little gain.
I do have some questions about this.
Do we have to do refresh? Note that you don't on a video card with 4 or
8 MB of memory, you just set up the address lines so that each row gets
read once per scan line. I presume that this isn't going to work with a
lot of memory; there are more than 512 rows.
Are we going to use evenly distributed refresh, or refresh enable
synchronized with the horizontal scan (i.e. refresh on horizontal sync)?
Either way, I presume that we will need a refresh posted counter since
refresh has to wait for the controller to be (forced?) into the idle state.
The spec says 400 MHz DDR memory (DDR400B, 200 MHz clock) so I presume
that we don't need to be able to adjust CAS latency (it will always be 3).
IIUC, screen refresh will read 4 pixels at a time. Are we going to use
any other methods to accelerate reading screen refresh? Specifically,
row/page mode? That is, will screen refresh read be just another read
except that it has the highest priority in bus arbitration.
I presume that there will be a separate 16 byte read buffer for screen
refresh, but that isn't part of the memory controller but it might need
to be synced with the refresh. I would probably use two to make a short
FIFO since memory read isn't going to be totally deterministic and you
have to read with a burst of 2.
--
JRT
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
