Building a Simulator for a RISC Architecture (MIPS) Pipeline

Questions:

This project is designed to help students to understand the pipelining on a RISC architecture (MIPS), pipeline hazards, and hazards mitigation techniques including forwarding and stalling. Students will gain programming experience in C.

Your team of 2 students will build a simulator of a (5-stage pipelined) MIPS in C. This simulator will read a binary executable file containing a sequence of MIPS instructions and simulate their execution in stages in a (pipelined) MIPS processor.

Input
Your simulator will read a binary executable file. It is of size 1KB and consists of 512B of data segment followed by 512B of text segment (offset 0x200). Do not try to open this file as it causes an error. Assume big-endian. Assume input files do not contain any errors.

Registers
The user can use any of the 32 MIPS registers (0-31). Please note that $0 is read-only and should always contain the value 0. Your simulator will need to include a register file (e.g., an array of 32 integers) that maintains the values of all the 32 registers and updates the registers as the instructions are executed.

Data segment
The data segment is of 512B and the only form of data will be integer numbers (4 bytes long). I.e., there can be at maximum 128 integer data in the data segment. The data will not contain any other form of data such as string (ascii characters) or floating point numbers. When the program sees load or store instructions, the address will resolve to access one of these 128 integer data. Therefore, as execution proceeds, loads (lw) can read from the data segment and stores (sw) can write to the data segment.

Text segment
The text segment is of 512B, i.e., there can be at maximum 128 MIPS instructions because each MIPS instruction is 4 bytes long. However, due to the presence of branches and jumps, some instructions will be executed multiple times. The text segment will only contain the following MIPS instructions. 

The ‘halt’ instruction indicates the end of the program but note that it is not an actual MIPS instruction.

Note that branch target will be contained in the program. In other words, it does not go beyond the 512B boundary. Since the text segment begins at 0x200, this means the targets will be in the range of 0x200 ~ 0x400.

Please note the use of labels in the branch (beq and bne) instructions. You will need to calculate the branch target based on the following relationship.
Addr(Label) = Addr(branch_instruction) + 4 + immediate(16 bits)*4 

Objectives

Note that this file begins with the data segment (512 bytes) followed by the text segment (512 bytes). The data segment contains two non-zero data at location 8 and 12 and the data is 1 and 2, respectively, and the first instruction is “20010008” which indicates an ADDI instruction. In general, when you execute a program, OS reads the program executable file and loads it into memory. You can assume the 1KB file mentioned above is an executable file and thus is loaded.

Therefore, the 512 bytes of data in the data segment is loaded into Memory[0~511]. The two nonzero data can be explained as Memory[8] = 1 and Memory[12] = 2. The 512 bytes of text segment is loaded into Memory[512~1023]. The first instruction, “20010008” (ADDI) is thus at Memory[512].

Output
Your simulator should show the followings for every cycle of program execution until it encounters an HALT instruction.
Clock cycle count and the value of PC
Data memory words (the first 16 only out of 128 words)
Registers ($0 ~ $15 only)

Testing
Part of the process of developing a good software artifact is thoroughly testing the artifact. The sample test cases, while extensive, do not cover all the possible combination of instructions your program could encounter.

For this project, you are required to develop your own suite of test cases. You can write anywhere between 1 (very long) and 10 (somewhat small) test programs, using the reduced instruction set for this project) to ensure the quality of your simulator. The quality of the test suite will be determined by how many of our reduced set of instructions are tested and how varied the tests are.

For example, testing if the simulator works for BEQ for both the equal and not equal cases, and forward and backward branching, and all combinations of these, would get a better grade than just testing for one case of BEQ.

Submission and Grading
Each group submits the source code as a single file: simulator_lastname1_lastname2.c (all lower case). The file should begin with comments with students’ names and CSUIDs and list CLEARLY all the instructions and directives your program does NOT handle along with all known issues of your program (those that are not implemented, those that are implemented but not work correctly, etc.).

Your submitted C program will be compiled and run on a conventional linux machine with the following commands, where test.out is a binary executable file (1KB), as described below: $ gcc [-std=c99] simulator.c $ ./a.out test.out Make sure your program is compiled and run okay under a conventional linux machine using “gcc”. You should not rely on any special compilation flags or other input methods.

You must submit before 11:59 PM on October 6 (October 29 for Project 2 and November 17 for project 3) to get full credit. Late submissions will be accepted for 10% off per day up to three additional days. Automatic plagiarism detection software will be used on all submissions. Any cases detected will result in a grade of 0 for both students, reduction of the overall grade by one letter grade, and a report will be sent to Academic Affairs.