Computer Science 324 Computer Architecture Mount Holyoke College Fall 2007

Your task in this lab is to build two simulators that are able to execute programs that use the MIPS subset we have discussed in class. You will be working with the MIPS multi-cycle data path as shown in Figure 5.28 of Patterson and Hennessy and the control as described later in Section 5.5 and Section 5.7 on the CD.

You may work alone or in pairs. Everyone should inform me by Thursday, November 13 whether you intend to work individually or have formed a group.

You will implement three components that will be used to construct two simulators:

1. The data path simulator will load a program into main memory, then begin executing. In one cycle, the control lines will indicate what the data path should do. When that is complete, the control is notified and a new set of control lines will be presented to the data path.
2. The finite state control simulator will provide the correct sequence of control outputs to execute the given opcodes, using the finite state machine approach as described in Section 5.5.
3. The microprogrammed control simulator also provides the sequence of control outputs, but does so using a microprogramming approach as described in Section 5.7.

The data path simulator can be combined with either control simulator to produce a program that can execute simple MIPS programs.

Data Path/Control Interface

In order to allow our simulators to work together in either combination, we must define the interface between the data path and the control. This is done with a set of functions that have prototypes defined in MIPScontrol.h. Any control implementation must provide implementations of each of these functions.

Data Path Simulator

The data path simulator is to be implemented in the file datapath.c. In order to keep busy work to a minimum, I am providing much of the infrastructure for the data path, including definitions of the state components and a complete main execution loop. You will need to think carefully about how to take the current values of the state elements (registers, memory) and control lines to get the correct values for all state elements at the end of the cycle. For example, if you are both reading the PC to get a memory address and updating its value, you need to make sure you use the old value before replacing it with the new value.

In addition to implementing the data path to function as described in the text, we have this special functionality:

1. If you ever load the special value 0xffffffff into the instruction register, your program should stop (return to the prompt). This is taken care of in the provided code framework.
2. The MIPS ISA specifies that register 0 always contains the value 0. You will need to make sure you initialize register 0 appropriately and make sure any attempt to modify it does not succeed.

Finite State Control

Your finite state control implementation should be done in the file fsm.c. You should implement a finite state machine as described in Chapter 5.5. This implementation is in a sense "hard wired" in that you will explicitly program the details of which control lines are to have particular values (aside: use "don't care" conditions to your advantage to keep code simple!) and how to transition from one state to the next based on the opcode.

Microprorammed Control

Your microprogrammed control implementation should be done in the file microcode.c. You should implement a machine that can read a microprogram from a file and execute it appropriately. This programmability is the advantage of the approach - the implementation of the microsequencer and microcode store are independent of the microcode it executes.

Executing Programs

The provided framework in datapath.c includes a main program that takes the name of a memory initialization file. That file is loaded into main memory, the program counter is initialized to 0, and the simulation begins.

The main program interacts with the user through a command prompt. The commands it implements:

• help: print a list of commands.
• mem lower upper: print memory between locations lower and upper.
• reg: print values of the registers.
• control: print values of the control lines.
• run steps: run for "steps" cycles (default 1).
• quit: exit the simulator.

My Implementations

As with the MIPS instruction decoding lab (which may be worth looking back at, by the way), I will provide compiled object files of my implementation to aid you as you proceed. You can use the provided Makefile to switch back and forth between my version and your own.

I have also provided a few memory files that you can use. These, along with the starter framework, are available on the CSLab Linux systems in
/home/jteresco/shared/cs324/labs/mipscontrol.

Related Questions

In addition to the software you develop, you should include a file rq.txt in your submission with your responses to the following questions:

1. Relate the simulators we have built to actual hardware implementations. What did you need to do in the simulation, particularly of the data path, to approximate the behavior of the hardware? Compare the complexity of a hardware implementation of control using the finite state approach with the microprogrammed approach.
2. How would you augment each component of the simulator to implement the following MIPS instructions: sll, addi, lui?

Submission and Grading

When you are finished, you are to submit your source code using the turnin utility. Detailed submission instructions will be provided.

In addition to the example programs provided, you should develop a few of your own programs to make sure you test all required functionality. Please include your tests in your submission. I will develop my own tests, will use your submitted tests, plus the ones I provided, to aid in grading.