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