Assumptions Pipeline Model NOTES Simulator Skeleton Code Sample Test Code and Sample Output Some Modifications Before Starting The Assignment Submission InstructionsG22.2243 Spring 2006 G22.2243: High Performance Computer Architecture SimpleScalar Assignment #1 (Due: February 15, 2006) This exercise is meant to help you better understand how pipelines function and to further familiarize you with the SimpleScalar 3.0 toolset. Assumptions For the purposes of this exercise, we are assuming the following: • Perfect instruction cache (no I-cache misses) • Perfect data cache (no D-cache misses) • No branch prediction • Split-phase register access for the writeback (WB) stage. This means that writes to registers occur in the first half of the clock cycle, and reads occur in the second half. The above assumptions mean that for the moment, we will not add cache or branch predictor functionality to the simulator (that is left for subsequent assignments). Therefore, for now, no stalling will be required in the fetch stage (IF) for instruction cache misses, or in the memory stage (MEM) for data cache misses. When branches occur, stalling will be required until the branch condition and target are resolved, which in our pipeline will be the execute stage (EX). Pipeline Model Other than the above assumptions, the pipeline we will be modeling is the 5-stage pipeline described in Hennessy and Patterson, Appendix A, with the main difference being that branch resolution is in the EX stage rather than ID. The following is a brief description of the pipeline stage functionality: • IF – instruction fetch from memory based on PC+4 or PC provided by branch resolution. • ID – instruction decoding, hazard detection, and register fetch. • EX –ALU and other computation operations, memory effective address calculation for memory instructions, branch resolution. • MEM – perform loads/stores to perfect D-cache using address calculated in EX. • WB – writeback of results to register file and instruction retirement. NOTES 1. For the IF stage we are assuming a perfect instruction cache (icache) which will always have the instruction we are looking for. This assumption is not true in a real processor: if the I-cache doesn’t contain the required instructions we may have to go out to memory to fetch the instruction, requiring us to suffer a cache miss penalty. However, assuming a perfect I-cache simplifies the assignment significantly. In a subsequent assignment, we will add caches and account for miss penalties in both the IF and MEM stages. 2. The decode stage, ID, takes the instruction passed from fetch and decodes it, determining what type of operation it is. Because of the design of SimpleScalar, in the first couple of assignments, we will actually completely execute the instruction from the standpoint of functional simulation in the decode 1G22.2243 Spring 2006 stage. The EX and subsequent stages merely exist for accurate modeling of timing. We must still write appropriate information into the latches so that we can model the pipeline behavior. 3. wb_finished_s: An extra pipeline latch is included in the code provided with this assignment. It is not a part of the behavioral model, but is merely there to keep information about what actions the WB stage has just completed. Simulator Skeleton Code 0. Download the code distribution for this assignment from: /home/mb/CompArch/assign1.tar 1. Upon unpacking this distribution (as described in the Assignment 0 handout), you should see a file, sim-pipe.c, which is a slightly modified version of sim-base.c from Assignment 0. sim-pipe.c contains a few hints on how to proceed with the assignment. 2. The basic thing to note is that there are 5 functions corresponding to the 5 stages of the pipeline, and that several structures have been provided to serve as the inter-stage latches (or pipeline registers in Hennessey and Patterson terminology). The main simulator loop simulates as one cycle: WB, MEM, EX, ID, IF. (traversing the stages in backwards order allows reading of a latch by a later stage in the pipeline before it is overwritten in the current cycle of simulated execution). 3. The following is the code for the stage latch: /* naming convention follows H&P latch name convention */ struct stage_latch { int busy; /* latch stage is busy */ md_inst_t IR; /* instruction bits */ md_addr_t PC; /* PC */ md_addr_t NPC; /* the new PC */ md_addr_t addr; /* mem address to read or write */ int out1; /* output 1 register number */ int out2; /* output 2 register number */ int in1; /* input 1 register number */ int in2; /* input 2 register number */ int in3; /* input 3 register number */ enum md_opcode op; /* decoded op code */ int will_exit; /* will this inst force the pgm to exit */ } if_id_s, id_ex_s, ex_mem_s, mem_wb_s, wb_finished_s; This is the information the instructor feels might be necessary to have available for the pipeline you are simulating. You may augment this structure if you feel you need additional information in any of the stages. out1-2, and in1-3 are provided for hazard detection purposes. machine.def (linked to target-pisa/pisa.def) names the inputs and outputs for each instruction. The DEFINST macro included in sim-pipe.c will allow you to gather the necessary input and output register information needed for hazard detection. will_exit is provided as a measure to prevent cycle miscounts due to the fact that we will actually be executing instructions in the ID stage. will_exit is basically a variable that will prevent the exit system call in the program (signalling the end of the program) from being executed until the WB stage. This is a slight violation of the normal behavior of our pipeline, but if we allow the exit system call to execute in either ID (for SimpleScalar) or EX (for a real pipeline), the program will terminate without allowing the exit instruction to reach the WB stage when it will truly have 2G22.2243 Spring 2006 been “completed.” Not tracking this case means that we will have under-counted the total number of cycles to complete the program. Sample Test Code and Sample Output 1. Assembly Code Programs. Three small sample assembly code programs: raw.S, branch.S, and branch2.S have been provided as sample tests for you to use during your simulator development. To compile these, simply use