SIEMENS HLS Academy

SystemC Modeling

Using SystemC to model HLS designs enables a wide range of hardware design types to be modeled and efficiently verified before HLS. SystemC enables hardware aspects to be modeled such as modules and module hierarchy, ports, signals, concurrent processes, reset signals, and time. All major HDL simulators support simulation of mixed testbench and design hierarchies that may contain SystemC, SystemVerilog, and VHDL modules. Within SystemC HLS models, libraries such as Matchlib can be used to enable transaction interfaces to be modeled and to provide building block IP models. SystemC HLS models can use fixed-point and floating-point datatypes to accurately model aspects such as limited numerical precision and saturation and rounding. C++ libraries for HLS enable blocks to model math functions, DSP functions, and more.

Stuart Swan

  1. SystemC Modeling Featured Content

    • Machine-Learning-Assisted Agile VLSI Design for Machine Learning

      SystemC Modeling Aug 31, 2019 Brucek Khailany link

      We will highlight two design automation research directions being pursued in the ASIC and VLSI Research group at NVIDIA: (1) An automated C++-to-layout VLSI flow that leverages HLS tools and open-source HLS-compatible C++ libraries for design productivity; and (2) Machine-learning assisted VLSI design techniques. We will also describe our experience using these tools as part of an agile hardware design flow to build for a deep neural network (DNN) inference accelerator testchip.

    • NVIDIA's Use of Catapult HLS for Building ML Inference Accelerators

      SystemC Modeling Nov 29, 2023 Stuart Swan link

      This is a short introduction to NVIDIA's use of Catapult HLS for building machine learning accelerator SOCs. We will present the MatchLib modeling methodology that NVIDIA has developed and which is now supported within Catapult HLS, and we will describe the results of the fully working SOC ASIC that was almost entirely developed using HLS.

    • NVIDIA: Design and Verification of a Machine Learning Accelerator SoC Using an Object-Oriented HLS-Based Design Flow

      SystemC Modeling Oct 10, 2018 Brucek Khailany Webinar

      A high-productivity digital VLSI flow for designing complex SoCs is presented in this webinar. It includes High-Level Synthesis tools, an efficient implementation of Latency-Insensitive Channels, and MatchLib - an object-oriented library of synthesizable SystemC and C++ components. The flow was demonstrated on a programmable machine learning inference accelerator SoC designed in 16nm FinFET technology.

    • MatchLib Toolkit

      SystemC Modeling Jun 20, 2024 Stuart Swan Tool Kit

      MatchLib is a new open-source SystemC library originally developed by NVIDIA Research to enable digital hardware to be accurately and efficiently designed and verified at a high level of abstraction, leveraging commercial High-Level Synthesis tools.

    • NVIDIA: High-Level Synthesis in Agile System-on-Chip Flows: Overview and Techniques

      SystemC Modeling Jul 24, 2024 Nathaniel Pinckney Webinar

      Catapult High-Level Synthesis has been successfully employed within NVIDIA for multiple generations of system-on-chip research demonstrations. This talk provides a brief overview of NVIDIA Research’s use of Catapult HLS and highlights some useful features and flows of the Connections library, such as the ability to back-annotate SystemC simulations to identify and fix performance bugs.

  2. SystemC Modeling Overview

    SystemC is a hardware description language (HDL) implemented as classes using the C++ language. Because SystemC enables both combinational and sequential processes to be modeled, and because it supports detailed hardware concepts such as modules and module hierarchies, ports, clocks, resets, signals, and time, it can be used to model any type of digital hardware.

    SystemC is standardized as IEEE 1666, and Accellera has standardized a synthesizable subset of SystemC and is actively working on extensions.

    When used with HLS, SystemC enables the following design aspects to be modeled:

    • Arbitrary module hierarchies
    • Designs with multiple clocks and resets, including sync and async resets.
    • Resets can be dynamic, i.e. they can occur during normal operation of the design.
    • Feedback paths and re-convergent paths within dataflow designs are supported.
    • Non-blocking IO, arbitration, and timing dependent behaviors are supported.
    • Arbitrary communication protocols and bus interfaces can be modeled.
    • Direct inputs to datapath pipelines can be modeled, and they can be reliably updated as the design operates.

    SystemC HLS Libraries

    There are a number of libraries that are commonly used with SystemC when developing HLS models.

    These include:

    1. ac_types for arbitrary precision integer, fixed-point and floating-point types
    2. ac_math for mathematical functions such as sine, cosine, tangent, square root, etc.
    3. ac_dsp for DSP functions such as filters and FFTs.

    An important library that is often used with SystemC HLS designs is MatchLib. MatchLib is an open-source SystemC library that was originally developed by NVIDIA Research, and it enables digital hardware to be accurately and efficiently designed and verified at a high level of abstraction, leveraging commercial high level synthesis tools. MatchLib contains classes for modeling message passing interfaces within HLS models, and on top of these classes it provides parameterized building block models such as AXI bus fabric components (routers, arbiters, etc), network on chip components, banked memories, scratchpads, crossbars, etc.

    Some of the key goals of MatchLib are to enable SystemC models to be directly synthesized to HW with very high quality of results, and to enable very accurate performance simulation of these models in SystemC prior to synthesis, so that the overall design and verification effort is much more efficient.

    MatchLib is being actively used by hardware design teams in both industry and academia for advanced hardware design projects, and multiple tapeouts from different groups have occurred for chips that have been almost entirely designed with MatchLib.

    MatchLib is being discussed in the Accellera Synthesis Working Group for possible standardization. You can download the open source MatchLib examples kit and run the examples on any Linux machine from the MatchLib ToolKit.

    SystemC HLS Verification and Debug

    A primary objective when utilizing High-Level Synthesis (HLS) is to identify and fix nearly all issues and bugs in the model before HLS, rather than dealing with them by debugging the post-HLS RTL. SystemC and MatchLib are tools that, when used with HLS, offer essential capabilities to achieve this goal:

    • A SystemC testbench enables comprehensive testing of the SystemC Design Under Test (DUT) by applying extensive stress tests.
    • For additional rigor, a SystemVerilog Universal Verification Methodology (UVM) testbench can also be used to stress test the SystemC DUT. All major EDA simulators support this mixed language capability.
    • MATLAB facilitates the verification of the SystemC DUT by allowing its importation through the MATLAB MEX interface.
    • Python programs can verify the SystemC DUT by importing the DUT via the Python C API, broadening the scope of verification tools.
    The picture is a screenshot showing a Verilog testbench that instantiates a SystemC DUT in a mixed language simulation within Questa.
    This screenshot shows a Verilog testbench that instantiates a SystemC DUT in a mixed language simulation within Questa.

    MatchLib enhances the verification and debugging capabilities of the pre-HLS model with several critical features:

    • Throughput-accurate modeling ensures the performance of the pre-HLS model is verified, predicting how it will perform after HLS.
    • Random stall injection simplifies the process of stress testing the pre-HLS DUT by introducing potential real-world operational delays.
    • Automatic generation of channel logs aids in the easy debugging of transaction streams, allowing for straightforward analysis of data flow.
    • Similarly, automatic memory log generation facilitates the inspection and debugging of memory accesses.
    • Automatic waveform generation provides a graphical representation of signal waveforms, making detailed analyses more accessible.
    • The ability to use latency and capacity back annotation helps in accurately simulating the effects that will be introduced during the HLS process, leading to more accurate pre-HLS simulations.

    These tools and features collectively enable a thorough and efficient verification process before HLS, significantly reducing the likelihood of issues persisting into the final RTL implementation.

    After the HLS process is completed, the generated RTL design undergoes verification. This phase usually demands considerably less effort compared to the verification of manually written RTL. The reason for this reduced effort is that the majority of issues and bugs are addressed during the pre-HLS verification phase.

    During the post-HLS verification of the RTL, several key practices are followed:

    • The testbench and test scenarios employed during the pre-HLS phase are reused to test the post-HLS RTL. This ensures consistency in testing conditions and objectives.
    • Standard RTL verification tools and techniques are applied to ensure the RTL design meets the required specifications and standards.
    • Metrics for functional coverage and RTL code coverage are carefully monitored and achieved to ensure comprehensive testing of the design.
    • If necessary, formal verification tools can be used to check RTL properties and identify unreachable code, which can then be excluded from RTL coverage metrics. This step enhances the accuracy of the verification process.
    • Optionally, random stall injection can be automatically introduced to the transaction channels within the RTL Design Under Test (DUT) to rigorously stress test the design and improve coverage metrics. This technique further ensures the robustness and reliability of the RTL design.

    These practices ensure that the verification of the post-HLS RTL is thorough and efficient, leveraging the groundwork laid during the pre-HLS verification phase.