Design and implement a RISC-V-compatible processor simulator At the minimum, your processor must be able to execute simple RISC-V (RV64IM) programs (pre-compiled testcases and the RISC-V tool-chain will be provided), via a 5-stage pipeline, multiple functional units with varying latencies, and direct mapped instruction and data caches.
| Processor + cache | Points |
|---|---|
| 5+ stage pipeline + direct-mapped caches | 50 pts |
| 5+ stage pipeline + set-associative caches | 60 pts |
| Super-scalar 5-stage pipeline, set-associative cache | 70 pts |
| Super-Scalar, Out-of-order, Set-Associative Caches | 80 pts |
| Extra Credit (Can add up to > 80 points) | Points |
|---|---|
| Any of the above + Multi-cycle divider and pipelined multiplier | +5 pts |
| Any of the above + TLBs | +10 pts |
| Any of the above + Branch Prediction | +10 pts |
| Any of the above + Speculative Execution | +10 pts |
| Any of the above + SMT | +20 pts |
I will provide the code for the multi-cycle divider and pipelined multiplier as part of the project sekelton code. Please read the code and comments carefully to make sure you know how to use them. A pipelined multiplier accepts a new multiplication operation every cycle but generates the result after multiple cycles (just like a normal pipeline) A multi-cycle divider accepts a new operation when the “start” signal is given and takes “n” cycles to finish it. After that, it can accept another operation.
You can clone the code from GitHub. You should implement your processor by modifying the existing SystemVerilog files and adding new ones. top.sv is the top-level SystemVerilog file and Core.sv is your processor core. The README file contains more detailed instructions.
Project Report In addition to submitting your code (via a private GitHub/BitBucket repository), you should also submit a short report (ideally, no more than 3 pages). It should provide a high-level overview of your processor pipeline, the implemented features and details of each pipeline stage. In particular:
A well-organized and comprehensive report can substantially improve your project grade. It can help me identify important aspects of your design that we might overlook otherwise. You should email me your reports by the project deadline.
Target Instruction Set Your processor should implement the user-mode (non-privileged) subset of RISCV with only Integer and Multiplication/Division instructions – RV64IM. The latest ISA specification can be found here You can ignore all other parts of the ISA in the manual. Specifically, your processor needs to implement all the instructions (and the requisite architectural state) described in the following sections of the manual:
Traps and Interrupts Your processor need not deal with external interrupts. It should treat all “exceptions” (i.e., traps caused by instructions) as precise—no deferred interrupts. Your implementation should correctly check for and generate all the exceptions described in the semantics of your implemented instructions.
Virtual Memory and MMU Your processor need not include any virtual memory support. Hence, you don’t need to implement an MMU and can ignore the issues related to the Address Space Identifiers (ASI). Implementing a TLB is extra credit.
Hardware designers typically use a Hardware Description Language (HDL) to describe their designs in manners that are amenable to automatic translation to specific hardware technologies using “Synthesis Tools”. HDLs are used for many tasks in a hardware design flow, including hardware description, testing and verification. In this course you will use an HDL to describe your design, and perhaps write some test cases.
You will implement your designs in a subset of the SystemVerilog HDL. Although it is a hardware description language, SystemVerilog has many features that make it resemble high-level programming languages such as C or C++. Many of these features, however, are primarily intended for testing and verification, and not hardware description. In this course, we will use a “synthesizable” subset of the language to describe your processors. A synthesizable subset is what a synthesis tool can automatically translate to hardware.
Do not panic if you have not used an HDL before! We will teach and discuss SystemVerilog and its synthesizable subset (which is frankly quite simple) in enough detail in the class. We will also provide a SystemVerilog-to-C++ translator (called Verilator) to translate your SystemVerilog code to C++ code that can be compiled and run to simulate your design. We will provide the necessary testing infrastructure that you will compile together with Verilator’s output to create a fully functional simulator for your design.
Resources
Each student enrolled in the class will be given a Linux virtual machine on a departmental teaching cluster with the basic required software installed. You will have root access to this virtual machine, and be able to install additional tools (editors, debuggers, etc) as you see fit.
Accessing Your VMs
Student VMs will contain all the software needed for the lab assignments, including Verilator, DRAMSim2, gtkwave and the RISCV cross-compiler toolchain. You will receive further instructions on how to access the VM in a private email, after you have submitted your group information to me.
Installing on your own machines
You are also welcome to install the needed software on your own machine. The course staff will provide you with the necessary instructions, but is not available to help you debug your personal laptop configuration.
You will need to install Verilator, gtkwave and the RISCV cross-compiler toolchain. The instructions provided here are for Ubuntu; adapt them as necessary for your distro of choice.
Git
The files you will need for the labs are distributed using the Git version control system. You will be handing in your work via Git, as well. Git is a powerful, but tricky, version control system. We highly recommend taking time to understand git so that you will be comfortable using it during the labs. Here are some resources to learn more about Git:
©2021 Amogh Akshintala