Computer Organization Ellen Walker Hiram College

Slides:



Advertisements
Similar presentations
Another Implementation Style
Advertisements

Microprocessor Design Multi-cycle Datapath Nia S. Bradley Vijay.
Chapter 5 The Processor: Datapath and Control Basic MIPS Architecture Homework 2 due October 28 th. Project Designs due October 28 th. Project Reports.
Week 11Spring :332:331 Computer Architecture and Assembly Language Spring 2006 Week 11: Microprogramming [Adapted from Dave Patterson’s UCB CS152.
CS 161Computer Architecture Chapter 5 Lecture 12
©UCB CS 161Computer Architecture Chapter 5 Lecture 11 Instructor: L.N. Bhuyan Adapted from notes by Dave Patterson (http.cs.berkeley.edu/~patterson)
Preparation for Midterm Binary Data Storage (integer, char, float pt) and Operations, Logic, Flip Flops, Switch Debouncing, Timing, Synchronous / Asynchronous.
ENEE350 Ankur Srivastava University of Maryland, College Park Based on Slides from Mary Jane Irwin ( )
Prof. John Nestor ECE Department Lafayette College Easton, Pennsylvania ECE Computer Organization Multi-Cycle Processor.
331 W10.1Spring :332:331 Computer Architecture and Assembly Language Spring 2005 Week 10 Building a Multi-Cycle Datapath [Adapted from Dave Patterson’s.
Class 9.1 Computer Architecture - HUJI Computer Architecture Class 9 Microprogramming.
Dr. Iyad F. Jafar Basic MIPS Architecture: Multi-Cycle Datapath and Control.
Datapath and Control: MultiCycle Implementation. Performance of Single Cycle Machines °Assume following operation times: Memory units : 200 ps ALU and.
1 Computer Organization & Design Microcode for Control Sec. 5.7 (CDROM) Appendix C (CDROM) / / pdf / lec_3a_notes.pdf.
CPE232 Basic MIPS Architecture1 Computer Organization Multi-cycle Approach Dr. Iyad Jafar Adapted from Dr. Gheith Abandah slides
Exam 2 Review Two’s Complement Arithmetic Ripple carry ALU logic and performance Look-ahead techniques Basic multiplication and division ( non- restoring)
C HAPTER 5 T HE PROCESSOR : D ATAPATH AND C ONTROL M ULTICYCLE D ESIGN.
1 Processor: Datapath and Control Single cycle processor –Datapath and Control Multicycle processor –Datapath and Control Microprogramming –Vertical and.
Multicycle Implementation
LECTURE 6 Multi-Cycle Datapath and Control. SINGLE-CYCLE IMPLEMENTATION As we’ve seen, single-cycle implementation, although easy to implement, could.
ECE-C355 Computer Structures Winter 2008 The MIPS Datapath Slides have been adapted from Prof. Mary Jane Irwin ( )
Datapath and Control AddressInstruction Memory Write Data Reg Addr Register File ALU Data Memory Address Write Data Read Data PC Read Data Read Data.
Datapath and Control AddressInstruction Memory Write Data Reg Addr Register File ALU Data Memory Address Write Data Read Data PC Read Data Read Data.
RegDst 1: RegFile destination No. for the WR Reg. comes from rd field. 0: RegFile destination No. for the WR Reg. comes from rt field.
CDA 3101 Spring 2016 Introduction to Computer Organization Microprogramming and Exceptions 08 March 2016.
Chapter 4 From: Dr. Iyad F. Jafar Basic MIPS Architecture: Multi-Cycle Datapath and Control.
Computer Architecture Lecture 6.  Our implementation of the MIPS is simplified memory-reference instructions: lw, sw arithmetic-logical instructions:
Design a MIPS Processor (II)
EE204 Computer Architecture
Multi-Cycle Datapath and Control
Chapter 5: A Multi-Cycle CPU.
CS161 – Design and Architecture of Computer Systems
IT 251 Computer Organization and Architecture
/ Computer Architecture and Design
ECE/CS 552: Multicycle Data Path
Systems Architecture I
Multi-Cycle CPU.
Computer Organization & Design Microcode for Control Sec. 5
Extensions to the Multicycle CPU
Single Cycle Processor
D.4 Finite State Diagram for the Multi-cycle processor
Multi-Cycle CPU.
CS/COE0447 Computer Organization & Assembly Language
CS/COE0447 Computer Organization & Assembly Language
Processor: Finite State Machine & Microprogramming
Single-Cycle CPU DataPath.
Chapter Five The Processor: Datapath and Control
The Multicycle Implementation
CS/COE0447 Computer Organization & Assembly Language
Vishwani D. Agrawal James J. Danaher Professor
Processor: Datapath and Control (part 2)
Chapter Five The Processor: Datapath and Control
Drawbacks of single cycle implementation
CSE 331 Computer Organization and Design Fall 2007 Week 12
The Multicycle Implementation
Systems Architecture I
Vishwani D. Agrawal James J. Danaher Professor
COSC 2021: Computer Organization Instructor: Dr. Amir Asif
COSC 2021: Computer Organization Instructor: Dr. Amir Asif
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
Control Unit for Multiple Cycle Implementation
5.5 A Multicycle Implementation
Systems Architecture I
Control Unit for Multiple Cycle Implementation
FloorPlan for Multicycle MIPS
Alternative datapath (book): Multiple Cycle Datapath
The Processor: Datapath & Control.
CS/COE0447 Computer Organization & Assembly Language
Presentation transcript:

Computer Organization Ellen Walker Hiram College Microprogramming Computer Organization Ellen Walker Hiram College Figures from Computer Organization and Design 3ed, D.A. Patterson & J.L. Hennessey, Morgan Kauffman © 2005 unless otherwise specified

Defining Hardware as Program Microinstruction Wide instruction containing 1 bit for each control bit (later we might relax) Executing a microinstruction asserts the specified state bits Instruction address = state Increment vs. branch (via AddrCtl) Instruction ROM = control ROM Idea: we know about programming already, let’s use what we know to organize seriously complex information!

Ideas from Programming Symbolic instructions translated to “machine code” Subroutines Complex instructions sets often have shared sub-instructions Example: decoding registers or addresses

Choosing an Implementation Our Example CPU About 10 instructions, 3-5 cycles Hand-coded state machine & logic MIPS-32 About 100 instructions, 2-20 cycles Use hardware description language, machine-synthesized state machine IA-32 (Intel Architecture) Several hundred instructions, widely varying Hundreds of states in machine Microprogramming is needed

Control Unit As Microcode Microcode memory = control path and AddrCS logic Adder (increments like regular computer) Micro-pc is actually the state number (“states” vs. “instructions”)

Microinstruction Format Instruction divided into fields Each field controls a non-overlapping set of signals Signals that are never asserted simultaneously can share the same field E.g. memory read/write

Microinstruction Fields ALU Control (operation) SRC1 and SRC 2 (for ALU) Register Control Read/write and source for write Memory Read or write and source or destination register PCWrite Does the PC change? (fetch or branch) Sequencing

Sequencing Seq label Dispatch i increment microinstruction counter Jump directly to a label in the microprogram Dispatch i Use a dispatch table in ROM Lookup next microinstruction based on opcode bits from the IR (MIPS instruction)

Microinstruction Summary Use of symbols - we can write microinstructions without knowing (e.g.) which order the multiplexor inputs are in Also symbolic addresses like assembler Label field: generic label like fetch, or label that will be in dispatch ROM (ends in 1 or 2) ALU control: add, subtract, or use funct code Note “compressed options” for memory, pcwrite, register control -- e.g. don’t have to specify memory src or dest data since it’s always the register file (field 2)

Contents of Dispatch ROMS Each ROM contains a list of labels, ending in the ROM number ROM 1: Mem1 RFormat1 BEQ1 Jump1 ROM 2: LW2 SW2

Microprogram for “Fetch” label ALU ctrl Src1 Src2 Reg ctrl Mem PC write Seq Fetch add PC 4 read PC ALU seq ext shft read disp.1 First instruction (PC<-PC+4, IR<-mem[PC]) Extshft = imm16, sign-extended and left-shifted by 2 Second instruction (A<- reg[a], B<-reg[b], ALUOut<-PC+shift-ext-imm16) Reg. read = set values of A and B registers from register file Corresponds to states 0 and 1

Microprogram for Memory label ALU ctrl Src1 Src2 Reg ctrl Mem PC write Seq Mem1 add A ext disp. 2 Lw2 read ALU writeMDR Fetch Sw2 write ALU Mem1: Add register to imm16 (extended but not shifted), save to ALUOut Lw2: MDR <- mem[ALUOut] ; reg[b]<- MDR Sw2: mem[ALUOut] <- reg[b]

Microprogram for R-Format label ALU ctrl Src1 Src2 Reg ctrl Mem PC write Seq Rfor-mat1 func code A B seq write ALU Fetch Although no overlapping fields are used, if we combined these, we’d need a longer cycle time and not to write to/from ALUOut

Microprogram for BEQ & Jump label ALU ctrl Src1 Src2 Reg ctrl Mem PC write Seq BEQ1 ALUOut cond fetch Jump1 Jump addr BEQ1: PC<- ALUOut Jump1: PC <- JumpAddr (PC[32-29]:IR[23:0]:00)

Comments on Microprogram One microinstruction per state But, for complex machines, microprogramming is easier Symbolic labels and field codes Software combines compatible microinstructions into the same state when possible Abstraction: consider one instruction (group) at a time Essentially software determination and minimization of the state machine with a much more understandable interface to the human designer / programmer Complex machines have more complex datapaths, extra temporary registers, the equivalent of variables to be set. Microprogramming makes this easier for people.

Microcode vs. Assembler Language Wider instructions (more fields) Only one instruction format, no opcode Explicit sequencing field instead of separate branch instructions Unused fields more likely in microcode Goal: make microcode closer to hardware, don’t “encode” as much - wasted bits are worth it…

Translating to Hardware Specify how each field translates to control signals Implement microcode as Finite State Machine or with explicit sequencer FSM: 1 state per microcode instruction; truth tables for next state function Sequencer: choose between increment, direct jump, or dispatch table

ALU Signals SRC2 ALU control SRC1 B: ALUSrcB = 00 Add: ALUOp=00 Extend: ALUSrcB=10 ExtShift: ALUSrcB=11 ALU control Add: ALUOp=00 Subt: ALUOp=01 Func: ALUOp=10 SRC1 PC: ALUSrcA=0 A: ALUSrcA=1 ALU control (2 bits) = connect directly to ALUOp SRC1 (1 bit) = connect directly to ALUSrcA (PC=0, A=1)’ SRC2 (2 bits) = connect directly to ALUSrcB

Register Signals Read: Write ALU: Write MDR: RegWrite=0 RegWrite=1, RegDst=0, MemtoReg=1 Write MDR: RegWrite=1, RegDst=1, MemtoReg=0 A and B are written from the register file in every cycle. No explicit control signals are needed Register control (2 bits): 1 bit connected to RegWrite, the other connected to RegDst and inverted to MemtoReg Read = 0x, WriteALU = 10, WriteMDR = 11

Memory Signals Memory Control Read PC: MemRead=1, MemWrite=0, IorD=0, IRWrite=1 Read ALU: MemRead=1, MemWrite=0, IorD=1, IRWrite=0 Write ALU: MemRead=0, MemWrite=1, IorD=1, IRWrite=0 2 bits: one connected to memread and negative connected to memwrite The other bit connected to IorD and negative connected to IRWrite ReadPC = 10, ReadALU = 11, WriteALU = 01 Unused: MemRead=X, MemWrite=0, IorD=X, IRWrite=0 encode as 00 - needs more logic to prevent MemWrite

PC Write Control Signal ALU PCSource = 00 PCWrite = 1, PCWriteCond=0 ALUOutCond PCSource = 01 PCWrite = 0, PCWriteCond=1 Jump Addr PCSource = 10 Unused: PCWrite=0, PCWriteCond=0, PCSource=xx Encoding: 11 = ALU, 10=PCSource, 01=JumpAddr, 00= unused Low bit -> PCWrite, “01”->PCWriteCond, negate both bits -> PCSource

Sequencing Signals Seq: AddrCtl = 11 Fetch: AddrCtl = 00 Disp1: AddrCtl = 01 Disp2: AddrCtl = 10 Direct connect bits to AddrCtl, encoded as shown

Blank Fields When a field is blank, no changes should be made All signals affecting units with state (e.g. RegWrite, MemRead, MemWrite) should be off for blank fields Signals controlling other units, e.g. multiplexor select signals can be don’t cares

Blank Field Signals Register Control is blank Memory Control is blank RegWrite, RegDst=X, MemtoReg=X Memory Control is blank MemRead=0, MemWrite=0, IorD=X, IRWrite=0 PCWriteControl is blank PCSource=XX, PCWrite=0, PCWriteCond=0

Building Dispatch Tables Determine addresses of labels in MicroInstruction Insert ROM Contents Contents at address corresponding to opcode become address of appropriate label

Freedoms for “Assembler” Locations of microinstructions Except for sequential ones Encodings of field values Choose encodings that make logic easier (easiest = #signals) Choose encodings that make microcontroller smaller (smallest = log #signals) Narrow but Long vs. Wide but Short Go back and consider tighter encodings

Control Implementation: Microcode ROM vs. PLA ROM microcontroller easy to modify BUT now, generally incorporated on same die as datapath hardware Microcode “assembler” generates hardware from “program” BUT CAD tools generate PLA from HDL “program” ROM microcontrollers were fast BUT new RAM is as fast as ROM, and PLA might be smaller (faster) Microprogramming invented by wilkes in 1956 For those times, it was a great breakthrough and obvious choice; but now, it’s not as necessary, mostly because we have tools that can do the tedious work that microprogramming avoids, also everything has gotten smaller, faster and more integrated.