[Top] [All Lists]

Re: Second level cache?

To: riscy@pyramid.com
Subject: Re: Second level cache?
From: Drew Eckhardt <drew@romeo.cs.Colorado.EDU>
Date: Tue, 10 Aug 1993 05:06:32 -0600
In-reply-to: Your message of "Tue, 10 Aug 1993 09:29:38 +0200." <9308100729.AA24344@neptune>
Reply-to: riscy@pyramid.com
Sender: owner-riscy@pyramid.com
    > It could be configurable (ie, my i386 uses jumpers), the question is 
    > can a second level cache be done within the constraints of our
    > cost design goal.
    What is our cost design goal?  $2000 US?  Less?  More?

From what I remember, discussions on the mailing list have placed this 
somewhere between $600 and $800 for a mainboard with dumb frame 
buffer (using MAC VRAM SIMMs), SCSI, serial ports, parallel
ports, IDE, and ethernet onboard, where some unpopular 
features (ethernet has been named as the first thing to
go in the base configuration) may be designed in but the 
sockets left empty to facilitate meeting this goal.
    > R4x00 SC and MC chips include support for a second level cache, ie you 
    > throw enough SRAM on for tag, tag ECC, data, and data ECC with a 
    > few PALs for address decode and have it.  However, preliminary reports 
    > indicate the 4000SC has a ~$600 price tag rather than ~$300 for the 
    > 4000PC, meaning using an SC is not practical in our design entirely
    > because of the cost constraint.
    For low cost, I would not think about the SC/MC chips.  They have
    400+ pins, and that will be a nightmare to make a cheap board out of.

That's about what I was getting at.
    I was more thinking along the lines of a 4000PC, with an external
    cache controller.  I don't know if it's possible, but that would
    take our pin count down to ~180 pins...

I had been thinking along the same lines, but don't know 
how practical it would be.

Existing cache sets aren't likely to directly support the r4000 system
interface, (64 bit A/D bus + 8 bit parity / ECC + 9 bit command 
bus +  1 bit parity + handshaking signals) since this is a departure
from other systems, the chips are new, and the high end chips that
will be using external caches allready support them.

Weather we can force something existing to do what we want is 
another issue - you can ignore the high 32 bits of the address, you 
can disable parity/ECC checking, can mangle various read and write 
commands to look like what the external cache controller expects,
the 4000 chips flag the last read/write in a burst transfer so bursts
could be handled with counter latched when the address was specified, 
incrementing on each read/write handshake, etc. but the external logic to 
do all of this will increase propogation delays which might make it 
impossible with the parts when can afford.

Another alternative would be be having what passes as a memory
controller in the talk to some other cache/memory controller
instead of DRAM, again, you can't say that it will work until
you see what the timing looks like.

IMHO : a lot of things would be "neat," ie the second level
cache, but no one has suggested chips that would be useful, with 
pricing for said chips to determine weather they work for 

Waiting for an initial lead on these chips to drop out of thin air
(as was the case with the 4200 with someone stumbling across a MIPS 
press on the net, other people following up on NEC second sourcing
them, and people on the list finally ending up with more solid data
some time later) will take a random, potentially infinite amount
of time :-)

IMHO : We need to get parts and prices so their feasibility can be studied
before a design is done, or we need to go ahead with a design so us
software people have something to play with.

    |Tobias Weingartner  |    PGP2.x Public Key available at     |
    | +41'01'254'7205    |   'finger weingart@tau.inf.ethz.ch'   |
    %SYSTEM-F-ANARCHISM, the operating system has been overthrown



<Prev in Thread] Current Thread [Next in Thread>