2. Prof. John Nestor ECE Department Lafayette College Easton, Pennsylvania 18042 nestorj@lafayette.edu ECE 313 - Computer Organization Multi-Cycle Processor Design 3 Fall 2005 Portions of these slides are derived from: Textbook figures © 1998 Morgan Kaufmann Publishers all rights reserved Tod Amon's COD2e 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 other sources as noted

3. Fall 2005Multicycle Design 32 Outline - Multicycle Design  Overview  Datapath Design  Controller Design  Aside: FSM Design in Verilog  Performance Considerations  Extending the Design: An Example  Microprogramming  Exceptions 

4. Fall 2005Multicycle Design 33 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

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

6. Fall 2005Multicycle Design 35 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.) Exception: undefined instruction Return from exception user program add.s f0,f1,f2 srl r1,r2,2 beq r0,r1,L sub r5,r3,r2 add r5,r4,r3 bne r4,r3,L2 add r3,r1,r2 Exception Handler (System) rfe

7. Fall 2005Multicycle Design 36 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

8. Fall 2005Multicycle Design 37 Implementing Exceptions  Add datapath components - Figure 5.39  ExceptionPC (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)

9. Fall 2005Multicycle Design 38 Adding Exception Support to Datapath 55 RD1 RD2 RN1RN2WN WD RegWrite Registers Operation ALU 3 E X T N D 1632 Zero RD WD MemRead Memory ADDR MemWrite 5 Instruction I 32 ALUSrcB <<2 PC 4 RegDst 5 I R M D R M U X 0 1 2 3 M U X 1 0 M U X 0 1 A B ALU OUT 0 1 2 M U X <<2 CONCAT 2832 M U X 0 1 ALUSrcA jmpaddr I[25:0] rd MUX 01 rtrs immediate PCSource MemtoReg IorD PCWr* IRWrite E P C EPCWrite C A U S E CauseWrite M U X 0 1 IntCause. 1 0 3 8000 0180 hex Overflow

10. Fall 2005Multicycle Design 39 Fig.5.39

11. Fall 2005Multicycle Design 310

12. Fall 2005Multicycle Design 311 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

13. Fall 2005Multicycle Design 312 Adding Exception Support to Control - Undefined Instruction IntCause = 0 CauseWrite ALUSrcA = 0 ALUSrcB = 01 ALUOp = 01 EPCWRITE PCWrite PCSource=11 State 10 Undefined Instruction State 0 ALUSrcA = 0 ALUSrcB = 11 ALUOp = 00 State 1 Instruction Decode / Register Fetch State 9 Jump State State 8 Branch State State 6 Execution States State 2 Mem. Ref States (OP = ‘J’) (OP = ‘BEQ’) (OP = ‘R-Type’) (Op = ‘LW’ or Op = ‘SW’) from State 0 (OP = Other)

14. Fall 2005Multicycle Design 313 Adding Exception Support to Control - Arithmetic Overflow IntCause = 1 CauseWrite ALUSrcA = 0 ALUSrcB = 01 ALUOp = 01 EPCWRITE PCWrite PCSource=11 State 10 Overflow State 0 Overflow Note: requires storage of overflow condition from previous state ALUSrcA = 1 ALUSrcB = 00 ALUOp = 10 State 6 RegDst = 1 RegWrite MemtoReg = 0 State 7 R-type completion from State 1 (OP = R-Type) to State 0 Execution No Overflow

15. Fall 2005Multicycle Design 314 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)

16. Fall 2005Multicycle Design 315 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!

17. Fall 2005Multicycle Design 316 Project 3 - Multicycle MIPS in Verilog

18. Fall 2005Multicycle Design 317 Review - Multicycle FSM

19. Fall 2005Multicycle Design 318 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

20. Fall 2005Multicycle Design 319 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