Project 4

By Friday, February 26, please make a post on Piazza with your project choice, along with your group members.

• You can work in groups of 2-3. It is expected that projects involving 3 students will be of larger scope and greater difficulty than projects with 2 students.
• All students in the group will receive the same score.
• A technical report is required. There are no formal page requirements. The report length should be as much as needed but not more.
• You must turn in your source code and detail how to compile and use your code base. To streamline grading, all source code must compile in the course project virtual machine. If you need to install additional packages in the VM, please document it to simplify compiling on my end.

Throughout the quarter, we utilized the eSESC architectural simulator to conduct design space exploration of microarchitecture design for pipeline design, branch predictors, and caches. For the final project, you will have the option of building your own mini-simulator! In computer architecture research, new research ideas are typically first implemented in simulation to facilitate rapid design space exploration. Rather than hacking the eSESC simulator, you will instead implement detailed simulation of various microarchitectural components that we studied this quarter. You have the choice of building the following:

• Trace-driven cache simulator
• Trace-driven branch prediction simulator
• 5-stage pipelining simulator / visualizer
• Tomasulo simulator / solver

All projects must be configurable and must be able to take in different workloads/instruction traces. Preferably, project should be implemented in C/C++, Java, or Python. Details of each project choice follows.

For this project option, you will be designing a fully configurable L1 data cache simulator.

Instructions are typically inserted into simulators in two ways: execution-driven or trace-driven. Execution-driven simulators receive dynamic instruction streams from executing the binary and decoding the instructions (such as eSESC). To simplify the simulator requirements, we will use a trace-driven approach where we will take in a text file of instructions as input (hence, trace-driven). It is up to you to generate the instruction traces. You may have to hack into eSESC in order to print out/dump the instructions while running a workload.

Due to time constraints, you can use the traces provided at https://www.cis.upenn.edu/~milom/cis501-Fall12/traces/trace-format.html. If you will pre-process the traces in any way before feeding it into your simulator, please also turn in your pre-processing script. Similarly, if you have any post-processing scripts, turn that in too.

Note that in order to simulate the cache, just the load/store instructions are sufficient for the trace. Representing the trace in this form can reduce the size of the instruction trace.

The cache must be configurable using a configuration file. The following parameters must be configurable:

• Cache block size
• Cache size
• Associativity
• Replacement policies (Must implement: Random, LRU, FIFO. You can implement more policies if you desire.)

You can assume a cache hit time of 1 cycle, and assume a L1 miss would result in an additional 100 cycles to fetch the block from L2.

Must be able to measure basic cache statistics such as:

• Total number of cache accesses
• Cache hits
• Cache misses
• Average Memory Access Time
• Other cache statistics would be nice to have too.

For this project, you will be designing a configurable branch predictor simulator.

Instructions are typically inserted into simulators in two ways: execution-driven or trace-driven. Execution-driven simulators receive dynamic instruction streams from executing the binary and decoding the instructions (such as eSESC). To simplify the simulator requirements, we will use a trace-driven approach where we will take in a text file of instructions as input (hence, trace-driven). It is up to you to generate the instruction traces. You may have to hack into eSESC in order to print out/dump the instructions while running a workload.

Due to time constraints, you can use the traces provided at https://www.cis.upenn.edu/~milom/cis501-Fall12/traces/trace-format.html. If you will pre-process the traces in any way before feeding it into your simulator, please also turn in your pre-processing script. Similarly, if you have any post-processing scripts, turn that in too.

Note that in order to simulate branch prediction, just the branch instruction pc and the true branch outcome is required. Representing the trace in this form can reduce the size of the instruction trace.

This step is similar to the Trace-driven Cache Simulator project. Feel free to help each other out on Piazza when running into difficulties.

At minimum, the branch predictor should implement the following features:

• 1-bit, 2-bit, n-bit predictors (Would be great if you can take 'n' as a configuration)
• Global history buffer size
• (m,n) predictor (aka correlating, 2-level predictor)
• Tournament Predictor (for groups of 3)

Should provide basic branch predictor statistics, such as misprediction rate, and total number of branches.

For this project, you will be designing a configurable 5-stage pipeline simulator which can graphically output the pipeline status.

This project will take in simple assembly instructions in a text file. Your simulator will then decode the instructions to drive the 5-stage pipeline simulator. For simplicity, we can limit the ISA to the following instructions:

• ADD (ex. add r1, r2, r3 and add r1, r2, #4)
• SUB (similar to add)
• MULT (similar to add)
• DIV (similar to add)
• BRA (ex. bra r1, r2, LABEL and bra LABEL ←- non-conditional branch)
• LD/ST (ex. ld r1, 8(r2) and st r1, 0(r2) )

Furthermore, we can limit the number of architectural registers to 10 (r0-r9).

The following features must be implemented and can be configured on/off:

• Full Forwarding
• Register Bypassing
• Branch predicted not taken/taken by default
• Stage where branches are taken
• Stage where branches are resolved

Graphically output the space-time diagram of the pipeline. Essentially, this project will be an automated solver for Problem 2 of Exam 1.

For groups of 3, it would be great to have an interactive 5-stage pipeline visualizer, or even a webpage for future students to use as a learning too!

For this project, you will be designing a configurable Tomasulo algorithm simulator.

This project will take in simple assembly instructions in a text file. Your simulator will then decode the instructions to drive the Tomasulo simulator. For simplicity, we can limit the ISA to the following instructions:

• ADD (ex. add r1, r2, r3 and add r1, r2, #4)
• SUB (similar to add)
• MULT (similar to add)
• DIV (similar to add)
• BRA (ex. bra r1, r2, LABEL and bra LABEL ←- non-conditional branch)
• LD/ST (ex. ld r1, 8(r2) and st r1, 0(r2) )

Furthermore, we can limit the number of architectural registers to 10 (r0-r9).

The following parameters must be configurable:

• Number and type of execution units (ex. Memory Unit, Adder Unit, Mult/Div Unit, Branch Unit)
• Execution time of execution units (ex. Adder unit takes 2 cycles, Mult/Div Unit takes 20 cycles, etc.)
• Number of reservation stations for each execution unit resource
• Speculation
• Size of ROB

Output in table form the solution for the Tomasulo Algorithm. Essentially, this is an automated solver for Problem 3 of Exam 1.

For groups of 3, it would be great to have a Tomasulo visualizer (like the powerpoint animation), or even a webpage for future students to use as a learning too!

In addition to the default project options, there is an open-ended project option. You can freely pick a project as long as the project is microarchitecture related (optimizing applications for specific architectures do not count!).

Example projects include: (please contact me for more details if interested)

• Implementing data prefetching in eSESC
• Implementing Compiler-optimizations
• Designing microbenchmarks to identify real-machine cache/memory architecture configurations
• GPGPU microarchitecture research projects using GPGPU-Sim simulator.
• Emulating non-volatile memories
• Modeling (Reliability, Power, Thermal)

If you choose your own architecture project, please contact me first for approval.