Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cbmvax!daveh From: daveh@cbmvax.UUCP (Dave Haynie) Newsgroups: comp.arch Subject: Re: System clock rate vs. memory chip speed. Message-ID: <8861@cbmvax.UUCP> Date: 6 Dec 89 23:23:49 GMT References: <3069@cello.UUCP> Distribution: usa Organization: Commodore Technology, West Chester, PA Lines: 97 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