CS 152 Computer Architecture and Engineering Lecture 9

  • Slides: 35
Download presentation
CS 152 Computer Architecture and Engineering Lecture 9 Multiprogramming and Exceptions February 25, 2004

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/~cs 152/

The Big Picture: Where are We Now? ° The Five Classic Components of a

The Big Picture: Where are We Now? ° The Five Classic Components of a Computer Processor Input Control Memory Datapath Output ° Today’s Topics: • • • 2/25/04 Microprogramed control Administrivia; Courses Microprogram it yourself Exceptions Intro to Pipelining (if time permits) ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 2

2/25/04 Ext. Op Equal B ©UCB Spring 2004 S Reg. File Reg. Dst Reg.

2/25/04 Ext. Op Equal B ©UCB Spring 2004 S Reg. File Reg. Dst Reg. Wr Mem. To. Reg Mem. Rd Mem. Wr ALUctr Ext ALUSrc ALU A Result Store Reg File Mem Access IR n. PC_sel E Data Mem Operand Fetch Instruction Fetch PC Next PC Review: Multicycle Datapath M ° Critical Path ? CS 152 / Kubiatowicz Lec 9. 3

Review: Control Specification as State Machine IR <= MEM[PC] S <= A fun B

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

Review: Performance Evaluation ° What is the average CPI? • state diagram gives CPI

Review: Performance Evaluation ° What is the average CPI? • state diagram gives CPI for each instruction type • workload gives frequency of each type Type CPIi for type Frequency CPIi x freq. Ii Arith/Logic 4 40% 1. 6 Load 5 30% 1. 5 Store 4 10% 0. 4 branch 3 20% 0. 6 Average CPI: 4. 1 2/25/04 ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 5

Review: Micro-Controller Design ° The state digrams that arise define the controller for an

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 datapath control microinstruction micro-PC 2/25/04 sequencer ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 6

Example: Jump-Counter “Zero” 0000 “Increment” “Load” i i i+1 Map ROM None of above:

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

Using a Jump Counter IR <= MEM[PC] 0000 inc “decode” A <= R[rs] B

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

Our Microsequencer Equal ZIL datapath control Micro-PC op-code Map ROM 2/25/04 ©UCB Spring 2004

Our Microsequencer Equal ZIL datapath control Micro-PC op-code Map ROM 2/25/04 ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 9

Microprogram Control Specification: Logic? ROM? Inputs µPC Equal 0000 0001 BEQ: 0011 R: 0100

Microprogram Control Specification: Logic? ROM? Inputs µPC Equal 0000 0001 BEQ: 0011 R: 0100 0101 ORi: Outputs Next IR PC Ops Exec Mem Write-Back en sel A B Ex Sr ALU S R W M M-R Wr Dst x x 0 1 x x inc load zero inc zero x x inc 1 11 1 1 0 1 fun 1 1 0 0 1 1 0110 LW: 0111 0 0 or 1 1 0 0 1000 SW: 1001 1 1010 2/25/04 0 x zero 1 0 add 1 1 0 ©UCB Spring 2004 1 1 CS 152 / Kubiatowicz Lec 9. 10

Alternative multicycle datapath (book) ° Miminizes Hardware: 1 memory, 1 adder PCWr. Cond Zero

Alternative multicycle datapath (book) ° Miminizes Hardware: 1 memory, 1 adder PCWr. Cond Zero Mem. Wr IRWr Reg. Dst ALUSel. A Reg. Wr 32 PC 32 32 5 Rt 0 Rd Rb bus. A A Reg File Rw bus. W bus. B 1 1 Mux 0 Imm 16 1 4 B << 2 Extend Ext. Op 2/25/04 Ra 32 32 0 1 32 32 2 3 ALU Control 32 Memto. Reg ©UCB Spring 2004 Equal ALU Out Wr. Adr 32 Din Dout 32 Rt Mux Ideal Memory 1 5 32 ALU 32 Rs Mem Data Reg Mux RAdr 0 Mux 0 32 Instruction Reg 32 1 Mux Ior. D PCSrc ALUOp ALUSel. B CS 152 / Kubiatowicz Lec 9. 11

New Finite State Machine (FSM) Spec PC <= PC + 4 0000 “instruction fetch”

New Finite State Machine (FSM) Spec PC <= PC + 4 0000 “instruction fetch” “decode” Q: How improve to do something in state 0001? 0001 R-type ALUout <= A fun B 0100 ORi ALUout <= A or ZX 0110 LW ALUout <= A + SX 1000 M <= MEM[ALUout] 1001 R[rd] <= ALUout 0101 2/25/04 R[rt] <= ALUout 0111 BEQ SW ALUout <= A + SX 1011 MEM[ALUout] <= B 1100 R[rt] <= M 1010 ©UCB Spring 2004 ALUout <= PC +SX 0010 If A = B then PC <= ALUout 0011 Memory Write-back Execute IR <= MEM[PC] CS 152 / Kubiatowicz Lec 9. 12

Finite State Machine (FSM) Spec IR <= MEM[PC] PC <= PC + 4 0000

Finite State Machine (FSM) Spec IR <= MEM[PC] PC <= PC + 4 0000 ALUout <= PC +SX “instruction fetch” “decode” 0001 ALUout <= A fun B 0100 ORi ALUout <= A or ZX 0110 LW ALUout <= A + SX 1000 M <= MEM[ALUout] 1001 R[rd] <= ALUout 0101 2/25/04 R[rt] <= ALUout 0111 BEQ SW ALUout <= A + SX 1011 MEM[ALUout] <= B 1100 R[rt] <= M 1010 ©UCB Spring 2004 If A = B then PC <= ALUout 0010 Memory Write-back Execute R-type CS 152 / Kubiatowicz Lec 9. 13

Microprogramming sequencer datapath control Inputs -Code ROM microinstruction ( ) micro-PC Opcode -sequencer: fetch,

Microprogramming sequencer datapath control Inputs -Code ROM microinstruction ( ) micro-PC Opcode -sequencer: fetch, dispatch, sequential Dispatch ROM Decode To Data. Path ° 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 2/25/04 ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 14

Microprogramming ° Microprogramming is a convenient method for implementing structured control state diagrams: •

Microprogramming ° Microprogramming is a convenient method for implementing structured control state diagrams: • Random logic replaced by micro. PC 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 2/25/04 ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 15

“Macroinstruction” Interpretation Main Memory ADD SUB AND . . . DATA execution unit CPU

“Macroinstruction” Interpretation Main Memory ADD SUB AND . . . DATA execution unit CPU User program plus Data this can change! one of these is mapped into one of these AND microsequence control memory e. g. , Fetch Calc Operand Addr Fetch Operand(s) Calculate Save Answer(s) 2/25/04 ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 16

Administrivia ° Lab 3 design document to go over in section • EMail preliminary

Administrivia ° Lab 3 design document to go over in section • EMail preliminary design document to TA by 9 pm 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 Chip. Scope 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? 2/25/04 ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 17

Review: Testing: Make sure that things work ° Testing methodologies Alewife Numbers • Understand

Review: Testing: Make sure that things work ° Testing methodologies Alewife Numbers • 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 2/25/04 ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 18

Review: Monitor Modules: Passthrough testing module monitorsum 32(carry, sum, A, B ); input [31:

Review: Monitor Modules: Passthrough testing module monitorsum 32(carry, sum, A, B ); input [31: 0] A, B; output [31: 0] sum; output carry; reg [31: 0] predsum; reg precarry; // The “real” adder sum 32 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: 0 x%x+0 x%x->0 x%x carry %x”, A, B, sum, carry); end `endif endmodule 2/25/04 ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 19

Lab 3 version: monitors and benches ° Important design idea: • Set up your

Lab 3 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” Complete Top-Level Design Test Bench Device Under Test Inline Monitor Output in readable format (disassembly) Assert Statements Inline vectors Assert Statements File IO (either for patterns or output diagnostics) 2/25/04 ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 20

Designing a Microinstruction Set 1) Start with list of control signals 2) Group signals

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 2/25/04 ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 21

Recap: Multicycle datapath (book) PCWr PCSrc Reg. Dst ALUSel. A Reg. Wr 32 PC

Recap: Multicycle datapath (book) PCWr PCSrc Reg. Dst ALUSel. A Reg. Wr 32 PC 32 32 5 Rt 0 Rd Rb bus. A A Reg File Rw bus. W bus. B 1 1 Mux 0 Imm 16 1 4 B << 2 Extend Ext. Op 2/25/04 Ra 32 32 0 1 32 32 2 3 ALU Control 32 Memto. Reg ©UCB Spring 2004 Equal ALU Out Wr. Adr 32 Din Dout 32 Rt Mux Ideal Memory 1 5 32 ALU 32 Rs Mem Data Reg Mux RAdr 0 Mux 0 32 Instruction Reg 32 1 Mux PCWr. Cond Zero Ior. D Mem. Wr IRWr Mem. Rd ALUOp ALUSel. B CS 152 / Kubiatowicz Lec 9. 22

Multiple Bit Control Single Bit Control Step 1 Start with List of control signals

Multiple Bit Control Single Bit Control Step 1 Start with List of control signals Signal name Effect when deasserted Effect when asserted ALUSel. A 1 st ALU operand = PC 1 st ALU operand = Reg[rs] Reg. Write None Reg. is written Memto. Reg. write data input = ALU Reg. write data input = memory Reg. Dst Reg. dest. no. = rd Mem. Read None Memory at address is read, MDR <= Mem[addr] Mem. Write None Memory at address is written Ior. D Memory address = PC Memory address = S IRWrite None IR <= Memory PCWrite None PC <= PCSource PCWrite. Cond None IF ALUzero then PC <= PCSource = ALUout Ext. Op Zero Extended Signal name Value ALUOp 00 01 10 11 ALUSel. B 00 01 10 11 2/25/04 Effect ALU adds ALU subtracts ALU does function code ALU does logical OR 2 nd ALU input = 4 2 nd ALU input = Reg[rt] 2 nd ALU input = extended, shift left 2 2 nd ALU input = extended ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 23

Step 2 Group together related signals PCWrite PCWr. Cond Destination Memory Zero Ior. D

Step 2 Group together related signals PCWrite PCWr. Cond Destination Memory Zero Ior. D Mem. Wr IRWr Reg. Dst Reg. Wr Mem. Rd PCSrc SRC 1 32 PC 32 32 5 Rt 0 Rd bus. A A Reg File Rw bus. W bus. B 1 1 4 B << 2 Extend Ext. Op SRC 2 Rb 1 Mux 0 Imm 16 2/25/04 Ra 32 32 0 1 32 32 2 3 ALU Control 32 Memto. Reg ©UCB Spring 2004 Equal ALU Out Wr. Adr 32 Din Dout 32 Rt Mux Ideal Memory 1 5 32 ALU 32 Rs Mem Data Reg Mux RAdr 0 Mux 0 32 Instruction Reg 32 1 Mux ALUSel. A ALUOp ALUSel. B CS 152 / Kubiatowicz Lec 9. 24

3&4) Microinstruction Format: unencoded vs. encoded fields Field Name Width Control Signals Set wide

3&4) Microinstruction Format: unencoded vs. encoded fields Field Name Width Control Signals Set wide narrow ALU Control 4 2 ALUOp SRC 1 2 1 ALUSel. A SRC 2 5 3 ALUSel. B, Ext. Op ALU Destination 3 2 Memory 2 Mem. Read, Mem. Write, Ior. D Memory Register 1 1 IRWrite PCWrite Control PCSource 3 2 PCWrite, PCWrite. Cond, Sequencing 3 2 Addr. Ctl Total width 24 15 bits 2/25/04 3 Reg. Write, Memto. Reg, Reg. Dst ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 25

Step 5 Group into Fields, Order and Assign Names ALU SRC 1 SRC Dest

Step 5 Group into Fields, Order and Assign Names ALU SRC 1 SRC Dest Memreg 2 PCwrite Seq Field Name Values for Field Function of Field with Specific Value ALU Add ALU adds Subt. ALU subtracts Func ALU does function code Or ALU does logical OR SRC 1 PC 1 st ALU input <= PC rs 1 st ALU input <= Reg[rs] SRC 2 4 2 nd ALU input <= 4 Extend 2 nd ALU input <= sign ext. IR[15 -0] Extend 0 2 nd ALU input <= zero ext. IR[15 -0] Extshft 2 nd ALU input <= sign ex. , sl IR[15 -0] rt 2 nd ALU input <= Reg[rt] dest(ination) rd ALU Reg[rd] <= ALUout rt ALU Reg[rt] <= ALUout rt Mem Reg[rt] <= Mem(ory) Read PC Read memory using PC Read ALU Read memory using ALUout for addr Write ALU Write memory using ALUout for addr Memreg IR IR <= Mem PCwrite PCwr PC <= PCSource PCSrc IF Zero then PCSource <= ALUout else ALU PCWr. Cond IF Zero then PC <= PCSource Seq(uencing) Seq Go to next sequential µinstruction CS 152 / Kubiatowicz 2/25/04 ©UCB Spring 2004 Fetch Go to the first microinstruction Lec 9. 26 Dispatch using ROM.

Quick check: what do these fieldnames mean? Destination: Code Name 00 01 10 11

Quick check: what do these fieldnames mean? Destination: Code Name 00 01 10 11 Reg. Write --0 rd ALU 1 rt MEM 1 Mem. To. Reg X X 0 1 0 Reg. Dest SRC 2: Code 000 001 010 011 100 111 2/25/04 Name --4 rt Ext. Shft Extend 0 ALUSel. B X 00 01 10 11 11 Ext. Op X X X 1 1 0 ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 27

Specific Sequencer for our Microcoding Sequencer-based control unit from last lecture • Called “micro.

Specific Sequencer for our Microcoding Sequencer-based control unit from last lecture • Called “micro. PC” or “µPC” vs. state register Code 00 01 10 ROM: 2/25/04 Name Effect fetch Next µaddress = 0 dispatch Next µaddress = dispatch ROM seq Next µaddress = µaddress + 1 Opcode: Dispatch state 000000: Rtype (0100) 000100: BEQ (0010) 001101: ORI (0110) 100011: LW (1000) 101011: SW (1011) 1 Adder µAddress Select Logic ©UCB Spring 2004 micro. PC Mux 2 1 0 0 ROM Opcode CS 152 / Kubiatowicz Lec 9. 28

Recap: Finite State Machine (FSM) Spec IR <= MEM[PC] PC <= PC + 4

Recap: Finite State Machine (FSM) Spec IR <= MEM[PC] PC <= PC + 4 0000 ALUout <= PC +SX “instruction fetch” “decode” 0001 ALUout <= A fun B 0100 ORi ALUout <= A or ZX 0110 LW ALUout <= A + SX 1000 M <= MEM[ALUout] 1001 R[rd] <= ALUout 0101 2/25/04 R[rt] <= ALUout 0111 BEQ SW ALUout <= A + SX 1011 MEM[ALUout] <= B 1100 R[rt] <= M 1010 ©UCB Spring 2004 If A = B then PC <= ALUout 0010 Memory Write-back Execute R-type CS 152 / Kubiatowicz Lec 9. 29

Microprogram it yourself! Write Fetch: Addr ALU Sequencing SRC 1 SRC 2 Dest. Memory

Microprogram it yourself! Write Fetch: Addr ALU Sequencing SRC 1 SRC 2 Dest. Memory Mem. Reg. PC 0000: Seq Add PC 4 Read PC ALU 0001: Add Dispatch PC Extshft 0010: Fetch Subt. rs rt ALUout. Cond. 0100: 0101: Func rs rt Seq Fetch 0110: Seq 0111: Or 1000: 1001: Seq Add IR Decode: BEQ: Rtype: rd ALU ORI: rs Extend 0 rt ALU Fetch LW: 2/25/04 rs Extend ©UCB Spring 2004 Seq Read ALU CS 152 / Kubiatowicz Lec 9. 30

Overview of Control ° Control may be designed using one of several initial representations.

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 Sequencing Control Function Finite State Diagram Microprogram Explicit Next State + Dispatch ROMs Logic Representation Logic Equations Implementation Technique 2/25/04 PLA Microprogram counter Truth Tables ROM “hardwired control” ©UCB Spring 2004 “microprogrammed control” CS 152 / Kubiatowicz Lec 9. 31

Exceptions user program Exception: System Exception Handler return from exception normal control flow: sequential,

Exceptions user program Exception: System Exception Handler return from exception normal control flow: sequential, jumps, branches, calls, returns ° 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” 2/25/04 ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 32

Two Types of Exceptions: Interrupts and Traps ° Interrupts • caused by external events:

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 2/25/04 ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 33

Precise Exceptions ° Precise state of the machine is preserved as if program executed

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 2/25/04 ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 34

° Summary Microprogramming is a fundamental concept • • • ° implement an instruction

° 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 micromachine language! • • 2/25/04 Branches, jumps, etc Old MIT course: many levels: Machine language, Microcode, nanocode ©UCB Spring 2004 CS 152 / Kubiatowicz Lec 9. 35