Microprocessor Architecture Project
Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: THEend8_
ECE463/563 – Microprocessor Architecture Project
The goal of this project is to design and implement a C/C++ cycle-accurate simulator of a dynamically
Objective Microprocessor
The goal of this project is to design and implement a C/C++ cycle-accurate simulator of a dynamically scheduled processor implementing the Tomasulo algorithm with Reorder Buffer.
Students taking the course at the undergraduate level (ECE463) do not need to support store instructions (SW and SWS) in their simulator, while students taking the course at the graduate level (ECE563) will need to support store instructions as well.
Code organization Microprocessor
The project2_code.tar.gz archive contains C and C++ code templates for the simulator, as well as test cases to validate its operation. ECE563 students are required to use C++ code templates.
In order to extract the code in a Linux environment, you can invoke the following command:
tar –xzvf project2_code.tar.gz
This will create a project2_code folder containing two subfolders: c and c++, the former containing the C templates and the latter containing the C++ templates. The content of these two subfolders is very similar.Microprocessor
The c and c++ folders have the following content:
-
h/sim_ooo.cc (or sim_ooo.c): code templates for the dynamically scheduled processor’s simulator. These are the only files that you need to modify to implement the simulator.
-
Test cases: test cases to validate the operation of the dynamically scheduled processor’s simulator. This folder contains five test cases. For each of them, you will find two files: Test caseN.cc and Test caseN.out. The former contains the test case implementation, and the latter the expected output of the test case. You should not modify any of the test case files. We recommend writing your own test cases to verify the functionality that is not covered by the test cases
-
Makefile:Makefile to be used to compile the The use of this Makefile will cause an object file (.o) to be created for each C or C++ file that is part of the project. If the compilation succeeds, the binaries corresponding to the test cases will be generated in the bin folder. You don’t need to modify the Makefile unless you are working on the floating-point pipeline simulator or you are using a library that is not included by default.
-
asm: assembly files used by the test
-
bin: once you compile the code, the test cases binaries will be saved into this
Important Microprocessor
The sim_ooo.h header file is commented and contains details on the functions/methods that you need to implement. Be sure to read the comments in this header file carefully before you start coding.
Assumptions & Requirements
-
Data types and registers: The simulator operates on 32-bit integer numbers and 32-bit floating-point numbers stored in data memory. The simulator has 32 integer registers (R0-R31) and 32 single-precision floating- point registers (F0-F31).
-
Memories: The instruction and data memories are separated. The instruction memory returns the instruction fetched within the clock cycle, while the data memory has a configurable
-
Execution units and memory: The number of execution units and their latency must be configurable. The function init_exec_unit can be invoked at the beginning to configure the execution units used. Execution units can be of five kinds: INTEGER unit, floating-point ADDER, MULTIPLIER, DIVIDER and MEMORY (see exe_unit_t data type). The integer units are used for integer additions (and branches),subtractions and logic operations; the floating-point adders are for floating-point additions and subtractions; the multipliers are for integer and floating-point multiplications; and the dividers for integer and floating- point divisions. While the simulator can have multiple integer units, adders, multipliers and dividers, it will always have a single data memory unit (used by load and store instructions). While the processor can have multiple execution units of the same type with different latencies, in our test cases all the units of the same type will have the same latency. For simplicity, assume that all execution units are unpipelined. You can assume that the latency of the execution stage corresponds to that of the execution unit it Microprocessor
Microprocessor
4.Reservation stations and load buffers:
Besides load buffers, the processor should have three kinds of reservation stations (see res_station_t data type). Integer reservation stations (INTEGER_RS) feed the integer units, add reservation stations (ADD_RS) feed the floating-point adders, and multiplier reservationstations (MULT_RS) are shared by multipliers and dividers. Load buffers (LOAD_B) are used by memory instructions.
5.Initialization: the size of the data memory, the size of the reorder buffer, the number of reservation stations and load buffers, and the issue width can be configured when instantiating the simulator.Microprocessor
/* Instantiates the simulator
Note: registers must be initialized to UNDEFINED value, and data memory to all 0xFF values
*/
sim_ooo(unsigned mem_size, // size of data memory (in byte) unsigned rob_size, // number of ROB entries
unsigned num_int_res_stations, // number of integer reservation stations unsigned num_add_res_stations, // number of ADD reservation stations unsigned num_mul_res_stations, // number of MULT/DIV reservation stations unsigned num_load_buffers, // number of LOAD buffersMicroprocessor
unsigned issue_width=1 // issue width
);
-
Reservation stations, ROB, instruction window: the code template already contains data structures to model reservation stations, ROB and the instruction window. You can extend these data structures if you need, but you should not modify existing
-
Instructionssupported: the processor simulator needs to support the following instructions (which are listed in the h header file).
-
LW– Load word: Loads a 32-bit integer into a register from the specified address.
-
SW– Store word: Stores a 32-bit integer into data memory at a specified address.
-
ADD/SUB/XOR/AND/MULT/DIV – Add/Sub/Xor/And/Mult/Div: Computes the addition/subtraction/exclusive XOR/AND/multiplication/division of the values of two integer registers and stores the result into an integer
-
ADDI/SUBI – Add/Sub Immediate: Computes the addition/subtraction of the value of an integer register and a sign-extended immediate value and stores the result into an integer
-
BEQZ, BNEZ, BLTZ, BGTZ, BLEZ, BGEZ – Branch if the value of the register is =, ≠, <, >, ≤,≥Microprocessor
zero. JUMP – Unconditional branch.
-
LWS– Load word: Loads a 32-bit floating-point into a register from the specified address.
-
SWS– Store word: Stores a 32-bit floating-point value into data memory at a specified address.
-
ADDS/SUBS/MULTS/DIVS – Add/Sub/Mult/Div: Computes the addition/subtraction/
/multiplication/division of the values of two floating-point registers and stores the result into a floating- point register.Microprocessor
-
EOP – End of program: Special instruction indicating the end of the Asmentioned above, ECE463 do not need to support the SW and SWS instructions in their simulator.
8.Load/store instructions and dependencies:
Load and store instructions use the memory unit in different stages. Load instructions load data from memory in the execution stage and send their result to the reservation stations and ROB in the write result stage. Store instructions write data to memory at the commit stage and use the execution stage only for the computation of the effective memory address. Load and store instructions from/to different memory addresses do not conflict.Microprocessor
However, in a dynamically scheduled processor load and store instructions that operate on the same memory address can cause RAW, WAW and WAR memory hazards. Note, however, that since the ROB postpones writing memory to the commit stage (and this stage processes instructions in program order), in this case WAW and WAR dependencies are not an issue. So, your implementation should handle only RAW load/store dependencies occurring when a load operation follows a pending store operation to the same memory address. Your implementation should assume that, in this situation, the value that will be written to memory by the pending store should be bypassed to the load. To meet these requirements,
your implementation should process memory instructions asfollows: Microprocessor
-
When a load or store instruction is issued, the address field of the corresponding reservation station isfilled with the value of the immediate field of the instruction. The address field is updated with the effective memory address when the instruction is moved to the execution stage.
-
When multiple instructions are eligible to move from the issue to the execution stage, they are considered in program order. In addition, the effective memory address is computed in program order. Load instructions are not allowed to execute if preceded by potentially conflicting store
-
Store instructions are allowed in the execution stage only if the values of both their input registers are Note that,
-
while a less stringent timing is possible, this facilitates the handling of data bypassing between store and dependent load instructions.Microprocessor Architecture代写
-
Store instructions update the destination field of the ROB with the effective memory address when they enter the execution stage, and they update the value field of the ROB with the result that they will later write to memory in the write-result
-
In the presence of a pending store to the same address, data bypassing from the store to the load instructionis done when the load enters the execution In this stage, the load will save the value bypassed in the value2 field of its reservation station. In the write-result stage, the load will write this value in the reorder buffer.
-
Bypassing happens through the ROB (for the timing, see timing constraint on data dependenciesbelow).
-
Store instructions spend only one clock cycle in execution stage, and a number of clock cycles equal to the memory latency in the commit stage. In the presence of store-to-load data bypassing, load instructions spend only one clock cycle in the execution stage (since in this case they don’t use the memoryunit).Microprocessor
Note that data bypassing does not modify the timing of store instructions, but it only speeds up the processing of dependent load instructions.Microprocessor
9.Other timingconstraints:
-
If an instruction I uses a ROB entry, such ROB entry becomes available and can be used in the clock cycle after I
-
In the presence of a structural hazard on an execution unit, the execution unit is available to the second instruction in the clock cycle after the first instruction has finished using it. If an instruction I uses an execution unit in the execution stage, such execution unit is freed when I writes the result and is available to a different instruction starting from the next clock
-
If an instruction I uses a reservation station or a load buffer, such reservation station or load buffer is freedwhen I writes the result, and is available to a different instruction starting from the next clock
-
If an instruction J depends on instruction I, the data written by instruction I will be available to J in the clock cycle when I writes the result (say t), and (in the absence of data hazard), instruction J will be able to execute in the following clock cycle (sayt+1).Microprocessor
-
In the write result stage branch instructions write their target address in the result field of the corresponding ROB entry. If the branch is mispredicted, the target instruction of the branch is fetched in the clock cycle after the branch instruction commits. While a less strict timing is possible, this allows precise exception
-
CPI computation: The EOPinstruction should be excluded from the computation of the CPI.
Format of the output Microprocessor
The code template includes functions to print out the content of the data memory, the status of the registers (and, if their value is pending, the ROB entry that will update the register), the content of the reservation stations and load buffers, the content of the reorder-buffer, the status of the pending instructions (that is, the ones still in the ROB), and the instruction execution history (which shows the cycle-by-cycle execution of all instructions fetched during operation). These functions do not need to be modified, and they are invoked from the test case files.