On Wed, 24 Oct 2007 13:06:34 -0800,
glen herrmannsfeldt <[email protected]> wrote:

>Processor speed has increased somewhat faster than DRAM speed.

Indeed so; a fair point. And you could perhaps also argue
that the cost of row access, as a fraction of a data access,
has increased quite dramatically over that time.

>> A DRAM row is effectively a cache. When you access a row,
>> you read the whole row into the DRAM's row buffer as a free
>> side-effect, and can then make very fast column accesses
>> to anly location in the row. It's preposterous to throw
>> away that massive free bandwidth just to save yourself
>> some refresh effort - unless you're trying to design
>> a $80 home computer/toy in the early 1980s.
>
>When RAM cycle time was faster than processor cycle time.

That too is an interesting point. My own experience of
that sort of video controller was that they typically
caused lots of processor stalling while video data
was being fetched, but it may have been different
for other designs.

>If you address it such that sequential characters are
>in different rows then it is refreshed much faster than
>the frame rate.

True, but then you are *really* wasting bandwidth
by doing more row accesses than necessary.

I guess you could, by juggling the use of address bits
sufficiently cunningly, arrange that row accesses by
video scan would *just* provide enough refresh to
satisfy the data sheet spec.

I've seen many different variants on this: block refresh
during frame blanking, for example. They all seemed
pretty unpleasant to me at the time, and still seem so
now - although, of course, no-one needs to do that sort
of dirty trick any more (do they? please?)
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
[email protected]
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.