[SoC Modelling] Modelling Abstractions

An SoC combines hardware and software to communicate with the outside world through various interfaces. Ideally, the design process for an SoC would involve a modeling system that supports all stages from design input to manufacturing. However, it’s practically impossible to model an entire SoC in detail and simulate the operating system booting within a reasonable time frame. For instance, a model running a million times slower than actual hardware would take 115 days to simulate a 10-second boot sequence! Therefore, ESL virtual platforms need to support various levels of abstract modeling and facilitate interactions between them.

Most ESL models are based on Event-Driven Simulation (EDS). An EDS simulator defines various types of discrete events, and the simulation progresses through time by tracking these events. The key differences in modeling are mainly related to the types of events used. These can range from changes in individual digital net states to the transmission of entire Ethernet packets. The level of abstraction depends on the application requirements, and the focus will typically be on lower-level details.

The general classification of modeling levels includes:

1. Functional Modeling: The simulation output is accurate. In functional modeling, the internal structure does not need to match the actual SoC, but the critical aspect is that the final output is the same. This model checks whether the SoC performs its intended functions correctly, focusing on the accuracy of external results rather than internal implementation. This approach is useful for validating the basic operations of the SoC and establishing a broad outline in the early design stages.
2. Memory-Accurate Modeling: Ensures that the content and layout of the memory are accurate.
3. Cycle-Lumped or Untimed TLM: Complete transactions, like data transfers between IP blocks, are modeled as atomic events without timestamps. The total cycle count after program execution is accurate, but individual cycles are not modeled. Typically, sub-models update the cycle count after completing specific tasks.
4. Stochastic or Loosely Timed TLM: The number of transactions is accurate, but their order may vary. Each transaction is timestamped based on a standard queuing model, allowing for the reporting of overall execution time.
5. Approximately Timed TLM: Both the number and order of transactions are accurate, and the extent of their overlap or interference is measured.
6. Cycle-Accurate Simulation: The number of clock cycles used is exact, and the tasks performed in each cycle are modeled precisely. Synthesizable RTL simulations provide this level of detail.
7. Net-Level EDS: The netlist of the subsystem is fully modeled, accurately reflecting the sequence of net changes within each clock cycle.
8. Analog and Mixed-Signal Simulation: Models the voltage waveforms at specific nodes.

Before diving deeper into these modeling levels, there are two additional terms worth defining:

1. Programmer-View Accuracy: This model accurately reflects the contents of memory and registers visible to the programmer. The programmer’s view (PV) includes only the structurally significant registers that software programmers manipulate through instructions. Other registers specific to hardware implementation, such as pipeline stages or holding registers used to overcome structural hazards, are not included in the PV model. If the PV model incorporates a concept of time, it is referred to as PV+T. Similarly, PV+ET indicates the modeling of both energy and time usage.
2. Behavioral Modeling: This term lacks a precise definition but generally refers to simulation models that differ from the actual implementation. For instance, a handcrafted program might be written to model the behavior of a specific component or subsystem. More specifically, it can refer to models that use imperative threads, akin to software programming, to represent the behavior of components.

In some application classes, the starting point for the SoC may be a software program that generates the same outputs the SoC is expected to produce. This is known as a Functional Model. For example, in IoT devices, this model must provide identical responses over the network. For an RF transmitter subsystem, it could record analog waveforms that would be sent to a real antenna into a file on a modeling workstation. Although these models do not represent the structure of the SoC implementation, they define the necessary fundamental behaviors and provide reference data to evaluate SoC-based solutions and their ecosystem.

Typically, an SoC includes a substantial amount of memory. The next step is determining the number of logical memory spaces required within the SoC and planning their detailed layout. The software in a functional model should be divided between parts representing the hardware and the software running within the SoC. This model ultimately includes several arrays that will be stored in one or more actual SRAM and DRAM components in the final hardware. In a memory-accurate model, the content of each array in the model matches the actual memory content in the final implementation. By manually calculating the frequency of operations on these arrays or the number of iterations of internal loops, one can make preliminary estimates of the processing power and memory bandwidth required by the SoC. These figures can be analyzed in a simple spreadsheet to make an initial estimate of the final power consumption and battery life.

In ESL modeling, the next step is creating Transaction Level Models (TLMs). TLMs do not need to represent numerous actual nets or interconnect components, allowing them to run much faster than net-level simulations. TLMs can optionally include timing, power, and energy.

A cycle-accurate model captures every state bit of registers and RAM within a subsystem. These state bits are updated on each clock cycle to reflect new values at each clock edge. To enhance performance, cycle-accurate models often use simple two-valued or four-valued logic systems rather than the richer logic of Verilog or VHDL. A cycle-callable model is a cycle-accurate model of a single clock domain. Essentially, it is composed of subroutines that can be called by the parent simulator’s thread, advancing the model one clock cycle at a time. For example, a cycle-callable model of a counter would be a subroutine that increments the counter value. Low-level models represent every flip-flop and bus of the actual implementation, and these models are typically based on the RTL implementation of the components.

As discussed, low-level simulations can also model voltage waveforms on nets, which is necessary for analog and mixed-signal systems but generally not required for digital logic.

ESL Flow Diagram

The ESL flow is primarily based on C++ and commonly utilizes the SystemC TLM library. In SoC design, C/C++ is mainly used for behavioral modeling of peripherals, embedded applications, operating systems, and device drivers. The interface specifications for the API between hardware and software are found in .h files, which are used by both hardware and software. These C++ files are depicted at the top of the diagram.

To generate embedded machine code for SoC-level products, the software side is compiled using compilers suited for the embedded core (e.g., gcc-arm). On the hardware side, the behavioral models of the hardware are converted into Register Transfer Level (RTL) and Gate-level representations through various methods. This process is illustrated diagonally from right to left in the diagram.

Conversely, the fastest ESL models are typically generated through a path that runs from left to right. This path integrates hardware models and embedded software, allowing the entire system to be executed as a single application program, provided appropriate coding guidelines are followed. These hybrid models can run faster than real-time and, in some cases, may execute even quicker than an embedded SoC core if a high-performance modeling workstation with more powerful processors is used.

Example of Performance Enhancement

Consider a scenario where a network packet is received by a device driver and transferred to memory via the bus. In the actual implementation, this would involve tens of thousands of gate output transitions. Using net-level simulation, simulating each gate transition might require 100 instructions on the modeling workstation. However, with an appropriate ESL coding style, the packet reception transaction can be modeled as a simple method call from one component to another, requiring fewer than 100 instructions in total. With careful memory management, data transferred through transactions need not be copied; only pointers to buffers need to be transmitted.

Key Points

Instruction Set Simulator (ISS): An ISS can be used to interpret the machine code of embedded cores. The best ISS implementations identify frequently used execution paths and cross-compile these codes into native machine code for the modeling workstation, achieving performance faster than real-time.

Conversion between RTL and C++ Models: If the RTL model significantly differs from the initial high-level model or if no high-level model exists, RTL designs can be converted into C++ models using standard tools. Tools like Verilator are often used for such conversions. For example, Arm uses the Carbon toolchain to provide C++ models generated from internal RTL.

This flow is critical in SoC design, enabling fast and efficient modeling and simulation.

SystemC EDS Kernel

The SystemC EDS Kernel is one of the core components of the SystemC library, also known as the Event-Driven Simulation (EDS) kernel. It plays a central role in managing and executing simulations in SystemC. SystemC is a C++-based hardware design language that enables the simulation of hardware behavior in a software-like manner.

Roles of the SystemC EDS Kernel

1. Event-Driven Simulation Management

• The EDS Kernel manages events occurring during hardware simulation. Hardware simulation typically progresses by updating states and processing subsequent events whenever an event (e.g., signal change, timer event) occurs.
• In SystemC, each component (e.g., modules, processes) generates or reacts to events, performing actions accordingly. The EDS Kernel sorts and processes these events in chronological order.

1. Synchronization and Scheduling

• The SystemC EDS Kernel synchronizes processes and events according to simulation time, ensuring that the simulation proceeds with accurate timing, similar to how actual hardware operates based on clock signals.
• The kernel determines when each process should execute and the order of event occurrences, allowing verification of the hardware design’s accuracy and timing.

1. Minimization of Context Switching

• To enhance performance, the EDS Kernel is designed to minimize context switching, reducing transitions between processes and helping run simulations as fast as possible.
• For instance, when multiple processes run simultaneously in a hardware design scenario, the EDS Kernel schedules these processes to execute as efficiently as possible.

1. Support for Hybrid Simulation

• The SystemC EDS Kernel supports hybrid simulations between software and hardware, allowing the entire system to run as a single program and often simulating faster than real hardware.
• This capability enables rapid and efficient validation of complex SoC performance.

The SystemC EDS Kernel is essential for managing event-based operations in hardware simulations, synchronizing processes and events according to simulation time, and minimizing context switching for efficiency. It is a critical element in simulating and verifying complex SoC designs, making it central to hardware and system modeling using SystemC.

Role of SystemC

While SystemC is a vital tool in ESL (Electronic System Level) design, ESL design does not exclusively rely on SystemC. Although SystemC is a powerful and widely used tool for ESL design, there are various methods and tools available for performing ESL design.

SystemC excels particularly in C++-based hardware design and simulation, supporting high levels of abstraction, such as Transaction Level Modeling (TLM). For this reason, it is widely used in SoC (System on Chip) design and plays a significant role in the ESL design flow.

Various Approaches in ESL Design

However, ESL design can also be achieved without SystemC. Here are some examples:

• Other Languages and Libraries:
• Other hardware design languages or libraries can be used for ESL design. For example, MATLAB/Simulink is often employed for hardware and system-level modeling and simulation.
• Python-based MyHDL, VHDL, and Verilog are also used for high-level modeling and simulation.
• Dedicated ESL Tools:
• Commercial ESL tools provided by companies like Cadence, Synopsys, and Mentor Graphics enable ESL design without using SystemC. These tools support ESL design flows and facilitate integrated hardware and software design at various levels of abstraction.
• Non-Simulation-Based Verification:
• ESL design does not necessarily need to be simulation-based. Methods like mathematical verification, formal verification, and model checking are also used in ESL design. These methods can be employed independently of SystemC and play a crucial role in ensuring the accuracy of SoC designs.

While SystemC is a highly useful and powerful tool in ESL design, it is not indispensable. ESL design can be carried out using a variety of tools and methods, each chosen according to specific requirements. The success of ESL design depends on how well designers select and use the appropriate tools and methods for their needs, even without SystemC.