Project Topics
Get Complete Project Material File(s) Now! »
Discrete Event (DE) Simulation Kernel
The DE simulation kernel of SystemC provides the core features for the elaboration and simulation of models [25]. Elaboration creates the data structures required to support the simulation semantics: creates the module hierarchy, instantiates processes, bounds ports and channels, and sets the time resolution to be used (by default is 1ps). Simulation, runs the scheduler and deletes the data struc-tures created during elaboration. The elaboration and simulation semantics defined by the SystemC standard are summarized in Figure 2.4.
The scheduler is the heart of SystemC, it controls the timing and the order for executing the processes. The scheduler execution is performed in five phases: (1) initialization, where all defined processes are entirely executed (methods) or until the first wait statement (threads); (2) evaluation, where each process ready to run is selected and its execution is resumed (this may cause new processes ready to run in the same phase); (3) update, where channels are updated thanks to the results of the evaluation phase; (4) delta notification, where are analyzed the notifications made during the previous two phases: if they should be executed in the current simulation time then, the evaluation phase is re-executed; (5) timed notification, where the notifications are also evaluated: if they should not be executed in the current simulation time, such time is increased and then, the evaluation phase is re-executed. When no more notifications are present, the scheduler execution is stopped.
An important feature of the scheduler is that it supports the notion of delta cycle, which is an infinitesimal increase of time used to impose a partial order of the simulation actions. When the scheduler processes a delta cycle, it executes actions that are scheduled at the current time in the three consecutive evaluation, update and delta notification phases. At a particular simulation time, multiple delta cycles may occur.
In addition to the phases to create/destroy the module hierarchy, and to perform the scheduler execution, the SystemC standard offers four callbacks or virtual functions that can be overloaded by objects in the module hierarchy (modules, ports and channels) for allowing the applications to perform further elaboration and simulation actions. These callbacks are introduced below. before_end_of_elaboration(): it allows to perform elaboration actions depending on the properties of the module hierarchy, which can still be modified in this stage. The instantiation of modules, ports and channels; the port binding; and the instantiation of static processes are also allowed. Using this callback, for example, some modules could be instantiated to monitor the module hierarchy. end_of_elaboration(): it allows to perform elaboration actions, which do not need to modify the module hierarchy. In this stage, the instantiation of objects derived from the SystemC modules, ports, and channels; and the creation of static and dynamic processes are allowed. Using this callback, for example, an application can perform rule checking, diagnostics about the module hierarchy, and internal actions to prepare the hierarchy for simulation.
start_of_simulation(): it allows to perform actions at the start of simulation, for example: to open stimulus and files, or to print additional diagnostic messages. In this phase the instantiation of objects derived from the SystemC modules, ports, and channels; and the creation of dynamic processes are allowed.
end_of_simulation(): it allows to perform actions at the end of simulation, for example: to close files and to print simulation results. In this phase SystemC objects cannot be instantiated, and new processes cannot be created.
The four callbacks previously introduced are very important because they make SystemC an extensible language. We will take advantage of this fact for making the heterogeneous simulation a generic process.
SystemC Analog/Mixed-Signal (AMS) Extensions
The AMS extensions of SystemC were created for increasing the capabilities of the modeling language to allow the design, simulation and verification of not only digital software and hardware systems, but also of analog/continuous time behaviors. Therefore, they attempt to address the needs from the telecommunication, automotive, and semiconductor industry [26].
These extensions are defined as a C++ standardized library, which follows the same block-oriented approach of SystemC to allow the creation of multi-disciplinary models, that can be simulated in the Discrete Event (DE), Discrete Time (DT), and Continuous Time (CT) domains. They were standardized by the Accellera Systems Initiative organization [27] with the specific purpose of providing: a methodol-ogy for modeling embedded AMS systems [28], and also a complete definition of the AMS class library so that a SystemC AMS implementation can be developed [13]. At present, only one implementation of these extensions is available, it is the SystemC-AMS Proof-of-Concept (PoC) library [16] developed by the Fraunhofer Institute for Integrated Circuits IIS [29].
SystemC AMS Language Standard Architecture
Due to the heterogeneity involved in the complex embedded systems designed today, different de-scription styles and Models of Computation (MoCs) should be combined within a system. Therefore, the architecture of the SystemC AMS language standard, as shown in Figure 2.5, is structured following a layered approach [30].
Time-domain and small-signal frequency-domain simulation infrastructure First, the synchronization layer, indicated with 1 and constructed on top of the SystemC standard, is responsible for scheduling the SystemC AMS simulation: it determines the time points at which the digital and analog simulations are synchronized, it activates each solver, and it performs the communication among the different solvers. A solver in SystemC AMS, is the object instantiated not only for computing the solution of systems by mathematical methods, but also for performing the specific elaboration and simulation phases associated to a MoC.
Second, the solvers layer, indicated with 2 and constructed on top of the synchronization layer, computes the behavior of analog blocks and contains the algorithms proposed for solving specific systems. Third, the view layer, indicated with 3 , provides the interfaces used by the designer to write executable models, e.g. procedural behaviors or netlists. Besides, it contains the methods (accessible by solvers) for defining the structures to be used by each MoC during simulation. MoCs integrated in SystemC AMS attempt to follow the layered architecture, and represent the set of rules for defining the behavior and interactions among AMS components. The Timed Data Flow (TDF) MoC, allows discrete time modeling, and efficient simulation of signal processing algorithms and communication systems at the functional and architectural level; the Linear Signal Flow (LSF) MoC, supports modeling of continuous time behaviors through a set of predefined primitives for non-conservative system descriptions; and the Electrical Linear Network (ELN) MoC enables modeling of electrical networks, also in the continuous time domain.
Despite the three MoC independent formalisms and the well-separated layered architecture pro-posed by the standard, some drawbacks are present in the SystemC-AMS PoC implementation during the synchronization with the DE domain, and the addition of new MoCs. These aspects are discussed below.
SystemC-AMS PoC Synchronization
Based on the principle of describing continuous time behaviors to be embedded in timed data flow clusters (set of interconnected timed data flow modules), SystemC-AMS allows the communication and synchronization with the DE domain only through the TDF MoC.
The current implementation of the synchronization layer includes a Synchronous Data Flow (SDF) algorithm, which uses a static scheduler for determining the order in which the AMS modules should be executed, and the order in which the analog solvers should be activated during simulation.
Although this implementation can be efficiently simulated at high abstraction levels [31], it imposes restrictions for the other MoCs included in the prototype. Only one synchronization mechanism (by means of TDF MoC) is available between the DE kernel and the existing MoCs, then, all MoCs are always executed under the control of the TDF MoC, which imposes temporal semantics for synchronization. This means that the time resolution in other MoCs is limited by the time resolution of the TDF MoC.
SystemC-AMS PoC Extension
At present, the MoCs included in the PoC simulator are not sufficient for representing the behaviors of complex multi-disciplinary systems: extensions require new formalisms for describing, for example, electromechanical or fluidic behaviors.
The drawback in SystemC AMS is that mechanism to add new MoCs is not well defined. Only programmers and experienced designers, with an extensive knowledge of the current implementation, can include new solvers and synchronization methods [32].
Although there is not any document explaining the mechanism required to add new MoCs, two extensions have been proposed. The first [33], introduces a MoC enabling the modeling of non-linear networks; and states that in networks where DE, DT, and CT models are coupled, the synchronization becomes more complex. In this case specific details about the synchronization implementation are not provided. The second [34], introduces a MoC facilitating the unified description of the power transfer within parts of heterogeneous systems, thanks to the Bond Graph formalism. The addition of this MoC is only based on the PoC simulator’s internal details, which are not clearly specified in the standard. Due to the importance of the TDF MoC during the synchronization and the addition of MoCs in SystemC-AMS, the TDF MoC should be carefully analyzed.
Timed Data Flow (TDF) Model of Computation (MoC) in SystemC-AMS
The TDF MoC is based on the SDF formalism [35]. It is described as a DT modeling style that considers data as signal, which values are sampled with constant time steps. It was created with the aim of offering an efficient simulation approach for high abstraction levels. TDF not only keeps two important properties of the SDF formalism: the abilities to determine a static schedule, and to perform a periodic execution; but also adds temporal semantics to this SDF formalism, with the purpose of linking it with other timed MoCs. TDF is considered as a powerful modeling style for the creation of AMS descriptions in virtual prototypes, because it processes modules at DT points without directly using the dynamic schedule of the SystemC DE simulation kernel [10].
A TDF model, as shown in Figure 2.6, is basically composed of a set of TDF modules (indicated with 1 ) and it can be interconnected using TDF signals (indicated with 2 ). Connections among TDF modules and TDF signals are established through TDF ports (indicated with 3 ). Sometimes, a TDF model can interact with SystemC (SC) modules (indicated with 4 ). In this case, the SC modules which have SC ports (indicated with 5 ) are interconnected with the TDF modules using SC signals (indicated with 6 ). Connections from SC modules to TDF modules are established through TDF input converter ports (indicated with 7 ), and connections from TDF modules to SC modules are established through TDF output converter ports (indicated with 8 ). The set of interconnected TDF modules (indicated with 9 ) is called TDF cluster. In Figure 2.6, two clusters are presented: the first is composed by A and B modules, and the second is composed by C and D modules.
Table of contents :
List of Figures
List of Tables
1. Introduction
1.1 Context
1.2 Objectives and Research Contributions
1.3 Thesis Organization
2. Motivation and Problem Definition
2.1 Introduction
2.2 SystemC
2.2.1 Core Language Elements
2.2.2 Discrete Event (DE) Simulation Kernel
2.3 SystemC Analog/Mixed-Signal (AMS) Extensions
2.3.1 SystemC AMS Language Standard Architecture
2.3.2 Timed Data Flow (TDF)Model of Computation (MoC) in SystemC-AMS
2.4 Problem Statement
2.5 Conclusion and Outlook
3. State of the Art
3.1 Introduction
3.2 Frameworks Based onMetamodels and High-Level Programming Languages
3.2.1 Metropolis
3.2.2 Metro II
3.2.3 Ptolemy II
3.2.4 Preliminary Conclusions
3.3 Frameworks Specified Using SystemC
3.3.1 HetSC
3.3.2 HetMoC
3.3.3 ForSyDe
3.3.4 Preliminary Conclusions
3.4 Frameworks Extending the SystemC Discrete Event (DE) Simulation Kernel
3.4.1 SystemC-H
3.4.2 SystemC-A
3.4.3 Preliminary Conclusions
3.5 Conclusion and Outlook
4. Synchronization between the Discrete Event (DE) and Discrete Time (DT) Domains
4.1 Introduction
4.2 Discrete Event (DE) and Timed Data Flow (TDF) Synchronization Issues
4.2.1 TDF TimeManagement
4.2.2 Occurrence of Synchronization Issues
4.2.3 Preliminary Conclusions
4.3 CPN-Based Representation of DE and TDF Synchronization Interactions
4.3.1 Coloured Petri Nets (CPN) Extension
4.3.2 Representation of DE-TDFModels as Equivalent Timed CPN
4.3.3 Preliminary Conclusion
4.4 DE-TDF Pre-Simulation Analysis
4.4.1 Firing Transitions in Equivalent CPNModels
4.4.2 Verification of Final States in Equivalent CPNModels
4.4.3 Detection of Synchronization Issues in Equivalent CPNModels
4.4.4 Fixing Synchronization Issues in Equivalent CPNModels
4.4.5 Preliminary Conclusions
4.5 Conclusion and Outlook
5. SystemC Multi-Disciplinary Virtual Prototyping (MDVP) Simulator Prototype
5.1 Introduction
5.2 Model of Computation in SystemC MDVP
5.3 Modeling in SystemC MDVP
5.3.1 Model Components
5.3.2 MoC Hierarchical Approach
5.4 Solver in SystemCMDVP
5.4.1 MoC Synchronization
5.4.2 MoC Elaboration and Simulation Semantics
5.5 Elaboration and Simulation Phases in SystemC MDVP
5.5.1 Elaboration Phase
5.5.2 Simulation Phase
5.6 Overview of the SystemC MDVP Kernel Implementation
5.6.1 Kernel Requirements
5.6.2 SystemC MDVP Kernel Classes
5.6.3 SystemC MDVP Kernel Implementation Details
5.6.4 SystemC and SystemCMDVP Interconnection
5.7 Methodology to AddModels of Computation in SystemC MDVP
5.7.1 Addition ofMoC’sModules
5.7.2 Addition ofMoC’s Channels
5.7.3 Addition ofMoC’s Ports
5.7.4 Addition ofMoC’s Solvers
5.8 Conclusion and Outlook
6. Timed Data Flow (TDF) Model of Computation (MoC) in SystemC MDVP
6.1 Introduction
6.2 Requirements for the TDFMoC Implementation
6.2.1 Definition of the TDFMoC Interface
6.2.2 Specification of the TDFMoC Components
6.2.3 Location of the TDFMoC inside the SystemCMDVP ArchitecturalModel
6.3 TDF Elaboration and Simulation Phases in SystemCMDVP
6.3.1 TDF Elaboration Phase
6.3.2 TDF Simulation Phase
6.4 Overview of the TDFMoC Implementation
6.4.1 Implementation of the TDFModule
6.4.2 Implementation of the Predefined TDF Channel
6.4.3 Implementation of the Predefined TDF Ports
6.4.4 Implementation of the DE-TDF Solver
6.5 Execution of a Basic TDF Example
6.6 Conclusion and Outlook
7. Case Study: Vibration Sensor
7.1 Introduction
7.2 Case Study Description
7.3 Model Elaboration
7.3.1 Creation of Clusters and Instantiation of Solvers
7.3.2 Elaboration ofModules by means of Solvers
7.4 Model Simulation
7.5 Conclusion
8. Conclusion
8.1 Conclusion
8.2 FutureWork
Bibliography
