linux-mips-fnet
[Top] [All Lists]

Re: r10000 boards

To: linux-mips
Subject: Re: r10000 boards
From: Dominic Sweetman <dom@algor.co.uk>
Date: Wed, 2 Apr 97 13:56:15 GMT
Cc: dom@algor.co.uk
In-reply-to: <199704021257.OAA06309@informatik.uni-koblenz.de>
References: <194.199704020805@gladsmuir.algor.co.uk> <199704021257.OAA06309@informatik.uni-koblenz.de>
Ralf asked...

> > Don't get me started on the MIPS system interface...
> 
> Why?

[short version]

In 1991 MIPS wanted the MIPS R4000 to sweep away Sun workstations
(with something like the Magnum) and IBM mainframes with a 16 x R4000
multiprocessor Unix server using a wondrous synchronous bus held
together with phase locked loops.  The latter never quite got built,
but I guess the SGI Challenge is it's spiritual successor.

The R4000 is designed to be in either a low-pin-count 'PC' package (no
secondary cache, workstation) or high pin-count 'MC' package
(secondary cache, multiprocessor support).  The secondary cache
interface is quite separate, and big; so in both cases they wanted to
connect the CPU to the appropriate controller ASIC with as few pins as
possible.

The resulting interface has significant virtues, particularly at the
then high clock rate of 50MHz.  It is really synchronous (same timing
on all pins referenced to the clock) and packs a lot of bandwidth and
a wealth of complicated multiprocessor cycles into about 90 active
pins.

It also has significant vices, mostly because it's just weird compared
with most other buses.  

o Whole system had to run off CPU clock output.
o Unique approach to multiplexing (when not ready it stalls on the
  address phase, not the data phase).
o Unpredictable sequencing; write cycles could have arbitrary numbers
  of idle cycles inserted for undocumented reasons.
o Bizarre attitude to bus arbitration, pretends that the memory
  becomes a bus master when sending data back in a read cycle.
o Timings (hold times particularly) never satisfactorily specified.
o Burst writes particularly difficult...

The really crazy thing is that companies building CPUs not intended
for SGI use (R4640, Vr4300, RM5230) have retained everything strange
about the bus, while being entirely incompatible with their
predecessors.  Chip companies are not system designers, and perhaps
they think that everyone *likes* the R4000 interface.

Better alternatives for modern CPUs might be:

o Put direct DRAM + PCI interfaces on the CPU itself.  That gets the
  best performance and the lowest pin count at the same time.

o Pretend to be a Pentium, at least enough so system builders can use
  PC chip sets.  (Yes, you are allowed to do that, though not to call it
  Pentium, probably).

o If you're only willing to tinker, just demultiplex the addresses and
  add some flow control to write cycles.

If you can print or view postscript you can see the gruesome details
by downloading:

  http://www.algor.co.uk/ftp/pub/doc/r4k-interface-guide.ps.gz

Dominic Sweetman
dom@algor.co.uk

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