Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!batcomputer!itsgw!imagine!pawl22.pawl.rpi.edu!jesup From: jesup@pawl22.pawl.rpi.edu (Randell E. Jesup) Newsgroups: comp.arch Subject: Re: Impossible 40MHz R2000 ?? Message-ID: <169@imagine.PAWL.RPI.EDU> Date: 18 Dec 87 14:11:07 GMT References: <1145@mips.UUCP> Sender: news@imagine.PAWL.RPI.EDU Reply-To: beowulf!lunge!jesup@steinmetz.UUCP Organization: RPI Public Access Workstation Lab - Troy, NY Lines: 118 In article <1145@mips.UUCP> mark@mips.UUCP (Mark G. Johnson) writes: >Quoting from author jesup@pawl22.pawl.rpi.edu (Randell E. Jesup) > > Given current technology, r2000 could probably be scaled > > to about 20 MHz. However, custom RISC designs in CMOS are > > now reaching 40 MHz, which would be impossible with the > > double-clocked interface currently on the r2000. Perhaps > > the interface could be removed, given enough pins, but > > that gets you back into the packaging limits. > >"Impossible" is quite a strong word. "Difficult", sure. But he's >saying that a 2.4X improvement of a first-chip-designed-at-a-startup- >company, 2-micron-generic-silicon-foundry device is IMPOSSIBLE. Oops. You're right, I shouldn't have said 'impossible'. Take that as rephrased to 'very tough'. >Other factors conspire to make the job of building a 40 MHz >double-clocked interface not "impossible": > > 1. Cache RAM access times will continue to decrease, likely > at the same rate as the processor clock, since SRAM vendors > now build RISC chips (including SPARC, R2000, Am29K). So > RAM access time will probably stay at 40-50% of processor > cycle time. {presently 60 ns cycle, 25-30 ns RAM access}. > The rest of the cycle is used up by setup & hold times, > bus drive (slew) times, timing uncertainties, and "margin". If you're willing to pay for it, you can get 20ns cycle SRAMs in reasonable sizes now. > 2. Surface mount packages (having the *same number* of > leads, 144) might be used instead of the current 144 pin > Pin Grid Array. Their lower inductance and better > controlled impedance can decrease dispersion and improve > signal quality. Such packages, available today, are > more than 2.4X better than the existing PGA package, so > the net percentage of the cycle wasted in package-induced > "timing slop" would decrease. You can get leadless chip carriers now with 144 'pins' that are certified to run at 40Mhz. However, to 'double-clock' I assume they would have to be certified at 80Mhz, which they are not. PGAs at that speed are right out (though perhaps not impossible :-) > 3. Output voltage drive levels might shrink from the present > 0.0 volts and 5.0 volts, to (an example) 0.4V and 2.7V. > This speeds up output transitions (dT = dV * C/I) without > increasing switching noise. Less of the cycle (in > percentage terms) would be spent slewing the bus around. This may well be they way the world goes. However, at least for the next few years, I think we're stuck with 0-5V. > 4. The clock generation and distribution technology may > get a factor of > 2.4X more precise. If this happened, > the fraction of the cycle lost to "slop" (timing edge > uncertainty) would go down. Definitely helps, but you can get some VERY accurate clocks if you put some real thought into it and limit the loading. Things like 2 40Mhz non-overlapping clocks, for example. > 5. BiCMOS fab processes might be employed, permitting the > use of open emitter, Wired-OR interfacing to ECL-compatible > cache RAM chips. Current ECL RAMs are about 15-20 nsec, > a smaller fraction of the current processor cycle (60 nsec) > than current MOS RAM chips. So the timing margins > *improve*. Additionally, multiple-driver "collisions" or > "contention" are non-deadly in the wired-OR ECL structure, > (unlike CMOS tristate busses), such that the time between > disabling X and enabling Y onto the bus, can be reduced > dramatically. And there's reason to believe that BiCMOS > RAM access times will scale at about the same rate as > traditional CMOS RAMs. I'm not a silicon person, so I'll take your word. However, as I said earlier, 20-25ns cycle time SRAMs exist and can be bought now. In fact, all 40Mhz RISC chip designs being worked on that I know about will need them. Does the BiCMOS require that ALL chips be BiCMOS? (sounds like it would.) >Taken individually or as a group, these scenarios indicate (at least >to me) that 40 MHz "double clocked cache interfaces" are indeed >possible, and might in fact be as robust (or moreso) than existing >implementations at 16.7 MHz. I think your real limiting factor, even with some of those you stated above, will be packaging technology. You can build a 40Mhz RISC chip with single-clocked interfaces with current tech. With better tech, you could build better ones, more or less as fast as the interface lets you go. It seems to be the limiting factor at the bleeding edge right now. The 16Mhz double-clocked RISC chips are now putting about the same load on the technology as a 30-32Mhz single-clocked chip would. For double-clocking to be a win, you have to have packaging tech that is at least twice as fast as you can make your CPU cycle times go. With 16Mhz now that's easy, it is not possible (caveat:-) with 40Mhz now. (Note that my earlier article was about current state-of-the-art, not what can happen in the next n years. There are 40Mhz RISC chips out there now, using 1.25u. My comment on scaling was that the r2000 chip couldn't do 40Mhz given CURRENT vlsi, packaging, and ram technologies (once again, caveat:-)) If you believe that packaging tech will improve sufficiently faster than CPU cycle times, maybe it will continue to be reasonable. However, it seems that packaging is NOT keeping up right now. One last caveat: I know there are new packaging technologies under development that may (more like will) turn the world upside down. However, my earlier comment was about NOW, not 1-3 years from now. >Regards, > >-Mark Johnson *** DISCLAIMER: The opinions above are personal. *** >UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mark TEL: 408-720-1700 x208 >US mail: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086 // Randell Jesup Lunge Software Development // Dedicated Amiga Programmer 13 Frear Ave, Troy, NY 12180 \\// lunge!jesup@beowulf.UUCP (518) 272-2942 \/ (uunet!steinmetz!beowulf!lunge!jesup)