Analyzing SystemC Designs: SystemC Analysis Approaches for Varying Applications

Abstract

The complexity of hardware designs is still increasing according to Moore's law. With embedded systems being more and more intertwined and working together not only with each other, but also with their environments as cyber physical systems (CPSs), more streamlined development workflows are employed to handle the increasing complexity during a system's design phase. SystemC is a C++ library for the design of hardware/software systems, enabling the designer to quickly prototype, e.g., a distributed CPS without having to decide about particular implementation details (such as whether to implement a feature in hardware or in software) early in the design process. Thereby, this approach reduces the initial implementation's complexity by offering an abstract layer with which to build a working prototype. However, as SystemC is based on C++, analyzing designs becomes a difficult task due to the complex language features that are available to the designer. Several fundamentally different approaches for analyzing SystemC designs have been suggested. This work illustrates several different SystemC analysis approaches, including their specific advantages and shortcomings, allowing designers to pick the right tools to assist them with a specific problem during the design of a system using SystemC.

Figure 1

Arbiter example SystemC code. This provides a module scalable that decides which of the NUMC connected devices is granted access to a shared resource (such as a bus or something similar). Notice that a) the constructor SC_CTOR(scalable) that is executed each time a scalable arbiter is created is pure C++ code but highly procedural, generating as many outputs, inputs and RTLCell submodules (which are omitted in this figure) as needed and interconnecting them as required and b) the start of the simulation phase using the sc_start command, splitting the code into the elaboration phase (before starting the simulation) where new objects are created and the simulation phase (after starting the simulation) where the system is run. Figure 2 illustrates the resulting design.

Figure 2

Diagram of the scalable arbiter shown in Figure 1 for a number of cells NUMC = 2.

Figure 3

Parsing SystemC: Parsers rely solely on inspecting the source code. While this is a straightforward approach for extracting information and does not rely on a complex architecture, statically analyzing C++ source code is a non-trivial problem.

Figure 4

Hybrid approaches split the analysis into two parts. First, the static information is extracted from or by the compiler, which is translating the program anyway. Second, the executable file generated by the compiler is executed, and the dynamic information (esp.SystemC object instances) is extracted from the running program.

Figure 5

Aspect-oriented programming allows the designer to combine the original SystemC source code with aspect code. A preprocessor (the aspect weaver) combines these into new source code, which is compiled as usual. The aspect code can be used to, e.g., make the resulting binary extract the needed information as needed.

Figure 6

The feedback loop that is implemented for coverage-driven test generation using machine learning algorithms: an AI retrieves the output generated by a given system and generates new input to increase, e.g., a given coverage metric.

Figure 7

Cone of influence analysis allows a designer to inspect from where, e.g., a faulty signal originated. While this technique is easy to implement on, e.g., the gate level, where full netlists are available, the nature of SystemC's black-box-like modules does not allow a simple extraction of these structures (dotted lines). (a) At the RTL or gate level; (b) at the ESL.