Personal tools

Difference between revisions of "IP-Based SoC Generation and Configuration (1-3S/B)"

From iis-projects

Jump to: navigation, search
Line 2: Line 2:
 
[[Category:High Performance SoCs]]
 
[[Category:High Performance SoCs]]
 
[[Category:Computer Architecture]]
 
[[Category:Computer Architecture]]
[[Category:2020]]
+
[[Category:2021]]
 
[[Category:Semester Thesis]]
 
[[Category:Semester Thesis]]
 
[[Category:Bachelor Thesis]]
 
[[Category:Bachelor Thesis]]
Line 12: Line 12:
 
== Introduction ==
 
== Introduction ==
  
At IIS, we often tape out systems-on-chip (SoCs) with new hardware configurations and small-scale hardware extensions to evaluate their impact.Moving to more complex SoCs, '''top-level connectivity and parameterization''' become a major design issue:
+
At IIS, we often tape out systems-on-chip (SoCs) with new hardware configurations and small-scale hardware extensions to evaluate their impact. Moving to more complex SoCs, top-level connectivity and parameterization become a major design issue:
  
* Each SoC will '''share many of the same IPs''', but have its '''own top-level design''', creating numerous design variants which are hard to maintain.
+
* Each SoC will share many of the same IPs, but have its own top-level design, creating numerous design variants which are hard to maintain.
* Manually managing connection and parametrization of IPs is the norm, '''but becomes more difficult and error-prone''' the larger the system becomes.
+
* Manually managing connection and parametrization of IPs is the norm, but becomes more difficult and error-prone the larger the system becomes.
* '''Design exploration is severely impeded''' by the effort of manually instantiating all top-level SoC modules and configuring them individually in various packages.
+
* ''Design exploration is severely impeded'' by the effort of manually instantiating all top-level SoC modules and configuring them individually in various packages.
  
This increasingly time-consuming tedium to ensure the SoC is properly parametrized and connected is fittingly referred to as '''top-level hell'''.
+
This increasingly time-consuming tedium to ensure the SoC is properly parametrized and connected is fittingly referred to as ''top-level hell''.
  
An industry-standard approach to tackle this issue is '''High-level Synthesis''' (HLS), for example using SystemC, Chisel [https://www.chisel-lang.org/], or Spinal HDL [https://spinalhdl.github.io/SpinalDoc-RTD/]. However, this approach introduces significant drawbacks:
+
An industry-standard approach to tackle this issue is ''High-level Synthesis'' (HLS), for example using SystemC, Chisel [https://www.chisel-lang.org/], or Spinal HDL [https://spinalhdl.github.io/SpinalDoc-RTD/]. However, this approach introduces significant drawbacks:
  
* '''All RTL is generated''', taking control from the designers to adapt and optimize it and leaving them exposed to possible generation bugs.
+
* ''All RTL is generated'', taking control from the designers to adapt and optimize it and leaving them exposed to possible generation bugs.
* Unlike hand-written code, the generated RTL is '''neither readable nor interpretable''', making debugging in simulation and implementation difficult to impossible.
+
* Unlike hand-written code, the generated RTL is ''neither readable nor interpretable'', making debugging in simulation and implementation difficult to impossible.
* The designers lose control over '''clock gating''', '''power gating''' (which has to be inserted manually), and certainty in applying targeted '''design constraints'''.
+
* The ''designers lose control'' over clock gating, power gating (which has to be inserted manually), and certainty in applying targeted design constraints.
 +
 
 +
At IIS, we focus on creating highly-optimized, interoperable core and SoC IPs. Ideally, we want to directly use these in designs instead of generating suboptimal, intransparent RTL with HLS. Instead, we want to assemble SoCs from our IPs by ''connecting and configuring them automatically''.
 +
 
 +
Recently, we created a script-based tool called ''Solder'', which combines a bunch of templated snippets to connect IP instantiations to a top level in a comprehensive, human-readable way. However, Solder is currently tied to a specific environment, barely configurable, and incapable of optimizing the generated hardware automatically.
  
 
== Project ==
 
== Project ==
  
At IIS, we focus on creating highly-optimized, interoperable core and SoC IPs. Ideally, we want to use these in designs instead of generating suboptimal, intransparent RTL with HLS. Instead, we want to assemble SoCs from our IPs by '''connecting and configuring them automatically'''. This entails:
+
In this project, you will '''improve on our SoC generation and configuration stack''' using Solder through:
 +
 
 +
* '''Generalization''': Currently, Solder is simply a loose collection of scripts and templates shipped with the Snitch system [https://github.com/pulp-platform/snitch]. You will
 +
** Turn it into a standalone tool independent of the Snitch source tree which can be used with any System/IPs and a number of protocols
 +
** Make it fully configurable and extensible through per-IP maniftests and a top-level configuration.
 +
* '''Demonstration''': You will use this new standalone tool to generate the top level of a representative SoC from existing IPs.
  
* '''Generating interconnects''' by configuring and connecting our verified and optimized, parameterizable AXI, TCDM, and Request-response IPs.
+
Depending on our interests and the time remaining, the following tasks can also be tackled:
* '''Connecting top-level modules''' by configuring and connecting SoC components from a minimal configuration file.
 
* '''Configuring firmware and drivers''' for our new configurable peripheral system.
 
  
The work will allow you lots of freedom in how you implement such an SoC generator and configurator and the opportunity to '''shape how we make SoCs in the future''':
+
* '''QoR Estimation''': You can use the information of the configured top-level and IPs to estimate key figures of merit without sythesizing or simulating the hardware, such as area, latency, throughput, and possibly power.
* How do we '''define and specify IPs''' for use in this generation system?
+
* '''Optimization''': You can use your estimations to automatically optimize your SoC configuration given certain constraints, greatly simplifying SoC design and exploration.
* How do we '''define and specify SoCs''', through a configuration file or using a metalanguage?
+
* '''Secondary output generation''': Like the existing scripts, you can generate additional outputs from your unified SoC view such as address maps, header files, and linker scripts among others.
* What '''other outputs''' can we generate? This may entail linking scripts and header files, datasheets and documentation, synthesis and implementation constraints, or crude area, timing, and power estimates using existing IP figures.
 
  
 
== Requirements ==
 
== Requirements ==
  
* Experience with Python
+
* Experience with software development (''not'' only ML) in Python
* Experience with RTL design and HDLs (SystemVerilog) as taught in VLSI I
+
* Experience with digital design in SystemVerilog as taught in VLSI I
 
* Preferably: previous experience with or exposure to SoC design or architecture
 
* Preferably: previous experience with or exposure to SoC design or architecture
* Preferably: previous experience with synthesis and implementation constraints
+
* Preferably: previous experience with templating engines such as Mako
  
 
==Composition==
 
==Composition==
  
* 20% initial exploration
+
* 10% Code review
* 50% implementation
+
* 20% Software architecture planning
* 30% evaluation
+
* 50% Implementation
 +
* 20% Evaluation
  
 
== Project Supervisors ==
 
== Project Supervisors ==

Revision as of 18:47, 15 November 2021


Introduction

At IIS, we often tape out systems-on-chip (SoCs) with new hardware configurations and small-scale hardware extensions to evaluate their impact. Moving to more complex SoCs, top-level connectivity and parameterization become a major design issue:

  • Each SoC will share many of the same IPs, but have its own top-level design, creating numerous design variants which are hard to maintain.
  • Manually managing connection and parametrization of IPs is the norm, but becomes more difficult and error-prone the larger the system becomes.
  • Design exploration is severely impeded by the effort of manually instantiating all top-level SoC modules and configuring them individually in various packages.

This increasingly time-consuming tedium to ensure the SoC is properly parametrized and connected is fittingly referred to as top-level hell.

An industry-standard approach to tackle this issue is High-level Synthesis (HLS), for example using SystemC, Chisel [1], or Spinal HDL [2]. However, this approach introduces significant drawbacks:

  • All RTL is generated, taking control from the designers to adapt and optimize it and leaving them exposed to possible generation bugs.
  • Unlike hand-written code, the generated RTL is neither readable nor interpretable, making debugging in simulation and implementation difficult to impossible.
  • The designers lose control over clock gating, power gating (which has to be inserted manually), and certainty in applying targeted design constraints.

At IIS, we focus on creating highly-optimized, interoperable core and SoC IPs. Ideally, we want to directly use these in designs instead of generating suboptimal, intransparent RTL with HLS. Instead, we want to assemble SoCs from our IPs by connecting and configuring them automatically.

Recently, we created a script-based tool called Solder, which combines a bunch of templated snippets to connect IP instantiations to a top level in a comprehensive, human-readable way. However, Solder is currently tied to a specific environment, barely configurable, and incapable of optimizing the generated hardware automatically.

Project

In this project, you will improve on our SoC generation and configuration stack using Solder through:

  • Generalization: Currently, Solder is simply a loose collection of scripts and templates shipped with the Snitch system [3]. You will
    • Turn it into a standalone tool independent of the Snitch source tree which can be used with any System/IPs and a number of protocols
    • Make it fully configurable and extensible through per-IP maniftests and a top-level configuration.
  • Demonstration: You will use this new standalone tool to generate the top level of a representative SoC from existing IPs.

Depending on our interests and the time remaining, the following tasks can also be tackled:

  • QoR Estimation: You can use the information of the configured top-level and IPs to estimate key figures of merit without sythesizing or simulating the hardware, such as area, latency, throughput, and possibly power.
  • Optimization: You can use your estimations to automatically optimize your SoC configuration given certain constraints, greatly simplifying SoC design and exploration.
  • Secondary output generation: Like the existing scripts, you can generate additional outputs from your unified SoC view such as address maps, header files, and linker scripts among others.

Requirements

  • Experience with software development (not only ML) in Python
  • Experience with digital design in SystemVerilog as taught in VLSI I
  • Preferably: previous experience with or exposure to SoC design or architecture
  • Preferably: previous experience with templating engines such as Mako

Composition

  • 10% Code review
  • 20% Software architecture planning
  • 50% Implementation
  • 20% Evaluation

Project Supervisors