Subject: Re: Second level cache?

From: Andreas Busse <[email-masked]>
Date: Wed, 11 Aug 93 12:19:45 +0200

> I suppose the discussion came becourse there is evidence that cache
> size can influence performens (big news ;^) It is then a natural
> question to ask "Can we have more? How much will it cost?" That the
> ARCset didn't support it was/is non-obvious for the most of us. (Given
> that most of us don't have any info on the ARCset besides what's
> revealed in this forum.)

Yes, of course. I always go this way myself :-) Without asking for
more you'll never get more. 

>  > If you all insist on a 2nd level cache design, we should forget
>  > about the ARCset. That means in turn that we should forget about
>  > having a design within the next 12 months. I'm not sure what then
>  > happens to the group...

> Given this, we proberly don't wan't 2nd level cache, but don't flame
> us for having the discussion.

Sorry, it wasn't meant as flame. I just wanted to stop a discussion
which is substantial in general, but isn't very useful for this
particular design.
I have posted the pin description of the NEC address path controller
so that everybody in the list gets at least the idea of what this
chip does.
If you like, I can also post the pin descr. of the data path
controller. Perhaps things are clearer then.

You all might have noticed that the NEC chip has built-in EISA
support. That does not mean that we have to use EISA as our bus
system. The chip also provides a nearly complete 386 bus, so it
shouldn't be a problem to add some ISA chips.

Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  [email-masked]
-------------------------------------------------------------------------------

---

From: Bill Broadley <[email-masked]>
Date: Wed, 11 Aug 1993 06:38:31 -0500 (EDT)

> shouldn't be a problem to add some ISA chips.

EISA is a pretty good bus, something like 6 times the bandwidth of ISA.

Isn't it completely upward compatible from ISA (i.e. we can use it just
like a ISA bus).

I certainly wouldn't object to an EISA bus on the riscy board, and if
the ARC chips support it it's practically free.

I believe the ARC 100 manufacturing kits include plans for 3 EISA boards
Etherenet/serial, audio/mouse, and video.  Whether we we use any of those
would just be a price/performance decision.

-- 
Bill					1st>	[email-masked]
[email-masked] <2nd 	3rd> 	             [email-masked]
Linux is great.         Bike to live, live to bike.                      PGP-ok

---

From: Dan Fishman <[email-masked]>
Date: Wed, 11 Aug 1993 06:28:29 -0600 (MDT)

> Isn't it completely upward compatible from ISA (i.e. we can use it just

Yes, EISA is totally upward compatible with ISA.  It has a max clock rate the
same as ISA (8.xxx Mhz I believe) but it has 4byte transfer capability to
get to somewhere around 30+ MB/sec trasnfer rates.  This rate is good enough
for most high speed IO with the possible exceptions of video and future high
speed LANs (FDDI...).

> the ARC chips support it it's practically free.

I strongly agree.  If it has EISA then that implies ISA support for free and
EISA is good enough reason to go with it.

> would just be a price/performance decision.

P.S.  What is the overall status of this effort.  I haven't followed closely
but I gather that it is still in discussion and planning stages apparently
discarding R3000 architecture for R4000.  I agree with the decision, but 
keep in mind that this market move incredibly fast these days.  Discuss, plan,
strategize for a few months and a whol new set of options become available.

Let's get this going!  Not to decide is to decide!  Power to the people...
(sorry I'm back now!  whew I was stuck in the sixties for a minute).

Dan Fishman ([email-masked]) (W) (303) 469-6469 (Fax) (303) 465-4396