Personal tools

A Snitch-Based SoC on iCE40 FPGAs (1-2S/B)

From iis-projects

Jump to: navigation, search


Overview

Status: In progress

Character

  • 50% exploration
  • 30% evaluation
  • 20% implementation

Prerequisites

  • Interest in computer architecture
  • Experience with HDLs as taught in VLSI I
  • Preferably: Previous experience with FPGAs

Introduction

With the iCE40 FPGA family, Lattice Semiconductor  [[[#ref-fpga|1]]] provides FPGAs with the world’s smallest form factor, optimized for ultra-low-power applications. They enjoy great popularity in the hardware community due to their flexible logic architecture, simple footprint, minimal required support circuitry, and low price.

In addition to Lattice’s iCEcube2  [[[#ref-icecube|2]]] FPGA toolchain, a fully free and open-source tool chain  [[[#ref-snitch|3]]] has been developed, increasing the range of the iCE40 family.

At our group, we developed a cluster-based compute ecosystem targeting energy-efficient high-performance computing applications, built around a tiny single-stage RISC-V core called Snitch  [[[#ref-snitch|3]]] . This ecosystem allows Snitch to be configured as a standalone SoC or as a compute accelerator in heterogeneous SoCs or manycore applications. Snitch features a flexible accelerator interface, allowing it to be paired with a powerful FPU to achieve high FPU utilizations and compute-over-control ratio.

So far, we use Snitch only in ASICs and large, high-performance FPGAs. Due to its small area requirement and flexible interfaces, we propose the Snitch core to be used in ultra-low-power embedded applications. Next to embedded applications, such highly optimized Snitch-based systems can be used for low-overhead management functionality in larger systems, like observing and optimizing the energy consumption of a compute accelerator.

Project Description

The projects targets the evaluation of Snitch in ultra-low-power embedded applications by investigating the performance of Snitch in small SoCs mapped to the iCE40 FPGA family as well as its use as low-overhead management cores in large ASICs.

Milestones

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

  • Familiarize yourself with the iCE40 family. Compile a comprehensive overview of and their strengths, weaknesses, and core applications.
  • Familiarize yourself with the Snitch ecosystem.
  • Implement key modules of the Snitch ecosystem on the iCE40 FPGAs and evaluate their utilization, speed, and power.
  • Create an SoC containing the Snitch core; map it to an iCE FPGA to evaluate its performance and optimize it.
  • Synthesize your SoC in a modern ASIC node and compare area, timing, and power consumption with a minimal configuration of the ibex core.

Stretch Goals

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:

  • Include simple peripherals in your SoC (UART / I2C) to communicate with the outside world.
  • Explore extreme design points (largest and smallest SoC, lowest power, fastest design, ...).
  • Evaluate and implement design improvements to adapt the Snitch core and/or the Snitch ecosystem to better fit ultra-low-power embedded applications.
  • Create a custom PCB for the iCE40 family to facilitate measurements and/or demonstrate your system in action. Can we compete with a microcontroller in terms of performance and power?
  • Investigate the benefits and costs of the Compressed Extension in ultra-low-power Snitch-based SoCs.

Project Realization

Time Schedule

The time schedule presented in [tab:time_plan] 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
Exploration of iCE40 family 2 weeks
Familiarization with Snitch ecosystem 1 week
Implementing key modules 2 weeks
Create, optimize, map, and evaluate SoC 3 weeks
Stretch goals remaining time
Write report 2 weeks
Prepare presentation 1 week
Proposed time schedule and investment

Meetings

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

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 Guidelines

Naming Conventions

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/.

Report

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.

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.

Presentation

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.

Deliverables

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

References

[2] “iCEcube2 Design Software.” https://www.latticesemi.com/iCEcube2.

[3] 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.