EE 560 - Summer 2024 Digital Systems Design

Week 5

Overview

This lab is a continuation of the Lab 4. You should already have all the skeleton code necessary. Please refer to the lab folder `Labs/Lab04/ even though this is Lab 5.

This lab has 3 parts regarding Tomasulo 3. For this week, you need to complete:

1. Issue Unit
2. ROB
3. Dispatch

Prelab for all Tasks

Review the lectures slides in the shared folder pertaining to each component that you need to complete.

Overview and Structure of Various Parts

File Structure

All of the parts to the Tomasulo 3 labs are organized in a similar way.

• Source code that you need to complete is in the src/des/<part-name> folder where <part-name> is one of the parts are you are to complete (e.g. frl, bpb, etc.). Comments in the source code indicate the coding tasks you need to perform
• A completed testbench for each part is provided in the src/tb/<part-name> folder and is usually named top-tb-<partname>.vhd.
• Simulation via Questa/Modelsim should be performed in the appropriate sim/<part-name> folder. In each, there is a .do file that will perform all simulation of your design for various instruction streams that will exercise each component in potentially different ways.
• Components that we provide freely and which you do NOT need to modify are given in src/des/common
• Compiled instruction streams to be loaded into the processor’s instruction memory are in the src/tb/instruction_streams folder and can be viewed for reference (each file shows the assembly instructions it will run).

Signal Spy

To verify your design, testbench instantiates our full, golden processor design as well as your implementation of the component being tested. We then use the “signal spy” feature of Questa/Modelsim to feed the same input signals from inside our golden design to both our internal golden implementation as well as your design. We similarly take out the internal outputs from our golden implementation of that component and compare them to the outputs you produce in each cycle, looking for (and logging) mismatches. See the diagram below.

If all goes, well your outputs will match our golden results in each cycle and the logs will be empty. Your simulation folder will have two output files: TomasuloCompareTestLog.log and Tomasulo_do_file_log.txt.

So after you follow the simulation steps described in detail below, you can look at the TomasuloCompareTestLog.log to ensure it is empty.

And, similarly, look at the Tomasulo_do_file_log.txt to see the results from each instruction stream that we use to test your implementation.

Simulation

So for each part described below, you will complete the various incomplete portions of the design code and then simulate it to ensure it matches our expected, golden design. To perform the simulation of a given part (we will use the free register list, frl, as an example), follow the steps outlined below.

• Open Questa/Modelsim
• You do not need to make a new project but simply use the File..Change Directory menu option to open the sim/<part-name> (e.g. sim/frl) folder wherever it is on your file system.
• Run the simulation by simply typing the command do <part-name>.do (e.g. do frl.do) at the Questasim prompt. It will run the full set of instruction streams (over 20) one at a time, which could take a few minutes. The simulation will produce a summary listing the results of each instruction stream in the same folder named Tomasulo_do_file_log.txt. Open it and see if there are mismatches or whether all instruction streams passed. (Note: If all streams passed a message at the bottom of the file will tell you to go celebrate!). If all passed, you are done. Move on to the next part.
• If you had mismatches, then you can look at the file TomasuloCompareTestLog.log for the mistmatches of the LAST stream run. This may not be helpful since it is only the last stream, so at this point use the infor from Tomasulo_do_file_log.txt to pick a stream to debug, and then modify the frl.do file as described below.
  • Around one-third of the way into the .do file you will find a for loop iterating through all the instruction streams. Copy that for loop to another file or document as a backup (to restore it later). Then change the for loop to have just the one instruction stream you want to debug. For example, change the lines to: foreach item {i_fetch_test_stream_add.vhd }{, all on 1 LINE and ensure you keep the open brace { for the body of the for loop.
  • Add the command pause before the quit -sim line at the end of the .do file to ensure you have time to inspect the waveforms, etc. (Note: When you run the .do file and hit a pause statement, just type resume to continue execution).
  • Then rerun the .do file (e.g. do frl.do) to run the specific instruction streams and view waveforms, etc. after it finishes and debug your design.
  • More advanced users may consider simulating multiple streams at once by updating the for loop to have a subset of the list, ensuring the syntax is correct. (Note: Commenting out # lines in the middle of the list of streams in the for loop doesn’t work as cleanly, so it’s best to just delete the lines you don’t want, which is why we had you make a copy in another document so you can easily restore it later). You can add a pause command at the end for the for loop’s body to see the simulation results before going on to the next stream.
  • Once you believe your code works, paste back the full instruction stream list to the for loop, remove any pause commands, and rerun as described above.

Other Notes

• If an error occurs when running during a simulation, you can try to fix it and rerun the .do file, but if get a message that the TomasuloCompareTestLog.log or other file is open and cannot be deleted, you will need to EXIT Questa/Modelsim completely, and restart it and change directory back to the appropriate folder.

Part 1: Issue

Look in the issue subfolders in src/des/, src/tb, and sim for relevant files.

Procedure

There are 6 subtasks outlined the skeleton code that you need to complete. They include:

• initializing our CDB_slot shift register to track reservations for the CDB as well as the LRU_bit for prioritizing competing Int and Load issue requests.
• Shifting the CDB_slot each cycle
• Updating the LRU_bit appropriately on each cycle
• Updated CDB_slot to reserve a slot on the CDB for a requesting DIV instruction
• Updated CDB_slot to reserve a slot on the CDB for a requesting MUL instruction
• And, finally, using the issue requests, LRU_bit and CDB_slot bits to generate the issue signals back to each requester (i.e. issue queue / LS-Buffer)

Submission

• Online Submission: Copy over the following files to your SCF account
  • issue.vhd (from src/des/issue folder)
  • names.txt
• Then run the following submission commands.

submit -user ee560 -tag t3-issue issue.vhd names.txt

Part 2: ROB

Look in the rob subfolders in src/des/, src/tb, and sim for relevant files.

Procedure

There are 2 subtasks outlined the skeleton code that you need to complete. They involve:

• Generating the internal commit_s signal (that is assigned to the Rob_Commit signal) that describes the conditions when we can commit/graduate an instruction from the ROB.
• (Task 2.1) Generate the Internal_Depth signal which indicates the depth at which we are flushing when a mispredicted branch or jr $31 occurs, AND (Task 2.2) then use that value and whatever else is needed to update the bottom pointer (i.e. WP).

Submission

• Online Submission: Copy over the following files to your SCF account
  • rob.vhd (from src/des/rob folder)
  • names.txt
• Then run the following submission commands.

submit -user ee560 -tag t3-rob rob.vhd names.txt

Part 3: Dispatch

Look in the dispatch subfolders in src/des/, src/tb, and sim for relevant files.

Procedure

There are 6 small subtasks outlined the skeleton code as Task1-Task6. They involve:

• Updating the sign-extension of the branch address
• Determining the branch_target_addr and determining the Dis_JmpBrAddr (the next PC fetch address for jumps/branches that Dispatch can determine).
• Complete the logic for the sel_que_nearly_full signal by determining the type of instruction and whether the appropriate issue queue is nearly full.
• Determining the destination architectural register number to send to the CFC
• Generate the RegWrite control signal to issue with the instruction
• Update the stall logic to set the jr stall bit when appropriate and also the condition to clear it.

Submission

• Online Submission: Copy over the following files to your SCF account
  • dispatch.vhd (from src/des/dispatch folder)
  • names.txt
• Then run the following submission commands.

submit -user ee560 -tag t3-dispatch dispatch.vhd names.txt