Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rice!uw-beaver!uw-june!kolding
From: kolding@cs.washington.edu (Eric Koldinger)
Newsgroups: comp.arch
Subject: Re: RISC vs CISC (rational discussion, not religious wars)
Keywords: Die Space
Message-ID: <9769@june.cs.washington.edu>
Date: 10 Nov 89 09:51:20 GMT
References: <503@ctycal.UUCP> <15126@haddock.ima.isc.com> <28942@shemp.CS.UCLA.EDU> <31097@winchester.mips.COM> <28985@shemp.CS.UCLA.EDU>
Reply-To: kolding@june.cs.washington.edu.cs.washington.edu (Eric Koldinger)
Organization: University of Washington, Computer Science, Seattle
Lines: 39

In article <28985@shemp.CS.UCLA.EDU> frazier@oahu.UUCP (Greg Frazier) writes:
>Yeah, I've been wondering why people are bothering with on-chip
>caches.  Admittedly, a 2-chip CPU would probably be significantly
>more expensive than a single-chip CPU, but I think the product
>would be more flexible, and achieve better performance, if, instead
>of putting the $ on the CPU chip, the $ was provided on a companion
>chip.  This should only increase the latency to the cache by a
>single clock cycle, while significantly boosting the hit ratio.
>Particularly if this were a data $ (leave the instruction $ on
>chip - it belongs there).  With a separate cache chip, one could

    [Greg goes on to explain his logic.]

    Why not provide both on-chip and off-chip cache ($).  In the chip of the
    future, a 50-100Mhz part, keeping the processor fed from an off chip cache
    will be quite a bear.  The off-chip communication speeds are probably going
    to be substantially slower than what you can achieve on-chip, so feeding an
    instruction per cycle into the chip might improve almost impossible,
    especially if you put two CPUs on the chip (as Greg proposes somewhere in
    the article).  Instead, why don't you use a multi-level caching scheme.

    Put a "small" cache on-chip, keep it simple, possibly I-cache only, and
    have a larger backing cache off-chip.  This would allow you to build the
    off-chip cache as large as you like, and still keep the single cycle cache
    access most of the time, with a low (2-4 cycle) delay on most cache misses,
    and a larger delay (multiple bus cycles) when the second level cache
    misses.  You can also place cache-coherency mechanisms in the second level
    cache so that snooping will not cause the CPU to ever be locked out of the
    cache, except in the exceptional event of a cache-coherency action, in
    which case the second level cache can "interupt" the first level cache and
    invalidate any necesary entries.  The second level cache could easily
    service two processors, allowing more versatility than the 2 CPU chip that
    Greg proposes.

-- 
        _   /|                          Eric Koldinger
        \`o_O'                          University of Washington
          ( )     "Gag Ack Barf"        Department of Computer Science
           U                            kolding@cs.washington.edu