Processor Design 5Z032 Processor: Datapath and Control Chapter 5 Henk Corporaal Eindhoven University of Technology 2009

TU/e Processor Design 5Z0322 Topics n Building a datapath u support a subset of the MIPS-I instruction-set n A single cycle processor datapath u all instruction actions in one (long) cycle n A multi-cycle processor datapath u each instructions takes multiple (shorter) cycles n Control: microprogramming n Exception support n Real stuff: Pentium Pro/II/III implementation

TUE Dig.Sys.Arch3 Datapath and Control DatapathControl Registers & Memories Multiplexors Buses ALUs FSM or Micro- programming

TUE Dig.Sys.Arch4 n We're ready to look at an implementation of the MIPS n Simplified to contain only:  memory-reference instructions: lw, sw  arithmetic-logical instructions: add, sub, and, or, slt  control flow instructions: beq, j n Generic Implementation: u use the program counter (PC) to supply instruction address u get the instruction from memory u read registers u use the instruction to decide exactly what to do n All instructions use the ALU after reading the registers Why? F memory-reference? F arithmetic? F control flow? The Processor: Datapath & Control

TUE Dig.Sys.Arch5 n Abstract / Simplified View: n Two types of functional units: u elements that operate on data values (combinational) u elements that contain state (sequential) More Implementation Details

TUE Dig.Sys.Arch6 n Unclocked vs. Clocked n Clocks used in synchronous logic u when should an element that contains state be updated? cycle time rising edge falling edge State Elements

TUE Dig.Sys.Arch7 n The set-reset (SR) latch u output depends on present inputs and also on past inputs An unclocked state element R S Q Q Truth table: R S Q 0 0 Q ? state change

TUE Dig.Sys.Arch8 n Output is equal to the stored value inside the element (don't need to ask for permission to look at the value) n Change of state (value) is based on the clock u Latches: whenever the inputs change, and the clock is asserted u Flip-flop: state changes only on a clock edge (edge-triggered methodology) A clocking methodology defines when signals can be read and written — wouldn't want to read a signal at the same time it was being written Latches and Flip-flops

TUE Dig.Sys.Arch9 n Two inputs: u the data value to be stored (D) u the clock signal (C) indicating when to read & store D n Two outputs: u the value of the internal state (Q) and it's complement D-latch

TUE Dig.Sys.Arch10 D flip-flop n Output changes only on the clock edge QQ _ Q Q _ Q D latch D C D latch DD C C

TUE Dig.Sys.Arch11 Our Implementation n An edge triggered methodology n Typical execution: u read contents of some state elements, u send values through some combinational logic, u write results to one or more state elements Clock cycle State element 1 Combinational logic State element 2

TUE Dig.Sys.Arch12 n 3-ported: one write, two read ports Register File Read reg. #1 Read reg.#2 Write reg.# Read data 1 Read data 2 Write data

TUE Dig.Sys.Arch13 Register file: read ports Register file built using D flip-flops

TUE Dig.Sys.Arch14 Register file: write port n Note: we still use the real clock to determine when to write

TUE Dig.Sys.Arch15 Simple Implementation n Include the functional units we need for each instruction Why do we need this stuff? ALU control RegWrite Registers Write register Read data 1 Read data 2 Read register 1 Read register 2 Write data ALU result ALU Data Data Register numbers a. Registersb. ALU Zero

TUE Dig.Sys.Arch16 Building the Datapath n Use multiplexors to stitch them together PC Instruction memory Read address Instruction Add ALU result M u x Registers Write register Write data Read data 1 Read data 2 Read register 1 Read register 2 Shift left 2 4 M u x ALU operation 3 RegWrite MemRead MemWrite PCSrc ALUSrc MemtoReg ALU result Zero ALU Data memory Address Write data Read data M u x Sign extend Add

TUE Dig.Sys.Arch17 n All of the logic is combinational n We wait for everything to settle down, and the right thing to be done u ALU might not produce “right answer” right away u we use write signals along with clock to determine when to write n Cycle time determined by length of the longest path Our Simple Control Structure We are ignoring some details like setup and hold times ! Clock cycle State element 1 Combinational logic State element 2

TUE Dig.Sys.Arch18 Control n Selecting the operations to perform (ALU, read/write, etc.) n Controlling the flow of data (multiplexor inputs) n Information comes from the 32 bits of the instruction Example: add $8, $17, $18 Instruction Format: op rs rt rd shamt funct n ALU's operation based on instruction type and function code

TUE Dig.Sys.Arch19 Control: 2 level implementation instruction register ALUop ALUcontrol Opcode Funct bit Control 1 Control 2 ALU 00: lw, sw 01: beq 10: add, sub, and, or, slt 000: and 001: or 010: add 110: sub 111: set on less than

TUE Dig.Sys.Arch20 Datapath with Control Fig. 5.19

TUE Dig.Sys.Arch21 What should the ALU do with this instruction example: lw $1, 100($2) op rs rt 16 bit offset ALU control input 000 AND 001OR 010add 110subtract 111set-on-less-than n Why is the code for subtract 110 and not 011? ALU Control1

TUE Dig.Sys.Arch22 n Must describe hardware to compute 3-bit ALU control input u given instruction type 00 = lw, sw 01 = beq, 10 = arithmetic u function code for arithmetic n Describe it using a truth table (can turn into gates): ALU Operation class, computed from instruction type ALU Control1

TUE Dig.Sys.Arch23 ALU Control1 n Simple combinational logic (truth tables)

TUE Dig.Sys.Arch24 Deriving Control2 signals 9 control (output) signals Determine these control signals directly from the opcodes: R-format: 0 lw: 35 sw: 43 beq: 4 Input

TUE Dig.Sys.Arch25 Control 2 n PLA example implementation

TUE Dig.Sys.Arch26 Single Cycle Implementation n Calculate cycle time assuming negligible delays except: u memory (2ns), ALU and adders (2ns), register file access (1ns)

TUE Dig.Sys.Arch27 Single Cycle Implementation n Memory (2ns), ALU & adders (2ns), reg. file access (1ns) n Fixed length clock: longest instruction is the ‘lw’ which requires 8 ns n Variable clock length (not realistic, just as exercise): u R-instr: 6 ns u Load: 8 ns u Store: 7 ns u Branch: 5 ns u Jump: 2 ns n Average depends on instruction mix (see pg 374)

TUE Dig.Sys.Arch28 Where we are headed n Single Cycle Problems: u what if we had a more complicated instruction like floating point? u wasteful of area: NO Sharing of Hardware resources n One Solution: u use a “smaller” cycle time u have different instructions take different numbers of cycles u a “multicycle” datapath: IR MDR

TUE Dig.Sys.Arch29 n We will be reusing functional units u ALU used to compute address and to increment PC u Memory used for instruction and data n Add registers after every major functional unit n Our control signals will not be determined solely by instruction u e.g., what should the ALU do for a “subtract” instruction? n We’ll use a finite state machine (FSM) or microcode for control Multicycle Approach

TUE Dig.Sys.Arch30 n Finite state machines: u a set of states and u next state function (determined by current state and the input) u output function (determined by current state and possibly input) u We’ll use a Moore machine (output based only on current state) Review: finite state machines Next-state function Current state Clock Output function Next state Outputs Inputs

TUE Dig.Sys.Arch31 Review: finite state machines Example: B. 21 A friend would like you to build an “electronic eye” for use as a fake security device. The device consists of three lights lined up in a row, controlled by the outputs Left, Middle, and Right, which, if asserted, indicate that a light should be on. Only one light is on at a time, and the light “moves” from left to right and then from right to left, thus scaring away thieves who believe that the device is monitoring their activity. Draw the graphical representation for the finite state machine used to specify the electronic eye. Note that the rate of the eye’s movement will be controlled by the clock speed (which should not be too great) and that there are essentially no inputs.

TUE Dig.Sys.Arch32 n Break up the instructions into steps, each step takes a cycle u balance the amount of work to be done u restrict each cycle to use only one major functional unit n At the end of a cycle u store values for use in later cycles (easiest thing to do) u introduce additional “internal” registers n Notice: we distinguish u processor state: programmer visible registers u internal state: programmer invisible registers (like IR, MDR, A, B, and ALUout) Multicycle Approach

TUE Dig.Sys.Arch33 Multicycle Approach Shift left 2 PC Memory MemData Write data M u x 0 1 Registers Write register Write data Read data 1 Read data 2 Read register 1 Read register 2 M u x 0 1 M u x Instruction [15–0] Sign extend 3216 Instruction [25–21] Instruction [20–16] Instruction [15–0] Instruction register 1 M u x M u x ALU result ALU Zero Memory data register Instruction [15–11] A B ALUOut 0 1 Address

TUE Dig.Sys.Arch34 Multicycle Approach n Note that previous picture does not include: u branch support u jump support u Control lines and logic n For complete picture see fig 5.33 page 383 n Tclock > max (ALU delay, Memory access, Regfile access)

TUE Dig.Sys.Arch35 n Instruction Fetch n Instruction Decode and Register Fetch n Execution, Memory Address Computation, or Branch Completion n Memory Access or R-type instruction completion n Write-back step Five Execution Steps INSTRUCTIONS TAKE FROM CYCLES!

TUE Dig.Sys.Arch36 n Use PC to get instruction and put it in the Instruction Register n Increment the PC by 4 and put the result back in the PC Can be described succinctly using RTL "Register-Transfer Language" IR = Memory[PC]; PC = PC + 4; Can we figure out the values of the control signals? What is the advantage of updating the PC now? Step 1: Instruction Fetch

TUE Dig.Sys.Arch37 n Read registers rs and rt in case we need them n Compute the branch address in case the instruction is a branch n Previous two actions are done optimistically!! RTL: A = Reg[IR[25-21]]; B = Reg[IR[20-16]]; ALUOut = PC+(sign-extend(IR[15-0])<< 2); n We aren't setting any control lines based on the instruction type (we are busy "decoding" it in our control logic) Step 2: Instruction Decode and Register Fetch

TUE Dig.Sys.Arch38 n ALU is performing one of four functions, based on instruction type Memory Reference: ALUOut = A + sign-extend(IR[15-0]); R-type: ALUOut = A op B; Branch: if (A==B) PC = ALUOut; n Jump: PC = PC[31-28] || (IR[25-0]<<2) Step 3 (instruction dependent)

TUE Dig.Sys.Arch39 Loads and stores access memory MDR = Memory[ALUOut]; or Memory[ALUOut] = B; R-type instructions finish Reg[IR[15-11]] = ALUOut; The write actually takes place at the end of the cycle on the edge Step 4 (R-type or memory-access)

TUE Dig.Sys.Arch40 Memory read completion step Reg[IR[20-16]]= MDR; What about all the other instructions? Write-back step

TUE Dig.Sys.Arch41 Steps taken to execute any instruction class Summary execution steps

TUE Dig.Sys.Arch42 How many cycles will it take to execute this code? lw $t2, 0($t3) lw $t3, 4($t3) beq $t2, $t3, L1 #assume not taken add $t5, $t2, $t3 sw $t5, 8($t3) L1:... n What is going on during the 8th cycle of execution? In what cycle does the actual addition of $t2 and $t3 takes place? Simple Questions

TUE Dig.Sys.Arch43 n Value of control signals is dependent upon: u what instruction is being executed u which step is being performed n Use the information we have accumulated to specify a finite state machine (FSM) u specify the finite state machine graphically, or u use microprogramming n Implementation can be derived from specification Implementing the Control

TUE Dig.Sys.Arch44 FSM: high level view Start/reset Instruction fetch, decode and register fetch Memory access instructions R-type instructions Branch instruction Jump instruction

n How many state bits will we need? Graphical Specification of FSM PCWrite PCSource = 10 ALUSrcA = 1 ALUSrcB = 00 ALUOp = 01 PCWriteCond PCSource = 01 ALUSrcA =1 ALUSrcB = 00 ALUOp= 10 RegDst = 1 RegWrite MemtoReg = 0 MemWrite IorD = 1 MemRead IorD = 1 ALUSrcA = 1 ALUSrcB = 10 ALUOp = 00 RegDst=0 RegWrite MemtoReg=1 ALUSrcA = 0 ALUSrcB = 11 ALUOp = 00 MemRead ALUSrcA = 0 IorD = 0 IRWrite ALUSrcB = 01 ALUOp = 00 PCWrite PCSource = 00 Instruction fetch Instruction decode/ register fetch Jump completion Branch completionExecution Memory address computation Memory access Memory access R-type completion Write-back step ( O p = ' L W ' ) o r ( O p = ' S W ' ) ( O p = R - t y p e ) ( O p = ' B E Q ' ) ( O p = ' J ' ) ( O p = ' S W ' ) ( O p = ' L W ' ) Start

TUE Dig.Sys.Arch46 Implementation: Finite State Machine for Control

TUE Dig.Sys.Arch47 PLA Implemen- tation n If I picked a horizontal or vertical line could you explain it ? n What type of FSM is used? (see fig C.14) next state current state datapath control opcode

TUE Dig.Sys.Arch48 n ROM = "Read Only Memory" u values of memory locations are fixed ahead of time n A ROM can be used to implement a truth table u if the address is m-bits, we can address 2 m entries in the ROM u our outputs are the bits of data that the address points to ROM Implementation m is the "heigth", and n is the "width" m bits n bits ROM addressdata

TUE Dig.Sys.Arch49 n How many inputs are there? 6 bits for opcode, 4 bits for state = 10 address lines (i.e., 2 10 = 1024 different addresses) n How many outputs are there? 16 datapath-control outputs, 4 state bits = 20 outputs n ROM is 2 10 x 20 = 20K bits (very large and a rather unusual size) n Rather wasteful, since for lots of the entries, the outputs are the same — i.e., opcode is often ignored ROM Implementation

TUE Dig.Sys.Arch50 ROM Implementation Cheaper implementation: n Exploit the fact that the FSM is a Moore machine ==> u Control outputs only depend on current state and not on other incoming control signals ! u Next state depends on all inputs n Break up the table into two parts — 4 state bits tell you the 16 outputs, 2 4 x 16 bits of ROM — 10 bits tell you the 4 next state bits, 2 10 x 4 bits of ROM — Total number of bits: 4.3K bits of ROM

TUE Dig.Sys.Arch51 n PLA is much smaller u can share product terms (ROM has an entry (=address) for every product term u only need entries that produce an active output u can take into account don't cares Size of PLA: (#inputs  #product-terms) + (#outputs  #product-terms) u For this example: (10x17)+(20x17) = 460 PLA cells n PLA cells usually slightly bigger than the size of a ROM cell ROM vs PLA

TUE Dig.Sys.Arch52 Another Implementation Style n Real machines have many instructions => complex FSM with many states u Graphical specification becomes cumbersome n Specify control as an instruction u microinstructions u built out of separate fields (for controlling ALU, SRC1, SCR2, etc) n Exploit the fact that usually the next state is the next microinstruction (just like in a sequential programming language) u default sequencing u use micro program counter (indicating next state = next instr.)

TUE Dig.Sys.Arch53 n Complex instructions: the "next state" is often current state + 1 Another Implementation Style

TUE Dig.Sys.Arch54 Micro- programming What are the “microinstructions” ?

TUE Dig.Sys.Arch55 Microinstruction format n Each microinstruction contains 7 fields

Microinstruction format

TUE Dig.Sys.Arch57 n A specification methodology u appropriate if hundreds of opcodes, modes, cycles, etc. u signals specified symbolically using microinstructions Microprogramming

TUE Dig.Sys.Arch58 Details

TUE Dig.Sys.Arch59 Details

TUE Dig.Sys.Arch60 Microprogramming n Will two implementations of the same architecture have the same microcode? n What would a microassembler do?

TUE Dig.Sys.Arch61 n No encoding (also called horizontal encoding, or 1-hot encoding): u 1 bit for each datapath operation u faster, requires more memory (logic) u used for Vax 780 — an astonishing 400K of memory! n Lots of encoding (also called vertical encoding): u send the microinstructions through logic to get control signals u uses less memory, slower n Historical context of CISC: u Too much logic to put on a single chip with everything else u Use a ROM (or even RAM) to hold the microcode u It’s easy to add new instructions Maximally vs. Minimally Encoded

TUE Dig.Sys.Arch62 Microcode: Trade-offs n Distinction between specification and implementation is sometimes blurred n Specification Advantages: u Easy to design and write u Design architecture and microcode in parallel n Implementation (off-chip ROM) Advantages u Easy to change since values are in memory u Can emulate other architectures u Can make use of internal registers n Implementation Disadvantages, SLOWER now that: u Control is implemented on same chip as processor u ROM is no longer faster than RAM u No need to go back and make changes

TUE Dig.Sys.Arch63 Exceptions n Unexpected events n External: interrupt u e.g. I/O request n Internal: exception u e.g. Overflow, Undefined instruction opcode, Software trap, Page fault n How to handle exception? u Jump to general entry point (record exception type in status register) u Jump to vectored entry point u Address of faulting instruction has to be recorded !

TUE Dig.Sys.Arch64 Exceptions Changes needed: see fig / 5.49 / 5.50 n Extend PC input mux with extra entry with fixed address: “C000000hex” n Add EPC register containing old PC (we’ll use the ALU to decrement PC with 4) u extra input ALU src2 needed with fixed value 4 n Cause register (one bit in our case) containing: u 0: undefined instruction u 1: ALU overflow n Add 2 states to FSM u undefined instr. state #10 u overflow state #11

TUE Dig.Sys.Arch65 Exceptions 2 New states: Legend: IntCause =0/1type of exception CauseWritewrite Cause register ALUSrcA = 0select PC ALUSrcB = 01select constant 4 ALUOp = 01subtract operation EPCWritewrite EPC register with current PC PCWritewrite PC with exception address PCSource =11select exception address: C000000hex Legend: IntCause =0/1type of exception CauseWritewrite Cause register ALUSrcA = 0select PC ALUSrcB = 01select constant 4 ALUOp = 01subtract operation EPCWritewrite EPC register with current PC PCWritewrite PC with exception address PCSource =11select exception address: C000000hex IntCause =0 CauseWrite ALUSrcA = 0 ALUSrcB = 01 ALUOp = 01 EPCWrite PCWrite PCSource =11 IntCause =1 CauseWrite ALUSrcA = 0 ALUSrcB = 01 ALUOp = 01 EPCWrite PCWrite PCSource =11 #10 undefined instruction#11 overflow To state 0 (begin of next instruction)

TUE Dig.Sys.Arch66 Pentium Pro / II / III n Use multicycle data path for 80x86 instructions n Combine hardwired (FSM) control for simple instructions with microcoded control for complex instructions (since 80486) n Pentium Pro: u internal RISC engine executing micro-operations (of 72 bit) u multiple FUs u up to four 80x86 instructions issued per cycle and translated into micro-operations (by set of PLAs generating 1200 different micro-operations) u complex 80x86 instructions are handled by micro-code (8000 micro-instructions) u four micro-operations issued per cycle (4x72 bits expand into 120 Int and 285 FP control lines)

TUE Dig.Sys.Arch67 The Big Picture Initial representation Finite state diagram Microprogram Sequencing control Explicit next state function Microprogram counter + dispatch ROMS Logic representation Logic equations Truth tables Implementation technique Programmable logic array Read only memory

TUE Dig.Sys.Arch68 Exercises From Chapter five: n 5.1, 5.3 n 5.5, 5.6 n 5.9 n 5.12