Ottocore: A Minimal RISC-V Core Designed for Teaching (B/2G)
- 1 Overview
- 2 Introduction
- 3 Project Description
- 4 Milestones
- 5 Project Realization
- 6 Deliverables
- 7 References
Status: In progress
- Type: Bachelor's Thesis
- Semester: Spring Semester 2021
- Student: Lukas Hauser
- Start: March 01, 2021
- Professor: Prof. Dr. L. Benini
- 30% Exploration
- 30% Implementation
- 40% Evaluation
- Interest in computer architecture
- Preferably: Experience with HDLs as taught in VLSI I
When teaching digital design to students, it is hard to find well-suited examples: synthetic out-of-context designs, like a simple shift register, offer little functionality and are usually uninteresting to students. At the same time, large designs from research or industry are difficult to explore in a teaching environment. This makes it difficult to bridge the gap between teaching and research.
A interesting field suitable to both domains is processor design: the rising popularity and widespread adoption of the open RISC-V instruction set  has reinvigorated computer architecture in teaching and research alike. At IIS, we are actively working on multiple open RISC-V research cores. However, as our research is becoming deeper and our cores more complex, we feel we are leaving students behind.
One solution would be to create a simple, minimal core dedicated for teaching, which serves as a stepping stone for students to learn about core design. This core would focus on having a clean, minimalistic architecture with well-documented code. Unlike our research cores, it would provide stable and careful version management. Furthermore, it would enable interested students to explore core design on their own.
Ideally, this core comes with a beginner-friendly and simple-to-understand environment for compiling programs, running them in simulation, and synthesizing the core to obtain area and timing results. Interested students should be able to run and experiment with software within minutes of cloning its repository. They should be able to understand the core’s design, RTL implementation, and all the scripts used without external help.
We experimented with some of these ideas and created a specification for a RISC-V core fulfilling these criteria. We realized that this specification does not define one specific implementation, but a family of possible designs, which we named Ottocores. What we need is a reference Ottocore, serving as a starting point for anyone who wants to learn about it or create their own design.
The core goal of the project is to design the reference Ottocore and to create appropriate setups for software compilation, simulation, and synthesis. The core should implement the RISC-V base integer ISA (RV32I/E) and fulfill our existing specifications on core functionality and interfaces.
For your core’s design, you may refer to existing designs such as the single-stage MIPS pipeline , RI5CY , or Snitch  for inspiration. You may reuse existing work from our commonly used IP blocks where it is helpful, but ideally, the design would be a standalone without external dependencies.
The following are the milestones that we expect to achieve throughout the project:
- Get familiar with the RISC-V base integer ISA  and our specification.
- Draft the architecture of your core using block diagrams and simple schematics; focus on creating a simple architecture that is easy to explain and understand.
- Implement your core in SystemVerilog and verify it using simple programs:
- Set up a flow for simulation and simulate the core using Questasim.
- Focus on writing well-structured, well-documented, understandable code.
- Add a simple intruction tracer for debugging purposes.
- Try to remain compatible with open EDA tools like SV2V, Yosys, and Verilator.
- Set up a flow for synthesis and synthesize the core using Synopsys Design Compiler.
- Set up and run the CoreMark benchmark suite<ref>https://www.eembc.org/coremark/</ref> on your core.
Should the above milestones be reached earlier than expected and you are motivated to do further work, we propose the following stretch goals to aim for:
- Explore simulating and synthesizing your core using the above open EDA tools.
- Improve your tracer to annotate instructions with relevant data such as operands.
- Set up a simple value-change-based power estimation flow.
- Create the instruction decompressor to support the C extension.
- Optimize your core in terms of area, timing, performance, or power if available.
- Optimize your core for implementation on FPGAs.
The time schedule presented in 1 is merely a proposition; it is primarily intended as a reference and an estimation of the time required for each required step.
|Project phase||Time estimate|
|Get familar with spec||1 week|
|Draft architecture||2 weeks|
|Implement, verify architecture||5 weeks|
|Set up, run synthesis||1 week|
|Run coremark||1 week|
|Stretch goals||remaining time|
|Write report||2 weeks|
|Prepare presentation||1 week|
Weekly meetings will be held between the student and the assistants. The exact time and location of these meetings will be determined within the first week of the project in order to fit the student’s and the assistants’ schedule. These meetings will be used to evaluate the status and progress of the project. Beside these regular meetings, additional meetings can be organized to address urgent issues as well.
The student is advised, but not required, to a write a weekly report at the end of each week and to send it to his advisors. The idea of the weekly report is to briefly summarize the work, progress and any findings made during the week, to plan the actions for the next week, and to bring up open questions and points. The weekly report is also an important means for the student to get a goal-oriented attitude to work.
Adapting a consistent naming scheme is one of the most important steps in order to make your code easy to understand. If signals, processes, and entities are always named the same way, any inconsistency can be detected easier. Moreover, if a design group shares the same naming convention, all members would immediately feel at home with each others code. The naming conventions we follow in this project are at https://github.com/lowRISC/style-guides/.
Documentation is an important and often overlooked aspect of engineering. A final report has to be completed within this project.
The common language of engineering is de facto English. Therefore, the final report of the work is preferred to be written in English.
Any form of word processing software is allowed for writing the reports, nevertheless the use of LaTeX with Inkscape or any other vector drawing software (for block diagrams) is strongly encouraged by the IIS staff.
If you write the report in LaTeX, we offer an instructive, ready-to-use template, which can be forked from the Git repository at https://iis-git.ee.ethz.ch/akurth/iisreport.
The final report has to be presented at the end of the project and a digital copy needs to be handed in and remain property of the IIS. Note that this task description is part of your report and has to be attached to your final report.
There will be a presentation (15 min presentation and 5 min Q&A) at the end of this project in order to present your results to a wider audience. The exact date will be determined towards the end of the work.
In order to complete the project successfully, the following deliverables have to be submitted at the end of the work:
- Final report incl. presentation slides
- Source code and documentation for all developed software and hardware
- Testsuites (software) and testbenches (hardware)
- Synthesis and implementation scripts, results, and reports
 A. Waterman, Y. Lee, D. A. Patterson, and K. Asanović, “The RISC-v instruction set manual, volume i: User-level ISA, version 2.0,” EECS Department, University of California, Berkeley, UCB/EECS-2014-54, May 2014.
 D. A. Patterson and J. L. Hennessy, Computer organization and design, fifth edition: The hardware/software interface, 5th ed. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 2013.
 M. Gautschi et al., “Near-threshold RISC-v core with DSP extensions for scalable IoT endpoint devices,” IEEE Transactions on Very Large Scale Integration (VLSI) Systems, vol. 25, no. 10, pp. 2700–2713, 2017.
 F. Zaruba, F. Schuiki, T. Hoefler, and L. Benini, “Snitch: A tiny pseudo dual-issue processor for area and energy efficient execution of floating-point intensive workloads,” IEEE Trans. Comput., pp. 1–1, 2020.