Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpfcso!maf
From: maf@hpfcso.FC.HP.COM (Mark Forsyth)
Newsgroups: comp.arch
Subject: Re: HP PA-RISC Cache Question
Message-ID: <8840037@hpfcso.FC.HP.COM>
Date: 18 Jun 91 15:13:00 GMT
References: <1991Jun13.221247.6855@jetsun.weitek.COM>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 23

>From: ram@shukra.Eng.Sun.COM (Renu Raman)
>be found if you plan to use the BIT ECL SPARC processors. One could design
>large caches with ~10ns access time as the processor cycles at 80MhZ.  
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is very impressive. A cycle time overhead of 2.5ns above the SRAM 
access time is hard to beat ! Does this use conventional PGAs or multi-chip
module packaging ? Are the caches direct-mapped or set associative ? Are
the required SRAMs synchronous or asynchronous timing protocol ? Are the 
I/O levels TTL or ECL ?  There have been several published articles 
stating that static RAM speeds would not keep pace with processor speeds 
and that on-chip primary caches would be the only alternative for 
increasing frequency. This example seems to show that cycle times can be very
close to SRAM access times. With 8ns SRAMs (TTL I/O) available and 6ns 
devices undoubtedly just around the corner, and emergence of advanced 
packaging technologies it seems that discrete SRAMs will remain viable 
for primary (one cycle access) cache memories for a few more generations.   
Of course, on-chip caches can have other advantages besides cycle time. 
It would be interesting to see a discussion of performance tradeoffs between
on-chip caches, two-level (1 on-chip, 1 off-chip), and large external
primary caches.


>   Renukanthan Raman				ARPA:ram@sun.com