CS311 Lecture: CPU Control: Hardwired control and Microprogrammed ControlLast revised October 18, 2007Objectives:1. To explain the concept of a control word2. To show how control words can be generated using hardwired control3. To explain the concept of microprogramming4. To discuss the use of a RISC core in a CISC processor Materials: 1. Projectable Version of Diagrams2. MIPS Simulation3. Code for Lab 5 - part 1 to demonstrate using microprogrammingI. IntroductionA. We have seen that a CPU - whether simple or complex - basically consists of a control unit, plus a data part, encompassing:1. A set of registers (including registers that interface to the system bus) 2. A set of D-units (adders, shifters etc.)3. A set of data paths connecting the above.4. An interface to the "outside world" (memory, IO) - usually some sort of bus system. (We continue to assume a single instance of all components shared by all steps of instruction execution, and sequential execution of instruction steps. When we discuss pipelining and other forms of parallelism, we will see that some components will have to be replicated.) B. The data part is capable of performing a set of microoperations or primitive computations that can be performed in one cycle (clock pulse). Each microoperation changes the contents of a single register. An instruction in the user-visible instruction set must be programmed as a series of microoperations (some of which may be done in parallel on the same clock pulse.) C. Control of the system is accomplished by a control unit that - at the start of each clock cycle - activates the necessary control functions to cause the data part to perform the desired microoperation(s) on the next clock pulse. In the case of a multi-cycle CPU implementation (where a given 1component may perform different tasks on different cycles), this can be pictured as follows: PROJECTControl UnitALU, register set, and datapathsControl Signals(called thecontrol word)MemoryAddressDataCPUClock1.D. The set of control signals that pass from Control to the data part and bus system is called a micro-word or control word. Conceptually, each bit of this micro-word corresponds to the enabling of one particular microoperation that some system component can perform. (In practice, sometimes groups of bits are used to select from a set of mutually-exclusive options - e.g. the selection inputs to a MUX) E. The job of the control unit designer for such a CPU is to develop a means whereby an orderly sequence of control words may be presented to the data part (and other hardware such as the memory) - one per clock pulse. F. Historically, there have been two basic ways such a sequence of control words has been generated: 1. Hardwired control: The control unit is implemented as a state machine, with combinatorial circuits generating each of the control functions on the basis of the current state and certain variables such as the op-code of the user instruction undergoing execution. In machines that use a memory-memory or memory-register model for operations, the state machine may have two levels of states: major states, each of which is broken up into minor states. A given major state will consist of a series of minor states.2a) The major states may correspond to the various phases of instruction execution, or each major state may correspond to a single access to memory as part of instruction execution.b) Either way, the minor states correspond to the individual steps for a major state - e.g. if a certain major state requires three successive microoperations, then it will have three minor states.2. Microprogrammed control. The various control words needed to implement the user instructions are stored in a ROM, with a sequencer causing the appropriate control word to be fetched at each clock cycle and fed to the rest of the CPU.II. An Example of Hardwired ControlA. To get some feel for what is involved in hardwired control, we will discuss a hardwired control unit for our multicycle MIPS simulation. B. Observe that, in the RTL specification for this machine we discussed earlier, almost all instructions require exactly 4 cycles to fetch and execute. (One - j - requires only two - one for fetch and one for execute). For simplicity, we will allocate 4 cycles to every instruction - thus wasting two on j. 1. Our state machine then looks like this:PROJECTCycle 0Cycle 1Cycle 2Cycle 3a) The simplicity of the state machine for MIPS is a consequence of the regularity of the instructions, which in turn is a characteristic of the ISA designed to facilitate a pipelined implementation. (The ISA makes this part of the implementation easy)3b) Actually, a full implementation would need additional states to deal with issues like interrupts and exceptions.c) This simplified state machine can be realized by a 2 bit counter, with its output decoded to yield 4 signals used internally in the control unit. PROJECT2 bitcounter1 out of 4decoderCYCLE0CYCLE1CYCLE2CYCLE32. A CISC would require a much more complex state machines.a) The state machine for a CISC might have 6+ major states - with only some used for any given instruction. (No instruction would need them all) (1) IF - fetch the instruction (Common to all instructions)(2) OAC - calculate the address of the operand (used for instructions that reference memory)(3) INDIRECT - go to memory to get the address of an operand in cases where the instruction uses indirect addressing (if the ISA includes this)(4) OF - fetch an operand from memory (used for instructions that read an operand from memory) (5) EXEC - execute an instruction (all instructions)(6) OS - store an operand into memory (Used for instructions that store their result in memory) b) A two or three address machine would require multiple versions of states like OAC and OF - e.g. "calculate address of first operand", "calculate address of second operand", etc.c) Note that these are major states - some might have 2 minor states.4d) Example: consider what the state graph might look like for just a few