Jonathan, why so aggressive?
I was just pointing out that certain applications naturally perform
sufficient refresh operations in their normal addressing sequence. I
can't see why this is "completely ridiculuous"...
Peter Alfke

On Oct 24, 12:40 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Wed, 24 Oct 2007 07:15:08 -0000,
>
> Antti <Antti.Luk...@googlemail.com> wrote:
> >> For certain addressing patterns, the refresh can be eliminated
> >> alltogether, when the addressing sequence is such that all (used)
> >> memory cells are naturally being read, and thus refreshed, within the
> >> required time.
> >> Peter Alfke- Zitierten Text ausblenden -
>
> >> - Zitierten Text anzeigen -
>
> >Sinclair ZX?
> >at least some old Z80 homecomputers used refresh by video scan
>
> Yes, and it's a completely ridiculous way to do it. The
> added cost of making frequent additional row accesses is
> far greater than the cost of the necessary refresh.
>
> 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.
>
> In those days, the video buffer was a sufficiently
> large fraction of the overall DRAM that it was
> reasonable to lay out the video memory so that
> every row was automatically visited by the video
> scan, giving a refresh cycle every 20ms (16.7ms
> in the USA). That was out-of-spec for many DRAMs
> of the day (8ms refresh cycle) but in practice it
> worked in almost all cases - and the manufacturers
> of those computers had a shoddy enough warranty
> policy that they weren't going to worry about a
> handful of customers complaining about occasional
> mysterious memory corruption on a hot day.
>
> --
> 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
> jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.