Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site redwood.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxj!mhuxr!ulysses!allegra!bellcore!decvax!tektronix!hplabs!hpda!fortune!redwood!rpw3
From: rpw3@redwood.UUCP (Rob Warnock)
Newsgroups: net.micro
Subject: Re: Need a microprogramming consultant!
Message-ID: <184@redwood.UUCP>
Date: Tue, 5-Mar-85 03:35:30 EST
Article-I.D.: redwood.184
Posted: Tue Mar  5 03:35:30 1985
Date-Received: Sat, 9-Mar-85 08:47:58 EST
References: <1272@drux3.UUCP> <501@ahuta.UUCP>
Organization: [Consultant], Foster City, CA
Lines: 109

+---------------
| REFERENCES:  <1272@drux3.UUCP>
| It would be great to see the answer in the net.
+---------------
O.k., this is what I mailed to original poster (edited slightly):
==========================================================================

In-reply-to: your article <1272@drux3.UUCP>
+---------------
| I am not a very hardware oriented.  Could someone give
| me an explanation (in simple terms) of how microprogramming
| works?????    Reply either via mail to ihnp4!drux3!mmt
| or via the net.  Thank you.
+---------------

Well, for starters, you haven't said enough for me to know what your
problem is.  I assume you are talking about microprogramming as used
in the design of the instruction set of a computer, or in the design
of the data paths of some peripheral controller.

Most commonly, "microprogramming" is a term used to describe the design
of a hardware finite-state machine which was constructed with it's
state-transition matrix in a ROM. (Are you familiar with "finite
state machines"?) The contents of the ROM are the "micro-program".
Generally, there are a certain number of input variables (logic
levels) that can be tested, and which can cause state changes
(micro-code "branches"), and a certain number of output variables
(logic levels) which can be set, depending on the current state.

Inputs might be levels such as "The ALU Output Value Is Positive", or
"DMA Bus Request 4", or "Memory Data Bus Bit 15". Outputs might be such
as "Clear Timing Flip-Flop 27", or "Enable The Contents Of Memory
Address Register Onto The Memory Address Bus". (Hardware engineers
often shorten names like the latter to cryptic forms like "MAR2MAEN"...
or worse. ;-} )

In the most general case, the input vector is concatenated with the
state vector, and used to look up in the ROM the pair "new-state-vector"
and "new-output-vector". The "new-state-vector" is saved as the (now
current) state vector, and the "new-output-vector" is sent to the
various outputs. (Is this all too abstract for you?)

"Micro-programming" is the process of selecting those ROM contents,
and bears a faint resemblance to ordinary (macro-) programming.

Large state machines are easier (thus cheaper) to design using micro-
programming than are state machines built of random (or discrete)
logic gates, but because of its complexity, it still is expensive
to design a microprogram. (The logical conclusion is: "Large state
machines are expensive".) The resulting "micro-programmed machines"
are also usually cheaper to manufacture than discrete machines,
though sometimes they suffer in operating speed.

There are many simplifications, complications, and variations to the
general case to save space in ROM, to save other hardware, and to simplify
design ("programming"). Sometimes there is an explicit "micro-PC" (uPC)
which stores the current state vector; sometimes the state vector is
implicit in the value of some output variable(s). Sometimes the uPC can
be incremented and the incremented value used as the "next state" unless
explicitly overridden (allowing next-state bits in the ROM to be used
for other purposes except when explicitly needed); sometimes each micro-
instruction (word in the ROM) carries with it the next PC (ROM address).

Sometimes some of the outputs (from a previous state) are used to select
a subset of the inputs to be looked at (this reduces the size of the ROM,
since not all possible combinations of "state|input" are needed). Sometimes
only certain bits of the uPC are affected ("loaded", or "jammed") by the
results of a test.

Some micro-ROMs have one bit for every possible output wire or control
lead needed; such machines are said to use "horizontal microcoding".
Sometimes there is a coded field in the uROM which is decoded externally
to select which ONE of several outputs will be activated; such machines
are "vertically microcoded". Vertically-coded machines may also take
several steps in succession to do what a "horizontal" machine could
do in one step; conversely, vertically machines are usually cheaper,
because they use less ROM, and fast uROM is expensive. 

The range of variations is immense.  So... there is not very much one
can say further without relating it to a specific situation or hardware
design problem. Oops! There IS one other little thing: Sometimes when
microprogramming is used to design a system (such as a large computer),
the designers choose to store the microcode in RAM, rather than ROM.
(Obviously, it has to be loaded into RAM from "somewhere" when the
machine is first powered up. Usually "somewhere" is a smaller computer
which has ITS microcode in ROM, and which reads the large machine's
microcode from a disk file.) This means that the low-level function
of the machine can be changed if needed (say, to fix a design error or
defect) without being re-wired or without replacing (expensive) ROM
chips. This has allowed hardware engineers to get nearly as sloppy as
software people, so that one now routinely hears "Well, that bug is
fixed in the next release of the microcode".  ;-} ;-}

Note: Several semiconductor manufacturers make special chips that help
one to design/build microprogrammed logic systems. The "2900" series
chips (made first by AMD but now multiply-sourced) are quite popular
for microprogrammed machines. The applications notes for the 2911
sequencer (a uPC with extra goodies in it) will give more examples of
how microprogramming is used. I believe there is an AMD app note that
even gives a complete diagram for a disk controller, including the
table of micro-ROM contents. Ask your local hardware wizard.


Rob Warnock
Systems Architecture Consultant

UUCP:	{ihnp4,ucbvax!dual}!fortune!redwood!rpw3
DDD:	(415)572-2607
USPS:	510 Trinidad Lane, Foster City, CA  94404