Computer Science 220
Assembly Language & Computer Architecture

Fall 2010, Siena College

Home     Syllabus     Schedule

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

You may develop your simulator in any programming language (subject to approval if it is anything other than C, C++, or Java), but my starter files will be most useful to you if you program in C.

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.

Datapath/Control Interface

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.

Datapath Simulator

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.

Single Cycle Control

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.

Executing Programs

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.

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 (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 SoS Linux systems in my shared area under labs/mips-single.

Test Cases

While I have provided a handful of simple tests, they are neither comprehensive nor especially interesting. You are to develop at least 3 more interesting test cases that more thoroughly test your simulator (and mine) for correctness and completeness. These will be part of your submission and your grading. As an added incentive, up to 3 additional bonus points are available for test cases that are especially intereting (e.g.they actually compute something).

Related Questions

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? (For 3 lab bonus points each, you can implement these and provide appropriate test cases to demonstrate them.)

Submission and Grading

This lab is graded out of 40 points. Up to 12 additional bonus points are available.

By 3:00 PM, Monday, December 13, 2010, please submit your source code (include all C source 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 siena.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.

If you implement any extended functionality to be considered for bonus points, please include an additional file BONUS that describes what you have implemented and which of your test cases demonstrate the functionality.