Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bbn!bbn.com!slackey From: slackey@bbn.com (Stan Lackey) Newsgroups: comp.arch Subject: Re: cache speed Message-ID: <44607@bbn.COM> Date: 22 Aug 89 15:24:31 GMT References: <1473@unocss.UUCP> <3941@phri.UUCP> <1736@crdgw1.crd.ge.com> <1878@brwa.inmos.co.uk> Sender: news@bbn.COM Reply-To: slackey@BBN.COM (Stan Lackey) Organization: Bolt Beranek and Newman Inc., Cambridge MA Lines: 22 In article <1878@brwa.inmos.co.uk> davidb@inmos.co.uk (David Boreham) writes: >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 ? The thing that bothers me is that designers may be trading off access time for cycle time. I read in this n/g that customers demand equal cycle and access times. The only way I can imagine this is that those customers either A) when asked didn't understand the question, B) were nervous about somebody changing something on them, or C) have the fantasy that they're someday going to actually use vanilla SRAMS cycling at their access times (I guess they're either going to get registers with zero prop delays, zero setup times, and distribute clocks with zero skew; or have a brilliant design innovation that in some way breaks a law of physics). Now if the SRAM's had internal registers on address and data, it would be a different matter (actually, some do). Of course, pipelining is required for this to be a useful thing; the registers end up making things worse if the goal is minimum access time at the cost of bandwidth. -Stan