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: Why is SPARC so slow? Message-ID: <140@imagine.PAWL.RPI.EDU> Date: 13 Dec 87 13:02:20 GMT References: <1078@quacky.UUCP> <8809@sgi.SGI.COM> <1941@ncr-sd.SanDiego.NCR.COM> <1111@mips.UUCP> Sender: news@imagine.PAWL.RPI.EDU Reply-To: beowulf!lunge!jesup@steinmetz.UUCP Organization: RPI Public Access Workstation Lab - Troy, NY Lines: 51 Keywords: RISC, R2000, SPARC In article <1111@mips.UUCP> elh@mips.UUCP (Ed Hudson) writes: >>>This is indeed true. The price the R2000 pays for this is a complex >>clocking scheme whereby a 4 phase input clock at double frequency is >>required in order to control the double cycle external busses. > the cost of the 'complex' interface is a few dollars for > a tapped delay line. pretty cheap for a scheme that allows > sufficient control of the processors' io timings well enough > to double the available pin bandwidth with moderately cheap, > fast srams. further, in chip and package design, it's the io > transistions themselves that are expensive, the rate of the > transitions is secondary. >>Since at 16.7 MHz the R2000's I/O interface runs at 33.3MHz it remains to >>be seen whether the H/W architecture of the R2000 is scaleable - can it be >>carried to 25-30MHz where the bus must run at 50-60MHz ? > 20ns ttl-io srams today support transaction rates of 50mhz, and 15ns > rams hit 67mhz. although a full cpu subsytem is a little more > demanding, this is indicative of what is technologically possible. > the current r2000 interface was the result of carefull optimization > between the cpu subsystem (ie, 16-64k cache rams, AS ttl), 1985 cpu > process and packaging technology. i expect that future mips implement- > ations will also be similar optimizitions of the then available > technologies. 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. 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. One of the prime considerations in state-of-the-art RISC design today HAS to be chip-edge bandwidth, how to improve it and how to minimize it's usage (conserve it). Even going to off-chip cache is expensive at these speeds. I suspect you'll be seeing interesting attempts in this area soon. // 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)