Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!prls!mips!elh From: elh@mips.UUCP (Ed Hudson) Newsgroups: comp.arch Subject: Re: Why is SPARC so slow? Message-ID: <1111@mips.UUCP> Date: 12 Dec 87 22:09:08 GMT References: <1078@quacky.UUCP> <8809@sgi.SGI.COM> <1941@ncr-sd.SanDiego.NCR.COM> Reply-To: elh@mips.UUCP (Ed Hudson) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 46 Keywords: RISC, R2000, SPARC In article <1941@ncr-sd.SanDiego.NCR.COM> dennisr@ncr-sd.SanDiego.NCR.COM writes: >In article <8809@sgi.SGI.COM> baskett@baskett writes: >>both loads and stores mean that you can't fetch instructions. The R2000 >>also has a single address bus and a single data bus but it can use them >>twice per cycle. This means you can then split your cache into an >>instruction cache and a data cache and make use of the extra bandwidth >>by fetching an instruction every cycle in spite of loads and stores. >>>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. -Ed Hudson DISCLAIMER: I speak only for myself. elh@mips.com or {ames,decwrl,prls}!mips!elh MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086 (408) 720-1700 -- -Ed Hudson DISCLAIMER: I speak only for myself. elh@mips.com or {ames,decwrl,prls}!mips!elh MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086 (408) 720-1700