Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!codas!peora!pesnta!valid!markp
From: markp@valid.UUCP
Newsgroups: comp.arch
Subject: Re: shared memory multiproc. question
Message-ID: <977@valid.UUCP>
Date: Wed, 4-Feb-87 19:23:21 EST
Article-I.D.: valid.977
Posted: Wed Feb  4 19:23:21 1987
Date-Received: Sat, 7-Feb-87 18:22:49 EST
References: <76700001@uiucdcsp>
Organization: Valid Logic, San Jose, CA
Lines: 74

> 
> There are a number of shared memory multiprocessors on the market today
> that consist of a number of high-end microprocessors on a single bus.
> Decent performance is obtained by using fancy cache technology.  Making
> a single board computer is pretty trivial now-a-days, and making a
> multiprocessor system without the caches is not much harder but fairly
> pointless.  How hard is it to make these caches?  Are there chips on
> the market that do most of the work for you?
> 
> I am mildly interested in building a shared memory multiprocessor to
> attatch to a Sun or some other workstation for experimental purposes.
> Is anybody selling boards from which one could build such a system
> easily and inexpensively?
> 
> Ralph Johnson      ihnp4!uiucdcs!johnson      johnson@p.cs.uiuc.edu

Silicon support for caches is close to non-existent, with a few notable
exceptions.  The most obvious are "cache-tag RAMs," which are just fast
static RAMs with built-in expandable comparators for implementing the
cache tag directory.  The only cache management chips I know of off hand
are some Signetics 689xx (sic.) which do address translation and virtual
cache management, but only work on 68010's, hardly state-of-the-art.
Some processor designers have actually started to think about smart
caches, but all we see for the most part is a bit in the page table
controlling cacheability.  The 80386 doesn't even have that.  A notable
highlight is the MIPS R2000, which has on-chip cache control for
direct-mapped I/D caches, but which doesn't support hardware invalidates.
The 68030's on-chip data cache won't support invalidates either.  Yech!
Pure software-enforcement.  Might just as well use message-passing. :-)

Now, if you want something off the shelf, check out the Fairchild Clipper.
The Clipper modules have built-in instruction and data write-back caches,
but consistency is only enforced in write-through mode (programmable on a
per-page basis).  The modules are fairly expensive (well over a thousand
dollars in small quantities last time I checked), but are good for about
4-5 MIPS each.  You hook them in parallel on a proprietary synchronous bus
and would then need to build memory boards that plug into the same form
factor.  Unless you REALLY want to spend the time designing a cache-based
CPU, the Clippers might do the trick for you.  They might even give you a
good deal on off-speed parts for research use.  Call your local rep, or
(800)423-5516 (Fairchild advanced processor division in Palo Alto, CA).

It is not inherently difficult or expensive to design a cache-based CPU board,
particularly direct-mapped with a block size of 1 word and write-through.
The only modification to an otherwise-conventional CPU board design that you
make is a bank of cache tag RAMs and cache data RAMs, hooked up in a fashion
left as an exercise for the reader, and a circuit to steal cycles in the
cache directory whenever somebody else does a write on the external bus.
When this happens, you query the cache directory and invalidate.

The suitability of this approach depends on how many boards you want to
build, and what kind of performance you want.  Write-through is essentially
worthless with more than 2 or 3 of today's 32-bit microprocessors.  If you
want to cascade enough processors to make it really interesting, write-back
is a necessity.  When Futurebus (IEEE P896) is adopted (in May/June), it
will become the first bus standard that supports write-back caches.
However, the design of a smart write-back cache with a finite block size is
not an exercise for the faint-hearted, particularly with no advanced silicon
support.  It is expected that this will change, now that there will be a
standard bus structure to interface to (instead of Sequent/Encore/Convergent
/ad nausem's proprietary busses), and a well-documented set of bus operations
to support the functioning of smart caches.

I love talking about caches, and could probably continue on forever, but
won't in this public forum.  Feel free to address more specific questions
by email.

	Mark Papamarcos
	Valid Logic Systems, Inc.
	{ihnp4,hplabs}!pesnta!valid!markp
	(member, P896 working group and cache task group)

Generic disclaimer-- I have no vested interest in anyone mentioned above.
(except Futurebus, whose banner I loyally wave)