Personal tools

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

From iis-projects

Jump to: navigation, search
 
Line 8: Line 8:
 
[[Category:Nwistoff]]
 
[[Category:Nwistoff]]
 
[[Category:Available]]
 
[[Category:Available]]
 +
[[Category:Hot]]
  
 
== Introduction ==
 
== Introduction ==

Revision as of 18:34, 2 November 2020


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.

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:

  • Generating interconnects by configuring and connecting our verified and optimized, parameterizable AXI, TCDM, and Request-response IPs.
  • 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:

  • How do we define and specify IPs for use in this generation system?
  • How do we define and specify SoCs, through a configuration file or using a metalanguage?
  • 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

  • Experience with Python
  • Experience with RTL design and HDLs (SystemVerilog) as taught in VLSI I
  • Preferably: previous experience with or exposure to SoC design or architecture
  • Preferably: previous experience with synthesis and implementation constraints

Composition

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

Project Supervisors