/// LSU EE 3755 -- Fall 2001 -- Computer Organization
/// Note Set 13 -- Our MIPS Implementations

// Time-stamp: <5 December 2001, 18:29:25 CST, koppel@sol>

These notes are outdated. The lectures page contains links to the latest versions of these notes.

/// Contents // // Class MIPS Implementations // Strawman MIPS Implementation // Hardwired Control MIPS Implementation // Microcoded Control MIPS Implementation // Other Implementations /// References // // :P: Palnitkar, "Verilog HDL" // :Q: Qualis, "Verilog HDL Quick Reference Card Revision 1.0" // :H: Hyde, "Handbook on Verilog HDL" // :LRM: IEEE, Verilog Language Reference Manual (Hawaii Section Numbering) // :PH: Patterson & Hennessy, "Computer Organization & Design" // :HP: Hennessy & Patterson, "Computer Architecture: A Quantitative Approach" // :Mv1: MIPS Technologies, "MIPS32 Architecture for Programmers Vol I: Intro" // :Mv2: MIPS Technologies, "MIPS32 Architecture for Programmers Vol II: Instr" //////////////////////////////////////////////////////////////////////////////// /// Class MIPS Implementations /// Summary of Implementation Types // All Verilog descriptions are synthesizable. // They execute only a subset of MIPS instructions. /// Strawman Implementation (EE 3755) // // http://www.ece.lsu.edu/3755/2001f/mips.html // // Not intended for synthesis. // Illustrates basic implementation techniques. // Can be used to validate other models. /// Hardwired Control Implementation (EE 3755) // // http://www.ece.lsu.edu/3755/2001f/mips3lt.html // // Low cost, small size. // // Processors implemented this way may be used where the smallest // size is needed, for example as part of a complete system on a // chip used to control, say, a microwave oven. /// Microcoded Control Implementation (EE 3755) // // http://www.ece.lsu.edu/3755/2001f/mipsmc.html // // Low cost. // // Microcoding usually applied to processors with more complex // instruction sets. /// Pipelined, Statically Scheduled (EE 4720) // // Similar to hardwired control, but much faster at little additional cost. // Many current processors implemented this way, e.g., Ultrasparc-III /// Pipelined, Dynamically Scheduled (EE 4720) // // Some additional speed, lots of additional complexity. // Many current processors implemented this way, e.g., Pentium IV, MIPS R10000 //////////////////////////////////////////////////////////////////////////////// /// Strawman MIPS Implementation // http://www.ece.lsu.edu/3755/2001f/mips.html /// Simple as possible. /// Uses // // Illustrate basics of implementation to students. // Verify more complex implementations. /// Key Characteristics // /// Each instruction executed in a single cycle. // // Unrealistic because it precludes hardware sharing, for example, // using the ALU to compute a branch condition and target. /// Memory is within processor. // // Unrealistic because memory is usually too large to fit on the // same chip as the CPU. // // Even if some memory is on-chip an interface to that memory // (addr, we, etc) is usually needed for external communication. // // Even if an external interface is present, we might not trust // the synthesis program to properly infer a memory from our // "casual" use of the mem array. /// Almost no thought given to synthesized hardware. // // Synthesis programs cannot yet be trusted to do a good job. // The problems above are only relevant if the description is synthesized. // If simulation is our goal then the Strawman MIPS implementation is // fine because of its simplicity. For simulation a description should // be as simple as possible to minimize the chance of errors. //////////////////////////////////////////////////////////////////////////////// /// Hardwired Control MIPS Implementation // http://www.ece.lsu.edu/3755/2001f/mips3lt.html /// Low Cost Implementation /// Key Characteristics // /// Memory is outside the CPU. // // This is the way it should be. /// The ALU is a separate module. // // In the Strawman Implementation a synthesis program might have // synthesized an adder each place an addition operator is used, a // bitwise AND for each AND, etc. The Hardwired code instantiates // one ALU, so that's all the synthesis program will create. /// Each instruction is executed in multiple cycles. /// Further Refinements That Might Be Made // /// Separate out additional modules. // // In real systems arithmetic and shifting are done by separate // units because shifting logic cannot be shared with arithmetic // or logic. // // Humans know the GPR is a memory with two read ports and a write // port. The synthesis program might not realize it (perhaps due // bad Verilog coding style) and instead provide more write ports // than necessary or it might not realize it can use the // streamlined memory cell provided in the target technology // library. Having a separate GPR module can avoid these problems. // /// Perform some limited pipelining. // // The fetch of one instruction can be overlapped with the // execution of the previous one. See Fall 2001 Homework 7 // Problem 2. /// Refine the ALU design. // // Will the synthesis program efficiently combine the different // operations in the ALU module? If not, re-do the alu with a // lower level design, something like alu2 in l05.v (Section 4.5 // of the text). /// Move code for simmed, etc. out of the procedural block to simplify hardware. // // The synthesis program might create more registers and other // logic than necessary. For example, the assignment rs_val = gpr[rs]; // in the ID state might force the synthesis program to use a // register for rs_val (if it were accessed outside the ID state). // Making that a continuous assignment outside of procedural code // would solve the problem: wire [31:0] rs_val = gpr[rs]; // Another candidate for de-proceduralization is: {opcode,rs,rt,rd,sa,func} = ir; // since ir doesn't change. /// Check timing and move hardware between states. // // For example, "move" the alu input multiplexors from ID to the // EX state. The ID state would compute an alu control input, // like alu_a_src in the microcoded design. /// Use the ALU to compute NPC + 4. /// Add the remaining MIPS instructions! //////////////////////////////////////////////////////////////////////////////// /// Microcoded Control MIPS Implementation // http://www.ece.lsu.edu/3755/2001f/mipsmc.html /// Different Type of Control Logic // In the Hardwired Control Implementation the control signals (the // control inputs to the multiplexors and the enable inputs to the // registers) are output by combinational logic. (The combinational // logic is generated from the case expressions in case statements // and the condition in if statements. To reduce the number of // multiplexor inputs, optimization might make this logic quite // complex.) // In the Microcoded Control Implementation the control signals are // generated by a small computer, called the microcontroller. /// Key Characteristics // /// Control signals generated by microcontroller. // /// Control logic is very simple, complexity is in the microprogram ROM. /// Further Refinements That Might Be Made /// Make part of micro ROM writable. // // This would allow new instructions to be added after // the part is manufactured. (And yes, if it were writable // it probably shouldn't be called a ROM anymore.) /// Implement all instructions! //////////////////////////////////////////////////////////////////////////////// /// Other Implementations // http://www.ece.lsu.edu/ee4720 /// Implementation Techniques Covered in EE 4720 /// Pipelined, Statically Scheduled // // Overlap execution states, so the ID for one instruction // is done at the same time as IF for the previous one. // // "States" for a pipelined processor are carefully chosen to // allow overlap. // // One section of hardware, called a stage, is dedicated to doing IF, // one is dedicated to doing ID, and so on. // // Each stage does what the corresponding state did in the hardwired // processor. // // The stages are: IF, ID, EX, MEM, WB. The last is used to write // back the register file. // // At any cycle there can be up to five instructions in the processor, // each in a different stage. // // This pipelining opens up a can of worms, which we'll have fun playing // with in EE 4720. /// Pipelined, Dynamically Scheduled // // Some instructions take a long time to produce results, floating // point instructions and memory loads, for example. (This problem // was completely avoided in EE 3755 by omitting floating-point // instructions and having perfect memory.) // // In a dynamically scheduled processor instructions are fetched and // decoded in program order, but execute when their operands are // available. An instruction waiting for its operands (because a // previous instruction is taking a long time) does not prevent // instructions that follow it from being fetched, decoded, and // executed.