Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!prls!mips!hansen From: hansen@mips.UUCP (Craig Hansen) Newsgroups: comp.arch Subject: Re: Why is SPARC so slow? Message-ID: <1131@mips.UUCP> Date: 15 Dec 87 18:40:54 GMT References: <1078@quacky.UUCP> <8809@sgi.SGI.COM> <1941@ncr-sd.SanDiego.NCR.COM> <140@imagine.PAWL.RPI.EDU> Lines: 51 Keywords: RISC, R2000, SPARC In article <140@imagine.PAWL.RPI.EDU>, jesup@pawl22.pawl.rpi.edu (Randell E. Jesup) writes: > The real problem is the fact that your chip edge is clocked at twice your > instruction freqency. Running a higher-speed clock than the instruction rate > is fine, and makes internal design much easier. However, packaging > technology will be your limiting factor for some time to come, not really > ram speed per se. For the large number of pins required, it is hard to find > packages certified at that speed. For speeds well above 40 MHz in CMOS technology, our studies suggest that this will not be a limiting factor at all, and that multiplexed busses can work as fast as non-multiplexed buses at least up to that clock rate. The real enemy to high clock rates is clock skew, and controlling that skew is the reason why we use a tapped-delay-line clocking system, and phase-locked-loop technology. The tapped-delay lines also allow the timing of the chip to be adjusted to accomodate variations in the timing specifications of SRAM chips; the phase-locked-loop technology allows the CPU and FPU to have matched timings, no matter how the CMOS processing causes circuit speed variations. In our earlier days, some other company that shall remain nameless, (but recently had their "ship" repossessed), made some wild claims (that we heard repeatedly but always "second"-hand) that the MIPS chip was no faster (when used at half speed) than theirs (when used at full speed), but was actually clocked twice as fast as we said it was. After all, we have double-frequency clock inputs. Well, OK. But the other companies chip had double-frequency clock inputs, too, and when you compared the two chips at their specified clock rate, ours runs more than twice as fast (benchmark-wise), and theirs had double the input clock rate. Talk about double-speak! The multiplexed buses, far from being a limiting factor, are an important reason why the MIPS chip is "fast" and the SPARC chip is "slow." By putting all the important cache interface logic on the CPU chip, the critical paths in the cache are entirely set by the speed of static RAM chips, without interference by tag comparison logic, and parity generation and checking logic. Because SRAMs are used as technology drivers for new CMOS and BiCMOS technologies, MIPS can be assured of a good supply of highly agressive SRAMs that will work with the MIPS part. The real problem with the other RISC designs is that they require specialized cache RAMs or external tag comparitors. SRAM vendors can do good business selling RAMs with internal tag comparison logic that try to cover up the faults of the RISC processor designers, yet are based on the previous generation technology - to be blunt, specialized cache RAMs are a winner for the RAM vendor (who gets to sell a proprietary part on old technology for a high price) but a loser for the RAM vendee (who pays too much per bit for slower RAM). ...and the specialized cache chips from the RISC vendors have been even slower, smaller and more expensive per bit than standard SRAMs. -- Craig Hansen Manager, Architecture Development MIPS Computer Systems, Inc. ...{ames,decwrl,prls}!mips!hansen or hansen@mips.com