🚀 go-pugleaf

In article <51@microsoft.UUCP> w-colinp@microsoft.uucp (Colin Plumb) writes:
...
>I think the MIPS approach is the best: MMU and cache *control* on chip;
>the actual data (which can be a trifle slower) can be put in external
>SRAM.  SRAMs have a large market, so even ultra-fast ones are comparatively
>cheap.  Associative memory is much more expensive.
>
>I've said it before: I'm *astounded* nobody else has used this idea.
>It's such a great Win.  Cache control is the custom bit, so do it
>in custom logic.  With all the rest of the custom logic: on the
>microprocessor.  Cache RAM is very generic.  So don't re-invent the
>wheel.
>
>Has anyone out there (other than MIPS, of course) considered this scheme
>and then rejected it?  Is my enthusiasm blind to some Great Problem?
>-- 
>	-Colin (uunet!microsoft!w-colinp)
>
>"Don't listen to me.  I never do." - The Doctor

I agree that the MIPS scheme is nice, but it does have its drawbacks.  In
particular, they've fixed the cache control.  If they got it right (for your
application) then no problem.  Otherwise you're out of luck.  It would be
possible to make some of the details configurable, but I believe that MIPS 
doesn't allow this.

If I remember right (somebody borrowed my MIPS book so I can't verify), the 
MIPS cache control requires a write-through cache.  Personally, I don't want 
a write-through cache.  Another aspect is the write latency (i.e. how many 
cycles does your cache take to handle a write-hit?).  I think the MIPS 
controller assumes a single cycle.  This implies you've got to build a cache
to handle this, and this will get trickier when you can buy a 40 or 50MHz MIPS.

--
Mike Carlton, UC Berkeley Computer Science
Home: carlton@ji.berkeley.edu or ...!ucbvax!ji!carlton