CS Implementing the MIPS Processor with Pipelined Microarchitecture Solution

 Part 1. Preliminary Work (50 points)



Important Notes

    1. Assume that all Inputs are Correct. In all lab works, if it is not explicitly stated, you may as-sume that program inputs are correct.

Part 1.
In this part you will prepare a Design Report in PDF format named as:

StudentID_StudentFirstName_StudentLastName_SecNo_LabNo_REPORT.pdf

At the end of this lab, you will have implemented the pipelined MIPS architecture that can be seen in the file that is provided as PipelineDatapath.PNG (Notice that there is an early branch predic-tion in this pipeline. Hence, the branch resolution is done in the Decode stage.). Note also that there is no jump instruction implemented as well. Your Design Report should contain the following items:

    a) Cover page, with university name, department name, and course name and number at the top, ―Design Report‖, Lab # (e.g. 5), Section #, and your name and ID# in the middle, and the date of your lab at the bottom.

    b) [10 points] The list of all hazards that can occur in this pipeline. For each hazard, give its type (data or control), its specific name (―compute-use‖ ―load-use‖, ―load-store‖, ―branch‖ etc.), the pipeline stages that are affected.

    c) [10 points] For each hazard, give the solution (forwarding, stalling, flushing, combi-nation of these), and explanation of what, when, how

    d) [10 points] Give the logic equations for each signal output by the hazard unit, as a function of the input signals that come to the hazard unit. This hazard unit should handle all the data and control hazards that can occur in your pipeline (listed in b) so that your pipe-lined processor computes correctly

    e) [20 points] Write small test programs, in MIPS assembly, that will show whether the pipelined processor is working or not. Each of your test programs should be designed to catch problems, if there are any, in the execution of MIPS instructions in your pipelined ma-chine. Write:

 A test program with no hazards (to verify that there are no problems with the connec-tions in your pipeline etc.)

 A test program that has one type of hazard, and another, and another...
In the end, have at least 4 test programs (testing at least 3 different hazards) with their machine code (in hex) and MIPS code (written in your report).

You can use the student-written assembler tool available online to help you quickly implement your test programs (https://github.com/bilkentCraps/mips ). Remember that the goal of testing is to verify that all the instructions are fully working, and that all the instructions are working even in the pres-ence of hazards.

Part 2. Lab Work (50 points)

For the lab work, you only need to submit resulting code file in the txt format.

    a) [35 points] You are given a skeleton SystemVerilog code for your pipelined MIPS processor in the file PipelinedMIPSProcessorToFill.txt. The places in the code that needs to be modified are shown with comment blocks above them. Fill them to implement the

Pipelined Processor. You don’t need to follow the skeleton code point by point. If you think your design is better, you are welcome to try it in your code, as long as your version of the code works, too. Note that in the skeleton code register file is initialized to 0 on reset. That effectively means all register values are set to 0 at the beginning.

    b) [15 points] Now make a SystemVerilog testbench file and using EDAPlayground, simulate your Pipelined Processor by executing the test programs you wrote at Part 1-e). However, during lab day we will provide you with our test programs and grade your work based on those. The top_mips module will be the top module of your design. That is, your testbench should instantiate that module. You should not remove existing input-output vari-ables from that module as we will need at least those values for grading. Nevertheless, you are free to add more logic variables while testing your design. Present the results to your TA in the form of a waveform using waveform visualization functionality of EDA Playground. On the lab day, we might require you to add some logic variables to your top module so that we can see their values on the waveform.


Aim to complete lab part at home before coming to the online lab.

Part 6. Submit Your Code for MOSS Similarity Testing

    1. Submit your Lab Work MIPS codes for similarity testing to Moodle.

    2. You will upload one file. Use filename Studen-

tID_FirstName_LastName_SecNo_LAB_LabNo.txt

    3. Only a NOTEPAD FILE (txt file) is accepted. No txt file upload means you get 0 from the lab. Please note that we have several students and efficiency is important.

    4. Even if you didn’t finish, or didn’t get the MIPS codes working, you must submit your code to the Moodle Assignment for similarity checking.

    5. Your codes will be compared against all the other codes in the class, by the MOSS program, to determine how similar it is (as an indication of plagiarism). So be sure that the code you submit is code that you actually wrote yourself!

Part 7. Lab Policies (Reminder)

    1. As indicated in Lab1: Attendance is mandatory and the preliminary work is graded only if you submit your lab work with the observation/permission of your TA.

    2. You can do the lab only in your section. Missing your section time and doing in another day is not allowed.
    3. The questions asked by the TA will have an effect on your lab score.

    4. Lab score will be reduced to 0 if the code is not submitted for similarity testing, or if it is plagia-rized. MOSS-testing will be done, to determine similarity rates. Trivial changes to code will not hide plagiarism from MOSS—the algorithm is quite sophisticated and powerful. Please also note that obviously you should not use any program available on the web, or in a book, etc. since MOSS will find it. The use of the ideas we discussed in the classroom is not a problem.

Your lab attendance is tracked by the Zoom system. Please also see lab policies no. 1 item.