CS152 / Kubiatowicz Lec11.1 3/05/03©UCB Spring 2003 CS 152 Computer Architecture and Engineering Lecture 11 Multicycle Controller Design March 5, 2003 John Kubiatowicz ( lecture slides:

CS152 / Kubiatowicz Lec11.2 3/05/03©UCB Spring 2003 Review: High Level Design °Design Process Design Entry: Schematics, HDL, Compilers High Level Analysis: Simulation, Testing, Assertions Technology Mapping: Turn design into physical implementation Low Level Analysis: Check out Timing, Setup/Hold, etc °Verilog – Three programming styles Structural: Like a Netlist -Instantiation of modules + wires between them Dataflow: Higher Level -Expressions instead of gates Behavioral: Hardware programming -Full flow-control mechanisms -Registers, variables -File I/O, consol display, etc

CS152 / Kubiatowicz Lec11.3 3/05/03©UCB Spring 2003 Review: Testing: Make sure that things work °Testing methodologies Understand what correct behavior is when you design things -Collect vectors for later use Build monitor modules to check assertions of correct values Produce a regression test -Set of tests to run each time something changes °Types of test (Doug Clark): Directed Vectors – test explicit behavior Random Vectors – apply random values or orderings to device Daemons – continuous error insertion °Monitor modules: Check to see if invariants are maintained during long running simulations Alewife Numbers

CS152 / Kubiatowicz Lec11.4 3/05/03©UCB Spring 2003 module monitorsum32(carry,sum,A,B ); input [31:0] A,B; output [31:0] sum; output carry; reg [31:0] predsum; reg precarry; // The “real” adder sum32 mysum (carry,sum,A,B); `ifndef synthesis // This checker code only for simulation or B) begin #100 //wait for output to settle (don’t make too long!) {predcarry,predsum} = A + B; if ((carry != predcarry) || (sum != predsum)) $display(“>>> Mismatch: 0x%x+0x%x->0x%x carry %x”, A,B,sum,carry); end `endif endmodule Review: Monitor Modules: Passthrough testing

CS152 / Kubiatowicz Lec11.5 3/05/03©UCB Spring 2003 Lab4 version: monitors and benches °Idea: wrap testing infrastructure around devices under test (DUT) °Include test vectors that are supposed to detect errors in implementation. Even strange ones… °Can (and probably should in later labs) include assert statements to check for “things that should never happen” Test Bench Device Under Test Inline vectors Assert Statements File IO (either for patterns or output diagnostics) Inline Monitor Output in readable format (disassembly) Assert Statements Complete Top-Level Design

CS152 / Kubiatowicz Lec11.6 3/05/03©UCB Spring 2003 The Big Picture: Where are We Now? °The Five Classic Components of a Computer °Today’s Topics: Microprogramed control Administrivia; Courses Microprogram it yourself Exceptions Intro to Pipelining (if time permits) Control Datapath Memory Processor Input Output

CS152 / Kubiatowicz Lec11.7 3/05/03©UCB Spring 2003 Alternative multicycle datapath (book) °Miminizes Hardware: 1 memory, 1 adder Ideal Memory WrAdr Din RAdr 32 Dout MemWr 32 ALU 32 ALUOp ALU Control 32 IRWr Instruction Reg 32 Reg File Ra Rw busW Rb busA 32 busB RegWr Rs Rt Mux 0 1 Rt Rd PCWr ALUSelA Mux 01 RegDst Mux PC MemtoReg Extend ExtOp Mux Imm 32 << 2 ALUSelB Mux Zero PCWrCondPCSrc 32 IorD Mem Data Reg ALU Out B A

CS152 / Kubiatowicz Lec11.8 3/05/03©UCB Spring 2003 New Finite State Machine (FSM) Spec IR <= MEM[PC] PC <= PC + 4 R-type ALUout <= A fun B R[rd] <= ALUout ALUout <= A or ZX R[rt] <= ALUout ORi ALUout <= A + SX R[rt] <= M M <= MEM[ALUout] LW ALUout <= A + SX MEM[ALUout] <= B SW “instruction fetch” “decode” Execute Memory Write-back BEQ If A = B then PC <= ALUout ALUout <= PC +SX Q: How improve to do something in state 0001?

CS152 / Kubiatowicz Lec11.9 3/05/03©UCB Spring 2003 Finite State Machine (FSM) Spec IR <= MEM[PC] PC <= PC + 4 R-type ALUout <= A fun B R[rd] <= ALUout ALUout <= A or ZX R[rt] <= ALUout ORi ALUout <= A + SX R[rt] <= M M <= MEM[ALUout] LW ALUout <= A + SX MEM[ALUout] <= B SW “instruction fetch” “decode” BEQ 0010 If A = B then PC <= ALUout ALUout <= PC +SX Execute Memory Write-back

CS152 / Kubiatowicz Lec /05/03©UCB Spring 2003 sequencer control micro-PC  -sequencer: fetch,dispatch, sequential Dispatch ROM Opcode Inputs Recap: Microprogramming °Microprogramming is a fundamental concept implement an instruction set by building a very simple processor and interpreting the instructions essential for very complex instructions and when few register transfers are possible overkill when ISA matches datapath 1-1  -Code ROM To DataPath Decode datapath control microinstruction (  )

CS152 / Kubiatowicz Lec /05/03©UCB Spring 2003 Recap: Microprogramming °Microprogramming is a convenient method for implementing structured control state diagrams: Random logic replaced by microPC sequencer and ROM Each line of ROM called a  instruction: contains sequencer control + values for control points limited state transitions: branch to zero, next sequential, branch to  instruction address from displatch ROM °Horizontal  Code: one control bit in  Instruction for every control line in datapath °Vertical  Code: groups of control-lines coded together in  Instruction (e.g. possible ALU dest) °Control design reduces to Microprogramming Part of the design process is to develop a “language” that describes control and is easy for humans to understand

CS152 / Kubiatowicz Lec /05/03©UCB Spring 2003 Recap: “Macroinstruction” Interpretation Main Memory execution unit control memory CPU ADD SUB AND DATA User program plus Data this can change! AND microsequence e.g., Fetch Calc Operand Addr Fetch Operand(s) Calculate Save Answer(s) one of these is mapped into one of these

CS152 / Kubiatowicz Lec /05/03©UCB Spring 2003 Designing a Microinstruction Set 1) Start with list of control signals 2) Group signals together that make sense (vs. random): called “fields” 3) Place fields in some logical order (e.g., ALU operation & ALU operands first and microinstruction sequencing last) 4) To minimize the width, encode operations that will never be used at the same time 5) Create a symbolic legend for the microinstruction format, showing name of field values and how they set the control signals Use computers to design computers

CS152 / Kubiatowicz Lec /05/03©UCB Spring 2003 Again: Alternative multicycle datapath (book) °Miminizes Hardware: 1 memory, 1 adder Ideal Memory WrAdr Din RAdr 32 Dout MemWr 32 ALU 32 ALUOp ALU Control 32 IRWr Instruction Reg 32 Reg File Ra Rw busW Rb busA 32 busB RegWr Rs Rt Mux 0 1 Rt Rd PCWr ALUSelA Mux 01 RegDst Mux PC MemtoReg Extend ExtOp Mux Imm 32 << 2 ALUSelB Mux Zero PCWrCondPCSrc 32 IorD Mem Data Reg ALU Out B A

CS152 / Kubiatowicz Lec /05/03©UCB Spring &2) Start with list of control signals, grouped into fields Signal nameEffect when deassertedEffect when asserted ALUSelA1st ALU operand = PC1st ALU operand = Reg[rs] RegWriteNoneReg. is written MemtoRegReg. write data input = ALUReg. write data input = memory RegDstReg. dest. no. = rtReg. dest. no. = rd MemReadNoneMemory at address is read, MDR <= Mem[addr] MemWriteNoneMemory at address is written IorDMemory address = PCMemory address = S IRWriteNoneIR <= Memory PCWriteNonePC <= PCSource PCWriteCond NoneIF ALUzero then PC <= PCSource PCSource PCSource = ALU PCSource = ALUout ExtOpZero ExtendedSign Extended Single Bit Control Signal nameValueEffect ALUOp00ALU adds 01ALU subtracts 10ALU does function code 11ALU does logical OR ALUSelB002nd ALU input = 4 012nd ALU input = Reg[rt] 102nd ALU input = extended,shift left 2 112nd ALU input = extended Multiple Bit Control

CS152 / Kubiatowicz Lec /05/03©UCB Spring &4) Microinstruction Format: unencoded vs. encoded fields Field NameWidthControl Signals Set wide narrow ALU Control42ALUOp SRC121ALUSelA SRC253ALUSelB, ExtOp ALU Destination32RegWrite, MemtoReg, RegDst Memory32MemRead, MemWrite, IorD Memory Register11IRWrite PCWrite Control32PCWrite, PCWriteCond, PCSource Sequencing32AddrCtl Total width2415bits

CS152 / Kubiatowicz Lec /05/03©UCB Spring ) Legend of Fields and Symbolic Names Field NameValues for FieldFunction of Field with Specific Value ALUAddALU adds Subt. ALU subtracts Func codeALU does function code OrALU does logical OR SRC1PC1st ALU input = PC rs1st ALU input = Reg[rs] SRC242nd ALU input = 4 Extend2nd ALU input = sign ext. IR[15-0] Extend02nd ALU input = zero ext. IR[15-0] Extshft2nd ALU input = sign ex., sl IR[15-0] rt2nd ALU input = Reg[rt] destinationrd ALUReg[rd] = ALUout rt ALUReg[rt] = ALUout rt Mem Reg[rt] = Mem MemoryRead PCRead memory using PC Read ALURead memory using ALUout for addr Write ALUWrite memory using ALUout for addr Memory registerIRIR = Mem PC writeALUPC = ALU ALUoutCondIF ALU Zero then PC = ALUout SequencingSeqGo to sequential µinstruction FetchGo to the first microinstruction DispatchDispatch using ROM.

CS152 / Kubiatowicz Lec /05/03©UCB Spring 2003 Administrivia °Midterm I next Wednesday 5:30 - 8:30 probably in 277 Cory Bring a Calculator! One 8 1/2 by 11 page (both sides) of notes Make up exam: Tuesday 5:30 – 8:30 in 606 Soda Hall °Materials through Chapter 5, Appendix A, B & C °Review session this Sunday 7: Soda °Lab 3: Please include a file called instructions.txt that give explicit details on how to run the simulation for 3c °Tomorrow: Must come to section! Creating groups: 4 or 5 per group Also: Please read the Doug Clark paper on testing before section – you are going to discuss it °Lab 4 breakdown due midnight Friday to your TA This is a complicated lab – may need to give updates as we get the boards installed

CS152 / Kubiatowicz Lec /05/03©UCB Spring 2003 Quick check: what do these fieldnames mean? CodeNameRegWriteMemToRegRegDest XX 01rd ALU101 10rt ALU100 11rt MEM110 CodeNameALUSelBExtOp XX X 010rt01X 011ExtShft Extend Extend0110 Destination: SRC2:

CS152 / Kubiatowicz Lec /05/03©UCB Spring 2003 Specific Sequencer from last lecture Sequencer-based control unit from last lecture Called “microPC” or “µPC” vs. state register Code NameEffect 00 fetchNext µaddress = 0 01dispatchNext µaddress = dispatch ROM 10 seqNext µaddress = µaddress + 1 ROM: Opcode microPC 1 µAddress Select Logic Adder ROM Mux R-type BEQ ori LW SW

CS152 / Kubiatowicz Lec /05/03©UCB Spring 2003 Microprogram it yourself! LabelALU SRC1SRC2Dest.MemoryMem. Reg. PC Write Sequencing Fetch:AddPC4Read PCIRALUSeq

CS152 / Kubiatowicz Lec /05/03©UCB Spring 2003 Microprogram it yourself! LabelALU SRC1SRC2Dest.MemoryMem. Reg. PC Write Sequencing Fetch:AddPC4Read PCIRALUSeq AddPCExtshftDispatch Rtype:FuncrsrtSeq rd ALUFetch Lw:AddrsExtend Seq Read ALU Seq rt MEM Fetch Sw:AddrsExtendSeq Write ALUFetch Ori:Orrs Extend0 Seq rt ALUFetch Beq:Subt.rsrt ALUoutCond.Fetch

CS152 / Kubiatowicz Lec /05/03©UCB Spring 2003 An Alternative MultiCycle DataPath °In each clock cycle, each Bus can be used to transfer from one source °µ-instruction can simply contain B-Bus and W-Dst fields Reg File A B A-Bus B Bus IR S mem W-Bus PCPC inst mem next PC ZXSX

CS152 / Kubiatowicz Lec /05/03©UCB Spring 2003 What about a 2-Bus Microarchitecture (datapath)? Reg File A B A-Bus B Bus IR S PCPC next PC ZXSX Mem Reg File A B IR S PCPC next PC ZXSX Mem Instruction Fetch Decode / Operand Fetch M M

CS152 / Kubiatowicz Lec /05/03©UCB Spring 2003 Load °What about 1 bus ? 1 adder? 1 Register port? Reg File A B IR S PCPC next PC ZXSX Mem Reg File A B IR S PCPC next PC ZXSX Mem Reg File A B IR S PCPC next PC ZXSX Mem Execute addr M M M Mem Write-back

CS152 / Kubiatowicz Lec /05/03©UCB Spring 2003 Legacy Software and Microprogramming °IBM bet company on 360 Instruction Set Architecture (ISA): single instruction set for many classes of machines (8-bit to 64-bit) °Stewart Tucker stuck with job of what to do about software compatibility If microprogramming could easily do same instruction set on many different microarchitectures, then why couldn’t multiple microprograms do multiple instruction sets on the same microarchitecture? Coined term “emulation”: instruction set interpreter in microcode for non-native instruction set Very successful: in early years of IBM 360 it was hard to know whether old instruction set or new instruction set was more frequently used

CS152 / Kubiatowicz Lec /05/03©UCB Spring 2003 Microprogramming Pros and Cons °Ease of design °Flexibility Easy to adapt to changes in organization, timing, technology Can make changes late in design cycle, or even in the field °Can implement very powerful instruction sets (just more control memory) °Generality Can implement multiple instruction sets on same machine. Can tailor instruction set to application. °Compatibility Many organizations, same instruction set °Costly to implement °Slow

CS152 / Kubiatowicz Lec /05/03©UCB Spring 2003 Summary °Microprogramming is a fundamental concept implement an instruction set by building a very simple processor and interpreting the instructions essential for very complex instructions and when few register transfers are possible Control design reduces to Microprogramming °Design of a Microprogramming language 1.Start with list of control signals 2.Group signals together that make sense (vs. random): called “fields” 3.Place fields in some logical order (e.g., ALU operation & ALU operands first and microinstruction sequencing last) 4.To minimize the width, encode operations that will never be used at the same time 5.Create a symbolic legend for the microinstruction format, showing name of field values and how they set the control signals

CS152 / Kubiatowicz Lec /05/03©UCB Spring 2003 Thought: Microprogramming one inspiration for RISC °If simple instruction could execute at very high clock rate… °If you could even write compilers to produce microinstructions… °If most programs use simple instructions and addressing modes… °If microcode is kept in RAM instead of ROM so as to fix bugs … °If same memory used for control memory could be used instead as cache for “macroinstructions”… °Then why not skip instruction interpretation by a microprogram and simply compile directly into lowest language of machine? (microprogramming is overkill when ISA matches datapath 1-1)