ECE 313 Computer Organization MultiCycle Processor Design 3

  • Slides: 19
Download presentation
ECE 313 - Computer Organization Multi-Cycle Processor Design 3 Fall 2005 Prof. John Nestor

ECE 313 - Computer Organization Multi-Cycle Processor Design 3 Fall 2005 Prof. John Nestor ECE Department Lafayette College Easton, Pennsylvania 18042 nestorj@lafayette. edu Portions of these slides are derived from: Textbook figures © 1998 Morgan Kaufmann Publishers all rights reserved Tod Amon's COD 2 e Slides © 1998 Morgan Kaufmann Publishers all rights reserved Dave Patterson’s CS 152 Slides - Fall 1997 © UCB Rob Rutenbar’s 18 -347 Slides - Fall 1999 CMU Fall 2005 Multicycle Design 3 other sources as noted 1

Outline - Multicycle Design } } } } Overview Datapath Design Controller Design Aside:

Outline - Multicycle Design } } } } Overview Datapath Design Controller Design Aside: FSM Design in Verilog Performance Considerations Extending the Design: An Example Microprogramming Exceptions Fall 2005 Multicycle Design 3 2

Exceptions - “Stuff Happens” } Definition: "unexpected change in control flow" } Used to

Exceptions - “Stuff Happens” } Definition: "unexpected change in control flow" } Used to handle runtime errors } Overflow } Undefined Instruction } Hardware malfunction } Used to handle external events, "service" functions } Interrupts - external I/O Device request } Page fault - virtual memory } System call - user request for OS action Fall 2005 Multicycle Design 3 3

Example: Undefined Instructions (OP ≠ R-Type OP≠LW, OP–W, OP≠BEQ) What happens here ? ?

Example: Undefined Instructions (OP ≠ R-Type OP≠LW, OP–W, OP≠BEQ) What happens here ? ? Fall 2005 Multicycle Design 3 4

What happens during an exception } Save user state - register values, etc. }

What happens during an exception } Save user state - register values, etc. } Take action to handle exception } Restore user state and continue execution if possible (e. g. , emulate undefined instr. ) user program sub r 5, r 3, r 2 Exception: undefined instruction Exception Handler (System) beq r 0, r 1, L srl r 1, r 2, 2 add. s f 0, f 1, f 2 add r 5, r 4, r 3 bne r 4, r 3, L 2 add r 3, r 1, r 2 Fall 2005 Return from exception Multicycle Design 3 rfe 5

Adding Exceptions to the Multicycle Processor } Two exceptions (for now): } Undefined instruction

Adding Exceptions to the Multicycle Processor } Two exceptions (for now): } Undefined instruction } Arithmetic overflow } Add registers to architecture to save state } EPC - Exception Program Counter (32 bits) } Cause - records cause of exception (32 bits) • Undefined instruction: Cause <- 0 • Arithmetic overflow: Cause <- 1 } Alternatives used by other architectures • Save PC on stack • Communicate exception type using Exception Vector Fall 2005 Multicycle Design 3 6

Implementing Exceptions } Add datapath components - Figure 5. 39 } Exception. PC (EPC)

Implementing Exceptions } Add datapath components - Figure 5. 39 } Exception. PC (EPC) - stores PC of offending instruction } Cause Register - records the cause of the exception } Modify control - Figures 5. 40 } Undefined Instruction - state 1 (Instruction decode) } Overflow - state 7 (R-type completion) Fall 2005 Multicycle Design 3 7

Adding Exception Support to Datapath IRWrite 8000 0180 hex I R Instruction I PCWr*

Adding Exception Support to Datapath IRWrite 8000 0180 hex I R Instruction I PCWr* jmpaddr rs 32 Ior. D 5 U 1 X 5 0 MUX rd 1 I[25: 0] RN 1 Mem. Write ADDR Memory RD M D R 1 M U 0 X RN 2 Registers WD RD 1 RD 2 Mem. Read 0 M B Reg. Write immediate Fall 2005 16 Multicycle Design 3 U 1 X A Memto. Reg E X 32 T N D <<2 ALUSrc. A Operation WN WD 3 2 M U 1 X 0 32 CONCAT Reg. Dst 5 PC 0 M 5 rt 28 4 <<2 3 E P C Zero ALU 0 1 M U 2 X 3 ALUSrc. B PCSource ALU OUT Overflow 0 0 M 1 1 X U EPCWrite C A U S E Int. Cause. Write 8

Fig. 5. 39 Fall 2005 Multicycle Design 3 9

Fig. 5. 39 Fall 2005 Multicycle Design 3 9

Fall 2005 Multicycle Design 3 10

Fall 2005 Multicycle Design 3 10

Implementing Exceptions } Datapath modifications } Calculate address of offending instruction (PC-4) and store

Implementing Exceptions } Datapath modifications } Calculate address of offending instruction (PC-4) and store in EPC } Store 0 or 1 in Cause } Add overflow output from ALU (described in Ch. 4) } Assign "8000 0180 hex" to PC - fixed location of handler } Control modifications } Undefined instruction: add ”default" branch to Instruction Fetch state } Overflow: test after execution state for R-type instructions Fall 2005 Multicycle Design 3 11

Adding Exception Support to Control Undefined Instruction Decode / Register Fetch State 1 ALUSrc.

Adding Exception Support to Control Undefined Instruction Decode / Register Fetch State 1 ALUSrc. A = 0 ALUSrc. B = 11 ALUOp = 00 from State 0 State 2 Mem. Ref States Fall 2005 = State 6 Execution States EQ ’ State 8 Branch State (OP = ‘J’) ( OP ‘B -T ‘R (OP = Other) Int. Cause = 0 Cause. Write ALUSrc. A = 0 ALUSrc. B = 01 ALUOp = 01 EPCWRITE PCWrite PCSource=11 ) ’) e yp P= p (O ’ LW ‘ = ’) (O p O or SW =‘ Undefined State 10 Instruction State 0 State 9 Jump State Multicycle Design 3 12

Adding Exception Support to Control Arithmetic Overflow from State 1 (OP = R-Type) State

Adding Exception Support to Control Arithmetic Overflow from State 1 (OP = R-Type) State 10 Execution State 6 ALUSrc. A = 1 ALUSrc. B = 00 ALUOp = 10 R-type completion State 7 w Reg. Dst = 1 Reg. Write Memto. Reg = 0 No Overflow to State 0 Fall 2005 flo Over Note: requires storage of overflow condition from previous state Multicycle Design 3 Overflow Int. Cause = 1 Cause. Write ALUSrc. A = 0 ALUSrc. B = 01 ALUOp = 01 EPCWRITE PCWrite PCSource=11 State 0 13

What makes exceptions hard } The “real” MIPS architecture requires that instruction causing exception

What makes exceptions hard } The “real” MIPS architecture requires that instruction causing exception must have "no effect" } Implication: undo effects of instruction } decrement PC } prevent storage of result during R-type instruction } What about “recursive” exceptions? } Must add instructions to save exception registers on stack } Disable exceptions / interrupts until registers saved } More details in Appendix A (A. 7) Fall 2005 Multicycle Design 3 14

Summary - Exceptions } } } Must consider as part of overall design Must

Summary - Exceptions } } } Must consider as part of overall design Must find "convenient" places to detect exceptions Must find way to cleanly return from exception Must keep control “small and fast” Much harder in pipelined implementations! Fall 2005 Multicycle Design 3 15

Project 3 - Multicycle MIPS in Verilog Fall 2005 Multicycle Design 3 16

Project 3 - Multicycle MIPS in Verilog Fall 2005 Multicycle Design 3 16

Review - Multicycle FSM Fall 2005 Multicycle Design 3 17

Review - Multicycle FSM Fall 2005 Multicycle Design 3 17

Summary - Chapter 5 } Processor design: creating hardware to fetch and execute instructions

Summary - Chapter 5 } Processor design: creating hardware to fetch and execute instructions } What we've learned } } Design is a process Single cycle implementation Multicycle implementation Performance is key Fall 2005 Multicycle Design 3 18

Roadmap for the term: major topics } } } Overview / Abstractions and Technology

Roadmap for the term: major topics } } } Overview / Abstractions and Technology Instruction sets Logic & arithmetic Performance Processor Implementation } Single-cycle implemenatation } Multicycle implementation } Pipelined Implementation } Memory systems } Input/Output Fall 2005 Multicycle Design 3 19