Personal tools

Implementation of a Small and Energy-Efficient RISC-V-based Vector Accelerator (1M)

From iis-projects

Revision as of 11:49, 4 August 2021 by Matheusd (talk | contribs)
Jump to: navigation, search


Status: Available


  • VLSI I
  • SoCDAML (recommended)
  • Experience with SystemVerilog


Striving for high image quality, even on mobile devices, has lead to an increase in pixel count in smartphone cameras over the last decade. These image sensors, boasting tens of millions of pixels, create a massive amount of data to be processed on a tight power envelope as quickly as possible. While this processing is highly parallelizable, it requires specialized Image Signal Processors (ISPs) which can exploit this high degree of parallelism to meet the timing and power constraints. One modern example of such an ISP is Google's Pixel Visual Core, which contains eight image processing units, each consisting of 256 specialized processing elements to achieve a combined performance of 3.28 TOPS.

At ETH, we are developing our own many-core system called MemPool. It boasts 256 lightweight 32-bit Snitch cores. They implement the RISC-V instruction set architecture (ISA), a modular and open ISA. Despite its size, MemPool manages to give all 256 cores low-latency access to the shared L1 memory, with a zero-load latency of at most five cycles. Therefore, all cores can efficiently communicate, making MemPool suitable for various workloads.

Programming MemPool presents some challenges. Even though the scratchpad memory can be accessed within at most five cycles, memory banks close to the cores can be accessed with a lower latency. It is therefore beneficial to keep the cores' accesses local, reducing the latency and the load on the global interconnect. We acknowledged this through a hybrid memory addressing scheme, which allocates each cores' stack on a memory bank close to it, accessible within one cycle of latency.

We also explored programming MemPool with a systolic array, transforming it into a Coarse-Grained Reconfigurable Architecture (CGRA). This approach instantiates queues between cores, which privileges communication between neighboring cores. Through the addition of special push and pop instructions, similar to SSRs, we can also elide some memory loads and stores, alleviating the Von Neumann bottleneck.

A vector programming model can be also used to program MemPool. We can exploit the fact that each vector instruction can be translated into a long series of scalar micro-operations. By replicating such micro-operations, we can alleviate the pressure on the instruction issue of the scalar core, leaving it free to execute other instructions.


This thesis' goal is to develop a small and energy vector accelerator unit, and integrate it with MemPool. This unit should achieve a high performance on key computational photography kernels, while keeping the energy efficiency of the design under control. This manycore system with vector support is to be analyzed in terms of the performance improvements, power requirements, and area impacts of the hardware needed to implement the vector accelerator.

Project Description

The project has different aspects to be explored. First, we need to determine a small subset of RISC-V's Vector Extension to be implemented. If the Vector Extension has been ratified and proposes an instruction subset for small embedded subsystems, we can use it. Otherwise, we will base ourselves on the instructions needed to execute the software kernels of interest.

Then, we will investigate how to implement this small and energy-efficient vector accelerator. We can take inspiration on Ara, a RISC-V-based vector processor developed by our group. Keep in mind that Ara targets much higher operating frequencies, and is overall a complex vector machine---each lane of Ara is about as large as one tile of MemPool. We want to implement a simple, small, and energy-efficient vector unit instead.

Regarding the vector register file, we might either use a small vector register file per vector unit, or stream the operands from the local L1 memory. During the thesis, the student will be asked to evaluate both approaches, and implement the chosen one. The other approach, and the comparison between them, is taken as a stretch goal.


The following are the milestones that we expect to achieve throughout the project:

  • Familiarize yourself with MemPool and with the RISC-V Vector Extension
  • Choose a subset of interest of the RISC-V Vector Extension
  • Implement a vector unit and integrate it with the Snitch cores in the MemPool tile
  • Benchmark the performance of the design with vector kernels
  • Analyze the impacts of the vector support on area and on power consumption
  • Compare your solution with MemPool as a systolic array

Project Realization


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.

Weekly Reports

Semester Thesis: 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.

Coding Guidelines

HDL Code Style

Adapting a consistent code style is one of the most important steps in order to make your code easy to understand. If signals, processes, and modules are always named consistently, any inconsistency can be detected more easily. Moreover, if a design group shares the same naming and formatting conventions, all members immediately feel at home with each other’s code. At IIS, we use lowRISC’s style guide for SystemVerilog HDL:

Software Code Style

We generally suggest that you use style guides or code formatters provided by the language’s developers or community. For example, we recommend LLVM’s or Google’s code styles with clang-format for C/C++, PEP-8 and pylint for Python, and the official style guide with rustfmt for Rust.

Version Control

Even in the context of a student project, keeping a precise history of changes is essential to a maintainable codebase. You may also need to collaborate with others, adopt their changes to existing code, or work on different versions of your code concurrently. For all of these purposes, we heavily use Git as a version control system at IIS. If you have no previous experience with Git, we strongly advise you to familiarize yourself with the basic Git workflow before you start your project.


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

Final Report

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 20 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