CS152 / Kubiatowicz Lec10.1 10/03/01©UCB Fall 2001 CS 152 Computer Architecture and Engineering Lecture 10 Multicycle Controller Design (Continued) October.

Slides:



Advertisements
Similar presentations
EEM 486 EEM 486: Computer Architecture Lecture 4 Designing a Multicycle Processor.
Advertisements

ELEN 350 Multi-Cycle Datapath Adapted from the lecture notes of John Kubiatowicz (UCB) and Hank Walker (TAMU)
361 multicontroller.1 ECE 361 Computer Architecture Lecture 11: Designing a Multiple Cycle Controller.
CS 152 Computer Architecture and Engineering Lecture 9 Multiprogramming and Exceptions February 25, 2004 John Kubiatowicz (
CS152 / Kubiatowicz Lec11.1 3/8/99©UCB Spring 1999 CS 152 Computer Architecture and Engineering Lecture 11 Multicycle Controller Design Mar 8, 1999 John.
EECC550 - Shaaban #1 Lec # 5 Winter Major CPU Design Steps 1. Analyze instruction set operations using independent RTN ISA => RTN => datapath.
CS61C L26 Single Cycle CPU Datapath II (1) Garcia © UCB Lecturer PSOE Dan Garcia inst.eecs.berkeley.edu/~cs61c CS61C : Machine.
CS152 / Kubiatowicz Lec10.1 3/1/99©UCB Spring 1999 CS 152 Computer Architecture and Engineering Lecture 10 Multicycle Controller Design (Continued) Mar.
CS152 / Kubiatowicz Lec11.1 3/05/03©UCB Spring 2003 CS 152 Computer Architecture and Engineering Lecture 11 Multicycle Controller Design March 5, 2003.
CS152 / Kubiatowicz Lec10.1 3/1/99©UCB Spring 1999 Alternative datapath (book): Multiple Cycle Datapath °Miminizes Hardware: 1 memory, 1 adder Ideal Memory.
EECC550 - Shaaban #1 Lec # 5 Winter CPU Design Steps 1. Analyze instruction set operations using independent ISA => RTN => datapath requirements.
Savio Chau Single Cycle Controller Design Last Time: Discussed the Designing of a Single Cycle Datapath Control Datapath Memory Processor (CPU) Input Output.
EECC550 - Shaaban #1 Lec # 5 Winter CPU Design Steps 1. Analyze instruction set operations using independent RTN => datapath requirements.
EECC550 - Shaaban #1 Lec # 5 Winter CPU Design Steps 1. Analyze instruction set operations using independent RTN => datapath requirements.
Adapted from the lecture notes of John Kubiatowicz (UCB)
ECE 232 L15.Miulticycle.1 Adapted from Patterson 97 ©UCBCopyright 1998 Morgan Kaufmann Publishers ECE 232 Hardware Organization and Design Lecture 15 Multi-cycle.
Microprocessor Design
CS152 / Kubiatowicz Lec9.1 2/26/03©UCB Spring 2003 CS 152 Computer Architecture and Engineering Lecture 9 Designing a Multicycle Processor February 26,
Preparation for Midterm Binary Data Storage (integer, char, float pt) and Operations, Logic, Flip Flops, Switch Debouncing, Timing, Synchronous / Asynchronous.
ECE 232 L13. Control.1 ©UCB, DAP’ 97 ECE 232 Hardware Organization and Design Lecture 13 Control Design
ECE 232 L16.Microprog.1 Adapted from Patterson 97 ©UCBCopyright 1998 Morgan Kaufmann Publishers ECE 232 Hardware Organization and Design Lecture 16 Microprogrammed.
Ceg3420 L11.1 RWB Fall 98,  U.CB CEG3420 Computer Design Lecture 11: Multicycle Controller Design.
CS152 / Kubiatowicz Lec /04/99©UCB Fall 1999 CS 152 Computer Architecture and Engineering Lecture 11 Multicycle Controller Design October 4, 1999.
CS 61C L17 Control (1) A Carle, Summer 2006 © UCB inst.eecs.berkeley.edu/~cs61c/su06 CS61C : Machine Structures Lecture #17: CPU Design II – Control
CS152 Lec11.1 CS 152 Computer Architecture and Engineering Lecture 11 Multicycle Controller Design (Continued)
CS61C L26 CPU Design : Designing a Single-Cycle CPU II (1) Garcia, Fall 2006 © UCB Lecturer SOE Dan Garcia inst.eecs.berkeley.edu/~cs61c.
CS 61C L16 Datapath (1) A Carle, Summer 2004 © UCB inst.eecs.berkeley.edu/~cs61c/su05 CS61C : Machine Structures Lecture #16 – Datapath Andy.
361 control Computer Architecture Lecture 9: Designing Single Cycle Control.
EE30332 Ch5 Ext - DP.1 Ch 5 The Processor: Datapath and Control  The state digrams that arise define the controller for an instruction set processor are.
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,
CS152 / Kubiatowicz Lec /05/01©UCB Fall 2001 CS 152 Computer Architecture and Engineering Lecture 11 Multicycle Controller Design October 5, 2001.
EECC550 - Shaaban #1 Lec # 6 Spring Control may be designed using one of several initial representations. The choice of sequence control,
EECC550 - Shaaban #1 Lec # 5 Spring CPU Design Steps 1. Analyze instruction set operations using independent RTN => datapath requirements.
CPSC 321 Computer Architecture and Engineering Lecture 8 Designing a Multicycle Processor Instructor: Rabi Mahapatra & Hank Walker Adapted from the lecture.
Major CPU Design Steps 1. Analyze instruction set operations using independent RTN ISA => RTN => datapath requirements. This provides the the required.
EECC550 - Shaaban #1 Lec # 5 Spring CPU Design Steps 1. Analyze instruction set operations using independent RTN => datapath requirements.
Dr. Iyad F. Jafar Basic MIPS Architecture: Multi-Cycle Datapath and Control.
CASE STUDY OF A MULTYCYCLE DATAPATH. Alternative Multiple Cycle Datapath (In Textbook) Minimizes Hardware: 1 memory, 1 ALU Ideal Memory Din Address 32.
CPE 442 µprog..1 Intro. To Computer Architecture CpE 442 Microprogramming and Exceptions.
CS/EE 362 multicontroller..1 ©DAP & SIK 1995 CS/EE 362 Hardware Fundamentals Lecture 15: Designing a Multi-Cycle Controller (Chapter 5: Hennessy and Patterson)
ECS154B Computer Architecture Multicycle Controller Design
CS 152 L09 Multicycle (1)Patterson Fall 2003 © UCB CS152 – Computer Architecture and Engineering Lecture 9 – Multicycle Design Dave Patterson.
EEM 486: Computer Architecture Designing a Single Cycle Datapath.
Overview of Control Hardware Development
CMCS Computer Architecture Lecture 16 Micro-programming & Exceptions April 2, CMSC411.htm Mohamed Younis.
EEM 486: Computer Architecture Lecture 3 Designing Single Cycle Control.
CS 61C: Great Ideas in Computer Architecture (Machine Structures) Single-Cycle CPU Datapath & Control Part 2 Instructors: Krste Asanovic & Vladimir Stojanovic.
Single Cycle Controller Design
Chapter 4 From: Dr. Iyad F. Jafar Basic MIPS Architecture: Multi-Cycle Datapath and Control.
Design a MIPS Processor (II)
Problem with Single Cycle Processor Design
CS161 – Design and Architecture of Computer Systems
CpE 442 Designing a Multiple Cycle Controller
IT 251 Computer Organization and Architecture
Designing a Multicycle Processor
Designing a Multicycle Processor
CS/COE0447 Computer Organization & Assembly Language
CS 704 Advanced Computer Architecture
CS 704 Advanced Computer Architecture
The Multicycle Implementation
John Lazzaro ( CS152 – Computer Architecture and Engineering Lecture 8 – Multicycle Design and Microcode John.
The Multicycle Implementation
CS152 Computer Architecture and Engineering Lecture 8 Designing a Single Cycle Datapath Start: X:40.
Multi-Cycle Datapath Lecture notes from MKP, H. H. Lee and S. Yalamanchili.
Instructors: Randy H. Katz David A. Patterson
CpE 442 Designing a Multiple Cycle Controller
Alternative datapath (book): Multiple Cycle Datapath
What You Will Learn In Next Few Sets of Lectures
CS161 – Design and Architecture of Computer Systems
Presentation transcript:

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 CS 152 Computer Architecture and Engineering Lecture 10 Multicycle Controller Design (Continued) October 3, 2001 John Kubiatowicz (http.cs.berkeley.edu/~kubitron) lecture slides:

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Partitioning the CPI=1 Datapath °Add registers between smallest steps °Place enables on all registers PC Next PC Operand Fetch Exec Reg. File Mem Access Data Mem Instruction Fetch Result Store ALUctr RegDst ALUSrc ExtOp MemWr nPC_sel RegWr MemWr MemRd Equal

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Recap: Example Multicycle Datapath °Critical Path ? PC Next PC Operand Fetch Instruction Fetch nPC_sel IR Reg File Ext ALU Reg. File Mem Acces s Data Mem Result Store RegDst RegWr MemWr MemRd S M MemToReg Equal ALUctr ALUSrc ExtOp A B E

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Recap: FSM specification IR <= MEM[PC] R-type A <= R[rs] B <= R[rt] S <= A fun B R[rd] <= S PC <= PC + 4 S <= A or ZX R[rt] <= S PC <= PC + 4 ORi S <= A + SX R[rt] <= M PC <= PC + 4 M <= MEM[S] LW S <= A + SX MEM[S] <= B PC <= PC + 4 BEQ PC <= Next(PC) SW “instruction fetch” “decode” Execute Memory Write-back

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Sequencer-based control unit: Statemachine ++ Opcode State Reg Inputs Outputs Control Logic Multicycle Datapath Types of “branching” Set state to 0 Dispatch (state 1) Use incremented state number 1 Adder Address Select Logic

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Recap: Micro-controller Design °The state digrams that arise define the controller for an instruction set processor are highly structured °Use this structure to construct a simple “microsequencer” Each state in previous diagram becomes a “microinstruction” Microinstructions often taken sequentially °Control reduces to programming this device sequencer control datapath control micro-PC sequencer microinstruction (  )

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Recap: Specific Sequencer from last lecture °Sequencer-based control unit from last lecture Called “microPC” or “µPC” vs. state register Control ValueEffect 00 Next µaddress = 0 01 Next µaddress = dispatch ROM 10 Next µaddress = µaddress + 1 ROM: Opcode microPC 1 µAddress Select Logic Adder ROM Mux R-type BEQ ori LW SW

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Recap: Microprogram Control Specification 0000?inc load 00011inc 0010xzero xzero xinc0 1 fun xzero xinc0 0 or xzero xinc1 0 add xinc xzero xinc1 0 add xzero µPC TakenNext IRPCOpsExecMemWrite-Back en selA B Ex Sr ALU S R W MM-R Wr Dst R: ORi: LW: SW: BEQ

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Recap: Overview of Control °Control may be designed using one of several initial representations. The choice of sequence control, and how logic is represented, can then be determined independently; the control can then be implemented with one of several methods using a structured logic technique. Initial Representation Finite State Diagram Microprogram Sequencing ControlExplicit Next State Microprogram counter Function + Dispatch ROMs Logic RepresentationLogic EquationsTruth Tables Implementation PLAROM Technique “hardwired control”“microprogrammed control”

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 The Big Picture: Where are We Now? °The Five Classic Components of a Computer °Today’s Topics: Microprogramed control Administrivia Microprogram it yourself Exceptions Control Datapath Memory Processor Input Output

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Microprogramming (Maurice Wilkes) °Control is the hard part of processor design ° Datapath is fairly regular and well-organized ° Memory is highly regular ° Control is irregular and global Microprogramming: -- A Particular Strategy for Implementing the Control Unit of a processor by "programming" at the level of register transfer operations Microarchitecture: -- Logical structure and functional capabilities of the hardware as seen by the microprogrammer Historical Note: IBM 360 Series first to distinguish between architecture & organization Same instruction set across wide range of implementations, each with different cost/performance

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 “Macroinstruction” Interpretation Main Memory execution unit control memory CPU ADD SUB AND DATA User program plus Data this can change! AND microsequence e.g., Fetch Calc Operand Addr Fetch Operand(s) Calculate Save Answer(s) one of these is mapped into one of these

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Variations on Microprogramming ° “Horizontal” Microcode – control field for each control point in the machine ° “Vertical” Microcode – compact microinstruction format for each class of microoperation – local decode to generate all control points (remember ALU?) branch:µseq-opµadd execute:ALU-opA,B,R memory:mem-opS, D µseq µaddr A-mux B-mux bus enables register enables Horizontal Vertical

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Extreme Horizontal input select N3N2 N1N Incr PC ALU control 1 bit for each loadable register enbMAR enbAC... Depending on bus organization, many potential control combinations simply wrong, i.e., implies transfers that can never happen at the same time. Makes sense to encode fields to save ROM space Example: mem_to_reg and ALU_to_reg should never happen simultaneously; => encode in single bit which is decoded rather than two separate bits NOTE: the encoding should be only wide enough so that parallel actions that the datapath supports should still be specifiable in a single microinstruction

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 More Vertical Format src dst DECDEC DECDEC other control fields next statesinputs MUX Some of these may have nothing to do with registers! Multiformat Microcode: condnext address 1dstsrcalu DECDEC DECDEC Branch Jump Register Xfer Operation

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Hybrid Control Not all critical control information is derived from control logic E.g., Instruction Register (IR) contains useful control information, such as register sources, destinations, opcodes, etc. Register File RS1DECRS1DEC RS2DECRS2DEC RDDECRDDEC op rs1 rs2rdIR to control enable signals from control

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Vax Microinstructions VAX Microarchitecture: 96 bit control store, 30 fields, 4096 µinstructions for VAX ISA encodes concurrently executable "microoperations" USHFUALUUSUBUJMP = left 010 = right. 101 = left3 010 = A-B = A+B+1 00 = Nop 01 = CALL 10 = RTN Jump Address Subroutine Control ALU Control ALU Shifter Control Current intel architecture: 80-bit microcode, 8192  instructions

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Horizontal vs. Vertical Microprogramming NOTE: previous organization is not TRUE horizontal microprogramming; register decoders give flavor of encoded microoperations Most microprogramming-based controllers vary between: horizontal organization (1 control bit per control point) vertical organization (fields encoded in the control memory and must be decoded to control something) Horizontal + more control over the potential parallelism of operations in the datapath - uses up lots of control store Vertical + easier to program, not very different from programming a RISC machine in assembly language - extra level of decoding may slow the machine down

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Administration °Midterm on Wednesday (10/10) from 5:30 - 8:30 in 277 Cory Hall No class on that day °Pizza and Refreshments afterwards at LaVal’s on Euclid I’ll Buy the pizza LaVal’s has an interesting history °Review Session: Sunday (10/7), 7:00 PM in 306 Soda???? Material through this Friday °Look over Lab 4 soon! Must breakdown to your TA by Friday night at midnight

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 How Effectively are we utilizing our hardware? °Example: memory is used twice, at different times Ave mem access per inst = 1 + Flw + Fsw ~ 1.3 if CPI is 4.8, imem utilization = 1/4.8, dmem =0.3/4.8 °We could reduce HW without hurting performance extra control IR <- Mem[PC] A <- R[rs]; B<– R[rt] S <– A + B R[rd] <– S; PC <– PC+4; S <– A + SX M <– Mem[S] R[rd] <– M; PC <– PC+4; S <– A or ZX R[rt] <– S; PC <– PC+4; S <– A + SX Mem[S] <- B PC <– PC+4; PC < PC+4;PC < PC+SX;

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 “Princeton” Organization °Single memory for instruction and data access memory utilization -> 1.3/4.8 °Sometimes, muxes replaced with tri-state buses Difference often depends on whether buses are internal to chip (muxes) or external (tri-state) °In this case our state diagram does not change several additional control signals must ensure each bus is only driven by one source on each cycle Reg File A B A- Bus B Bus IR S W-Bus PCPC next PC ZXSX Mem

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Today: Alternative datapath (book) °Miminizes Hardware: 1 memory, 1 adder Ideal Memory WrAdr Din RAdr 32 Dout MemWr 32 ALU 32 ALUOp ALU Control 32 IRWr Instruction Reg 32 Reg File Ra Rw busW Rb busA 32 busB RegWr Rs Rt Mux 0 1 Rt Rd PCWr ALUSelA Mux 01 RegDst Mux PC MemtoReg Extend ExtOp Mux Imm 32 << 2 ALUSelB Mux Zero PCWrCondPCSrc 32 IorD Mem Data Reg ALU Out B A

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 New Finite State Machine (FSM) Spec IR <= MEM[PC] PC <= PC + 4 R-type ALUout <= A fun B R[rd] <= ALUout ALUout <= A or ZX R[rt] <= ALUout ORi ALUout <= A + SX R[rt] <= M M <= MEM[ALUout] LW ALUout <= A + SX MEM[ALUout] <= B SW “instruction fetch” “decode” Execute Memory Write-back BEQ If A = B then PC <= ALUout ALUout <= PC +SX Q: How improve to do something in state 0001?

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Finite State Machine (FSM) Spec IR <= MEM[PC] PC <= PC + 4 R-type ALUout <= A fun B R[rd] <= ALUout ALUout <= A or ZX R[rt] <= ALUout ORi ALUout <= A + SX R[rt] <= M M <= MEM[ALUout] LW ALUout <= A + SX MEM[ALUout] <= B SW “instruction fetch” “decode” BEQ 0010 If A = B then PC <= ALUout ALUout <= PC +SX Execute Memory Write-back

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Designing a Microinstruction Set 1) Start with list of control signals 2) Group signals together that make sense (vs. random): called “fields” 3) Place fields in some logical order (e.g., ALU operation & ALU operands first and microinstruction sequencing last) 4) Create a symbolic legend for the microinstruction format, showing name of field values and how they set the control signals Use computers to design computers 5) To minimize the width, encode operations that will never be used at the same time

CS152 / Kubiatowicz Lec /03/01©UCB Fall &2) Start with list of control signals, grouped into fields Signal nameEffect when deassertedEffect when asserted ALUSelA1st ALU operand = PC1st ALU operand = Reg[rs] RegWriteNoneReg. is written MemtoRegReg. write data input = ALUReg. write data input = memory RegDstReg. dest. no. = rtReg. dest. no. = rd MemReadNoneMemory at address is read, MDR <= Mem[addr] MemWriteNoneMemory at address is written IorDMemory address = PCMemory address = S IRWriteNoneIR <= Memory PCWriteNonePC <= PCSource PCWriteCond NoneIF ALUzero then PC <= PCSource PCSource PCSource = ALU PCSource = ALUout ExtOpZero ExtendedSign Extended Single Bit Control Signal nameValueEffect ALUOp00ALU adds 01ALU subtracts 10ALU does function code 11ALU does logical OR ALUSelB002nd ALU input = 4 012nd ALU input = Reg[rt] 102nd ALU input = extended,shift left 2 112nd ALU input = extended Multiple Bit Control

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Start with list of control signals, cont’d ° For next state function (next microinstruction address), use Sequencer-based control unit from last lecture Called “microPC” or “µPC” vs. state register Signal ValueEffect Sequen00Next µaddress = 0 -cing 01Next µaddress = dispatch ROM 10Next µaddress = µaddress + 1 ° Could even include “branch” option which changes microPC by adding offset when certain control signals are true. Opcode microPC 1 µAddress Select Logic Adder ROM Mux 0 012

CS152 / Kubiatowicz Lec /03/01©UCB Fall ) Microinstruction Format: unencoded vs. encoded fields Field NameWidthControl Signals Set wide narrow ALU Control42ALUOp SRC121ALUSelA SRC253ALUSelB, ExtOp ALU Destination32RegWrite, MemtoReg, RegDst Memory32MemRead, MemWrite, IorD Memory Register11IRWrite PCWrite Control32PCWrite, PCWriteCond, PCSource Sequencing32AddrCtl Total width2415bits

CS152 / Kubiatowicz Lec /03/01©UCB Fall ) Legend of Fields and Symbolic Names Field NameValues for FieldFunction of Field with Specific Value ALUAddALU adds Subt. ALU subtracts Func codeALU does function code OrALU does logical OR SRC1PC1st ALU input = PC rs1st ALU input = Reg[rs] SRC242nd ALU input = 4 Extend2nd ALU input = sign ext. IR[15-0] Extend02nd ALU input = zero ext. IR[15-0] Extshft2nd ALU input = sign ex., sl IR[15-0] rt2nd ALU input = Reg[rt] destinationrd ALUReg[rd] = ALUout rt ALUReg[rt] = ALUout rt Mem Reg[rt] = Mem MemoryRead PCRead memory using PC Read ALURead memory using ALUout for addr Write ALUWrite memory using ALUout for addr Memory registerIRIR = Mem PC writeALUPC = ALU ALUoutCondIF ALU Zero then PC = ALUout SequencingSeqGo to sequential µinstruction FetchGo to the first microinstruction DispatchDispatch using ROM.

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Quick check: what do these fieldnames mean? CodeNameRegWriteMemToRegRegDest XX 01rd ALU101 10rt ALU100 11rt MEM110 CodeNameALUSelBExtOp XX X 010rt01X 011ExtShft Extend Extend0110 Destination: SRC2:

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Alternative datapath (book): Multiple Cycle Datapath °Miminizes Hardware: 1 memory, 1 adder Ideal Memory WrAdr Din RAdr 32 Dout MemWr 32 ALU 32 ALUOp ALU Control 32 IRWr Instruction Reg 32 Reg File Ra Rw busW Rb busA 32 busB RegWr Rs Rt Mux 0 1 Rt Rd PCWr ALUSelA Mux 01 RegDst Mux PC MemtoReg Extend ExtOp Mux Imm 32 << 2 ALUSelB Mux Zero PCWrCondPCSrc 32 IorD Mem Data Reg ALU Out B A

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Microprogram it yourself! LabelALU SRC1SRC2ALU Dest.MemoryMem. Reg. PC Write Sequencing Fetch:AddPC4Read PCIRALUSeq

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Microprogram it yourself! LabelALU SRC1SRC2Dest.MemoryMem. Reg. PC Write Sequencing Fetch:AddPC4Read PCIRALUSeq AddPCExtshftDispatch Rtype:FuncrsrtSeq rd ALUFetch Ori:Orrs Extend0 Seq rt ALUFetch Lw:AddrsExtend Seq Read ALU Seq rt MEM Fetch Sw:AddrsExtendSeq Write ALUFetch Beq:Subt.rsrt ALUoutCond.Fetch

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Legacy Software and Microprogramming °IBM bet company on 360 Instruction Set Architecture (ISA): single instruction set for many classes of machines (8-bit to 64-bit) °Stewart Tucker stuck with job of what to do about software compatibility °If microprogramming could easily do same instruction set on many different microarchitectures, then why couldn’t multiple microprograms do multiple instruction sets on the same microarchitecture? °Coined term “emulation”: instruction set interpreter in microcode for non-native instruction set °Very successful: in early years of IBM 360 it was hard to know whether old instruction set or new instruction set was more frequently used

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Microprogramming Pros and Cons °Ease of design °Flexibility Easy to adapt to changes in organization, timing, technology Can make changes late in design cycle, or even in the field °Can implement very powerful instruction sets (just more control memory) °Generality Can implement multiple instruction sets on same machine. Can tailor instruction set to application. °Compatibility Many organizations, same instruction set °Costly to implement °Slow

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 An Alternative MultiCycle DataPath °In each clock cycle, each Bus can be used to transfer from one source °µ-instruction can simply contain B-Bus and W-Dst fields Reg File A B A-Bus B Bus IR S mem W-Bus PCPC inst mem next PC ZXSX

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 What about a 2-Bus Microarchitecture (datapath)? Reg File A B A- Bus B Bus IR S PCPC next PC ZXSX Mem Reg File A B IR S PCPC next PC ZXSX Mem Instruction Fetch Decode / Operand Fetch M M

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Load °What about 1 bus ? 1 adder? 1 Register port? Reg File A B IR S PCPC next PC ZXSX Mem Reg File A B IR S PCPC next PC ZXSX Mem Reg File A B IR S PCPC next PC ZXSX Mem Execute addr M M M Mem Write-back

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Summary °Specialize state-diagrams easily captured by microsequencer simple increment & “branch” fields datapath control fields °Most microprogramming-based controllers vary between: horizontal organization (1 control bit per control point) vertical organization (fields encoded in the control memory and must be decoded to control something) °Steps: identify control signals, group them, develop “mini language”, then microprogram °Control design reduces to Microprogramming Arbitrarily complicated instructions possible

CS152 / Kubiatowicz Lec /03/01©UCB Fall 2001 Summary: Microprogramming one inspiration for RISC °If simple instruction could execute at very high clock rate… °If you could even write compilers to produce microinstructions… °If most programs use simple instructions and addressing modes… °If microcode is kept in RAM instead of ROM so as to fix bugs … °If same memory used for control memory could be used instead as cache for “macroinstructions”… °Then why not skip instruction interpretation by a microprogram and simply compile directly into lowest language of machine?