Bringup and Evaluation of an Energy-efficient Heterogeneous Manycore Compute Platform (1-2S)
- 1 Overview
- 2 Introduction
- 3 Project Description
- 4 Milestones
- 5 Project Realization
- 6 Deliverables
- 7 References
- Type: Semester Thesis
- Professor: Prof. Dr. L. Benini
- Semester: Autumn Semester 2020
- Students: Julien Eudine, Till Mettler, Lukas Meier
- 20% FPGA RTL design
- 30% PCB testing and debugging
- 50% Bare-metal C programming
- RTL Design in SystemVerilog and Xilinx FPGA flow as taught in VLSI I
- Programming in C
- Preferred: Experience with bare-metal C programming
- Preferred: Experience with PCB design and/or bringup
Much of our recent work on high-performance computing systems at IIS uses the Snitch cluster . This multicore cluster couples tiny RISC-V Snitch cores with large double-precision FPUs and utilization-boosting extensions to maximize the area and energy spent on useful computation.
The Snitch cluster was already taped out on multiple chips. Most notably, it was featured on Baikonur , , our most capable 22nm chip to date: this heterogeneous SoC couples two application-grade Ariane cores with three octocore Snitch clusters for heavy compute tasks. It also features a novel serial link for die-to-die communication.
Last year, we created Exorcist , a hardware evaluation platform to demonstrate Baikonur. It combines a Xilinx FPGA with an FMC-attached PCB interconnecting 4 Baikonur ASICs through their serial links, creating a 104-core system with both application- and HPC-grade cores.
So far, we designed and fabricated the Exorcist PCB and tested its basic functionality. However, a lot of work still needs to be done to bring up the system so we can turn use it as an impressive evaluation and demonstration platform for our hardware.
The goal of this semester thesis is to create a complete setup on the accompanying Xilinx FPGA to drive the Exorcist demonstrator platform, enabling it to run meaningful applications on all of its 104 available cores.
The following are the milestones that we expect to achieve throughout the project:
- Familiarize yourself with the Xilinx Genesys 2 board used as a base, the Baikonur ASIC, and the Exorcist PCB.
- Create a simple SoC on the FPGA around Xilinx’ Microblaze softcore. Write code for the SoC that allows you to control the FPGA’s GPIOs.
- Attach the Exorcist PCB and write methods on the softcore to control the basic platform functions:
- Control the power supplies (I2C and GPIOs).
- Read out the on-board power meters (I2C).
- Control clocks / resets of the 4 Baikonur ASICs.
- Control the platform’s LED display.
- Bring up the serial link IP on the FPGA and write software to transfer data between the FPGA’s DRAM and the SRAM of one Baikonur SoC.
- Bring up one Baikonur SoC and execute a simple application on one of its Ariane cores; use the FPGAs softcore to control the execution process.
- Explore communication between two or more Baikonur ASICs.
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:
- Run a demonstrator application using all 104 cores orchestrated by the softcore on the FPGA.
- Perform power measurements using the on-board power meters.
- Investigate dynamic voltage and frequency scaling (DVFS) on the platform using the programmable power supplies and the on-chip FLLs.
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 familiar with the assets used||2 weeks|
|Implement SoC on FPGA||1 weeks|
|Control basic platform functions||3 weeks|
|Bring up serial link and transfer data||2 weeks|
|Run simple application on Ariane cores||1 weeks|
|Demonstrate communication between Baikonurs||1 weeks|
|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.
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: https://github.com/lowRISC/style-guides/.
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.
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 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
 F. Zaruba, F. Schuiki, and L. Benini, “Manticore: A 4096-core RISC-v chiplet architecture for ultra-efficient floating-point computing.” 2020.
 T. E. Benz, “Snitch Scale-Out on Amazon F1 Instances,” Master’s thesis, ETH Zurich, Switzerland, 2020.
 F. Zaruba, F. Schuiki, T. Hoefler, and L. Benini, “Snitch: A 10 kGE Pseudo Dual-Issue Processor for Area and Energy Efficient Execution of Floating-Point Intensive Workloads.” 2020.
 F. Schuiki, F. Zaruba, and S. Mach, “IIS Chip Gallery: Baikonur.” http://http://asic.ethz.ch/2019/Baikonur.html, 2019.