Implement Step by Step Simulator for Tomasulo Algorithm - Project | CDA 5155, Study Guides, Projects, Research of Electrical and Electronics Engineering

Material Type: Project; Class: COMPU ARCHITECT PRIN; Subject: COMPUTER DESIGN/ARCHITECTURE; University: University of Florida; Term: Spring 2002;

Typology: Study Guides, Projects, Research

Pre 2010

Uploaded on 09/17/2009

koofers-user-f4v
koofers-user-f4v 🇺🇸

9 documents

1 / 5

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CDA 5155
Spring 2002
Project Part 2
Date Assigned: March 7, 2002
Due Date : April 17, 2002 at 11:59pm
(A small part is due on March 21, 2002, read “Points to remember”)
In this part of the project we will implement a step-by-step simulator for the Tomasulo
Algorithm. The description of the hardware structure and related pipeline structure is
given below. In this project we modify certain details of the pipeline execution. However
the basic structure for Tomasulo algorithm in fig 4.12 will be applied.
You have to consider only the instructions given below:
ADD, ADDI, SUB, SUBI
MULT
SW, LW
SLT, SGT, SLE, SGE, SEQ, SNE
SLL, SRL, SRA, SLLI, SRLI, SRAI
J
BEQZ, BNEZ
TRAP
The description of the Tomasulo Algorithm using floating point instructions as examples
on Pgs 251- 262 apply to integer instructions also for our implementation of the
simulator.
The hardware profile that you should consider is:
Functional Unit (FU) Number of FU
INTEGER 3
MULT 2
Buffers (BUF) Number of BUF
Load 3
SW 1
Number of Common Data Buses
(CDB)
4
pf3
pf4
pf5

Partial preview of the text

Download Implement Step by Step Simulator for Tomasulo Algorithm - Project | CDA 5155 and more Study Guides, Projects, Research Electrical and Electronics Engineering in PDF only on Docsity!

CDA 5155

Spring 2002

Project Part 2

Date Assigned: March 7, 2002

Due Date : April 17, 2002 at 11:59pm

(A small part is due on March 21, 2002, read “Points to remember”) In this part of the project we will implement a step-by-step simulator for the Tomasulo Algorithm. The description of the hardware structure and related pipeline structure is given below. In this project we modify certain details of the pipeline execution. However the basic structure for Tomasulo algorithm in fig 4.12 will be applied. You have to consider only the instructions given below:  ADD, ADDI, SUB, SUBI  MULT  SW, LW  SLT, SGT, SLE, SGE, SEQ, SNE  SLL, SRL, SRA, SLLI, SRLI, SRAI  J  BEQZ, BNEZ  TRAP The description of the Tomasulo Algorithm using floating point instructions as examples on Pgs 251- 262 apply to integer instructions also for our implementation of the simulator. The hardware profile that you should consider is: Functional Unit (FU) Number of FU INTEGER 3 MULT 2 Buffers (BUF) Number of BUF Load 3 SW 1 Number of Common Data Buses (CDB)

The detail function of the pipeline stages are as follows. IF: Instruction fetch.  In each clock cycle we fetch one instruction and put the instruction into the instruction register (IR), same as the one we studied in chapter 3. No instruction is fetched when a previous instruction stalls in the IF stage, i.e. that instruction does not enter the Issue stage. IS: Instruction Decode / Issue Stage.  Only one instruction can be issued per clock cycle. If any instruction stalls in IS stage then the next instruction stalls in IF stage.  Handling loads/stores: o Loads are issued whenever there is a load buffer entry (Load unit) that is available and there is no store in the store buffer entry (Store unit). A load will not be issued if there is no free load buffer (Load unit) or if the store buffer is not empty. o A store is issued whenever there is a store buffer entry (store unit) that is free and there are no loads in the load buffer (Load unit). A store will stall if the store buffer (store unit) is not free or if the load buffer is not empty. {We have only one store unit, more on this later}  Handling ALU instructions o An ALU instruction is issued if the reservation station it requires is available, else it stalls in IS stage.  Handling Conditional Branch o A conditional branch instruction is issued if the reservation station (INTEGER) it requires is empty. No instruction following the branch enters the IS stage until the branch is resolved, i.e. the instruction following the conditional branch stalls in the IF stage. A conditional branch is resolved at the end of its execution stage at which time it sets a flag called the ‘branch resolved’ flag. The instruction (the one following the branch) that stalled in the IF stage keeps checking the ‘branch resolved’ flag at each clock cycle and enters the IS stage when it finds the flag set.  Handling Unconditional Branch o An unconditional branch (J) instruction is issued if the reservation station (INTEGER) it requires is empty. No instruction following the branch enters the IS stage until the jump is executed, i.e. the instruction following the unconditional branch stalls in the IF stage. An unconditional branch is resolved at the end of its execution stage at which time it sets the same ‘branch resolved’ flag. The instruction (the one following the Jump) that stalled in the IF stage keeps checking ‘branch resolved’ flag at each clock cycle and enters the IS stage when it finds the flag set.  Handling Trap o A trap instruction stalls in IS stage if any of the reservation stations or the load buffers or the store buffer is not empty. The trap instruction is issued only if the reservation stations (including the load buffers and the store buffer) are all empty. The program terminates after the Trap is issued. Addition details of issue stage can be found on page 254 and 259 of the textbook.

WB: Write Result Stage  Details of this stage are given on page 254 and 259 of the textbook. When successive updates to a register appear, only the last one is actually used to update the register. (See page 252, paragraph 2, line 9)  In this stage the result that is generated by the instruction is put onto the CDB. All the reservation stations (including the load and store buffers) view this result at the end of the instruction’s WB stage. Therefore, the dependent instructions should be able to start their EX stage in the next cycle.  SW and Branches (conditional and unconditional) have a dummy WB stage, in which it does nothing.  Remember we have 4 CDB. Load and Store Units (Load Buffers; Store Buffers)  It calculates the source address for the load  It calculates the destination address for the store.  It maintains flags to allow out of order execution and enforce the data dependencies as illustrated in Fig 4.  It records the active load/store to block or allow future load/store for issuing. Input Description:  Your program should take as input a binary file, map the entire input (including code and data) to a local data structure called MEMORY starting at location 100. (This is similar to the loader function). Then, your PC should be updated to the starting location of the code. Your simulator can then fetch the first 32-bit instruction, decode the instructions and simulate it through the pipeline according to the Tomasulo Algorithm mentioned above. Your simulator should continue until “TRAP 0” is encountered.  The internal data structures that you could use are an array for 32 registers, array for MEMORY, which has a starting location of 100.  Name your main code, which will take the binary file and produce the output as Tomasulo .java (c or cpp). Output descriptions: Your output should display on each clock cycle :  Cycle number x: (where x is the cycle number) Followed by 5 tables, namely ‘Instruction Status’, Reservation Stations’, ‘Register Status’, ‘Load Buffers’ and ‘Store Buffers’; exactly as shown on Pg 261 in Fig 4.12. After the program completes iteration and encounters the Trap instruction, you should display:  The total number of cycles your program took to execute the code  The values at data memory locations (first display all memory values) and then the register values.

Points to remember:  You can code in JAVA, C or C++ only.  Name your main program Tomasulo.  To run your program we will type Tomasulo [-o outputfile ] inputfile where outputfile if not given should be out.txt; the inputfile will be the binary input file.  Each student should submit a one-page description (this file should be the same for team members) of how the project is going to be divided within the team. This file is due by March 21, 2002 at 11:59pm. Your individual grade may be adjusted based on you carrying out your duty.  Include a README.txt (not .doc) file. This file should contain the group member names, ids and group number. It should explain the details on how your program needs to be executed i.e. the steps to be followed, right from the first to the last, to run the program at command line. It should also mention the work distribution among the team members. Among other things it should include the details of files you have written. It should also mention any shortcomings of your code (it is better that you let us know what your code cannot do, rather than we finding out the same; which will cause more deduction in points).  Note, at the beginning of your program, you should include a comment section to describe the major functions of your program as well as the way the project is partitioned among members in your team. You should also provide your names, ids, group number, the OS and hardware platform you have worked on, as well as the 'oath'. Remember, your program will be graded on either a CISE machine (Solaris/Sun) or a Windows NT/Intel PC.  Write a make file which compiles and generates the executable for your Tomasulo.java (or c or cpp). The executable should be called Tomasulo. Also allow 'make clean' to clean out all class/object files.  Include the sample binary input file along with your submission.  A new sample binary file, and its working will be given soon.  Submission Guideline:  jar all your files ( after doing a make clean) and submit it via CourseWorx before the deadline.