Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!ukc!inmos!braa!davidb From: davidb@braa.inmos.co.uk (David Boreham) Newsgroups: comp.arch Subject: Re: cache speed Message-ID: <1878@brwa.inmos.co.uk> Date: 21 Aug 89 14:49:54 GMT References: <1473@unocss.UUCP> <3941@phri.UUCP> <1736@crdgw1.crd.ge.com> Sender: news@inmos.co.uk Reply-To: davidb@inmos.co.uk (David Boreham) Organization: none Lines: 29 In article mccalpin@masig3.ocean.fsu.edu (John D. McCalpin) writes: >In article <1736@crdgw1.crd.ge.com>, Dennis O'Connor writes: >>Summary : it's currently impossible to build a 16-megabyte NMOS, >>CMOS, or TTL memory system with a 25ns access time. But with a good >>cache design, you can build a system with almost the same performance. > >Well, it is not exactly 25ns, but each of the 4 cpu's of our ETA-10G >at FSU has 32MBytes of 30ns CMOS SRAM. The time required for a load >is about 6 cycles, at 7ns/cycle. Deleting the instruction issue time >(1-2 cycles?), this is getting awfully close to 30ns. >They never could get the 128MByte memory arrays working at 7ns.... > >-- >John D. McCalpin - mccalpin@masig1.ocean.fsu.edu - mccalpin@nu.cs.fsu.edu > mccalpin@delocn.udel.edu Are you sure that the actual *memory* subsystem was cycled in 30ns ? As the previous poster pointed out, you can get 20--25ns SRAMs, but to build a 32Mbyte system which randomly cycles in 30ns, using CMOS sounds rather unlikely. Perhaps the memory is interleaved ? Also, surely the instruction fetch would be pipelined to overlap with the previous instruction ? Anyway, I wonder how many others share my concern that SRAM designers work to achieve cycle times equal to the access times, whereas very few systems can actually use a cycle time that fast ? David Boreham, INMOS Limited | mail(uk): davidb@inmos.co.uk or ukc!inmos!davidb Bristol, England | (us): uunet!inmos-c!davidb +44 454 616616 ex 543 | Internet : @col.hp.com:davidb@inmos-c