View source for A Flexible Peripheral System for High-Performance Systems on Chip (M)

<!-- (M): A Flexible Peripheral System for High-Performance Systems on Chip -->

= Overview =

== Status: Completed ==

* Type: Master Thesis
* Semester: Autumn Semester 2020
* Student: Flavien Solt
* Start: September 14, 2020
* Professor: Prof. Dr. L. Benini
* Supervisors:
** [[:User:Paulsc | Paul Scheffler]]: [mailto:paulsc@iis.ee.ethz.ch paulsc@iis.ee.ethz.ch]
** [[:User:Tbenz | Thomas Benz]]: [mailto:tbenz@iis.ee.ethz.ch tbenz@iis.ee.ethz.ch]
** [[:User:Smach | Stefan Mach]]: [mailto:smach@iis.ee.ethz.ch smach@iis.ee.ethz.ch]

== Character ==

* 10% Literature / existing work exploration
* 30% RTL
* 20% Verification
* 30% Implementation
* 10% Software / Tooling

== Prerequisites ==

* VLSI I and II or equivalent: Understanding of at least one RTL language and ASIC design principles.
* Basic prior knowledge of embedded / bare-metal C and Assembly.
* Preferred: prior experience writing RTL or low-level C.
* Preferred: prior experience with embedded peripherals, e.g. on microcontrollers.

[[Category:Digital]]
[[Category:High Performance SoCs]]
[[Category:Computer Architecture]]
[[Category:FPGA]]
[[Category:ASIC]]
[[Category:2020]]
[[Category:Master Thesis]]
[[Category:Paulsc]]
[[Category:Tbenz]]
[[Category:Smach]]
[[Category:Completed]]

[[File:Pulpissimo_archi_nice.png|thumb|600px|alt=Top-level architecture of the existing PULPissimo microcontroller and its APB- and DMA-based peripheral subsystem.  [<nowiki/>[[#ref-pulpissimo|1]]] |Top-level architecture of the existing PULPissimo microcontroller and its APB- and DMA-based peripheral subsystem.  [<nowiki/>[[#ref-pulpissimo|1]]] ]]

= Introduction =

At IIS, we often tape out Systems on Chip (SoCs) to try out new computer-architectural concepts and extensions, often differentiated by small-scale or configuration changes. This, however, requires a lot of time-consuming work on the surrounding hardware.

One of the most tedious and error-prone steps is assembling a peripheral system with the required and desired IO; this usually involves adapting existing peripheral RTL and connecting it to the new top-level architecture.

Our group puts a large focus on the Parallel Ultra-Low Power (PULP)  [<nowiki/>[[#ref-pulp|2]]]  platform, which provides a multicore cluster based on the RISC-V instruction set architecture (ISA). For PULP-based systems, a peripheral system around an APB bus and a centralized data mover called the micro DMA (\textmu DMA) has established itself. However, this system is very fragmented, monolithic, and specifically tailored to a PULP-style interconnect and memory system, making it unsuitable for unrelated SoCs.

[[File:Peripheral_prototype.png|thumb|600px|alt=A peripheral compliant with our specification  [<nowiki/>[[#ref-fenrir|3]]]  with its required hardware for each of the three incremental base classes.|A peripheral compliant with our specification  [<nowiki/>[[#ref-fenrir|3]]]  with its required hardware for each of the three incremental base classes.]]

Taking inspiration from our existing high-performance SoCs and the OpenTitan  [<nowiki/>[[#ref-opentitan|4]]]  project, we have proposed a much more flexible framework for peripherals  [<nowiki/>[[#ref-fenrir|3]]]  relying only on standard interfaces and mandatory core functionality, enabling their reuse with a wide variety of interconnect and memory systems and accommodating a wider variety of peripherals. [[#fig:peripheral_prototype|2]] shows the proposed architecture of a peripheral compliant to our specification.

This specification should be rigorous enough to automatically generate larger peripheral systems through hardware generation methods. It should also enable the SoC designer to tune bandwidth and Quality of Service (QoS) properties directly through interconnect design instead of being bound to one monolithic, inflexible architecture.

Although our idea works well in theory, we have not implemented any peripherals or a demonstrator system yet. If we had such a peripheral system, it would be the ideal starting point for each SoC we design from that point onwards.

= Work Description =

The core goal of the thesis is to evaluate and implement a new universal peripheral system for high-performance and energy-efficient SoCs and demonstrate it in a compact RISC-V-based microcontroller on real silicon.

The system architecture we propose is depicted in [[#fig:peripherals_soc|3]]: it is powered by the Snitch core  [<nowiki/>[[#ref-snitch|5]]] , a highly area-efficient single-stage RISC-V core recently developed in our group which is optionally coupled to a 64-bit FPU with utilization-boosting extensions.

[[File:Peripherals_soc.png|thumb|600px|alt=Top-level architecture of the proposed Snitch-based system with the novel peripheral subsystem.|Top-level architecture of the proposed Snitch-based system with the novel peripheral subsystem.]]

= Milestones =

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

* Get familiar with Snitch and run some example code in a testbench. Get familiar with the existing PULPissimo  [<nowiki/>[[#ref-pulpissimo|1]]]  peripheral system and its peripherals to analyze their behavior, configuration, and throughput requirements.
* Implement one peripheral according to the new specification and connect it to the system. Verify and evaluate the peripheral’s functionality using a simulation model. If necessary, use your observations to improve and extend the specification.
* Implement a complete set of peripherals, for example those included in PULPissimo, according to the specification and evaluate their performance. Devise and implement an appropriate interconnect for the peripheral system of your SoC using the throughput and performance information collected so far.
* Compare the figures of merit (area, energy efficiency, latency, throughput, scalability, simplicity, and maintainability) of your SoC’s peripheral system as a whole to that of a PULPissimo using the APB and \textmu DMA-based approach.
* Choose an appropriate name for your chip. Implement a backend flow for your SoC in TSMC’s 65 nm or GlobalFoundries’ 22 nm technology. Complete the tapeout by running successful post-layout simulations, design rule check (DRC), and layout versus schematic (LVS).
* Write your thesis and prepare your final presentation.

== 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:

* Realize your SoC on an appropriate FPGA platform and connect physical peripherals to it. You can also develop this goal during your regular milestones.
* Write a tool generating peripheral systems described in a simple configuration file by connecting the created peripherals and existing interconnect IPs automatically.
* Write some bare-metal drivers for your peripherals. Demonstrate them in a simple application, e.g. logging data to an SD card or playing audio through I2S.
* Design a system PCB carrying your chip and some of the peripherals.

= Thesis Realization =

== Time Schedule ==

The time schedule presented in [[#tab:time_plan|1]] is merely a proposition; it is primarily intended as a reference and an estimation of the time required for each required step.

<div id="tab:time_plan" style="padding-top: 1em;">
{| class="wikitable"
! <b >Thesis phase</b>
! <b >Time estimate</b>
|-
| Get familiar with Snitch and peripherals
| 2 weeks
|-
| Implement, verify, connect one peripheral
| 3 weeks
|-
| Implement remaining peripherals, interconnect
| 5 weeks
|-
| Evaluate against PULPissimo
| 3 weeks
|-
| Synthesis, backend, tapeout
| 6 weeks
|-
| <i >Stretch goals</i>
| <i >remaining time</i>
|-
| Write report
| 3 weeks
|-
| Prepare presentation
| 2 weeks
|+ style="caption-side:bottom; font-size: small; padding-top: 0.5em;" | Proposed time schedule and investment
|}
</div>
== 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 thesis in order to fit the student’s and the assistants’ schedule. These meetings will be used to evaluate the status and progress of the thesis. Beside these regular meetings, additional meetings can be organized to address urgent issues as well.

== Weekly Reports ==

The student is required to a write a weekly report at the end of each week and to send it to his advisors and his supervising professor by email. 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 discuss 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 thesis 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 thesis.

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 thesis 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 (20 min presentation and 5 min Q&amp;A) at the end of this thesis 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 thesis 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 =

<div id="refs" class="references">
<div id="ref-pulpissimo">
[1] PULPissimo contributors, ETH Zurich, University of Bologna, “PULPissimo.” GitHub.
</div>
<div id="ref-pulp">
[2] F. Conti, D. Rossi, A. Pullini, I. Loi, and L. Benini, “PULP: A ultra-low power parallel accelerator for energy-efficient and flexible embedded vision,” ''J. Signal Process. Syst.'', vol. 84, no. 3, pp. 339–354, Sep. 2016.
</div>
<div id="ref-fenrir">
[3] P. Scheffler, S. Mach, and T. Benz, “Fenrir: A Modular, Scalable Peripheral Specification.” IIS, ETH Zurich, 2020.
</div>
<div id="ref-opentitan">
[4] “OpenTitan.” https://opentitan.org/.
</div>
<div id="ref-snitch">
[5] 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.
</div>
</div>