🚀 go-pugleaf

In comp.arch, mash@mash.wpd.sgi.com (John R. Mashey) writes:

> In article <1992Oct29.032903.22340@cc.gatech.edu>, lyman@cc.gatech.edu (Lyman S. Taylor) writes:
> |> In article <lese5mINN6ju@exodus.Eng.Sun.COM> ram@shukra.Eng.Sun.COM (Renu Raman) writes:
> 
> |> >    Tsunamis or QED parts. Clearly HPs move away from integration of
> |> >    on-chip caches is very apparent still. One wonders why?
> |> 	
> |> 	Maybe they like designing CPUs more than memories. :-)
> |> 	[ Does HP make SRAM?  They build PA modules anyway so as long
> |> 	  as they get decent performance out of the 'package'.... last time I 
> |> 	  logged into a "Snake" it poked along at a pretty good pace. ]
> 
> There is a fairly consistent viewpoint:
> 1) People who don't sell SRAMs usually use off-chip SRAMs, or use 6T
> cells for on-chip caches.
> 2) People who sell SRAMs and build microprocessors usually use 4T cells
> for on-chip caches, right now.
> 3) As far as I know, HP doesn't build SRAMs.
> 4) There are legitimate technical reasons for liking bigger off-chip caches ...
> on the other hand, if one can keep increasing the on-chip cache size,
> without using too much of the die space, because one has SRAM processes,
> that's a pretty good choice from cost and flexibility reasons.
> In general, both approaches are rationally argued from the point of view
> of what technology the arguer has...  which once again reminds one that
> archiecture and implementation are *not* independent variables.
>
In HP's case, I don't think that lack of SRAM technology is the main 
reason for implementing off-chip caches, as the previous post implies.  
Embedded SRAM can and has been used in custom chips built by HP for other 
purposes.  Most good CMOS processes with relatively fine-pitch metal are 
adequate for 6T SRAM (IBM uses 6T cells and has the densest on-chip cache 
I've seen yet).  The reasons that were given at the conference are related 
to performance and system design flexibility.  On-chip caches are still 
constrained in size by practical limits of IC technologies and die sizes 
(although IBM's 601 shows that the limit is moving VERY quickly !).  The 
largest on-chip cache today is still smaller than the smallest cache size 
used in HP workstations.  Some benchmarks perform well in small caches but 
many applications don't.  Larger caches can give more consistent performance 
across applications.  Adding a large second level cache to a small on-chip 
cache does not solve the problem since the second-level caches generally 
have several cycle access times and performance can be dominated by the 
overhead of servicing first-level cache misses.  External caches are also
necessary to allow system designers the flexibility to choose the primary 
cache size.  Designers of multiuser or high-end systems generally want much 
larger caches than workstation designers need.  On-chip caches are best for 
area and power critical applications that are less performance sensitive 
today but are certainly becoming more interesting for high performance 
applications as the density of VLSI technologies increases.

I think that cache design choices are really more of a function of what 
price/performance points the designer is trying to reach rather than what
technologies are available - most companies have or can get access to 
similar technologies these days.  Cheers.

- mark forsyth (my opinions, not HP's)
  maf@fc.hp.com