Computer Science 324
Computer Architecture

You may work alone or in groups of 2 or 3. Everyone should inform me via email by Friday, November 13 whether you intend to work individually or have formed a group.

You will need to implement two components that will be combined to construct the simulator:

1. The datapath simulator that simulates the components of the single cycle implementation (registers, memories, ALUs, multiplexers, shifters, sign extenders, and the connections among these).
2. The control simulator will provide the datapath with the correct set of control outputs to execute the given opcodes.

The datapath simulator is combined with the control simulator to produce a program that can execute simple MIPS programs. For each instruction the datapath updates the control with the current opcode, then queries the control to determine the appropriate behavior of each hardware component.

In order to allow interaction between independently developed datapath and control simulators, we must define the interface between the datapath 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.

The datapath simulator is to be implemented in the file mips-single.c. In order to keep busy work to a minimum, I am providing much of the infrastructure for the datapath, including definitions of the state components and a complete main execution loop. You will need to think carefully about how information flows through the datapath during an instruction's execution and simulate in a reasonable order. For example, you need to make sure you have read the values from the registers before you can use them as inputs to the main ALU. In a hardware implementation, we would need to take special care (some extra clock cycles, perhaps) to ensure that combinational components have time to produce the desired results and that registers and memory are written only when their inputs have the necessary values ready, but for our simulation we simply compute intermediate results in a reasonable order to get the correct effect of each instruction.

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

1. While we will pretend to have separate instruction and data memories for timing purposes, to keep our simulation simpler, there will be a single common memory underlying both.
2. 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.
3. 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.

Your simulator should include a debug/trace mode in which each instruction's execution is described in detail. Your output should include values for each connection between hardware components. Please run the provided executable to see the level of detail expected.

Your single cycle control implementation should be done in the file control.c. Control is quite simple for a single cycle implementation. 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!) based on the opcode.

The provided framework in mips-single.c includes a main program that takes the name of a memory initialization file. That file is loaded into 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" instructions (default 1).
• debug: enter debug/trace mode.
• quit: exit the simulator.

As with the MIPS instruction decoding lab (which may be worth looking back at, by the way), I will provide compiled object files (for Linux) 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 CS Lab systems in my shared area under labs/mips-single.

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

1. Relate the simulator we have built to actual hardware implementations. What did you need to do in the simulation, particularly of the datapath, to approximate the behavior of the hardware? In what order are your components simulated? What assumptions, if any, are you making about relative speeds of the components?
2. How would you augment each component of the simulator to implement the following MIPS instructions: sll, addi, lui?

When you are finished, you are to submit your source code (please include all C and header files and your Makefile, but no object files or executables) and your file rq.txt that contains your responses to the related questions, all by email as attachments to jteresco AT mtholyoke.edu.

Your program will be graded on how accurately it simulates the single cycle implementation and on the documentation of your simulator. A "working" simulator that executes the MIPS instructions without properly simulating the underlying datapath and control will be eligible for very little credit.

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 use my own tests, your submitted tests, plus the ones provided, to aid in grading.