CS 152: Computer Architecture and Engineering Lecture 11 Multicycle Controller Design Exceptions Randy H. Katz, Instructor Satrajit Chatterjee, Teaching.

Slides:



Advertisements
Similar presentations
361 multicontroller.1 ECE 361 Computer Architecture Lecture 11: Designing a Multiple Cycle Controller.
Advertisements

ECE 232 L15.Microprog.1 Adapted from Patterson 97 ©UCBCopyright 1998 Morgan Kaufmann Publishers ECE 232 Hardware Organization and Design Lecture 15 Microprogrammed.
CS152 / Kubiatowicz Lec10.1 3/1/99©UCB Spring 1999 Alternative datapath (book): Multiple Cycle Datapath °Miminizes Hardware: 1 memory, 1 adder Ideal Memory.
Savio Chau Single Cycle Controller Design Last Time: Discussed the Designing of a Single Cycle Datapath Control Datapath Memory Processor (CPU) Input Output.
Pipeline Exceptions & ControlCSCE430/830 Pipeline: Exceptions & Control CSCE430/830 Computer Architecture Lecturer: Prof. Hong Jiang Courtesy of Yifeng.
Preparation for Midterm Binary Data Storage (integer, char, float pt) and Operations, Logic, Flip Flops, Switch Debouncing, Timing, Synchronous / Asynchronous.
Class 9.1 Computer Architecture - HUJI Computer Architecture Class 9 Microprogramming.
EECC550 - Shaaban #1 Lec # 6 Winter Control may be designed using one of several initial representations. The choice of sequence control,
S. Barua – CPSC 440 CHAPTER 5 THE PROCESSOR: DATAPATH AND CONTROL Goals – Understand how the various.
ECE 232 L23.Exceptions.1 Adapted from Patterson 97 ©UCBCopyright 1998 Morgan Kaufmann Publishers ECE 232 Hardware Organization and Design Lecture 23 Exceptions.
Dr. Iyad F. Jafar Basic MIPS Architecture: Multi-Cycle Datapath and Control.
What are Exception and Interrupts? MIPS terminology Exception: any unexpected change in the internal control flow – Invoking an operating system service.
Prof. John Nestor ECE Department Lafayette College Easton, Pennsylvania ECE Computer Organization Multi-Cycle Processor.
COSC 3430 L08 Basic MIPS Architecture.1 COSC 3430 Computer Architecture Lecture 08 Processors Single cycle Datapath PH 3: Sections
CASE STUDY OF A MULTYCYCLE DATAPATH. Alternative Multiple Cycle Datapath (In Textbook) Minimizes Hardware: 1 memory, 1 ALU Ideal Memory Din Address 32.
Exam 2 Review Two’s Complement Arithmetic Ripple carry ALU logic and performance Look-ahead techniques Basic multiplication and division ( non- restoring)
Interrupt driven I/O. MIPS RISC Exception Mechanism The processor operates in The processor operates in user mode user mode kernel mode kernel mode Access.
IT253: Computer Organization Lecture 9: Making a Processor: Single-Cycle Processor Design Tonga Institute of Higher Education.
Microprogramming and Exceptions Spring 2005 Ilam University.
CS152 Lec12.1 CS 152 Computer Architecture and Engineering Lecture 12 Multicycle Controller Design Exceptions.
Multicycle Implementation
Interrupt driven I/O Computer Organization and Assembly Language: Module 12.
Prof. John Nestor ECE Department Lafayette College Easton, Pennsylvania ECE Computer Organization Lecture 16 - Multi-Cycle.
Single Cycle Controller Design
CS/EE 362 multipath..1 ©DAP & SIK 1995 CS/EE 362 Hardware Fundamentals Lecture 14: Designing a Multi-Cycle Datapath (Chapter 5: Hennessy and Patterson)
CDA 3101 Spring 2016 Introduction to Computer Organization Microprogramming and Exceptions 08 March 2016.
Computer Architecture Lecture 6.  Our implementation of the MIPS is simplified memory-reference instructions: lw, sw arithmetic-logical instructions:
Design a MIPS Processor (II)
Problem with Single Cycle Processor Design
CS161 – Design and Architecture of Computer Systems
Computer Organization CS224
IT 251 Computer Organization and Architecture
IT 251 Computer Organization and Architecture
/ Computer Architecture and Design
Systems Architecture I
Extensions to the Multicycle CPU
Designing a Multicycle Processor
Designing a Multicycle Processor
Processor (I).
CS/COE0447 Computer Organization & Assembly Language
Multiple Cycle Implementation of MIPS-Lite CPU
CpE242 Computer Architecture and Engineering Designing a Single Cycle Datapath Start: X:40.
CSCE 212 Chapter 5 The Processor: Datapath and Control
Processor: Finite State Machine & Microprogramming
Computer Architecture
CS 704 Advanced Computer Architecture
ECE/CS 552: Microprogramming and Exceptions
CS 704 Advanced Computer Architecture
John Kubiatowicz (http.cs.berkeley.edu/~kubitron)
The Multicycle Implementation
Chapter Five The Processor: Datapath and Control
The Multicycle Implementation
CS152 Computer Architecture and Engineering Lecture 8 Designing a Single Cycle Datapath Start: X:40.
Systems Architecture I
CpE 442 Microprogramming and Exceptions
BIC 10503: COMPUTER ARCHITECTURE
The Processor Lecture 3.2: Building a Datapath with Control
COMS 361 Computer Organization
EECS 361 Computer Architecture Lecture 11: Designing a Multiple Cycle Controller Start X:40.
Processor: Multi-Cycle Datapath & Control
Multi-Cycle Datapath Lecture notes from MKP, H. H. Lee and S. Yalamanchili.
Chapter Four The Processor: Datapath and Control
Datapath and Control Exceptions
ECE/CS 552: Pipelining and Exceptions
Instructors: Randy H. Katz David A. Patterson
Systems Architecture I
Alternative datapath (book): Multiple Cycle Datapath
Control Implementation Alternatives For Multi-Cycle CPUs
COMS 361 Computer Organization
What You Will Learn In Next Few Sets of Lectures
Presentation transcript:

CS 152: Computer Architecture and Engineering Lecture 11 Multicycle Controller Design Exceptions Randy H. Katz, Instructor Satrajit Chatterjee, Teaching Assistant George Porter, Teaching Assistant

The Big Picture: Where are We Now? The Five Classic Components of a Computer Today’s Topics: Microprogramed control Microprogram it yourself Exceptions Intro to Pipelining (if time permits) Control Datapath Memory Processor Input Output So where are in in the overall scheme of things. Well, we just finished designing the processor’s datapath. Now I am going to show you how to design the control for the datapath. +1 = 7 min. (X:47)

Recap: Datapath—Single Memory, Single Regfile Minimizes Hardware: 1 memory, 1 adder PCWr PCWrCond PCSrc Zero IorD MemWr IRWr RegDst RegWr ALUSelA 1 32 32 Mux PC 32 Instruction Reg Mux 1 Zero Rs Mux 1 Ra 32 RAdr 5 32 Rt ALU Out 32 Rb busA A 32 Ideal Memory 32 ALU 5 Reg File Mux 1 Rt 4 Rw 32 WrAdr 32 B 32 32 Mem Data Reg Rd 32 1 Din Dout busW busB 32 2 ALU Control Putting it all together, here it is: the multiple cycle datapath we set out to built. +1 = 47 min. (Y:47) Mux 1 3 << 2 Extend Imm 16 32 ALUOp ExtOp MemtoReg ALUSelB

Recap: Finite State Machine (FSM) Spec IR <= MEM[PC] PC <= PC + 4 “instruction fetch” 0000 ALUout <= PC +SX “decode” 0001 LW BEQ R-type ORi SW ALUout <= A fun B ALUout <= A or ZX ALUout <= A + SX ALUout <= A + SX If A = B then PC <= ALUout Execute 0100 0110 1000 1011 0010 M <= MEM[ALUout] MEM[ALUout] <= B Memory 1001 1100 R[rd] <= ALUout R[rt] <= ALUout R[rt] <= M Write-back 0101 0111 1010

Recap: Specific Sequencer from last lecture Sequencer-based control unit from last lecture Called “microPC” or “µPC” vs. state register Control Value Effect 00 Next µaddress = 0 01 Next µaddress = dispatch ROM 10 Next µaddress = µaddress + 1 ROM: 1 microPC Adder R-type 000000 0100 BEQ 000100 0011 ori 001101 0110 LW 100011 1000 SW 101011 1011 Mux 2 1 µAddress Select Logic ROM Opcode

Microprogram It Yourself! Label ALU SRC1 SRC2 ALU Dest. Memory Mem. Reg. PC Write Sequencing Fetch: Add PC 4 Read PC IR ALU Seq Add PC Extshft Dispatch Rtype: Funct rs rt Seq rd ALU Fetch BEQ: Subt rs rt ALUoutCond Fetch 1) Do two microinstructions on slide 2) Refer to the FSD each time first to see what should be done 3) look up the values in the fields each time to see what to do 4) Probably want multiple slides 5) Come out of presentation mode so that can edit the result on the screen Advantages of microprogramming: ease of change (show edit step)

Microprogram It Yourself! Label ALU SRC1 SRC2 Dest. Memory Mem. Reg. PC Write Sequencing Fetch: Add PC 4 Read PC IR ALU Seq Add PC Extshft Dispatch Rtype: Func rs rt Seq rd ALU Fetch Ori: Or rs Extend0 Seq rt ALU Fetch Lw: Add rs Extend Seq Read ALU Seq rt MEM Fetch Sw: Add rs Extend Seq Write ALU Fetch Beq: Subt. rs rt ALUoutCond. Fetch

Idea: wrap testing infrastructure around devices under test (DUT) Test 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 (for patterns or output diagnostics) Inline Monitor Output in readable format (disassembly) Assert Statements Complete Top-Level Design

Exception = unprogrammed control transfer Exceptions user program System Exception Handler Exception: 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 construction of a “user virtual machine”

Two Types of Exceptions: Interrupts and Traps 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

Traps and Interrupts Exception means any unexpected change in control flow, without distinguishing internal or external; Type of event From where? terminology I/O device request External Interrupt Invoke OS from usr program Internal Trap Arithmetic overflow Internal Trap Using undefined instruction Internal Trap Hardware malfunctions Either Trap or Interrupt

What Happens to Instruction with Exception? MIPS architecture defines the instruction as having no effect if the instruction causes an exception. When we get to virtual memory we will see that certain classes of exceptions must prevent the instruction from changing the machine state. This aspect of handling exceptions becomes complex and potentially limits performance => why it is hard

Precise Interrupts 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 Difficult in the presence of pipelining, out-of-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 not implement 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

Big Picture: User / System modes By providing two modes of execution (user/system) it is possible for the computer to manage itself OS is a special program that runs in the privileged mode and has access to all of the resources of the computer Presents “virtual resources” to each user that are more convenient that the physical resources files vs. disk sectors virtual memory vs physical memory Protects each user program from others Protects system from malicious users. OS is assumed to “know best”, and is trusted code, so enter system mode on exception. Exceptions allow the system to taken action in response to events that occur while user program is executing: Might provide supplemental behavior (dealing with denormal floating-point numbers for instance). “Unimplemented instruction” used to emulate instructions that were not included in hardware

Addressing the Exception Handler iv_base cause handler code Traditional Approach: Interupt Vector PC <- MEM[ IV_base + cause || 00] 370, 68000, Vax, 80x86, . . . RISC Handler Table PC <– IT_base + cause || 0000 saves state and jumps Sparc, PA, M88K, . . . MIPS Approach: fixed entry PC <– EXC_addr Actually very small table RESET entry TLB other handler entry code it_base cause

Save it in special registers Saving State Push it onto the stack 68k, 80x86 Shadow Registers M88k Save state in a shadow of the internal pipeline registers Save it in special registers MIPS EPC, BadVaddr, Status, Cause

Additions to MIPS ISA to Support Exceptions? Exception state is kept in “coprocessor 0”. Use mfc0 read contents of these registers Every register is 32 bits, but may be only partially defined BadVAddr (register 8) register contains memory address at which memory reference occurred Status (register 12) interrupt mask and enable bits Cause (register 13) the cause of the exception Bits 5 to 2 of this register encodes the exception type (e.g undefined instruction=10 and arithmetic overflow=12) EPC (register 14) address of the affected instruction (register 14 of coprocessor 0). Control signals to write BadVAddr, Status, Cause, and EPC Be able to write exception address into PC (8000 0080hex) May have to undo PC = PC + 4, since want EPC to point to offending instruction (not its successor): PC = PC - 4

Details of Status register 15 8 5 4 3 2 1 Status k e Mask old prev current Mask = 1 bit for each of 5 hardware and 3 software interrupt levels 1 => enables interrupts 0 => disables interrupts k = kernel/user 0 => was in the kernel when interrupt occurred 1 => was running user mode e = interrupt enable 0 => interrupts were disabled 1 => interrupts were enabled When interrupt occurs, 6 LSB shifted left 2 bits, setting 2 LSB to 0 run in kernel mode with interrupts disabled

Details of Cause Register 15 10 5 2 Status Pending Code Pending interrupt 5 hardware levels: bit set if interrupt occurs but not yet serviced handles cases when more than one interrupt occurs at same time, or while records interrupt requests when interrupts disabled Exception Code encodes reasons for interrupt 0 (INT) => external interrupt 4 (ADDRL) => address error exception (load or instr fetch) 5 (ADDRS) => address error exception (store) 6 (IBUS) => bus error on instruction fetch 7 (DBUS) => bus error on data fetch 8 (Syscall) => Syscall exception 9 (BKPT) => Breakpoint exception 10 (RI) => Reserved Instruction exception 12 (OVF) => Arithmetic overflow exception

Example: How Control Handles Traps in our FSD Undefined Instruction–detected when no next state is defined from state 1 for the op value. Handle this by defining the next state value for all op values other than lw, sw, 0 (R-type), jmp, beq, and ori as new state 12. Shown symbolically using “other” to indicate that the op field does not match any of the opcodes that label arcs out of state 1. Arithmetic overflow–detected on ALU ops like signed add Used to save PC and enter exception handler External Interrupt – flagged by asserted interrupt line Again, must save PC and enter exception handler Note: Challenge in designing control of a real machine is to handle different interactions between instructions and other exceptions-causing events such that control logic remains small and fast. Complex interactions makes the control unit the most challenging aspect of hardware design

How to Add Traps and Interrupts to State Diagram “instruction fetch” EPC <= PC-4 PC <= exp_addr cause <= 0(INT) Handle Interrupt Pending INT IR <= MEM[PC] PC <= PC + 4 0000 overflow EPC <= PC-4 PC <= exp_addr cause <= 12 (Ovf) undefined instruction EPC <= PC-4 PC <= exp_addr cause<=10(RI) other “decode” S<= PC +SX 0001 BEQ LW R-type ORi SW If A = B then PC <= S S <= A fun B S <= A op ZX S <= A + SX S <= A + SX 0100 0110 1000 1011 0010 S <= A - B M <= MEM[S] MEM[S] <= B 1001 1100 R[rd] <= S R[rt] <= S R[rt] <= M 0101 0111 1010

But: What Has to Change in Our -sequencer? Need concept of branch at micro-code level µAddress Select Logic Opcode microPC 1 Adder Dispatch ROM Mux 2 overflow pending interrupt 4? N? Cond Select Do -branch -offset Seq Select R-type S <= A fun B 0100 overflow EPC <= PC - 4 PC <= exp_addr cause <= 12 (Ovf)

Microprogramming is a fundamental concept 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 Exceptions are the hard part of control Need to find convenient place to detect exceptions and to branch to state or microinstruction that saves PC and invokes the operating system Providing clean interrupt model gets hard with pipelining! Precise Exception  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