Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!swrinde!cs.utexas.edu!romp!auschs!d75!cello!weasel.austin.ibm.com!alvitar
From: alvitar@weasel.austin.ibm.com (Phillip L. Harbison)
Newsgroups: comp.arch
Subject: Re: System clock rate vs. memory chip speed.
Message-ID: <3069@cello.UUCP>
Date: 29 Nov 89 18:41:38 GMT
References: <8747@cbmvax.UUCP> <1989Nov28.222102.12113@agate.berkeley.edu>
Sender: news@cello.UUCP
Distribution: usa
Lines: 49

In article <8747@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes:
> In the above case, the 68000 CPU takes 4 clock cycles for its fastest memory
> cycle.  Rounding the Mac Plus's clock up to 8MHz (it's actually 7.8-something
> MHz), you find that the minimum memory cycle for that Mac is 500ns.
> ...
> Even if it comes out to 220ns, it should be apparent that it doesn't take
> much cleverness to build a no wait state memory system for a 68000 at 8MHz.

While the 68000 can perform a bus transfer in a minimum of 4 clock cycles,
the memory system does not necessarily have 4 clock cycles to respond.  The
address bus is not valid until well into the second clock cycle, and the
data must be latched at the middle of the fourth cycle.  Therefore, at least
1.5 cycles are wasted, leaving 2.5 cycles (312.5 nsec. at 8MHz).  To further
complicate matters, the memory system must tell the 68000 that data will be
available (by asserting DTACK) no later than the middle of the third cycle
if the data is to be latched in the fourth cycle.  Building a no-wait-state
memory system is not quite as trivial as you seem to imply.  Several of the
early DRAM controller chips (like the 8408) had a difficult time of this.

> The fastest possible 68030 cycle is two clocks, for a cycle time of 120ns
> at 16.666MHz.  But in the SE/30, IIx, and IIcx, Apple's ... using the
> asynchronous cycle, which runs in a minimum of 3 clocks, or 180ns ...

Once again, the entire bus cycle is not available to the memory.  In the
case of synchronous bus cycles, the memory system must assert STERM by the
beginning of the second cycle for data to be latched in the middle of the
second cycle.  Also, the address bus is not valid until around the middle
of the first cycle, so the memory system only has one clock cycle to get
the job done.  I've found this to be difficult for anything other than very
fast SRAM (as used in a cache).

The asynchronous bus cycle timing is similar to the 68000 timing, except
they got rid of the dead first cycle.  The address bus is valid shortly
after the beginning of the first cycle.  DSACKn must be asserted by the
middle of the second cycle if data is to be latched in the middle of the
third cycle.  At best, the memory system has about 2 full cycles to get
the job done, less if it has to check the data (i.e. parity or ECC) before
it asserts DSACK.

Having spent most of the last two months working on 88000 memory timing, I
can sympathize with anyone having difficulty designing no-wait-state or few-
wait-state memory systems.  It is never as easy as they make it sound in
the data books.  :-(

----
Live: Phil Harbison
Mail: alvitar@weasel.austin.ibm.com

"Skin it back!"


Brought to you by Super Global Mega Corp .com