John Lazzaro (www.cs.berkeley.edu/~lazzaro) CS152 – Computer Architecture and Engineering Lecture 8 – Multicycle Design and Microcode 2004-09-23 John.

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.
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 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.
ECE 232 L15.Miulticycle.1 Adapted from Patterson 97 ©UCBCopyright 1998 Morgan Kaufmann Publishers ECE 232 Hardware Organization and Design Lecture 15 Multi-cycle.
Give qualifications of instructors: DAP
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
CS61C L26 CPU Design : Designing a Single-Cycle CPU II (1) Garcia, Fall 2006 © UCB Lecturer SOE Dan Garcia inst.eecs.berkeley.edu/~cs61c.
361 control Computer Architecture Lecture 9: Designing Single Cycle Control.
Class 9.1 Computer Architecture - HUJI Computer Architecture Class 9 Microprogramming.
EECC550 - Shaaban #1 Lec # 5 Spring CPU Design Steps 1. Analyze instruction set operations using independent RTN => datapath requirements.
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.
1 Computer Organization & Design Microcode for Control Sec. 5.7 (CDROM) Appendix C (CDROM) / / pdf / lec_3a_notes.pdf.
EEM 486: Computer Architecture Designing a Single Cycle Datapath.
Exam 2 Review Two’s Complement Arithmetic Ripple carry ALU logic and performance Look-ahead techniques Basic multiplication and division ( non- restoring)
CS3350B Computer Architecture Winter 2015 Lecture 5.7: Single-Cycle CPU: Datapath Control (Part 2) Marc Moreno Maza [Adapted.
1 Processor: Datapath and Control Single cycle processor –Datapath and Control Multicycle processor –Datapath and Control Microprogramming –Vertical and.
Overview of Control Hardware Development
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
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)
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
IT 251 Computer Organization and Architecture
IT 251 Computer Organization and Architecture
Systems Architecture I
(Chapter 5: Hennessy and Patterson) Winter Quarter 1998 Chris Myers
Designing a Multicycle Processor
Designing a Multicycle Processor
Processor (I).
CS/COE0447 Computer Organization & Assembly Language
CpE242 Computer Architecture and Engineering Designing a Single Cycle Datapath Start: X:40.
CPU Organization (Design)
Single Cycle CPU Design
CS 704 Advanced Computer Architecture
Single-Cycle CPU DataPath.
Chapter Five The Processor: Datapath and Control
The Multicycle Implementation
John Kubiatowicz (http.cs.berkeley.edu/~kubitron)
Computer Organization Ellen Walker Hiram College
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
COMS 361 Computer Organization
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.
Instructors: Randy H. Katz David A. Patterson
Systems Architecture I
Alternative datapath (book): Multiple Cycle Datapath
The Processor: Datapath & Control.
COMS 361 Computer Organization
What You Will Learn In Next Few Sets of Lectures
Designing a Single-Cycle Processor
Processor: Datapath and Control
CS161 – Design and Architecture of Computer Systems
Presentation transcript:

John Lazzaro (www.cs.berkeley.edu/~lazzaro) CS152 – Computer Architecture and Engineering Lecture 8 – Multicycle Design and Microcode 2004-09-23 John Lazzaro (www.cs.berkeley.edu/~lazzaro) Dave Patterson (www.cs.berkeley.edu/~patterson) www-inst.eecs.berkeley.edu/~cs152/

Review Single cycle datapath => CPI=1, CCT => long 5 steps to design a processor 1. Analyze instruction set => datapath requirements 2. Select set of datapath components & establish clock methodology 3. Assemble datapath meeting the requirements 4. Analyze implementation of each instruction to determine setting of control points that effects the register transfer. 5. Assemble the control logic Control is the hard part MIPS makes control easier Instructions same size Source registers always in same place Immediates same size, location Operations always on registers/immediates Processor Input Control Memory Datapath Output

What’s wrong with our CPI=1 processor? Arithmetic & Logical PC Inst Memory Reg File ALU mux mux setup Load PC Inst Memory Reg File ALU Data Mem mux mux setup Critical Path Store PC Inst Memory Reg File ALU Data Mem mux Branch PC Inst Memory Reg File cmp mux Long Cycle Time All instructions take as much time as the slowest Real memory slower than idealized memory Duplicate Resources

Memory Access Time Physics => fast memories are small (large memories are slow) => Use a hierarchy of memories Storage Array selected word line storage cell address bit line address decoder sense amps mem. bus proc. bus memory L2 Cache Cache Processor 1 time-period 20 - 50 time-periods 2-3 time-periods

Reducing Cycle Time Cut combinational dependency graph and insert register / latch Do same work in two fast cycles, rather than one slow one May be able to short-circuit path and remove some components for some instructions! storage element storage element Acyclic Combinational Logic Acyclic Combinational Logic (A)  storage element Acyclic Combinational Logic (B) storage element

Limits on Cycle Time (new view of datapath) Next address logic PC <= branch ? PC + offset : PC + 4 Instruction Fetch InstructionReg <= Mem[PC] Register Access A <= R[rs] ALU operation R <= A + B Control MemRd nPC_sel ALUSrc ALUctr MemWr RegDst RegWr MemWr ExtOp Reg. File Exec Operand Fetch Instruction Fetch Mem Access PC Next PC Result Store Data Mem

Partitioning the CPI=1 Datapath Add registers between smallest steps Place so that balances length of clock cycle Logic delays about the same between registers Place to save information needed later in instruction execution Equal MemRd nPC_sel MemWr RegDst RegWr MemWr ExtOp ALUSrc ALUctr Reg. File Exec Operand Fetch Instruction Fetch Mem Access PC Next PC Result Store Data Mem

Example Multicycle Datapath Ext ALU Reg. File Mem Access Data Result Store RegDst RegWr MemWr MemRd S M MemToReg Equal ALUctr ALUSrc ExtOp nPC_sel E Reg File A PC IR Next PC B Instruction Fetch Operand Fetch Critical Path ?

Recall: Step-by-step Processor Design Step 1: ISA => Logical Register Transfers Step 2: Components of the Datapath Step 3: RTL + Components => Datapath Step 4: Datapath + Logical RTs => Physical RTs Step 5: Physical RTs => Control

Step 4: R-rtype (add, sub, . . .) Logical Register Transfer Physical Register Transfers inst Logical Register Transfers ADDU R[rd] <= R[rs] + R[rt]; PC <= PC + 4 inst Physical Register Transfers IR <= MEM[pc] ADDU A<= R[rs]; B <= R[rt] S <= A + B R[rd] <= S; PC <= PC + 4 Time E Reg. File A S Reg File Exec PC IR Next PC Inst. Mem B M Mem Access Data Mem

Administrivia Working on Homework #2 Single cycle simulation demo on Friday (add to your calendar Midterm 1 on Tuesday Oct 12 5:30 - 8:30pm 306 Soda)

Step 4: Logical immed Logical Register Transfer Physical Register Transfers inst Logical Register Transfers ORI R[rt] <= R[rs] | ZExt(Im16); PC <= PC + 4 inst Physical Register Transfers IR <= MEM[pc] ORI A<= R[rs]; B <= R[rt] S <= A | ZExt(Im16) R[rt] <= S; PC <= PC + 4 Time E A Reg. File S Reg File Exec PC IR Next PC Inst. Mem B M Mem Access Data Mem

Step 4 : Load Logical Register Transfer Physical Register Transfers inst Logical Register Transfers LW R[rt] <= MEM[R[rs] + SExt(Im16)]; PC <= PC + 4 Logical Register Transfer Physical Register Transfers inst Physical Register Transfers IR <= MEM[pc] LW A<= R[rs]; B <= R[rt] S <= A + SExt(Im16) M <= MEM[S] R[rd] <= M; PC <= PC + 4 Time E A Reg. File S Reg File Exec PC IR Next PC Inst. Mem B M Mem Access Data Mem

Step 4 : Store Logical Register Transfer Physical Register Transfers inst Logical Register Transfers SW MEM[R[rs] + SExt(Im16)] <= R[rt]; PC <= PC + 4 Logical Register Transfer Physical Register Transfers inst Physical Register Transfers IR <= MEM[pc] SW A<= R[rs]; B <= R[rt] S <= A + SExt(Im16); MEM[S] <= B PC <= PC + 4 Time E A Reg. File S Reg File Exec PC IR Next PC Inst. Mem B M Mem Access Data Mem

Step 4 : Branch Logical Register Transfer Physical Register Transfers inst Logical Register Transfers BEQ if R[rs] == R[rt] then PC <= PC + 4+{SExt(Im16), 2’b00} else PC <= PC + 4 inst Physical Register Transfers IR <= MEM[pc] BEQ E<= (R[rs] = R[rt]) if (!E) PC <= PC + 4; else PC <=PC+4+{SExt(Im16),2’b0} Time E Reg. File S Reg File A Exec PC IR Next PC Inst. Mem B M Mem Access Data Mem

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

Our Control Model State specifies control points for Register Transfer Transfer occurs upon exiting state (same clock edge) inputs (conditions) Next State Logic State X Register Transfer Control Points Control State Depends on Input Output Logic outputs (control points)

Step 4  Control Spec for multicycle proc “instruction fetch” IR <= MEM[PC] “Finite State Diagram” A <= R[rs] B <= R[rt] “decode / operand fetch” LW R-type ORi SW BEQ Execute Memory Write-back PC <= Next(PC,Equal) S <= A fun B S <= A | ZX S <= A + SX S <= A + SX M <= MEM[S] MEM[S] <= B PC <= PC + 4 R[rd] <= S PC <= PC + 4 R[rt] <= S PC <= PC + 4 R[rt] <= M PC <= PC + 4

Traditional FSM Controller next state state op cond control points Truth Table next State control points 11 Equal 6 State 4 op datapath State

Step 5  (datapath + state diagram control) Translate RTs into control points Assign states Then go build the controller

Mapping Register Transfers to Control Points IR <= MEM[PC] “instruction fetch” imem_rd, IRen A <= R[rs] B <= R[rt] “decode” Aen, Ben, Een LW R-type ORi SW BEQ S <= A fun B S <= A | ZX S <= A + SX S <= A + SX PC <= Next(PC,Equal) Execute Memory Write-back ALUfun, Sen M <= MEM[S] MEM[S] <= B PC <= PC + 4 R[rd] <= S PC <= PC + 4 RegDst, RegWr, PCen R[rt] <= S PC <= PC + 4 R[rt] <= M PC <= PC + 4

Assigning States “instruction fetch” IR <= MEM[PC] 0000 “decode” A <= R[rs] B <= R[rt] “decode” 0001 LW R-type ORi SW BEQ Execute Memory Write-back S <= A fun B S <= A or ZX S <= A + SX S <= A + SX PC <= Next(PC) 0100 0110 1000 1011 0011 M <= MEM[S] MEM[S] <= B PC <= PC + 4 1001 1100 R[rd] <= S PC <= PC + 4 R[rt] <= S PC <= PC + 4 R[rt] <= M PC <= PC + 4 0101 0111 1010

(Mostly) Detailed Control Specs (missing0) State Op field Eq Next IR PC Ops Exec Mem Write-Back en sel A B E Ex Sr ALU S R W M M-R Wr Dst 0000 ?????? ? 0001 1 0001 BEQ x 0011 1 1 1 0001 R-type x 0100 1 1 1 0001 ORI x 0110 1 1 1 0001 LW x 1000 1 1 1 0001 SW x 1011 1 1 1 0011 xxxxxx 0 0000 1 0 x 0 x 0011 xxxxxx 1 0000 1 1 x 0 x 0100 xxxxxx x 0101 0 1 fun 1 0101 xxxxxx x 0000 1 0 0 1 1 0110 xxxxxx x 0111 0 0 or 1 0111 xxxxxx x 0000 1 0 0 1 0 1000 xxxxxx x 1001 1 0 add 1 1001 xxxxxx x 1010 1 0 1 1010 xxxxxx x 0000 1 0 1 1 0 1011 xxxxxx x 1100 1 0 add 1 1100 xxxxxx x 0000 1 0 0 1 0 -all same in Moore machine BEQ: R: ORi: LW: SW:

Instruction Set and Control Options 7-instruction subset MIPS easy to implement FSM by hand Full MIPS instruction set > 100 instructions, inclucing *, /, Floating Point +, -, *, / Need to use Verilog, CAD tools Full IA-32 instruction set? > 500 instructions, including copy and edit, save/ restore state, setup for key-like memory protection, …

Controller Design The state diagrams that arise define the controller for an instruction set processor are highly structured Use this structure to construct a simple “microsequencer” Control reduces to programming this very simple device  microprogramming taken datapath control Z I L Micro-PC op-code Map ROM

Our Microsequencer taken datapath control Z I L Micro-PC op-code Map ROM

Adding the Dispatch ROM Sequencer-based control 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

Microprogramming To DataPath -Code ROM datapath control microinstruction () sequencer control micro-PC -sequencer: fetch,dispatch, sequential Dispatch ROM Opcode Inputs -Code ROM To DataPath Decode

Microprogramming Microprogramming is a convenient method for implementing structured control state diagrams: Random logic replaced by microPC sequencer and ROM Each line of ROM called a microinstruction: contains sequencer control + values for control points To reduce confusion, normal instruction (e.g., MIPS addu) called “macroinstruction” limited state transitions: branch to zero, next sequential, branch to instruction address from dispatch ROM Control design reduces to Microprogramming Part of the design process is to develop a “language” that describes control and is easy for humans to understand

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

Designing a “Microinstruction Set” 1) Start with list of control signals 2) Group signals together that make sense (vs. random): “fields” 3) Place fields in some logical order (e.g., ALU operation & ALU operands first and microinstruction sequencing last) 4) To minimize the width, encode operations that will never be used at the same time “Horizontal” Code: one control bit in Instruction for every control line in datapath “Vertical” Code: groups of control-lines coded together in Instruction (e.g. possible ALU dest) 5) 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

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

1&2) Start with list of control signals, grouped into fields Signal name Effect when deasserted Effect when asserted ALUSelA 1st ALU operand = PC 1st ALU operand = Reg[rs] RegWrite None Reg. is written MemtoReg Reg. write data input = ALU Reg. write data input = memory RegDst Reg. dest. no. = rt Reg. dest. no. = rd MemRead None Memory at address is read, MDR <= Mem[addr] MemWrite None Memory at address is written IorD Memory address = PC Memory address = S IRWrite None IR <= Memory PCWrite None PC <= PCSource PCWriteCond None IF ALUzero then PC <= PCSource PCSource PCSource = ALU PCSource = ALUout ExtOp Zero Extended Sign Extended Single Bit Control Signal name Value Effect ALUOp 00 ALU adds 01 ALU subtracts 10 ALU does function code (“R-format”) 11 ALU does logical OR ALUSelB 00 2nd ALU input = 4 01 2nd ALU input = Reg[rt] 10 2nd ALU input = extended,shift left 2 11 2nd ALU input = extended Multiple Bit Control

3&4) Microinstruction Format: unencoded vs. encoded fields Field Name Width Control Signals Set wide narrow ALU Control 4 2 ALUOp SRC1 2 1 ALUSelA SRC2 5 3 ALUSelB, ExtOp ALU Destination 3 2 RegWrite, MemtoReg, RegDst Memory 3 2 MemRead, MemWrite, IorD Memory Register 1 1 IRWrite PCWrite Control 3 2 PCWrite, PCWriteCond, PCSource Sequencing 3 2 AddrCtl Total width 24 15 bits “Horizontal” “Vertical”

5) Legend of Fields and Symbolic Names Field Name Values for Field Function of Field with Specific Value ALU Add ALU adds Subt. ALU subtracts Func code ALU does function code Or ALU does logical OR SRC1 PC 1st ALU input = PC rs 1st ALU input = Reg[rs] SRC2 4 2nd ALU input = 4 Extend 2nd ALU input = sign ext. IR[15-0] Extend0 2nd ALU input = zero ext. IR[15-0] Extshft 2nd ALU input = sign ex., sl IR[15-0] rt 2nd ALU input = Reg[rt] destination rd ALU Reg[rd] = ALUout rt ALU Reg[rt] = ALUout rt Mem Reg[rt] = Mem Memory Read PC Read memory using PC Read ALU Read memory using ALUout for addr Write ALU Write memory using ALUout for addr Memory register IR IR = Mem PC write ALU PC = ALU ALUoutCond IF ALU Zero then PC = ALUout Sequencing Seq Go to sequential µinstruction Fetch Go to the first microinstruction Dispatch Dispatch using ROM. Note: can specify combinations of fields that may not be possible or not work properly given the datapath (e.g., ALU operand and write register in single cycle)

Quick check: what do these fieldnames mean? Destination: Code Name RegWrite MemToReg RegDest 00 --- 0 X X 01 rd ALU 1 0 1 10 rt ALU 1 0 0 11 rt MEM 1 1 0 SRC2: Code Name ALUSelB ExtOp 000 --- X X 001 4 00 X 010 rt 01 X 011 ExtShft 10 1 100 Extend 11 1 111 Extend0 11 0

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

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 Lw: Add rs Extend Seq Read ALU Seq rt MEM Fetch Sw: Add rs Extend Seq Write ALU Fetch Ori: Or rs Extend0 Seq rt ALU Fetch Beq: Subt. rs rt ALUoutCond. Fetch

“microprogrammed control” 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 Control Explicit Next State Microprogram counter Function + Dispatch ROMs Logic Representation Logic Equations Truth Tables Implementation PLA ROM Technique “hardwired control” “microprogrammed control”

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 Control unit in same chip as data path, so can’t replace ROM ROM not faster than RAM (so not much faster than 1st level instruction cache), PLA smaller and therefore faster than ROM Simpler instruction sets popular now CAD tools + fast computers allows simulation => correct control

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

Thought: 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? (microprogramming is overkill when ISA matches datapath 1-1)

Summary (1 of 3) Disadvantages of the Single Cycle Processor Long cycle time Cycle time is too long for all instructions except the Load Multiple Cycle Processor: Divide the instructions into smaller steps Execute each step (instead of the entire instruction) in one cycle Partition datapath into equal size chunks to minimize cycle time ~10 levels of logic between latches Follow same 5-step method for designing “real” processor

Summary (cont’d) (2 of 3) Control is specified by finite state diagram Specialize state-diagrams easily captured by microsequencer simple increment & “branch” fields datapath control fields Control design reduces to Microprogramming Control is more complicated with: complex instruction sets restricted datapaths (see the book) Simple Instruction set and powerful datapath  simple control could try to reduce hardware (see the book) rather go for speed => many instructions at once!

Summary (3 of 3) 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 Design of a Microprogramming language Start with list of control signals Group signals together that make sense (vs. random): called “fields” Place fields in some logical order (e.g., ALU operation & ALU operands first and microinstruction sequencing last) To minimize the width, encode operations that will never be used at the same time Create a symbolic legend for the microinstruction format, showing name of field values and how they set the control signals

Where to get more information? Multiple Cycle Controller: Appendix C of your text book. Microprogramming: Section 5.7 of your text book. D. Patterson, “Microprograming,” Scientific American, March 1983. D. Patterson and D. Ditzel, “The Case for the Reduced Instruction Set Computer,” Computer Architecture News 8, 6 (October 15, 1980) ******* Keep the old slide: ******** So in the next town, the driver pretended to be the professor and started giving the lecture. Everything was going so well that both the audience and the real professor were impressed. That is until someone in the audience asked a technical question. But just when the professor was about to say “Got You.” His driver replied calmly: “Well this question is easily to answer. In fact, it is SO simple that even my driver sitting at the back can answer it.” So if you ask me how to implement this state diagram in hardware, I will say: “It is so simple even ... ********** New Slide ********** Well all jokes aside, Professor Patterson is probably one on the most qualified person to cover the next two topics. If you don’t already know, Professor Patterson’s PhD thesis was on microprogramming. He also wrote a very good article on microprogramming in Scientific America. But after spending early part of his career showing how great microprograming was, he then spend the next few years convining people what a bad idea microprogramming has become. One of the main feature of RISC (points to the reference) is that its control is hardwired instead of microprogrammed, a big difference from all other computers at that time. It is not uncommon to see people change their minds about something but the amazing part here is that Professor Patterson was right both times. So I am sure you guys will learn a lot in the next two lectures. I will see you guys in a week. +3 = 78 min. (Y:58)