🚀 go-pugleaf

in article <3069@cello.UUCP>, alvitar@weasel.austin.ibm.com (Phillip L. Harbison) says:

> 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.  ...
> 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.

Sure it is.  Don't even bother with a DRAM controller.  Build it with a couple
of PALs and TTL parts.  There are about 10 different expansion memory boards
for the Amiga 2000 that run with 0 wait states; most use hand-made memory
controllers.  Obviously you don't have the entire 4 clocks to access the memory,
but you don't need it either.  Using 150ns parts, it's possible to fit the
memory access by the 68000 and a CAS-before--RAS refresh cycle into one 
68000 memory cycle.

>> 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.  

Of course the memory system must assert the acknowledge quickly. So what? 
As long as you know when the memory read is going to be valid, that's no
problem.  You don't have to wait the entire memory access time before
acknowledging, you just have to take care of any nondeterministic stuff
before acknowledging the cycle.  In fact, with many cache designs, you
don't even worry about that -- you assume that it's a cache hit, assert
STERM before you really know, and re-run the cycle if it's a miss.

> 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).

That's still 60ns for the 16MHz 68030.  Fast static cache these days goes
around 35ns, fast PALs around 7.5ns; you can go faster if you want to
pay for it.  Certainly no real easy trick with SCRAM, but you still have
around 25ns from address valid to termination to decide, on an open 
page (access time of 35ns-50ns, depending on the part) whether or not you
want to run the cycle.  Which should be done in a single PAL.  Using a gate
array or other LSI-type controller will probably add a wait state no matter 
what you do.  Obviously it's not a piece of cake, or they'd just be hiring 
anyone off the street to design 68030 systems.  But designing for 16MHz or 
even 25MHz 68030 systems is hardly a black art, and there are plenty of 
parts out that will support these systems.

> 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.  

Actually, addresses are always valid at the S0->S1 edge.  You had it right 
above; the chip doesn't know if it's a synchronous or asynchronous cycle 
until you terminate the cycle.  It's also good to have a few more clock
edges than what you get basing everything on the 68030 clock; I've done 
it both ways, and wouldn't attempt another system without at least 90
degree clocks around.

> 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.

You never HAVE to check the parity or data before asserting the DSACKs;
you can always assume it's OK, and retry the cycle if it isn't.  Sure
that's more complicated, but it's also possibly faster.  Obviously you
can't let the cycle complete before the check is finished; same basic
idea as using retry for the cache -- you assume the thing that usually
happens is going to happen, and retry the cycle for the unusual case.

> 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.  :-(

I have yet to play with 88ks unfortunately :-(, so I can't comment on that
timing.  It's certainly never as easy as the data book claims, but more 
than a few folks seem to have figured it all out.

> Live: Phil Harbison
> Mail: alvitar@weasel.austin.ibm.com
> 
> "Skin it back!"
-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough