EIE2 Instruction Set Architecture & Compiler (IAC)

---

Team Project - RISC-V RV32I Processor

Peter Cheung, V1.3 - 23 Nov 2023

---

Objectives

• To learn RISC-V 32-bit integer instruction set architecture
• To implememnt a single-cycle RV32I instruction set in a microarchitecture
• To implemententing the F1 starting light algorithm in RV32I assembly language
• To verify your RV32I design by executing the F1 light program
• As stretched goal, to implement a simple pipelined version of the microarchitecutre with hazard detection and mitigation
• As a further stretched goal, add data cache to the pipelined RV32I

---

Learning the RV32I Instruction Set

---

Before you start the hardware design, every team member should learn the RV32I in some detail by jointly creating your team's assembly language program to implement the F1 starting light algorithm from Lab 3 in RV32I instructions.

Your implementation MUST use at least one subroutine so that you must include the Jump and Link (JAL) instruction. Your team's F1 program, together with another REFERENCE program from me will be used to test your processor implementation.

Unlike Lab 3, the clock signal does not control a hardware counter or state machine directly. Instead it is used to clock the RISC-V processor to execute one instruction. The Reset signal also resets only the processor to start the program, and is not used to reset counters or a state machine. The trigger signal is used to tell RISC-V when to start the F1 light sequence. How it is implemented in the RISC-V is not defined. You can decide, for example, that the trigger is automatic -- as soon as the program starts, the F1 light sequence is triggered.

You should also write your assembly language program using the following memory map.

This memory map is chosen to help debugging your design later. What is the size of the data and instruction memory specified by this map? Remember, both instructions and data are 32-bits or 4 bytes. RISC-V is a byte-addressing processor with least significant byte in lower address. (This is called "little-endian".)

---

Single-Cycle RV32I Design

---

This is the basic goal for every team - to implement the basic RV32I instruction set by extending your Reduced RISC-V design in Lab 4.

You do not need to implement every instruction in the RV32I instruction set, but you must implement the JAL instruction so that you can run code that uses subroutines.

To simplify matter, you should assume that you have separate instruction and data memory.

Similar to Lab 4, you must divide the task into roughly equal components, and each student will then be responsbile for one component. You can continue your role as in Lab 4 or, to diversify your learning, deliberately assigning a different component to your team members. The assessment of this project coursework will be mostly based on individual contributions with a smaller component based on the team's success. Details on assessment and deliverable are provided later in this project brief.

The testbench and test protocol for this processor is to provide evidence that your team's design is working for your team's F1 starting light program. You must also show evidence that your design works for the REFERENCE program that I have provided in this repo.

---

Stretch Goal 1: Pipelined RV32I Design

---

Once finished the basic goal, if your team have time, modify the the single-cycle processor to a pipelined processor.

A simple solution is to handle data and control hazards in software - by identifying and inserting NOPs, or by re-ordering instructions to avoid hazards.

For full credit, you are expected in implement hardware hazard detection, forwarding/bypassing or stalling hardware.

As before, make sure that your design is working by successfully running the team's version of the F1 light and the reference program.

---

Stretch Goal 2: Adding Data Memory Cache

---

As an additional stretch goal to the pipelined processor, you may also add data cache to your data memory. This is of course a "toy" exercise because your data memory is already a single-cycle memory and is very fast. Adding cache memory may make this slower, not faster. However, in real designs, data memory could be quite slow. Then, adding cache memory will help performance. Nevertheless, you may learn how cache memory works by implement it as an addition to your pipelined processor.

The data cache capacity should be no more than 1024 bytes. You may choose to implement a direct-mapped or associative cache.

---

Deliverable

---

All deliverables must be via your Team's project coursework repo via the github link you have provided for your team. The name of the repo has your team number at the end, and is private to your team, but accessible by myself. All deliverables must be in the repo by mid-night Friday 15 December 2023 when all coursework team repos must be frozen.

Deliverables must include the following:

1. A README.md file in the root directory that briefly describe what your team has achieved. This is a joint statement for the team.
2. Each individual's personal statement explaining what you contributed, reflection about what you have learned in this project, mistakes you made, special design decisons, and what you might do differently if you were to do it again or have more time. This statement must be succinct and to the point, yet must include sufficient details for me to check against the commit history of the repo so that any claims can be verified. Including links to a selection of specific commits which demonstrate your work would be most helpful. If you work with another member of your group on a module, make sure to give them co-author credit. Additionally, try to make meaningful commit messages.
3. A folder called rtl with the source of your processor. If you have multiple versions due to the stretched goals, you may use multiple branches. Your README.md file must provide sufficient explanation for me to understand what you have done and how to find your work on all branches you wish to be assessed. The rtl folder should also include a README.md file listing who wrote which module/file.
4. A test folder with your F1 program. The folder must also contain test results for your processor successfully executing the F1 program and my reference program.

You must also provide a Makefile or a shell script that allows me to build your processor model and run the testbench to repeat what you have done.

---

Assessment Criteria

---

Assessment for this coursework, which accounts for 25% of the entire two-terms IAC module, is divided into two components:

1. Team achievement (40%) - This component of the marks is common to all team members and is dependent on the overall achievement of the team.
2. Individual achievement (60%) - This component of the marks is awarded to individual student based on declaration by the team of the individual contribution, with verification based on evidence (e.g. based on the git commit and push profile of an individual), individual account of his/her contributions and reflections, and the actual deliverables by the individual in terms of SystemVerilog, C++ codes and/or test results.

This table shows the level of team's achievement and the range of grade to be awarded.

Here are the criteria on which individual assessment will be based.

---

Tips

---

• Agree a coding style between your team and stick to it. This document contains many suggested practices which are good to follow.
• Suffix module inputs and outputs with _i or _o respectively. This will make it much easier to understand what you are looking at in Gtkwave.
• Setup a .gitignore file to prevent yourself from committing generated files, the obj_dir directory and vcd files into Git
• Review each file before you stage and commit it into Git. You will catch many errors this way. VS Code has in-built tooling for Git which you should try to get familiar with.
• Write useful commit messages
• Work on your own branches on Git and get other members of your team to review your code before merging it in to the main branch