Personal tools

IP-Based SoC Generation and Configuration (1-3S/B)

From iis-projects

Jump to: navigation, search


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 assemble SoCs from these IPs by connecting and configuring them automatically instead of generating suboptimal, intransparent RTL with HLS.

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 hardware configurations automatically.


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.


  • 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


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

Project Supervisors