Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman
From: koopman@a.gp.cs.cmu.edu (Philip Koopman)
Newsgroups: comp.arch
Subject: Re: machines with some loadable microcode are easier to fix
Summary: sometimes it does help out
Keywords: microcode hardware bugs
Message-ID: <11512@pt.cs.cmu.edu>
Date: 4 Jan 91 12:46:49 GMT
References: <71537@bu.edu.bu.edu> <1991Jan04.035359.12547@kithrup.COM>
Organization: Carnegie-Mellon University, CS/RI
Lines: 46

In article <1991Jan04.035359.12547@kithrup.COM>, sef@kithrup.COM (Sean Eric Fagan) writes:
> John Mashey once posted that simulating a MIPS R3000 (I think it was),
> completely in software, from power up to single user mode, took something
> like seven days.  (John, sorry if I've gotten something wrong.)
> How long do you think it would take to do the same thing for, say, VAXen,
> Cybers (180 state, that is), or any other machine with loadable ucode?

The Harris Semiconductor RTX 4000 used partly ROMed and partly
writable ucode.  In the prototype run, the writable ucode was compiler-
selected fallback for any bugs in the ROM.  There was one bug that would
have been catastrophic if uncorrected (and unexercised in the simulation
by a stupid oversight).  So, we threw an opcode into RAM.
That was *much* easier than worrying about redoing all the
compiler code generation to avoid a particular instruction.
We were able to simulate power-on to running an interactive compiler
in about **10 minutes** of IBM PC-AT execution time using RTL-level
simulations.  But, it wasn't designed to be a Unix/workstation engine either.

> Which do you think is going to result in more sales:  selling and shipping a
> machine for which you need to send out periodic uCode upgrades, or building 
> a bug-free implementation by shipping time, which is three or more time 
> faster than the one with ucode?  Assuming neither party is IBM or DEC, that
> is 8-).
Unfortunately, RISC or CISC, microcoded or hardwired, it is highly
likely that the first rev. of *any* CPU has bugs.  That goes double
for compilers (especially RISC ones that are generally more ambitious).
I have personally observed such bugs in both RISCs and CISCs from
the "big guys".
Any CPU (RISC or CISC) can work around bugs by using the compiler,
but that takes more time and manpower than a mod to writable ucode
in many cases.
Note that as second-generation RISCs with heavy scoreboarding
come into use, the argument that they are simpler and therefore
more likely to be correct may(?) be less valid.

By the way, the RTX 4000 executed programs about 1.5 times as fast
as the RTX 2000 (which was hardwired) -- off the same fab line
and standard cell library.  The RTX 4000 never made it to market
because it had to wait for the not-bug-free, slower hardwired
processor to succeed enough to generate revenue (it didn't).

  Phil Koopman                koopman@greyhound.ece.cmu.edu   Arpanet
  2525A Wexford Run Rd.
  Wexford, PA  15090
*** this space for rent ***
Formerly, senior scientist at Harris Semiconductor.