Lab #5: Multi-cycle CPU Data-path and Controller

Lab 5 is due Monday, May 11. Your lab report and source code must be submitted by 10:10 AM on Monday before class. The late policy applies to this lab project.

This lab is to be done in teams. Get started early! Also, remember to put your names on the lab report! The required format for lab reports is shown here.

In this project, the size of a word is 32 bits.

In this project, you will design and build your own multicycle MIPS processor. Your processor should match the design from the text reprinted below (Figure 5.28 of Computer Organization and Design).

Your task in this lab will be to design and test a implementation for the multi-cycle controller (Problem 1), to merge your controller with a modified single-cycle datapath to build a complete multi-cycle processor, and to work out a test program for the processor as a whole (Problem 2). You may reuse any of your designs and implementations from previous labs.

Problem 1: Multi-cycle Datapath Controller

The controller is the most complex part of the multicycle processor. It should take the inputs and produce the outputs described in the lectures previously. Note that the controller comprises both the decoder using OP(5:0) and the ALUCONTROL logic taking ALUOP(1:0) and the FUNCT code from the low bits of the INSTRUCTION. You may combine the "Control" and the "ALU control" in Figure 5.28. On RESET, the controller should start at State 0. The unit should support all the instructions from Lab 4. The state transition table is shown in the slide 37 of the lecture "Multi-cycle Datapath Control" (ignoring the jump instruction).

The controller interface of inputs and outputs is defined as the table below. To simplify your task, you can use a behavior model for the implementation of the controller.

Contoller Interface
Control Signal Width Input/Output Control Signal Width Input/Output
CLK (0:0) Input REGWRITE (0:0) Output
RESET (0:0) Input REGDST (0:0) Output
OP (5:0) Input IORD (0:0) Output
FUNCT (3:0) Input MEMREAD (0:0) Output
ZERO (0:0) Input MEMWRITE (0:0) Output
PCSOURCE (1:0) Output MEMTOREG (0:0) Output
ALUCONTROL (3:0) Output IRWRITE (0:0) Output
ALUSRCB (1:0) Output PCENABLE (0:0) Output
ALUSRCA (0:0) Output      

Problem 2: Multicycle Datapath Completion

In this lab, you will complete your own multicycle MIPS processor. By this point, you should have a multi-cycle datapath controller and a single-cycle datapath at hand. You should reuse the single-cycle datapath components such as the ALU, signext and register file whereever possible. There are a few components that you need to modify or re-design for the context of multi-cycle datapath. For example, the memory unit contains the shared memory used to hold both data and instructions. In the PC circuit, you need to generate the register for the PC counter. You will need a multiplexer to select one of these cases for the PC input: from the ALURESULT, or from the ALUOUT. In addition, the PC is enabled by a PCENABLE signal generated in the controller.

In the memory, you need to have a RAM to store instructions and memory data. Both read and write are possible. Because we combine the instruction memory and the data memory, now the memory unit holds 256 memory lines, the first 128 for instruction and the second 128 for data. As you can see, the address for the RAM can come either from the PC (if you are accessing an instruction) or from ALUOUT (if you are accessing data) and it is determined by the IorD (Instruction or Data) signal from the controller. Once the content is fetched from the RAM, it is sent to one of two different registers for instruction and for memory data, respectively. Both RAM and registers must be set up properly by the controller.


In the ALU part, there are more functions to implement. The first item to set up is the sign extension module, which takes 16 bits and sign extends to 32 bits. The other key element is the register file that allows reading from two different addresses and, at the same time, writing data to another address. Set up additional multiplexers to choose the addresses for read and write according to the diagram.

There is an important issue related to the dual-port register file that can be read/writen in the same cycle. One trick to allow both writing and reading properly is to let the reading operation be done at the falling edge of the clock instead of the rising edge. This way, the reading address comes from the correct instruction, which is only valid until slightly after the clock rising edge.


You can copy additional function units, such as the ALU, from previous labs. Finally, when you have finished all components, connect them together in a top-level schematic. The design should only take CLK and RESET as inputs. All of your flip-flops should take a RESET input to reset the initial value to a known state. The Instruction Register and PC also require CLK_EN enable inputs. Pay careful attention to bus connections; they are an easy place to make mistakes.

Test bench for your implementation:

Because Lab 5 and Lab 4 support the same set of instructions, you can resue your test program in Lab 4 for this Lab. Be sure to enter your test program Lab 4 into the content of the memory RAM. Feed your mulci-cycle processor implementation with clock signals from your VHDL test-bench until the completion of the program. You should expect the same output as that of Lab 4 implementation, though different number of cycles are needed to finish the same test program. Check that your results match the expectations .


How to run MIPS test programs in your VHDL CPU model?

A sample MIPS test program, test.asm, is provided here. In addition, you can find a MIPS assembler at "/usa/xli/local/bin/mipsasm". You can load a test program by first generating the binary code for the MIPS assembly program, and rename the binary code to "imem". Remember in Lab 4 that your implementation of the instruction memory should read from the file "imem" to initialized the 128 memory lines. Also initialize the PC to be zero. As a result, at the first clock rising edge, your CPU model should start executing the first instruction at address 0, the starting address of the combined memory. The command line of mipsasm is "/usa/xli/local/bin/mipsasm test.asm imem".


How to test using GHDL

GHDL is installed under the directory /usa/xli/local/bin. The ghdl compiler is for linuxlab.acad.ece.udel.edu only. Assuming we have "shift_reg.vhdl", which is the implementation of a 4-bit shift register, and "shift_reg_tb.vhdl", which is the test bench for our implementation, there are three steps to run the test bench:

(1) Analyze: Compile the two vhdl files
"/usa/xli/local/bin/ghdl -a shift_reg.vhdl"
"/usa/xli/local/bin/ghdl -a shift_reg_tb.vhdl"

If you use any IEEE libraries, add "--ieee=synopsys" after "-a".

(2) Generate the executable for the test bench:
"/usa/xli/local/bin/ghdl -e shift_reg_tb"

If you use any IEEE libraries, add "--ieee=synopsys" after "-e".

(3) Run the test bench:
"/usa/xli/local/bin/ghdl -r shift_reg_tb"

What to Turn In

For this lab project, turn in all of your source code, including the code that implements the datapath, the controller, and the intergrated CPU model, and the code that tests your implementations. Describe the testing methodology.

How to Submit

Copy your lab report, which is a .pdf, a .doc, or a .html file, and all your source code into an empty directory. Assuming the directory is "submission", make a tar ball of the directory using the following command:

tar czvf [your_first_name]_[your_last_name]_lab5.tar.gz submission.

Replace [your_first_name] and [your_last_name] with your first name and your last name.

Log in to linuxlab.acad.ece.udel.edu. Run a program cpeg324_submit using the following command line:

/usa/xli/bin/cpeg324_submit lab5 [your_first_name]_[your_last_name]_lab5.tar.gz

The time when you run cpeg324_submit is used as the time-stamp of your submission.

Peer evaluation: Please email your peer evaluation (guideline is here) of your teammates, including scores and justification, directly to xli@ece.udel.edu.