[Top] [All Lists]

Re: Second level cache?

To: riscy@pyramid.com
Subject: Re: Second level cache?
From: weingart@inf.ethz.ch
Date: Tue, 10 Aug 93 15:05:22 +0200
In-reply-to: Your message of "Tue, 10 Aug 93 05:06:32 MDT." <199308101106.AA17966@romeo.cs.Colorado.EDU>
Reply-to: riscy@pyramid.com
Sender: owner-riscy@pyramid.com
You write: 
Sie schreiben: 

>     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.

Ok, junk the IDE.  I realize that you can get cheap IDE drives, etc,
but SCSI is getting pretty cheap too, and fast SCSI would be pleanty fast
for a *personal* machine.  Then again, if it only costs a cent or two,
why not keep it in.  Make the PC dudes happy.

I'd definitely want to be able to use ethernet.  Wether that will be add
on, or not is a money issue (I persume).  The machine becomes next to
unusable to me if I have to resort to SLIP over a slow link...

(What type of ethernet connector would this 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.

What sort of bandwidth does the R4kPC need?  How about some real
figures, using from 1 - N waitstates, from 0 - 100 MHz, etc.  I don't
have a databook handy, so can someone look them up?

> 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.

Hmm, does MIPS (or an alternative manufacturer) offer a DRAM controller
that directly interfaces to the R4kPC?  That might be the cheapest
(maybe fastest too) way to go.

Maybe a more cost effective alternative (already mentioned once) would be
to just interleave the DRAM.  Not as "neat" as a cache, but if we need to
keep cost down below US$800...

> 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.

I agree with the first version of this.  This way the design will not change
once it is laid down.  That way the software does not have to be kludged to
fit later.  From working on PC systems, I find a lack of percise (sp?) and
clear documentation to be the biggest stumbling block.  IE: How can you port
an OS, if you don't have the specs to the machine?

|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>