🚀 go-pugleaf

in article <1989Nov28.222102.12113@agate.berkeley.edu>, 128b-4ba@web-4c.berkeley.edu (Iain Richard Tyrone McClatchie) says:

> A Mac Plus has a 68000 running at 8 Mhz. That's a clock time of ~126 ns. It
> has 120 ns memory chips. Things seems clear in this case: It takes one clock
> cycle for each memory access. OK.

Not even close.  Clock speed rating on a CPU has about as much to do with the 
actual memory bus speed as row access time (that 120ns) does with the actual
speed of the memory.

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.  DRAM
cycle time is usually just less than twice the TRAC time that's the standard
rating number you see.  So after you've run your 120ns for row address access,
you have probably another 80ns-100ns of row address precharge time before you
can access another memory cell.  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.

> A Mac SE/30 has a 68030 running at 16 Mhz. That's a clock time of ~63 ns. When
> looking for SIMMs, I found 100 ns, 80 ns, and (I think) 70 ns versions. No-one
> I have talked to has heard of 60 ns SIMMs.

Well, the rating on that part is 16.6667MHz, so the clock pulse comes out an
even 60ns.  All Motorola parts work out this way.  Apple runs this one at 
twice their 68000 machine speed -- 15-something MHz.  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 basically pretending that have a 68020 and 
using the asynchronous cycle, which runs in a minimum of 3 clocks, or 180ns
(the new Mac IIci treats the 68030 with more respect -- I think they run it
a tad faster than the NeXT machine).  

180ns is too fast for 100ns DRAMs without doing something clever, which they
don't.  So they'll definitely add a wait state, for a cycle time of 240ns.
But with 240ns, they can probably use 120ns DRAM without much trouble, which
at least back when the IIx came out, was cheaper than 100ns DRAM.

> If that is the case, why sell faster than 120 ns ram, if 60 ns isn't available?
> It would seem that 70ns acts just like 80ns acts just like 100ns.  

You have the right idea here, as I illustrated above, just the wrong granulatity.
If they couldn't spring for 90ns DRAM to meet the 180ns cycle time in that
16MHz machine, they might as well go for 120s -- 100ns parts would be a waste
of money.

> Finally, why would 100ns RAM be _required_, like, 120 ns SIMMs won't work 
> at all?

You should believe whatever they tell you is required.  The match of CPU to
memory gives you an idea of what's possible, knowing the cycle time of CPU
and the cycle time of the DRAM.  It doesn't tell you anything about how they
actually implemented this memory.  Perhaps their refresh logic or some other
activity takes a little time out of the memory cycle, pushing the requirements
over to 100ns parts instead of 120ns, even though on paper there's no 
obvious reason for a 16MHz 68030 to want 100ns DRAM.  You have to know
how the whole system works, not just the CPU to memory interface, to have
a chance of understanding why everything does together the way they did it.

> Do 60ns 1Mbit DRAMs exist, and how much are they? 

They are in 1 Meg x 1 packages now, in rather small quantities, and they
aren't cheap.  But they should be pretty soon.

> If that is not the case, how is memory access asynchronous with the system
> clock?

In many systems today you'll find the CPU clock is a multiple of the bus
speed.  One good reason for this is to make it much more reasonable to 
add wait states.  One wait becomes 33% or 25% of your cycle time, not 100%.
Of course, as clocks get faster, it's going the other way so that you
don't have to work with clocks of outrageous speed.  And so the new chips 
look faster than the old ones, since everyone sees "clock speed" as the
indicator of performance and cost, when they really should look at "bus
speed" as well.

In the old days (long ago, when things were 8 bit) we used to stretch the
CPU clocks to add wait states, at least in 6502 systems.  On the 6502, one
bus clock == one CPU clock, and so wait states were expensive if you
really waited one whole CPU clock.

> -Dazed and Confused
> -Iain McClatchie
-- 
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