Lab #4: Single-cycle CPU Data-path and Controller

Lab 4 is due Monday, Apr. 27. 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.

Objective The objective of this laboratory is to develop a structural model for the single-cycle data-path and a behavioral model of the single-cycle CPU controller and to integrate the two components to model the CPU.

Problem 1
Design and implement a structural model for the single-cycle data path. Use your behavioral register file and ALU models from Laboratory 3 in conjunction with other components to implement your system. No behavioral VHDL is allowed in the data path description other than the models for the CPU components you have been implemented in Lab 3. The only exception is that you may design components to calculate offset values for BEQ, LW, and SW operation. Note that efficiency in these components is of utmost importance. Use multiplexers to select and route data to the memory access subsystem and route retrieved data appropriately. Note that handling output can be achieved largely using load-enables for various components and should not require the use of a demultiplexer. Your data path should be implemented as a single entity with a structural architecture using as many structural components as necessary. Document all control settings and outputs from the data path. Remember that you must include the system clock to trigger data storage elements. Note that, in the design of the data path, you should use behavioral models for both the register file and the ALU. You may modify your behavioral models as necessary to suite your particular design. It is unlikely that your register file will require modification, but the control signals to the ALU may be reconfigured to more effectively interpret instructions.

The input of this model is the clock signal and all the control signals. The output of this model is an instruction word (32-bit) for the controller defined in Problem 2.

Problem 2
Design and implement a behavioral model for the single-cycle CPU controller that implements six instructions. The six instructions are NOP, ADD, ORI, LW, SW, and BEQ. Your controller should be implemented behaviorally using case statements and/or if statements in a VHDL process. Note that each instruction may involve different numbers of control signals. You are suggested to draw an AND gate array and an OR gate array, as discussed in the class, for the controller, and systematically approach your design. Your controller should be implemented as a single entity with a behavioral architecture implementing the controller. Document all inputs and outputs defined for the controller.


The input of this model is the instruction word. The output of this model is all the control signals. The model does not accept the clock signal, because a controller is a combinational circuit, which has no internal states, and is triggered by the instruction word.

Problem 3
(CPU Model) Integrate your controller and data path to define a structural architecture for the single-cycle CPU. Use the entities from Lab 3 to define a structural architecture for the implementation. This architecture should use the same entity model developed for Laboratory 3. Modifications may be made to correct errors from Laboratory 3 if necessary.

The input of this model is the clock signal and the reset signal. There is no output from this model, because this model is a stand-alone CPU. However, in order to check the internal state of the CPU, so that we can verify the correctness of the model, we add a side effect to the instruction SW. If the target address of SW is 0, the SW instruction will print out the content of the word 0 of the memory.

Problem 4 Test your structural MIPS CPU implementation using a test bench that compares execution with the expected results of all the six instructions. Your VHDL test bench should only provide clock signals and an initial reset signal to drive the CPU model. Unlike the test benches in Lab 2 and Lab 3, we won't be able to read the internal state of the CPU model directly, or verify the correctness of out CPU implementations directly, because the CPU model has no output. Instead, you should develop MIPS test programs, like what we did in Lab 1, and run the test programs in your CPU model, in order to verify that your CPU works correctly for the six instructions. Remember, we can use the SW instruction to print out the content of the memory word 0. Hence, we can at least peek into the internal of CPU.

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 3 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 instruction memory. The command line of mipsasm is "/usa/xli/local/bin/mipsasm test.asm imem".


Congratulations! Now you have your own, though very simple, CPU.


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]_lab4.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 lab4 [your_first_name]_[your_last_name]_lab3.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.