1. CS 152 Computer Architecture and Engineering Lecture 9 Multiprogramming and Exceptions February 25, 2004 John Kubiatowicz (www.cs.berkeley.edu/~kubitron) lecture slides: http://inst.eecs.berkeley.edu/~cs152/

2. CS152 / Kubiatowicz Lec9.2 2/25/04©UCB Spring 2004 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

3. CS152 / Kubiatowicz Lec9.3 2/25/04©UCB Spring 2004 Review: Multicycle Datapath °Critical Path ? PC Next PC Operand Fetch Instruction Fetch nPC_sel IR Reg File Ext ALU Reg. File Mem Acces s Data Mem Result Store RegDst RegWr MemWr MemRd S M MemToReg Equal ALUctr ALUSrc ExtOp A B E

4. CS152 / Kubiatowicz Lec9.4 2/25/04©UCB Spring 2004 Review: Control Specification as State Machine IR <= MEM[PC] R-type A <= R[rs] B <= R[rt] S <= A fun B R[rd] <= S PC <= PC + 4 S <= A or ZX R[rt] <= S PC <= PC + 4 ORi S <= A + SX R[rt] <= M PC <= PC + 4 M <= MEM[S] LW S <= A + SX MEM[S] <= B PC <= PC + 4 BEQ PC <= Next(PC,Equal) SW “instruction fetch” “decode / operand fetch” Execute Memory Write-back

5. CS152 / Kubiatowicz Lec9.5 2/25/04©UCB Spring 2004 Review: Performance Evaluation °What is the average CPI? state diagram gives CPI for each instruction type workload gives frequency of each type TypeCPI i for typeFrequency CPI i x freqI i Arith/Logic440%1.6 Load530%1.5 Store410%0.4 branch320%0.6 Average CPI:4.1

6. CS152 / Kubiatowicz Lec9.6 2/25/04©UCB Spring 2004 Review: Micro-Controller Design °The state digrams that arise define the controller for an instruction set processor are highly structured °Use this structure to construct a simple “microsequencer” °Control reduces to programming this very simple device  microprogramming sequencer control datapath control micro-PC sequencer microinstruction

7. CS152 / Kubiatowicz Lec9.7 2/25/04©UCB Spring 2004 Example: Jump-Counter op-code Map ROM Counter zero inc load 0000 i i+1 i None of above: Do nothing (for wait states) “Zero”“Increment”“Load”

8. CS152 / Kubiatowicz Lec9.8 2/25/04©UCB Spring 2004 Using a Jump Counter IR <= MEM[PC] R-type A <= R[rs] B <= R[rt] S <= A fun B R[rd] <= S PC <= PC + 4 S <= A or ZX R[rt] <= S PC <= PC + 4 ORi S <= A + SX R[rt] <= M PC <= PC + 4 M <= MEM[S] LW S <= A + SX MEM[S] <= B PC <= PC + 4 BEQ PC <= Next(PC) SW “instruction fetch” “decode” 0000 0001 0100 0101 0110 0111 1000 1001 1010 00111011 1100 inc load zero inc Execute Memory Write-back

9. CS152 / Kubiatowicz Lec9.9 2/25/04©UCB Spring 2004 Our Microsequencer op-code Map ROM Micro-PC Z I L datapath control Equal

10. CS152 / Kubiatowicz Lec9.10 2/25/04©UCB Spring 2004 Microprogram Control Specification: Logic? ROM? 0000xinc1 0001xload1 1 00110zero1 0 00111zero1 1 0100xinc0 1 fun 1 0101xzero1 00 1 1 0110xinc0 0 or 1 0111xzero1 00 1 0 1000xinc1 0 add 1 1001xinc1 0 1 1010 xzero1 01 1 0 1011xinc1 0 add 1 1100xzero 1 00 1 0 µPC EqualNext IRPCOpsExecMemWrite-Back en selA B Ex Sr ALU S R W MM-R Wr Dst R: ORi: LW: SW: BEQ: InputsOutputs

11. CS152 / Kubiatowicz Lec9.11 2/25/04©UCB Spring 2004 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 5 5 32 busA 32 busB RegWr Rs Rt Mux 0 1 Rt Rd PCWr ALUSelA Mux 01 RegDst Mux 0 1 32 PC MemtoReg Extend ExtOp Mux 0 1 32 0 1 2 3 4 16 Imm 32 << 2 ALUSelB Mux 1 0 32 Equal Zero PCWrCondPCSrc 32 IorD Mem Data Reg ALU Out B A

12. CS152 / Kubiatowicz Lec9.12 2/25/04©UCB Spring 2004 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 0000 0001 0100 0101 0110 0111 1000 1001 1010 1011 1100 BEQ 0010 0011 If A = B then PC <= ALUout ALUout <= PC +SX Q: How improve to do something in state 0001?

13. CS152 / Kubiatowicz Lec9.13 2/25/04©UCB Spring 2004 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” 0000 0001 0100 0101 0110 0111 1000 1001 1010 1011 1100 BEQ 0010 If A = B then PC <= ALUout ALUout <= PC +SX Execute Memory Write-back

14. CS152 / Kubiatowicz Lec9.14 2/25/04©UCB Spring 2004 sequencer control micro-PC  -sequencer: fetch,dispatch, sequential Dispatch ROM Opcode Inputs 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 (  )

15. CS152 / Kubiatowicz Lec9.15 2/25/04©UCB Spring 2004 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

16. CS152 / Kubiatowicz Lec9.16 2/25/04©UCB Spring 2004 “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

17. CS152 / Kubiatowicz Lec9.17 2/25/04©UCB Spring 2004 Administrivia °Lab 3 design document to go over in section EMail preliminary design document to TA by 9pm tonight Email final version to TA by midnight Thursday Sections back in normal rooms This is a complicated lab – may need to give updates as we get the boards installed °Change to Lab specification Your ChipScope should be set up to trigger on a PC entered from board switches (8-switches  10-bit PC) °Homework quiz still next Wednesday Homework is shorter this time Make sure to check on assigned problems °Midterm I, Wednesday March 10 th (Two Weeks) 5:30 - 8:30 in 306 Soda Hall Bring a Calculator! One 8 1/2 by 11 page (both sides) of notes Make up exam?

18. CS152 / Kubiatowicz Lec9.18 2/25/04©UCB Spring 2004 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

19. CS152 / Kubiatowicz Lec9.19 2/25/04©UCB Spring 2004 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 always @(A 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

20. CS152 / Kubiatowicz Lec9.20 2/25/04©UCB Spring 2004 Lab3 version: monitors and benches °Important design idea: Set up your processor so that you can take the same design and both simulate and push it to board °Testing Ideas: 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

21. CS152 / Kubiatowicz Lec9.21 2/25/04©UCB Spring 2004 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

22. CS152 / Kubiatowicz Lec9.22 2/25/04©UCB Spring 2004 Recap: Multicycle datapath (book)

23. CS152 / Kubiatowicz Lec9.23 2/25/04©UCB Spring 2004 Step 1  Start with List of control signals 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

24. CS152 / Kubiatowicz Lec9.24 2/25/04©UCB Spring 2004 Step 2  Group together related signals ALU SRC1 SRC2 Destination Memory PCWrite

25. CS152 / Kubiatowicz Lec9.25 2/25/04©UCB Spring 2004 3&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

26. CS152 / Kubiatowicz Lec9.26 2/25/04©UCB Spring 2004 Step 5  Group into Fields, Order and Assign Names Field NameValues for FieldFunction of Field with Specific Value ALUAddALU adds Subt. ALU subtracts FuncALU 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] dest(ination)rd ALUReg[rd] <= ALUout rt ALUReg[rt] <= ALUout rt Mem Reg[rt] <= Mem Mem(ory)Read PCRead memory using PC Read ALURead memory using ALUout for addr Write ALUWrite memory using ALUout for addr MemregIRIR <= Mem PCwritePCwrPC <= PCSource PCSrc IF Zero then PCSource <= ALUout else ALU PCWrCond I F Zero then PC <= PCSource Seq(uencing)SeqGo to next sequential µinstruction FetchGo to the first microinstruction DispatchDispatch using ROM. ALUSRC 1 SRC 2 DestMemMemregPCwriteSeq

27. CS152 / Kubiatowicz Lec9.27 2/25/04©UCB Spring 2004 Quick check: what do these fieldnames mean? CodeNameRegWriteMemToRegRegDest 00---0XX 01rd ALU101 10rt ALU100 11rt MEM110 CodeNameALUSelBExtOp 000---XX 001400X 010rt01X 011ExtShft101 100Extend111 111Extend0110 Destination: SRC2:

28. CS152 / Kubiatowicz Lec9.28 2/25/04©UCB Spring 2004 Specific Sequencer for our Microcoding 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 0 012 Opcode: Dispatch state 000000:Rtype (0100)  000100:BEQ (0010)  001101:ORI (0110)  100011:LW (1000)  101011:SW(1011) 

29. CS152 / Kubiatowicz Lec9.29 2/25/04©UCB Spring 2004 Recap: 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” 0000 0001 0100 0101 0110 0111 1000 1001 1010 1011 1100 BEQ 0010 If A = B then PC <= ALUout ALUout <= PC +SX Execute Memory Write-back

30. CS152 / Kubiatowicz Lec9.30 2/25/04©UCB Spring 2004 Microprogram it yourself! AddrALU SRC1SRC2Dest.MemoryMem. Reg. PC Write Sequencing Fetch: 0000:AddPC4Read PCIRALUSeq Decode: 0001:AddPCExtshftDispatch BEQ: 0010:Subt.rsrt ALUoutCond.Fetch Rtype: 0100:FuncrsrtSeq 0101:rd ALUFetch ORI: 0110:Orrs Extend0 Seq 0111:rt ALUFetch LW: 1000:AddrsExtend Seq 1001:Read ALU Seq 1010: rt MEM Fetch SW: 1011:AddrsExtendSeq 1100:Write ALUFetch

31. CS152 / Kubiatowicz Lec9.31 2/25/04©UCB Spring 2004 Overview of Control °Control may be designed using one of several initial representations. The choice of sequence control, and how logic is represented, can then be determined independently; the control can then be implemented with one of several methods using a structured logic technique. Initial Representation Finite State Diagram Microprogram Sequencing ControlExplicit Next State Microprogram counter Function + Dispatch ROMs Logic RepresentationLogic EquationsTruth Tables Implementation PLAROM Technique “hardwired control”“microprogrammed control”

32. CS152 / Kubiatowicz Lec9.32 2/25/04©UCB Spring 2004 Exceptions °Exception = unprogrammed control transfer system takes action to handle the exception -must record the address of the offending instruction -record any other information necessary to return afterwards returns control to user must save & restore user state °Allows constuction of a “user virtual machine” normal control flow: sequential, jumps, branches, calls, returns user program System Exception Handler Exception: return from exception

33. CS152 / Kubiatowicz Lec9.33 2/25/04©UCB Spring 2004 Two Types of Exceptions: Interrupts and Traps °Interrupts caused by external events: -Network, Keyboard, Disk I/O, Timer asynchronous to program execution -Most interrupts can be disabled for brief periods of time -Some (like “Power Failing”) are non-maskable (NMI) may be handled between instructions simply suspend and resume user program °Traps caused by internal events -exceptional conditions (overflow) -errors (parity) -faults (non-resident page) synchronous to program execution condition must be remedied by the handler instruction may be retried or simulated and program continued or program may be aborted

34. CS152 / Kubiatowicz Lec9.34 2/25/04©UCB Spring 2004 Precise Exceptions °Precise  state of the machine is preserved as if program executed up to the offending instruction All previous instructions completed Offending instruction and all following instructions act as if they have not even started Same system code will work on different implementations Position clearly established by IBM Difficult in the presence of pipelining, out-ot-order execution,... MIPS takes this position °Imprecise  system software has to figure out what is where and put it all back together °Performance goals often lead designers to forsake precise interrupts system software developers, user, markets etc. usually wish they had not done this °Modern techniques for out-of-order execution and branch prediction help implement precise interrupts

35. CS152 / Kubiatowicz Lec9.35 2/25/04©UCB Spring 2004 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 °Sophisticated microcontrollers lead to complete micro- machine language! Branches, jumps, etc Old MIT course: many levels: Machine language, Microcode, nanocode