Project Proposal Format: The proposal should be in pdf format. It should be no longer than two pages in a single-column single-spaced 10pt Times font. Margins are one inch each (top, bottom and both sides).
Final Project Report and Code [14 points]: (Due Dec 15 at midnight) Your report should mimic a conference paper similar to the ones we covered in class. The report should include a title, author names, abstract, introduction, background, explanation of your project, evaluation results, a conclusion, references, and optional appendices. Your report should be no longer than 10 pages using the same format as your project proposal and progress report. Any extra material beyond 10 pages should be put in appendices. Please note that any material beyond 10 pages may not be considered for grading. As part of your final project submission, you also need to submit your project code. Instructions on final project submissions will be provided as we get closer to the project deadline. Important: Your project report Appendix should include a description of each project member’s contribution to the project code, report and presentation.
(1) Project report (in pdf).
(2) A README text file with a pointer to your project code and detailed instructions for how to run it. You need to give both instructors and both TAs permission to access your code.
(3) A pdf version of your project presentation.
For each of the projects described below, students will be graded based on the tasks that have been accomplished in the project. Each project will have two goals, and the grade will be based only on finished goals. If only one goal is accomplished, the maximum project score will be 50%. If both goals are accomplished, the maximum project score will be 100%. Note that these maximum levels do not mean that students will always achieve the maximum. The actual student score will be based on other aspects: Project proposal, progress report, presentation and final report/code.
Accurate branch prediction is critical to improve performance in superscalar processors. However, if a certain branch is frequently mispredicted, it could be better to stall instruction fetch until that branch is resolved. Explore existing work in evaluating branch prediction confidence, and implement branch confidence predictor techniques in gem5. Evaluate the performance for the configuration where you predict all branches, and different configurations where you place a confidence threshold on predicting branches and only predict branches above a certain confidence level. You need to implement and evaluate three of the branch confidence prediction techniques presented in prior work. Some references to consider:
Implement a branch predictor in gem5 that could predict two, three, and four conditional branches every cycle. Choose a technique from literature that could be used to predict many branches. Compare its performance and prediction accuracy to that of the bimodal predictor implemented in gem5. Some references to consider:
Implement the Perceptron branch predictor (Jimenez) in gem5. Compare its accuracy to the other predictors currently implemented in gem5. References to consider:
Implement a stride-based prefetcher (Chen and Baer) or any other data prefetcher you choose. You should use two implementations of the prefetcher: PC-based (where you issue prefetches when you detect patterns for the same PC), and data-address-based (where you issue prefetches based on strided addresses that miss in the cache). Compare performance, prefetching accuracy and coverage for different benchmarks.
Effective cache replacement policies can significantly reduce cache miss rates and improve performance. Recent research showed that it is beneficial to bypass the insertion of some blocks in the cache if they are not predicted to be reused. An example of such research is the winner of the cache replacement championship (http://www.jilp.org/jwac-1/online/papers/005_gao.pdf). In this project, you should implement a cache replacement policy with bypass in gem5, and compare its performance to the default processor and cache replacement policy already implemented in gem5.
Some recent research on caches have pointed out that many cache lines are DOA, and shouldn’t be allowed to stay in the cache for a long time. An example is in the paper “Sampling Dead Block Prediction for Last-Level Caches” . In this project, you need to implement a simplified version of a dead block predictor that predicts such blocks and either bypasses the cache or assigns low priority for them. You should compare your algorithm to the default cache replacement policy in gem5.
Some architectures use a single read and a single write port to the L1 data cache which might limit the amount of instruction-level parallelism available in a program in order to achieve fast cache access times. You should explore the performance of different benchmarks when the number of read and write ports is limited to 1, 2, 3, …etc. for a six-wide superscalar processor. Following this limit study, you should factor in the impact of access latency increase as you increase the number of ports.
Recent conferences at ISCA, MICRO, HPCA have included multiple kernel accelerators. Kernel accelerators are those that include minimal programmability and offload a particular kernel end-to-end. Implement one of these accelerators on the gem5 SALAM framework and evaluate the design. Some suggested accelerators
Publishable result
By definition, while DSAs seem incomparable to each other, they do adopt a common underlying common theme. Dally et al. and Hennessy and Patterson comment that while computation parallelism and density are important, DSAs must exploit locality and make few global accesses. Thus, most of the resources (area and energy) in current DSAs tend to be dedicated to organizing on-chip memory and fetching data from DRAM. DSAs exploit three main optimizations: i) DSA-specific data types The early wave of DSAs predominantly needed to supply regular loop nests with dense data. However, emerging DSAs work on non-indexed metadata-based data structures e.g., compressed sparse matrix~\cite{sparch}, graph nodes\cite{graphpulse}, or database indexes~\cite{walker}. ii) DSA-specific walkerslike CPUs, DSAs employ hardwired address generators and DRAM fetchers that maximize channel bandwidth. While address generators for DMAing dense arrays tend to be simple \code{base+offset}, state-of-the-art DSAs require complex walkers making referencing multiple elements. iii) DSA-specific orchestration Finally, DSAs explicitly orchestrate movement, overlap computation and maximize DRAM channel utilization. DSAs leverage domain knowledge to pack/unpack data on-chip.
Multiple ideas can be explored in this context
Phi, Coup. Replicate the works in these papers and figure out if DSAs can benefit from this. Create a general framework for DSAs to exploit. Simulators
Develop a framework for design space exploration to optimize dynamic updates in applications such as graphs. graphbolt
Benchmarks Machsuite(https://github.com/harvard-acc/ALADDIN/tree/master/MachSuite)
A number of custom DSAs have been created targetting specific algorithm kernels. However, the key challenge in a DSA is to figure out what to leave programmable. Pick your favorite application domain, study the cost of keeping something programmable or reconfigurable. The typical overheads of making a DSA programmable involves i) tcost of storing and retreiving the instructions from associated RAM ii) the cost of dynamically scheduling instructions to spatial resources. iii) the cost of transfering operands to the scheduled resources. The key benefit of making a DSA programmable is reusability and elimination of dark silicon i.e., many parts of the DSA remain active and are not underutilized during phases. For instance in a heterogeneous CGRA if the specialized PE is not-utilized the other associated components such as register files and routers also go underutilized. In a homogeneous CGRA such components tend to be shared and this enables better utilization. See this paper Databases. Queries
Prior references
Suggested application domains, image processing, tensor processing, security, databases.
Spectre v1 (https://spectreattack.com/spectre.pdf) exploits speculative execution to leak private data from memory. An expensive mechanism to defend against such attacks is by disabling speculative execution. However, recent research has explored mechanisms with much lower performance impact. In this project, you need to compare the performance impact in gem5 of two such strategies: Invisispec (http://iacoma.cs.uiuc.edu/iacoma-papers/corrected_micro18.pdf) and Speculative Taint Tracking (http://iacoma.cs.uiuc.edu/iacoma-papers/micro19_2.pdf).
…more ideas may be posted later.