On 7/19/06, James Richard Tyrer <[EMAIL PROTECTED]> wrote:
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'm not sure what you mean. Can you tell me how that is different
from some other mode?
We'll open different rows on each bank. This means we can do
back-to-back accesses to different objects in different parts of
memory without row misses.
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.
I've considered that, but it seems to me that there's little point in
my logic to have a counter when the RAM chip already has one. The
only way to gain anything would be to keep track of how long ago any
one row was last accessed, but that's a lot of logic for practically
no gain.
Are we going to use evenly distributed refresh, or refresh enable
synchronized with the horizontal scan (i.e. refresh on horizontal sync)?
I'd refresh one row so that the whole memory gets refreshed in its max
refresh period. Doing one refresh or a couple back to back doesn't
make much difference. They're not very frequent.
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.
Yeah. We'll have a separate counter for that.
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).
I would design it to be adjustable, just in case we can get faster CAS
latency for a high-perf model or something. Besides, I want a
generalized design that I can license to others for other designs.
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.
Basically. We'll read video data in bulk into a fifo.
What option is there besides page/row mode? I'm confused about that.
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.
The fifo will hold 512 256-bit words. That's because it needs to be
that wide and dual-ported, so the FPGA SRAMs dictate the depth. In
effect, you'll be able to read an entire scanline into the fifo.
Video has the highest priority, so other things will have to wait, so
no glitches on the screen.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
