From owner-riscy@pyramid.com  Mon Aug  9 10:57:46 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA04974; Mon, 9 Aug 93 10:57:46 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA14529; Mon, 9 Aug 93 07:56:01 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA25017; Mon, 9 Aug 93 07:54:04 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA25010; Mon, 9 Aug 93 07:54:02 -0700
Received: from neurocog.lrdc.pitt.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA14466; Mon, 9 Aug 93 07:54:56 -0700
Message-Id: <9308091454.AA14466@gossip.pyramid.com>
Received: by neurocog.lrdc.pitt.edu
	(1.37.109.4/16.2) id AA04093; Mon, 9 Aug 93 10:52:43 -0400
From: Bill Broadley <broadley@neurocog.lrdc.pitt.edu>
Subject: Second level cache?
To: riscy@pyramid.com (Mips 3000)
Date: Mon, 9 Aug 1993 10:52:43 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 950       
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Somebody mentioned that some research needs to be done on how a second level 
cache will effect performance.  Any suggestions on how to do this?

Based on observation it seems that a cache is worth it, SGI mips 4000 SC is
around 35/34 and the mips 4000 PC is around 60/58 specint/specfp.

Adding the decreased locality of Unix+X11 over dos, the higher (100 Mhz
internal) clock rate, and mips binaries being bigger then 486 it would
seem that a large secondary cache would be necessary.  Based on a 486's
secondary cache being useful.

Any suggestions on how to get some numbers experimentally?

I have a decstation 3100 running Ultrix, and a 486/66 running linux
available for any attempts to quantify the advantages of second level
cache's.

--
Bill					1st>	Broadley@neurocog.lrdc.pitt.edu
Broadley@schneider3.lrdc.pitt.edu <2nd 	3rd> 	             Broadley+@pitt.edu
Linux is great.         Bike to live, live to bike.                      PGP-ok
 
From owner-riscy@pyramid.com  Mon Aug  9 11:18:51 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA06214; Mon, 9 Aug 93 11:18:51 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17032; Mon, 9 Aug 93 08:18:48 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA28631; Mon, 9 Aug 93 08:17:20 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA28624; Mon, 9 Aug 93 08:17:18 -0700
Received: from boulder.Colorado.EDU 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16951; Mon, 9 Aug 93 08:18:20 -0700
Received: from agua.Colorado.EDU by boulder.Colorado.EDU with SMTP id AA16600
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Mon, 9 Aug 1993 09:16:00 -0600
Received: by agua.colorado.edu (cu.generic.890828)
Date: Mon, 9 Aug 93 09:13:39 MDT
From: Alan Krantz <atk@agua.Colorado.EDU>
Message-Id: <9308091513.AA10979@agua.colorado.edu>
To: riscy@pyramid.com
Subject: Re:  Second level cache?
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

  > From owner-riscy@pyramid.com Mon Aug  9 08:53:13 1993
  > Status: R

  > Somebody mentioned that some research needs to be done on how a second level 
  > cache will effect performance.  Any suggestions on how to do this?

  > Based on observation it seems that a cache is worth it, SGI mips 4000 SC is
  > around 35/34 and the mips 4000 PC is around 60/58 specint/specfp.

  > Adding the decreased locality of Unix+X11 over dos, the higher (100 Mhz
  > internal) clock rate, and mips binaries being bigger then 486 it would
  > seem that a large secondary cache would be necessary.  Based on a 486's
  > secondary cache being useful.

The subject isn't that simple. For example the usefulness of the cache 
greately depends on how the memory is interleaved (the R4xxx has an external
64 bit path way). Also there is an issue of the internal cache size. An
internal cache on a 486 is 16k (I think 8k each for I&D) (but writethrough not
write back). The R4xxxx has a larger internal cache.

  > Any suggestions on how to get some numbers experimentally?

Yea build an R4000 system with the desired level of interleaving; one with
and one without secondary cache. Then run both systems :)


 
From owner-riscy@pyramid.com  Mon Aug  9 11:23:55 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA06832; Mon, 9 Aug 93 11:23:55 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17679; Mon, 9 Aug 93 08:23:50 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA29178; Mon, 9 Aug 93 08:22:38 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA29171; Mon, 9 Aug 93 08:22:36 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17671; Mon, 9 Aug 93 08:23:35 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id GO10729; Mon, 9 Aug 1993 17:19:15 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA25027; Mon, 9 Aug 93 17:20:23 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA00925; Mon, 9 Aug 93 17:20:14 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Mon, 9 Aug 93 17:19:20 +0200
Message-Id: <9308091519.AA19828@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA19828; Mon, 9 Aug 93 17:19:20 +0200
To: riscy@pyramid.com
Subject: Re:  Second level cache?
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


> Somebody mentioned that some research needs to be done on how a second level 
> cache will effect performance.  Any suggestions on how to do this?
> 
> Based on observation it seems that a cache is worth it, SGI mips 4000 SC is
> around 35/34 and the mips 4000 PC is around 60/58 specint/specfp.

Yes, although these numbers seem to mixed-up, a secondary cache *would*
improve performance. But: Neither the R4200 nor the Orion will have
secondary cache support. We should better forget about that, otherwise
we'll try to build a high-end thing, which is probably not what we
want...

Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Mon Aug  9 11:25:28 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA06948; Mon, 9 Aug 93 11:25:28 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17990; Mon, 9 Aug 93 08:25:26 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA29320; Mon, 9 Aug 93 08:24:14 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA29300; Mon, 9 Aug 93 08:24:12 -0700
Received: from bernina.ethz.ch 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA17982; Mon, 9 Aug 93 08:25:14 -0700
Received: from neptune by bernina.ethz.ch with SMTP inbound id <3627-0@bernina.ethz.ch>; Mon, 9 Aug 1993 17:24:02 +0200
Message-Id: <9308091523.AA13831@neptune>
Received: from tau.inf.ethz.ch by neptune id AA13831; Mon, 9 Aug 93 17:23:58 +0200
To: riscy@pyramid.com
Subject: Re: Second level cache? 
In-Reply-To: Your message of "Mon, 09 Aug 93 09:13:39 MDT."
	     <9308091513.AA10979@agua.colorado.edu> 
Date: Mon, 09 Aug 93 17:23:56 +0200
From: weingart@inf.ethz.ch
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

You write: 
Sie schreiben: 


>   > Any suggestions on how to get some numbers experimentally?
> 
> Yea build an R4000 system with the desired level of interleaving; one with
> and one without secondary cache. Then run both systems :)

Ok, I'll throw in my ballot for the cache one...

Can I "test-drive" for free?  ;-)


I don't know much about hardware design, but could you design the thing
in such a way that you can plug in cache, when you need it.  IE: if you
don't have the money, the board will run without the SC, and if you do,
you just buy some SRAM, and plug 'er in...

Or will this cause the logic to go beserk?

--Toby.
--------------------------------------------------------------
|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
 
From owner-riscy@pyramid.com  Mon Aug  9 23:58:52 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA11911; Mon, 9 Aug 93 23:58:52 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA26931; Mon, 9 Aug 93 20:58:38 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA05236; Mon, 9 Aug 93 20:57:13 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA05215; Mon, 9 Aug 93 20:57:09 -0700
Received: from romeo.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA26923; Mon, 9 Aug 93 20:58:12 -0700
Received: from localhost by romeo.cs.Colorado.EDU with SMTP id AA14495
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Mon, 9 Aug 1993 21:56:58 -0600
Message-Id: <199308100356.AA14495@romeo.cs.Colorado.EDU>
To: riscy@pyramid.com
Subject: Re: Second level cache? 
In-Reply-To: Your message of "Mon, 09 Aug 1993 09:13:39 MDT."
             <9308091513.AA10979@agua.colorado.edu> 
Date: Mon, 09 Aug 1993 21:56:57 -0600
From: Drew Eckhardt <drew@romeo.cs.Colorado.EDU>
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


    
      > Adding the decreased locality of Unix+X11 over dos, the higher (100 Mhz
      > internal) clock rate, and mips binaries being bigger then 486 it would
      > seem that a large secondary cache would be necessary.  Based on a 486's
      > secondary cache being useful.
    
    The subject isn't that simple. For example the usefulness of the cache 
    greately depends on how the memory is interleaved 

Yes.  2-way interleaving can cut the wait states in half in the 
average case with a cache-miss, 4-way in half again, etc.  However,
the 4000, 4200, and 4400 are all 64 bit chips meaning you need 
a 128 bit wide memory subsystem for 2-way, 256 for 4-way.
    
    Also there is an issue of the internal cache size. An
    internal cache on a 486 is 16k 

No.  The internal cache on an Intel 486 is 8K combined I&D, although
IBM is building it's own 486's that may have a larger internal cache.

    but writethrough not write back. 

Yes.  This is very significant.  Also important are cache interleave,
line size, etc.  

    The R4xxxx has a larger internal cache.

R4000 : 8K I, 8K D
R4400 : 16K I, 16K D

The maximum imposed by the R4000 architecture is 32K each for the primary
cache.  I don't know about the 4200 since I don't have a data book in front
of me like I do for the NEC Vr4000 and Vr4400, PC, SC, and MC variants :-)
    
      > Any suggestions on how to get some numbers experimentally?
    
    Yea build an R4000 system with the desired level of interleaving; one with
    and one without secondary cache. Then run both systems :)

Yep.
    
--------

 
From owner-riscy@pyramid.com  Tue Aug 10 00:10:08 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA12495; Tue, 10 Aug 93 00:10:08 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28420; Mon, 9 Aug 93 21:09:44 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06063; Mon, 9 Aug 93 21:08:31 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06056; Mon, 9 Aug 93 21:08:29 -0700
Received: from romeo.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28412; Mon, 9 Aug 93 21:09:31 -0700
Received: from localhost by romeo.cs.Colorado.EDU with SMTP id AA14595
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Mon, 9 Aug 1993 22:08:22 -0600
Message-Id: <199308100408.AA14595@romeo.cs.Colorado.EDU>
To: riscy@pyramid.com
Subject: Re: Second level cache? 
In-Reply-To: Your message of "Mon, 09 Aug 1993 17:23:56 +0200."
             <9308091523.AA13831@neptune> 
Date: Mon, 09 Aug 1993 22:08:21 -0600
From: Drew Eckhardt <drew@romeo.cs.Colorado.EDU>
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


    I don't know much about hardware design, but could you design the thing
    in such a way that you can plug in cache, when you need it.  IE: if you
    don't have the money, the board will run without the SC, and if you do,
    you just buy some SRAM, and plug 'er in...
    
    Or will this cause the logic to go beserk?

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.

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.

The question becomes : can we meet our cost target by having 
a second level cache *external* to the processor, with low
cost boards shipped with 0K SRAM.

--------

 
From owner-riscy@pyramid.com  Tue Aug 10 00:14:15 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA12651; Tue, 10 Aug 93 00:14:15 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28789; Mon, 9 Aug 93 21:13:34 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06394; Mon, 9 Aug 93 21:12:21 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06387; Mon, 9 Aug 93 21:12:19 -0700
Received: from vanbc.wimsey.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA28778; Mon, 9 Aug 93 21:13:01 -0700
Received: by vanbc.wimsey.com (Smail3.1.28.1)
	id m0oPl3U-0000PZC; Mon, 9 Aug 93 21:11 PDT
Message-Id: <m0oPl3U-0000PZC@vanbc.wimsey.com>
From: bhenning@wimsey.com (Bill Henning)
Subject: Re: Second level cache?
To: riscy@pyramid.com
Date: Mon, 9 Aug 1993 21:11:23 -0700 (PDT)
In-Reply-To: <9308091454.AA14466@gossip.pyramid.com> from "Bill Broadley" at Aug 9, 93 10:52:43 am
X-Mailer: ELM [version 2.4 PL20]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1439      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

> Somebody mentioned that some research needs to be done on how a second level 
> cache will effect performance.  Any suggestions on how to do this?

One data point: 486DX2/66, IBM's CSet/2 compiler, 16Mb ram, 256k L2 cache
compile time is aprox. 2.5x faster with the L2 cache than without.

> Based on observation it seems that a cache is worth it, SGI mips 4000 SC is
> around 35/34 and the mips 4000 PC is around 60/58 specint/specfp.

Agreed.

> Adding the decreased locality of Unix+X11 over dos, the higher (100 Mhz
> internal) clock rate, and mips binaries being bigger then 486 it would
> seem that a large secondary cache would be necessary.  Based on a 486's
> secondary cache being useful.

I would suggest 256k expandable to 1Mb. Maybe someone could run some apps
on the MIPS simulator, and instrument the emulator to record the saved cycles
for caches of different sizes.

> Any suggestions on how to get some numbers experimentally?

See above.

> I have a decstation 3100 running Ultrix, and a 486/66 running linux
> available for any attempts to quantify the advantages of second level
> cache's.

Can you turn its L2 cache off under software/hardware control?
If you can, you might want to try the following with the L2 cache enabled/
disabled, and if you do, please post both sets of numbers:

- recompiling gcc
- cross compiling the Linux kernal
- x11perf
- a database test of some sort
- the Byte unix benchmarks

Bill
 
From owner-riscy@pyramid.com  Tue Aug 10 03:31:11 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA17818; Tue, 10 Aug 93 03:31:11 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21864; Tue, 10 Aug 93 00:31:12 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA00614; Tue, 10 Aug 93 00:29:59 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA00607; Tue, 10 Aug 93 00:29:56 -0700
Received: from bernina.ethz.ch 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21856; Tue, 10 Aug 93 00:30:58 -0700
Received: from neptune by bernina.ethz.ch with SMTP inbound id <17043-0@bernina.ethz.ch>; Tue, 10 Aug 1993 09:29:43 +0200
Message-Id: <9308100729.AA24344@neptune>
Received: from tau.inf.ethz.ch by neptune id AA24344; Tue, 10 Aug 93 09:29:39 +0200
To: riscy@pyramid.com
Subject: Re: Second level cache? 
In-Reply-To: Your message of "Mon, 09 Aug 93 22:08:21 MDT."
	     <199308100408.AA14595@romeo.cs.Colorado.EDU> 
Date: Tue, 10 Aug 93 09:29:38 +0200
From: weingart@inf.ethz.ch
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

You write: 
Sie schreiben: 

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


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

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

--Toby.
--------------------------------------------------------------
|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
 
From owner-riscy@pyramid.com  Tue Aug 10 07:08:09 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA23134; Tue, 10 Aug 93 07:08:09 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10074; Tue, 10 Aug 93 04:08:02 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA25199; Tue, 10 Aug 93 04:06:44 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA25192; Tue, 10 Aug 93 04:06:41 -0700
Received: from romeo.cs.colorado.edu 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA10023; Tue, 10 Aug 93 04:07:43 -0700
Received: from localhost by romeo.cs.Colorado.EDU with SMTP id AA17966
  (5.65c/IDA-1.4.4 for <riscy@pyramid.com>); Tue, 10 Aug 1993 05:06:33 -0600
Message-Id: <199308101106.AA17966@romeo.cs.Colorado.EDU>
To: riscy@pyramid.com
Subject: Re: Second level cache? 
In-Reply-To: Your message of "Tue, 10 Aug 1993 09:29:38 +0200."
             <9308100729.AA24344@neptune> 
Date: Tue, 10 Aug 1993 05:06:32 -0600
From: Drew Eckhardt <drew@romeo.cs.Colorado.EDU>
Sender: owner-riscy@pyramid.com
Reply-To: 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 
us.

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.
































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

--------

 
From owner-riscy@pyramid.com  Tue Aug 10 09:08:11 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA26721; Tue, 10 Aug 93 09:08:11 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20140; Tue, 10 Aug 93 06:07:16 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06938; Tue, 10 Aug 93 06:05:47 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA06931; Tue, 10 Aug 93 06:05:44 -0700
Received: from bernina.ethz.ch 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA20124; Tue, 10 Aug 93 06:06:47 -0700
Received: from neptune by bernina.ethz.ch with SMTP inbound id <800-0@bernina.ethz.ch>; Tue, 10 Aug 1993 15:05:27 +0200
Message-Id: <9308101305.AA27360@neptune>
Received: from tau.inf.ethz.ch by neptune id AA27360; Tue, 10 Aug 93 15:05:23 +0200
To: riscy@pyramid.com
Subject: Re: Second level cache? 
In-Reply-To: Your message of "Tue, 10 Aug 93 05:06:32 MDT."
	     <199308101106.AA17966@romeo.cs.Colorado.EDU> 
Date: Tue, 10 Aug 93 15:05:22 +0200
From: weingart@inf.ethz.ch
Sender: owner-riscy@pyramid.com
Reply-To: 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?


--Toby.
--------------------------------------------------------------
|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
 
From owner-riscy@pyramid.com  Tue Aug 10 09:52:23 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA28609; Tue, 10 Aug 93 09:52:23 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21783; Tue, 10 Aug 93 06:52:10 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10252; Tue, 10 Aug 93 06:50:57 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA10245; Tue, 10 Aug 93 06:50:55 -0700
Received: from fngate.fnal.gov 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA21772; Tue, 10 Aug 93 06:51:58 -0700
Received: by fngate.fnal.gov (5.57/Ultrix3.0-C)
	id AA06101; Tue, 10 Aug 93 08:50:47 -0500
Received: by fncrdg.fnal.gov (920330.SGI/890607.SGI)
	(for ) id AA22261; Tue, 10 Aug 93 08:48:24 -0500
From: rohrer@fncrd8.fnal.gov (Keith Rohrer)
Message-Id: <9308101348.AA22261@fncrdg.fnal.gov>
Subject: Re: Second level cache?
To: riscy@pyramid.com
Date: Tue, 10 Aug 1993 08:48:23 -0600 (CDT)
In-Reply-To: <9308101305.AA27360@neptune> from "weingart@inf.ethz.ch" at Aug 10, 93 03:05:22 pm
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1228      
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

[as elm fries attributions]
> >     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,
Junk IDE as built-in to the mainboard, but don't forget the ISA bus!
Unless, as is said later, the IDE-on-the-motherboard is dirt cheap,
nobody really needs it; on the other hand, for expansion, lots of
us want or need ISA...

> but SCSI is getting pretty cheap too, and fast SCSI would be pleanty fast
For me, the cost of SCSI would be the cost of replacing ~450 megabytes of
hard drive.  Not happening.  Sorry.
> for a *personal* machine.  Then again, if it only costs a cent or two,
> why not keep it in.  Make the PC dudes happy.
You mean, don't invalidate some people's current investment?

[deletia]
 
	Keith


 
From owner-riscy@pyramid.com  Tue Aug 10 14:18:21 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA12289; Tue, 10 Aug 93 14:18:21 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA04308; Tue, 10 Aug 93 11:17:53 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16542; Tue, 10 Aug 93 11:16:29 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16534; Tue, 10 Aug 93 11:16:26 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9308101816.AA16534@sword.eng.pyramid.com>
Subject: Re: Second level cache?
To: riscy@pyramid.com
Date: Tue, 10 Aug 93 11:16:25 PDT
In-Reply-To: <199308101106.AA17966@romeo.cs.Colorado.EDU>; from "Drew Eckhardt" at Aug 10, 93 5:06 am
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

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

What I understand is that the ARC chipset supports a secondary cache
similar to the way it does for the 486.  It is not necessary to use
the cache support signals from the R4k to have a secondary cache, although
it may mean that this cache will take two cycles to access data where
the R4000SC cache would take one.  This may not be great, but it is still
better than the cycles required to get data from DRAM.

Note that I am guessing about the timing issue; it may be that the ARC
chipset's cache logic can handle one cycle access.

With the ARC chipset's arangement, it is possible to add cache the same
as you would with a 486 MB; probably using the same cache chips.

BTW, Pyramid has a R4000MC machine, which uses the maximum 4Mbytes of
secondary cache.  I will ask if anyone has done some serious benchmarks
on how well this works.

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

I, like quite a few others on this list, am hassling a distributor about
the NEC r4k.  I am having just as much joy as everyone else - none... ;-(
My personal opinion is that the R4k + ARC is the best solution that we
have.  Unfortunately, we cannot do anything without that information.
Stay tuned; when the manufacturers are forthcomming with the data,
we will be forthcomming with a board.

-- 
Neil Russell		(The wizard from OZ)
Pyramid Technology			Email:  caret@pyramid.com
3860 N. First Street			Voice:  (408) 428-7302
San Jose, CA 95134-1702			  FAX:  (408) 428-8845
 
From owner-riscy@pyramid.com  Tue Aug 10 16:19:37 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA20185; Tue, 10 Aug 93 16:19:37 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15149; Tue, 10 Aug 93 13:18:26 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02475; Tue, 10 Aug 93 13:16:54 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA02461; Tue, 10 Aug 93 13:16:51 -0700
From: caret@pyramid.com (Neil Russell)
Message-Id: <9308102016.AA02461@sword.eng.pyramid.com>
Subject: Re: Second level cache?
To: riscy@sword.eng.pyramid.com
Date: Tue, 10 Aug 93 13:16:51 PDT
In-Reply-To: <9308101415.AA14388@cbfsb.cb.att.com>; from "Stephen P Hill +1 708 979 0366" at Aug 10, 93 2:12 pm
X-Mailer: ELM [version 2.3 PL11]
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Stephen P Hill writes:

> My $0.02:
> 
> A second level cache would be really, really nice.  But it sounds 
> like it will be out of our price range.  Unless it proves 
> (somehow) to be cheep to have an unpopulated 2nd level cache 
> on the board, it is time to forget it.

From what I understand, the ARC chipset provides secondary cache
support.  So we could easily end up with unpopulated 2nd level
cache sockets for very small additional cost.

-- 
Neil Russell		(The wizard from OZ)
Pyramid Technology			Email:  caret@pyramid.com
3860 N. First Street			Voice:  (408) 428-7302
San Jose, CA 95134-1702			  FAX:  (408) 428-8845
 
From owner-riscy@pyramid.com  Wed Aug 11 05:54:39 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA18248; Wed, 11 Aug 93 05:54:39 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16012; Wed, 11 Aug 93 02:54:14 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15629; Wed, 11 Aug 93 02:52:54 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA15620; Wed, 11 Aug 93 02:52:51 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA15998; Wed, 11 Aug 93 02:53:50 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id IZ02343; Wed, 11 Aug 1993 11:49:25 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA05120; Wed, 11 Aug 93 11:49:35 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA14282; Wed, 11 Aug 93 11:50:00 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Wed, 11 Aug 93 11:49:06 +0200
Message-Id: <9308110949.AA22367@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA22367; Wed, 11 Aug 93 11:49:06 +0200
To: riscy@pyramid.com
Subject: Re: Second level cache?
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


> What I understand is that the ARC chipset supports a secondary cache
> similar to the way it does for the 486.  It is not necessary to use
> the cache support signals from the R4k to have a secondary cache, although
> it may mean that this cache will take two cycles to access data where
> the R4000SC cache would take one.  This may not be great, but it is still
> better than the cycles required to get data from DRAM.

I really wonder from where the information comes that ARCset supports
any kind of 2nd level cache in its *true* sense.
I had a closer look the uPD31432 (Adress Path Controller) data sheet.
Quoted (Page 58,59):

5.1 Memory Interface Signal SUmmary

Signal Name		Description

MADR[10:0]		Multiplexed row and column adress lines.
			Shared with video interface.
/MRAS[3:0]		Early Memory Row Adress Strobe. [...]
/MEM_CAS[A:D]		Four identical copies of early memory
			Column Adress Strobes. [...]
/MWR_CMD		Memory Write Command.
MEM_DATA_OE		The uPD31431 memory data lines output enables.
MEM_DATA_LE		[...] Data latch enables [...]
/B_MASK			Time multiplexed byte mask lines. Used during
			memory and video partial write operations
			originating at Vr4000. Also used for I/O operations.
BM_PHASE		Signal to provide the phase information required
			to demultiplex the B_MASK line. [...]

5.2 uPD31432 Video Interface Signal Summary

Signal Name		Description

VIDEO_CMD[2:0]		Video command bus - Identifies the current
			command being sent to the video interface.
			[...]
VIDEO_ADR10		Video adress bit 10 is used with MADR[10:0] to
			provide a time multiplexed 20bit adress to the
			video interface.
VIDEO_RDY		Video ready is used by the video controller to
			inform the uPD31432 chip that is has completed
			the requested operation.

5.3 Memory System Transfers

Memory Operation	 Description

32 byte read		Vr4000 32 byte cache block fill. [...]
			I/O cache fill operation.
16 byte read		Vr4000 16 byte cache block fill. [...]
32 byte write		Vr4000 32 byte cache block flush. [...]
			I/O full cache line flush
16 byte write		Vr4000 16 byte cache block flush. [...]
Read modify write	Vr4000 write partial [...]
			I/O partial cache line flush
Memory Refresh		Refresh timing set in Refresh Rate Register

[end of qouted material]

Please note those I/O cache operations. These are operations are
I/O caching, what means that 32byte-blocks of data to be transfered
from or to I/O is cached in main memory.
This has ***nothing*** to do with 2nd level cache.
Next thing: The memory interface is a *true* DRAM interface.

Again, quoted from the data sheet. Here's the complete pinout:
[Page 147ff]

Signal Name		I/Otype	Description

R4000_DAL[32:00]	I/O	Vr4000 mux'ed data/adress lines
R4000_CMD[8:0]		I/O	Vr4000 system interface command bus.
R4000_CMDP		I/O	Single bit even parity for command bus.
/R4000_EXTRQST	        OUT	This is the external request line to
				the Vr4000 processor. [...]
/R4000_RELEASE		IN	Vr4000 release indicates that Vr4000
				has released the bus.
/R4000_RDY		OUT	Asserted by uPD31432 when ready to
				accept a R4000 command.
/R4000_VALID_IN		OUT	The uPD31432 asserts this signal when
				driving a command or data on the
				Vr4000 interface.
/R4000_VALID_OUT	IN	The Vr4000 asserts this signal when
				driving a command or data on the
				Vr4000 interface.
R4000_RCLOCK		IN	50 MHz receive clock
R4000_TCLOCK		IN	50 MHz transmit clock
/B_MASK[7:0]		OUT	Contains the byte mask information
				used during write partials [...]
BM_PHASE		OUT	Used to demultiplex /B_MASK[7:0]
CACHE_OP[2:0]		OUT	uPD31432 control bus used to control
				the I/O cache.
BLK_NUM[2:0]		OUT	I/O Cache block number selects one of
				eight cache blocks for current operation.
C_LINE			OUT	The cache line selects the 128 bit cache
				line in the cache block selected by
				BLK_NUM.
DMA_BANK_SEL		OUT	The DMA bank select is used to select
				a 64bit quantity from the selected
				cache line.
C_LTCH_EN		OUT	The cache latch enable is used as the
				latch enable for the selected cache data.
R4000_DP_OD[1:0]	OUT	The R4000_DAL output enable is used to
				turn off the the Vr4000 system bus drivers.
IO_OP[2:0]		OUT	These lines contain encoded control
				information from the uPD31432 to configure
				the uPD31431 chips during 386 bus operations.
/INTR1			IN	Vr4000 interrupt level 1
/INTR2			IN	Vr4000 interrupt level 2
/INTR3			IN	Vr4000 interrupt level 3
/INTR5			IN	Vr4000 interrupt level 5
/MCT_INTR		OUT	I/O DMA channel interrupt
/TIMER_INTR		OUT	Interval Timer Interrupt
TIMER_CLK		IN	Interval Timer base clock
BANK_SEL		OUT	This signal is used to select a 64 bit bank
				out of the 128bit memory line to drive on
				the R4000_DAL.
WMEM_STATE[2:0]		OUT	uPD31431 Vr4000 write buffer control bus.
PAR_ERR[1:0]		IN	Memory parity error lines from each of the
				two datapath chips.
/MRAS[3:0]		OUT	Main memory row adress strobe lines
/MWR_CMD		OUT	Main memory read/write control line.
/MEM_CAS[A:D]		OUT	Four copies of the same main memory
				DRAM column adress strobe.
MEM_DATA_OE		OUT	The uPD31431 memory data output enable
MEM_DATA_LE		OUT	Memory data latch enable controls the
				uPD31431 memory data latches. [...]
MADR[10:0]		OUT	Memory adress lines are multiplexed
				system memory DRAM row and column address
				lines.
VID_ADR10		OUT	Video address bit 10, used with MADR[10:0]
				to from complete video address bus.
VIDEO_CLK		OUT	25 MHz output signal used to drive the
			        video interface
VIDEO_CMD[2:0]		OUT	Video command is used to encode the video
				interface control bus.
VIDEO_RDY		IN	Video ready is used by the video system to
				respond to a uPD31432 video command.
CLK386			OUT	25 MHz (1/2 R4000_TCLOCK) clock used as
				the 386 bus clock.
H386_ADR[23:02]		I/O	I/O adress bus. It is also used to source
				a 3 bit encoded DMA acknowledge packet
				during local DMA operations [...]
/H386_ADS		I/O	I/O bus address strobe.
/H386_BE[3:0]		I/O	I/O bus byte enables.
/H386_M_IO		OUT	I/O bus control signal; used to select
				between 386 I/O bus I/O or memory space.
/H386_RDY		I/O	I/O bus slave ready signal. [...]
/H386_BUS_ERROR		OUT	I/O bus error signal. [...]
/H386_W_R		I/O	I/O bus read and write line. [...]
/H386D_C		OUT	I/O bus command line. Selects between
				normal data cycles and command cycles.
				Used only to perform a 386 compatible
				interrupt acknowledge signal.
ADR[1:0]		OUT	The signals provide the low two addresses
				used by local I/O devices.
DMA_REQ[7:0]		IN	These DMA request lines are used by the
				local DMA devices to signal the availability
				to accept or deliver data.
LDMA_TC			OUT	Local DMA terminal count is used to signal
				the acknowledged DMA operation has reached
				its terminal count. [...]
/DMA_ACK_CNT		OUT	This signal is used to control the assertion
				of the local device DMA line selected with
				H386_ADR[4:2]
/LOCALIO		OUT	Local I/O is used to control the assertion
				of the local device chip select selected
				with H386_ADR[23:20]
/SLAVE_RD		OUT	Local device read strobe.
/SLAVE_WR		OUT	Local device write strobe.
L_HLDA			OUT	LAN hold acknowledge. Used by the address
				chip to grant a requesting local bus master
				the remote bus.
L_HOLD			IN	The LAN; used by a remote bus master to
				request control of the remote bus.
EISA_BCLK		IN	EISA bus clock; received by the address chip
				to synchronize EISA control lines and
				operations.
E_HLDA			OUT	EISA hold acknowledge; used to grant the
				EISA chip set to take control of the remote
				I/O bus.
E_HOLD			IN	The EISA hold is used by the EISA chipsets
				to request control of the remote I/O bus.
HGT16M			IN	EISA address greater than 16MBytes. [...]
/REFRESH		IN	EISA refresh signal. [...]
/IO_BUS_REQ		OUT	I/O bus request. [...]
/EISA_CMD		IN	EISA command line. [...]
/EISA_EXRDY		OUT	EISA ready signal. [...]
/EISA_HLOCMEM		OUT	Driven when an EISA transfer into system
				memory is recognized. [...]
EIS_MBURST		IN	EISA master burst. [...]
EISA_START		IN	EISA start. [...]
/RESET			IN	Chip reset signal.
TEST			IN	Chip test signal.
/MACHCHK		OUT	Machine check interrupt is used to signal
				a catastrophic system error.

[end of qouted material]

Next, we have a look at the data path controller, uPD31431.
The data sheet tells us that this chip contains the I/O cache buffers
mentioned earlier.

qouted from the spec sheet, page 7:

3.4 I/O cache buffers
The I/O cache buffers provide the data storage for eight 128bit bidirectional
data buffers. The cache buffer has a 32bit read/write portto the I/O remote
bus and provide a 64bit bidirectional port to the memory data lines. [...]

[end of quoted material]


I hope it's clear now that this chip set *DOES NOT* support 2nd level
cache. What it does is providing a cache subsystem for I/O operations
which is a good idea, but has nothing to do with 2nd level cache.


Andy

-------------------------------------------------------------------------------
        Waldorf Electronics GmbH        | Phone:  +49 (0)2636-80294
              R&D Department            | Fax:    +49 (0)2636-80188
Neustrasse 9-12, 53498 Waldorf, Germany | email:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
From owner-riscy@pyramid.com  Wed Aug 11 06:04:34 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA18502; Wed, 11 Aug 93 06:04:34 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16618; Wed, 11 Aug 93 03:04:30 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16533; Wed, 11 Aug 93 03:03:15 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA16526; Wed, 11 Aug 93 03:03:12 -0700
Received: from avignon.daimi.aau.dk 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA16496; Wed, 11 Aug 93 03:04:12 -0700
Received: by avignon.daimi.aau.dk id AA03584
  (5.65c8/IDA-1.4.4 for riscy@pyramid.com); Wed, 11 Aug 1993 12:02:49 +0200
Date: Wed, 11 Aug 1993 12:02:49 +0200
From: Tommy Thorn <tthorn@daimi.aau.dk>
Message-Id: <199308111002.AA03584@avignon.daimi.aau.dk>
To: riscy@pyramid.com
Subject: Re: Second level cache?
References: <199308101106.AA17966@romeo.cs.Colorado.EDU>
	<9308101816.AA16534@sword.eng.pyramid.com>
Reply-To: Tommy.Thorn@daimi.aau.dk
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com

Neil Russell writes:
 > What I understand is that the ARC chipset supports a secondary cache
 > similar to the way it does for the 486.  It is not necessary to use
 > the cache support signals from the R4k to have a secondary cache, although
 > it may mean that this cache will take two cycles to access data where
 > the R4000SC cache would take one.  This may not be great, but it is still
 > better than the cycles required to get data from DRAM.

Andreas Busse writes:
 > 5. The R4200 ***DOES NOT*** support 2nd level cache. The Blockdiagram
 >    of ARCset shows no 2nd level cache, and there's ***NO SUPPORT*** at all.

Huh? 

 > Finally, I simply don't understand why this discussion came up.
 > I thought our goal was to design and produce a board with very good
 > price/performance relation. Although the price of the ARCset isn't
 > clear at the moment (which is not my or our fault, but NEC's) it seems
 > that this is what we are looking for. It offers more speed than
 > a R3081 solution probably for only few $s more.

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

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

/Tommy Thorn

 
From owner-riscy@pyramid.com  Wed Aug 11 06:24:18 1993
Received: from gossip.pyramid.com by SunSITE.unc.edu (4.1/tas-gen/1-30-93)
	id AA18843; Wed, 11 Aug 93 06:24:18 EDT
Received: from sword.eng.pyramid.com 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18222; Wed, 11 Aug 93 03:24:16 -0700
Received: by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA18034; Wed, 11 Aug 93 03:23:01 -0700
Received: from goss.pyramid.com
	by sword.eng.pyramid.com (5.61/Pyramid_Internal_Configuration)
	id AA18027; Wed, 11 Aug 93 03:22:58 -0700
Received: from mail.Germany.EU.net 
	by gossip.pyramid.com (5.61/OSx5.1a Pyramid-Internet-Gateway)
	id AA18079; Wed, 11 Aug 93 03:23:58 -0700
Received: by mail.Germany.EU.net(EUnetD-2.3.0.g) via EUnet
	id IZ03856; Wed, 11 Aug 1993 12:19:20 +0200
Received: from wegy
	by scotty.waldorf-gmbh.de with SMTP (5.65b/GEN-1.0.10)
	via EUnet for unido
	id AA05358; Wed, 11 Aug 93 12:20:08 +0200
Received: from resi 
	by wegy.waldorf-gmbh.de with SMTP (5.61/GEN-1.0.7)
	via EUnet for scotty
	id AA14488; Wed, 11 Aug 93 12:20:34 +0200
From: Andreas Busse <andy@resi.waldorf-gmbh.de>
Date: Wed, 11 Aug 93 12:19:45 +0200
Message-Id: <9308111019.AA22478@resi.waldorf-gmbh.de>
Received: by resi.waldorf-gmbh.de (5.61/GEN-1.0.7)
	via EUnet for wegy.waldorf-gmbh.de
	id AA22478; Wed, 11 Aug 93 12:19:45 +0200
To: Tommy.Thorn@daimi.aau.dk
Subject: Re: Second level cache?
Cc: riscy@pyramid.com
Sender: owner-riscy@pyramid.com
Reply-To: riscy@pyramid.com


> 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:  andy@resi.waldorf-gmbh.de
-------------------------------------------------------------------------------
 
