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