ucbesvax.turner@ucbcad.UUCP (01/05/84)
#N:ucbesvax:27900006:000:18787
ucbesvax!turner Jan 4 02:56:00 1984
If you are interested in computer implementation, and microprogramming as
an implementation technique, and especially the question of microprogramming
single-chip computers, this paper is for you.
Also, do not miss an opportunity to see Nick Tredennick perform live. With
his deadpan delivery, split-second timing, and irreverent treatment of
subject matter (the following was performed at UCB as "Why Computer Science
is Junk"), even if he had a stroke that destroyed only the part of his brain
that produces microcode, he would go on to be famous as a stand-up comedian.
(Nevertheless, this is a serious paper--forget the IBM address.)
----------------------------------------------------------------------------
_*The "Cultures" of Microprogramming*_
Nick Tredennick
IBM T. J. Watson Research Center
P.O. Box 218 39-254
Yorktown Hts., NY 10598
_*Abstract*_
I discuss four "cultures" of microprogramming. I call them: the Commercial
Machine Culture, the Bit-Slice Culture the Microprogrammable Machine Culture,
and the Single-Chip Culture. Commonly used microprogramming terms mean
different things to people from different cultures. I define the cultures
and then contrast some microprogramming folklore with realities from my
culture (the Single-Chip Culture). When you read or hear statements about
microprogramming, know which culture is speaking. I hope the discrepancies
between some folklore and reality in the single-chip case will convince you
it's important.
_*Introduction*_
Four "cultures" have emerged in the world of microprogramming. I call them
1) the Commercial Machine Culture,
2) the Bit-Slice Culture,
3) the Microprogrammable Machine Culture, and
4) the Single-Chip Culture.
_The Commercial Machine Culture_ has an "architecture" manual. IBM calls
theirs a "Principles of Operation." It is the assembler language
programmer's _view_. For machine designers it is the _prescribed_ view.
Enter "microprogrammers," who program low level hardware to give it the
appearance of a machine with the instruction set in the architecture manual.
Commercial machines are not meant to be microprogrammed by the people who
buy them.
_The Bit-Slice Culture_ builds tailored machines out of standard bit-slice
components. These machines are usually designed and microprogrammed by
hardware experts; they design these machines for specific applications.
Bit-slice machines are not usually meant to be microprogrammed by their
ultimate users.
_The Microprogrammable Machine Culture_ designs machines which can emulate
several computer architectures. Microprogrammable machines _are_ meant to
be microprogrammed by their buyers.
_The Single-Chip Culture_ focuses on individual _chips_--ones whose designs
use microprogramming as an implementation technique, not as a feature.
(This is a way to do it, not the neat thing about it.) These chips are not
meant to be microprogrammed by the user. This is _inside-the-chip_
microprogramming.
I will say more about cultures. Then I contrast some microprogramming
folklore with realities from my culture (the Single-Chip Culture). When
you read or hear statements about microprogramming, know which culture is
speaking. I hope the discrepancies between some folklore and reality
in the single-chip case will convince you it's important. (What's
feasible for bit-slice can be crazy for single chips.)
_*"Microprogramming"*_
"Microprogramming" is just a term we misuse in
common
across four environments.
It's like only saying "cooking" to a group of cooking fanatics. You convey
some general image--not enough for a chef to know whether he or she cares
about what you have to say. Microprogramming buffs do this with other
terms: "high level language," "microcode compaction," "control store
optimization," "microcode verification," "microprogrammable," "micromachine,"
and more. _Meanings depend on the environment people work in_!
_*The Commercial Machine Culture*_
IBM's System/370 is a good example. The System/370 Principles of Operation
is a document which prescribes software-compatible machines over a wide
performance range. Most of the machines are "microprogrammed."
Like all central processing units (CPUs), a System/370 CPU has two parts:
an "execution unit" (or "data flow") and a "controller." The execution
unit contains the general purpose register, the arithmetic and logic unit
(ALU), shifter, instruction counter, etc.--the resources needed to execute
System/370 instructions (object code). The controller "runs" the execution
unit--tells it what to do when. In a "microprogrammed" implementation, the
controller consists of a control store (storage to hold microwords) and
hardware which sequences the microwords. In System/370, this control store
is a random access memory (RAM). IBM calls it "reloadable control store"
(RCS) to distinguish it from the RAM used for main storage.
Implementations of System/370 CPUs are based on historical development.
IBM engineers have been designing these CPUs for 25 years. They know how
the block diagram of the CPU should look to attain set performance. When
designing a particular model, engineers first draw a block diagram of a
"micromachine." They also publish a microinstruction manual for the
micromachine. (Each CPU model is built on a different micromachine
so the manual is different for each one.) "Microprogrammers" then begin
writing the programs--called "microprograms"--which run on the micromachine.
Microprogrammers program the micromachine to make it look like the machine
described in the Principles of Operation.
It takes lots of programming. The microprogramming to implement System/370
is around half a million bits. Small machines have a simple micromachine
and narrow microword but require many microwords. Big machines use a
complicated micromachine with wider but fewer microwords. (The product
of microword width and number of microwords stays about the same.) The
control store is usually RAM and might even be pageable.
These machines are often called "microprogrammable." After all, you can
change the microprograms, add new instructions and diagnostic programs,
and even provide tailored operating system "assists." But if you program
a System/370 micromachine to be something other than a System/370, say
a Burroughs or Control Data architecture, it won't be very efficient.
The micromachine isn't designed to support just _any_ architecture. It's
designed to support _one_: System/370. When people from this culture
say "microprogrammable," they mean they can implement changes related to
the architecture. This is a _fixed-architecture microprogramming
environment_.
Microprogramming for these machines can be much like programming in
assembler language. The micromachine instructions ("microcode") can be
much like ordinary assembler-level instructions. These microprogrammed
machines are believed to be slower than corresponding "random logic"
or "hardwired" implementations. Why? Historically, the highest
performance machines (e.g., the System/360, Model 91 and the System/370
Model 195) were done in random logic.
_*The Bit-Slice Culture*_
Bit-slice machines use off-the-shelf chips (such as the Am2900 family) to
build special-purpose hardware. These machines are defined by the hardware
designer to be used in a specific application; there is a custom micromachine
for each application. There is no formal architecture document. The
micromachine and the Principles of Operation level are the same--there is
no predefined, prescribed set of instructions to implement. The machine
designer is also the microprogrammer. The machine is usually for physical
control applications. The designer uses the ones and zeros from the control
store to manipulate external control lines directly--lights, wires, switches,
... The microprogramming to implement a bit-slice machine varies greatly.
A simple engine controller might use only a few thousand bits; a sophisticated
computer might use over a million bits. Bit-slice machines may or may not be
microprogrammed by their ultimate users. Usually, they are not. This is a
_bit-slice microprogramming environment_.
_*The Microprogrammable Machine Culture*_
A third kind of microprogrammed machine is built like the micromachines in
the Commercial Machine Culture. But its execution unit is general purpose.
This execution unit is meant to be used to emulate _any_ architecture.
The controller for a microprogrammable machine is also general purpose.
The idea is to create a machine that can support any architecture just by
changing the microcode. Changing control store content (microcode) is
easy. Microcode for these machines is usually paged. It is paged because
there can be so much of it. You might want to change the "architecture"
for each language or run-time environment. You may even want to change the
"architecture" while the machine is running! (This is called dynamic
microprogramming.) Programming for a microprogrammable machine might be
supported by high level languages, assemblers, linkers, compilers, and all
the other stuff from a "regular" programming environment. The Burroughs
B1700 and the Nanodata QM1 are microprogrammable machines.
Because microprogrammable machines are versatile, they have the most
interest from people who want to develop microprogramming techniques.
This is a _variable-architecture microprogramming environment_.
_*The Single-Chip Culture*_
A single-chip microprocessor such as the Motorola M68000 is said to be
microproGRAMMED (not microproGRAMMABLE!) machine. Like the commercial
machines, there is a Principles of Operation (which Motorola calls a
User's Manual). Unlike the commercial machines, there is no
microinstruction manual for the micromachine. The controller and
execution unit for a single-chip microprocessor are defined to support a
specific architecture. "The design might tolerate a different architecture
by changing the microprogram; but the result can be like wearing a T-shirt
upside down as underwear," says my collaborator, Brion Shimamoto. As with
bit-slice machines, the hardware designer is also the microprogrammer,
but the microprogram and the hardware are more closely related. The
microcode is a _result_ of the design procedure, not an independent thing.
Unlike most bit-slice machines, there is no formal architecture. The
User's Manual prescribes which instructions are to be implemented. In
direct contrast to machines in the Microprogrammable Machine Culture,
these are _fixed-architecture non-microprogrammable machines_.
"Single-chip" means the control store, execution unit, bus controller,
and clock-phase generators are on the same chip. The control store
is read-only (ROM--IBM calls it read-only storage [ROS]).
Note: I do not count programming which resides in the main memory attached
to a microprocessor as "microprogramming." Microprogramming, in the context
of single-chip microprocessors, is what resides in the on-chip control store.
_*Contrasting Folklore and Reality*_
Because of the big investment (billions of dollars and thousands of man-years)
in microprogramming, people want cheaper, more reliable ways of developing
microprograms. Therefore, lots of people work on high-level languages,
compilers, and assemblers for microprogramming, microprogram verification,
control store optimization, and machine organization. Many people are
developing theoretical bases and practical methods to reduce cost and
improve reliability. THIS MEANS THERE IS TOO MUCH TO READ. You need a fine
filter--finer than just "microprogramming."
I am from the Single-Chip Culture. I worked at Motorola on the MC68000.
My job was to define the MC68000's microprogrammed controller, write the
microprograms, and specify what went into the execution unit. I collected
and read hundreds of pages on microprogramming, microprogrammed machine
design, and microprogram optimization. I finally decided I couldn't use
them, set them aside, and did an empirical design. These articles were
written for other microprogramming cultures--not mine. Here are quotes
from past and current literature (not cited, to protect the guilty.) You
may recognize them as part of the folklore of microprogramming. Here's
how I think they apply to the Single-Chip Culture.
*"...microprogramming differ very little from `regular' programming."*
I would have said the opposite--there is no relation between regular
programming and microprogramming the controller for a single-chip
microprocessor. For example, I design a controller using diagrams
which combine state transitions and register transfers. These diagrams
specify the exact operation of the machine. There is no programming
in the "regular" sense of the word. The microword format is unknown
till the diagrams are complete. Then a computer program generates
microword bit patterns by a clerical translation of the diagrams. It
still isn't _practical_ (it is _possible_) to use a high level language
to describe the operation of a commercial microprocessor.
*"Microcode compaction cab be considered one of the few solved problems
of microprogramming."*
Compaction techniques are still not useful for reducing the size of the
control store in _single-chip_ microprocessors. (The control store is
on the chip with the rest of the processor.) The theory for reducing the
number of bits in a microword depends on combining fields to control
mutually exclusive functions. This idea assumes wires can cross freely.
But in an nMOS implementation, wire crossings are not free. Combining
controls for functions that are widely separated may use more area (to
decode the signals and route the wires) than would have been used by
simply repeating the control field through the entire control store.
To be useful, the theory must know the importance of signal position
and the cost of wire crossings.
*"Design errors could be corrected easily by inexpensive changes in the
microprogram, rather than expensive changes in the hardware."*
In a single-ship implementation, one cost of the change is the same--you
need a new chip. It might take longer to correct random logic than it
takes to correct a microprogram. Even that isn't certain; it depends
on how the random logic or microprograms were generated. A single-chip
microprogrammed implementation is optimized to give maximum function
per unit area for a specific architecture. Cross-microword dependencies
can make the microwords as tightly intertwined as a set of reduced
Boolean equations. Changing the microprogram can upset the whole thing.
This is because the microwords were placed in the ROM by following a
complicated procedure involving trade-offs among at least six rigid
constraints. I feel that microword placement is a tougher problem than,
say, an eight variable Karnaugh map. (I've done both.) A small change
in the microprogram can cause a ripple effect, demanding that the placement
procedure be repeated. This could be more expensive than replacing a
piece of random logic. It might not even be possible. Finally, the
control store may not be large enough to stand the change.
*"...microprogramming allowed a designer to delay decisions about the
instruction set to be supported until after the microprogrammable
hardware was completed."*
True, but changing the instruction set late in the design will probably
increase the size of the design. For example, the MC68000 microprocessor
uses a type of two-level control store. Initially, we achieved a two to
one ratio between the 17-bit microwords, and the 68-bit nanowords. But
late changes in the instruction set dropped the ratio to around five to
three. This cost about 3,500 bits of control store.
In a single-chip microprocessor, the execution unit is custom-tailored
to the architecture (defined by the User's Manual). Therefore, architecture
changes may be tough to support with existing hardware. A general purpose
execution unit would be too slow or too big. It would, for example, be
difficult to add field manipulation instructions to an execution unit designed
to manipulate only bits, bytes, and half-words.
*"Performance may be the biggest drawback, as microprogrammed logic is
generally slower than its conventional counterpart."*
The Zilog Z8000, the Intel 8086, and the Motorola MC68000 are all
single-chip microprocessors of roughly equal technology. It would be
difficult to predict which design was microprogrammed by measuring their
performance at the pins with a logic analyzer. In this case I think the
microprogrammed machine is faster, but we don't have microprogrammed and
random logic implementations of the same architecture. In a single-chip
microprocessor, the balance among the decoders, execution unit, and
controller is crucial. If the delays through these elements can be
properly balanced, IT DOESN'T MATTER whether the controller is random
logic or microprogrammed. In other words, the right internal structure
contributes far more to performance than the choice of implementation
method--random logic, microprogrammed, or programmable logic array.
*"With the cost of R/W store fast approaching the cost of read-only
store, microprogrammed computers in the future will probably use ROMs
only for protecting very small critical sections of control memory."*
It is unlikely that single-chip microprocessors will be putting their
microprograms in on-chip RAM because RAM density is too low to store a
usable amount of microcode. Also, I want all the microprograms to
reside on the chip permanently.
_*Conclusion*_
Before you discuss microprogramming with someone, find out which culture
they adhere to. (Maybe we should carry id cards!) It saves time and
frustration. Try using a table like this one. Circle your contexts
and see if you can categorize the people you talk to . If you have
trouble determining where a person or article is coming from, you are
on the verge of wasting your time.
_*"THE TABLE"*_
(*me*)
---------------------------------------------------
| Paper Design vs *Real Design* |
---------------------------------------------------
| Commercial Machine vs Bit-Slice |
| vs |
| Variable Architecture vs *Single-Chip* |
---------------------------------------------------
| MicroProGRAMMABLE vs *MicroproGRAMMED* |
---------------------------------------------------
| *Industry* vs Academia |
---------------------------------------------------
| *EE* vs C.S. |
---------------------------------------------------
[Transcriber's note. _..._ = underlined, *...* = boldface;
copied by permission]
---
Michael Turner (ucbvax!ucbesvax.turner)