🚀 go-pugleaf

In article <1946@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>+++ stuff +++
>DRAMs take at least 100ns to fire up, so unless they are starting a RAM
>access even before the cache is checked, that would seem to mean 100ns
>(2 cycles at 20MHz) just for RAM access, not counting bus delay and time to
>drive addresses to RAM chips (required if you intend to support a
>reasonably sized main memory, e.g. >128 chips), and the time required
>for the RAMs to be ready for the *next* address (another 100ns
>or so).  And if the cache is running the RAM all the time even when
>it hits, the DRAMs will not be ready to jump into action when the miss
>comes along.
>+++ stuff +++

>If these figures are true, I suspect the system is a "hot rod" with a
>custom static RAM main memory on a local bus.  This amounts to building
>the whole main memory out of expensive cache RAMs.  I'm willing to be
>corrected, and/or to learn something new about memory design.

I am not a hardware type, so bear with me if I am a bit empiric about
this: I am qualified to make some measurements, but not to justify them
on theoretical grounds.

I have an 80386 system, running 16 MHz, with 1 MB of 100ns DRAM (32
bits wide) on the motherboard, and 2 MB of 120 ns DRAM on the 16 bit
bus. I have 64k of 35ns static cache which I can disable.

Without cache the 16 bit memory runs about 180% slower than 32 bit
memory. With cache enabled the penalty drops to 30%. Also, the 32 bit
memory runs about 30% faster than it did without cache, meaning that
the 16 bit memory is running as fast with cache as the 32 bit memory
without.

-- 
bill davidsen			sixhub \
      ihnp4!seismo!rochester!steinmetz ->  crdos1!davidsen
				chinet /
ARPA: davidsen%crdos1.uucp@ge-crd.ARPA (or davidsen@ge-crd.ARPA)