For this course, we have set up the SBRocks cluster of CEWIT with all the tools you need for your assignments. To get started, do "ssh -Y sbrocks.cewit.stonybrook.edu" using your CS Unix ID and password. If unable to log in, email rt@cs.stonybrook.edu to ask for help (this is particularly true for ECE students, who will need to explicitly request accounts). Once logged in, run "ssh-keygen” to create a key pair – leave the passphrase empty.
SBRocks is a cluster of machines and sbrocks.cewit.stonybrook.edu is the cluster head. You should never run your simulations or compilations on the cluster head. Instead, you should choose one of compute nodes of the cluster for your work. To do this, pick a random number A between 0 and 4, and another random number B between 0 and 34. Do "ssh -Y compute-A-B" to log in to your randomly chosen compute node. If your numbers didn’t work, pick two new random numbers and try again.
Once logged in to a compute node, execute the following command to set up your environment properly to be able to use course tools:
Hardware designers usually use a Hardware Description Language (HDL) to describe their designs in such a way that is amenable to automatic translation to hardware using the so called "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 for describing your design, and perhaps writing 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 such advanced features, however, are primarily intended for testing and verification, and not hardware description. In this course, we will use a subset of the language that is called the "synthesizable" subset for describing our 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 very 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.
We have prepared a simple Makefile and some skeleton code to help you get started with your first SystemVerilog programs. Do "git clone /home/facfs1/nhonarmand/cse502/cse502-sv-skeleton.git" to clone the skeleton code and makefile.
The goal of this homework is to implement a direct-mapped cache that you can later use in your course project. To get the code, do "git clone /home/facfs1/nhonarmand/cse502/cse502-hw1.git". Please carefully read the README file for an overview of what you need to do for this homework. You should work on the homework individually and not as a group. Each student should submit a separate solution.
In this course, you will design and implement a SPARCv8-compatible processor. At the minimum, your processor will include a 5-stage pipeline (similar to the one covered in the class), multiple functional units with varying latencies, and direct mapped instruction and data caches (40 pts). For more points, you can add the following features to your processor:
Do "git clone /home/facfs1/nhonarmand/cse502/cse502-proj.git" to clone the skeleton code for the project. 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. Read the README file for more information.
Your processor should implement the user-mode (non-privileged) subset of SPARCv8 instructions. You can ignore the ISA subset related to the "Alternate Address Spaces", "Ancillary State Registers" and the "Co-Processor" as well as any instruction that is marked as "privileged" in the SPARCv8 manual. Specifically, your processor need to implement all the instructions (and the requisite architectural state) described in the following sections of the manual:
Your processor need not deal with external interrupts. It should treat all "exceptions" (that is 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.
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).