Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!bpa!cbmvax!daveh From: daveh@cbmvax.UUCP (Dave Haynie) Newsgroups: comp.arch Subject: Re: System clock rate vs. memory chip speed. Message-ID: <8747@cbmvax.UUCP> Date: 29 Nov 89 06:40:55 GMT References: <1989Nov28.222102.12113@agate.berkeley.edu> Distribution: usa Organization: Commodore Technology, West Chester, PA Lines: 87 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 Brought to you by Super Global Mega Corp .com