Computer Science 220
Assembly Language & Computer Architecture

Fall 2011, Siena College

Home     Syllabus     Schedule

You may work alone or in groups of 2 or 3. Everyone should inform me via email by Friday, December 2 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. Should you choose a different language, you should follow the same organization of the code as described below and as provided in the C starter code.

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

A starter for the datapath simulator is given 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.

Each component should be simulated using only the inputs available to it and providing only the outputs it computes. For example, you might be able to look at the opcode of the instruction to determine which ALU operation is to take place, but the ALU must not examine any part of the instruction. It should determine its operation based on the output value of the "ALU Control" unit, it should take its operands from the "Read Data 1" output line and the "ALUSrc" multiplexer's output line, and should produce its results, the ALU result and the Zero output, without knowing or caring how or by whom those will be used.

Each component should also be simulated regardless of whether it is actually needed by the instruction being executed. For example, only the beq instruction will ever use the result of the ALU that adds PC+4 to the branch offset, but that will be computed every time by the hardware, so it should be computed every time by your simulation.

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 (olsen) in my shared area under labs/mips-single.

Test Cases

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

The starter includes a C program in asmhelper.c that may be useful to you as you convert MIPS instructions from their mnemonics and register numbers to the 32-bit hexadecimal numbers that represent those instructions.

Related Questions and Bonus Opportunity

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 and main ALU, 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, or, bne and nor? (For 1 lab bonus point each, you can implement any or all of these and provide appropriate test cases to demonstrate them.)

Submission and Grading

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

By 4:00 PM, Monday, December 12, 2011, please submit your source code (include all source and header files and your Makefile, but no object files, class 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.