Project Topics
Get Complete Project Material File(s) Now! »
Heterogeneous Systems Virtual Prototyping Challenges
How does one simulate a heterogeneous system? The answer is not trivial. The heterogeneity aspect can be difficult to address due to the gap between the different disciplines involved in the design of heterogeneous systems (e.g. software engineering vs biological engineering). We have identified several challenges which represent the different issues that may occur when dealing with the simulation of heterogeneous systems and the requirements induced by these issues.
Smooth Management of Heterogeneity
In the context of heterogeneous systems, one key aspect is to define what it is intended by the term heterogeneous. Heterogeneity can be defined as the use of several simulation tools, or the use of different languages, semantics, disciplines, etc. In such a context, a clear definition of the term heterogeneity and the composition of this heterogeneity are required.
These components (entity), which defined the heterogeneity, must be well-defined, not only from the simulator viewpoint, but also from the user viewpoint. The simulator requires a well-known distinction between components in order to correctly simulate each component within its associated
environment. The user should have access to well-defined components in order to correctly and easily design the system he wants to simulate. Our approach relies on the definition of these heterogeneous entities by means of interacting Models of Computation (MoCs). We must therefore provide a well-defined interface for these MoCs to interact with the kernel, without neglecting the user’s interface.
Sound Management of Interacting Entities
Once heterogeneity has been clearly defined, one of the key challenges lies in the interaction between the entities that define this heterogeneity and their composition. They usually express different semantics, with potentially different time abstraction. Incompatibility between physical domains or design errors should be detected by the simulator. It is necessary to be able to identify when two components are connected together when they should not be.
As such, we need a well-defined interaction mechanism between different heterogeneous entities. It should express the constraints associated with each entity and, consequently, it should enable and define their composition. Interaction is not limited to the composition of the heterogeneous entities; it is also required to be able to express semantics information if needed. This information is associated with the data handled within each entity (such as dimension or unit).
Flexible Virtual Prototyping Environment
Since multi-physical systems represent non-homogeneous applications, various physical modeling environments may be used to model and simulate them. Multiple approaches exist to perform simulation of heterogeneous systems, from a global simulation framework to the use of multiple specific simulation tools dedicated to each discipline. This situation can be simply summarized as the choice between a unified, unique simulation environment and a co-simulation environment. Both approaches have their pros and cons, but we believe performing the simulation of the whole system within the same simulation environment allows us to truly appreciate the dependencies and all the interactions involved in the system. It is crucial that each discipline take part in the design exploration phase of the system. Consequently we have to set up an environment which enables the coupling of all the disciplines within the same simulation framework.
In the scope of heterogeneous systems simulation, we have to provide a highly flexible framework. Flexibility is understood, in this work, in the sense that the simulator must be able to evolve and to simulate any heterogeneous system. Naturally, we want to perform the simulation of a system which involves several heterogeneous entities, therefore we cannot afford to provide a rigid, static simulator.
Heterogeneous entities which may take part in the conception of a multi-physical system are numerous, ranging from biological to optical through mechanical, etc., without forgetting the different semantics or time abstraction associated. It seems unlikely that we would be able to define every existing heterogeneous entity and, furthermore, to define those which do not yet exist. In consequence, heterogeneous simulation requires a way to easily integrate new heterogeneous entities into the simulator, in a convenient manner.
Multi-Disciplinary Monitoring
In the context of systems simulation and, more specifically, in the case of heterogeneous systems, the monitoring mechanism constitutes an important feature of the simulator. This mechanism must adapt to, and fit, the different digital/physical parts involved in the design. With the term monitoring, we refer to a mechanism which aims to observe and record information about the signals of a system, independently of the outcome of this observation (tracing, profiling, etc.).
The information associated with a digital component (such as a micro-controller) is different from that associated with an analog component (such as a thermal sensor). The relevant data may vary from one domain to another and the way to express them may also differ. Thus, setting up the monitoring mechanism of such systems represents a challenge in itself since it is dependent on the domain modeled, and yet it must remain a generic mechanism in order to manage all the different disciplines and ensure the flexibility of the simulator.
Multi Disciplinary Monitoring Mechanism
Monitoring is a mechanism which aims to observe and record information about a system. It may be used, for example, to detect threshold crossing, to perform profiling evaluation on a system or as a tracing mechanism. Tracing mechanisms are mainly used for debugging purposes, through the log of information during the simulation.
Monitoring, threshold detection, profiling and tracing functionalities, represents an important feature in a simulator framework. We think that these functionalities should be developed simultaneously. Performing the detection of threshold crossing, the profiling or the tracing involves the same mechanisms, only the outcome is different. All of these capabilities require a mechanism to probe the system in order to gather relevant, specific information.
In the following sub-sections we will introduce existing solutions that may fit the requirement to provide an efficient monitoring mechanism.
Aspect-Oriented Programming (AOP)
Object-Oriented Programming (OOP) [62] allows us to break up a problem into a set of reusable objects. Although these objects mainly describe a single functionality, they usually share common, secondary behaviors with other objects. These common behaviors are usually scattered throughout the whole system, as shown on Figure 3.5, breaking the encapsulation principle. You can see the same behavior replicated in different components (objects).
Think of the tracing of the functions called during the simulation. You would have to insert print function within every function of your system (potentially the exact same code line)! These common behaviors are identified as cross-cutting concerns. Cross-cutting concerns denote behavior that cuts across the boundaries of assigned responsibility for a given modular element. They are often shared, and common. They may describe process synchronization, location control, timing constraints, persistence, failure recovery, tracing, monitoring, verification, etc.
Timed Data Flow (TDF)
Timed Data Flow (TDF) Model of Computation is based on the timeless SDF theory. It uses a discrete time representation and introduces time-stamped sampled data. As with DE Model of Computation, the designer describes the behavior associated with a TDF module and also handles the communication between them through ports and signals.
TDF Signal TDF Module TDF Port composed of three modules (A, B and C), four ports and two signals connected together as a TDF cluster. Again, the behavior associated with these modules is specified by the designer. Module A writes data to its port then the data is transported to the module B through a signal. As before, the communication between B and C is achieved in a similar fashion. Within the TDF MoC you have to set out specific attributes in order to correctly represent the system. TDF requires that you define a timestep value which represents a time period; the meaning can vary depending on the object to which this attribute is applied. Applied to a module it represents the time period in which the processing() function associated to this module should be executed. Applied to a port, it represents the time period in which the samples are read or written by this port. One have to specify a rate attribute associated with a port. If applied to an output port, the rate attribute defines the number of sample written by the port in question and when applied to an input port, the number of sample read by this port. One also may specify a delay attribute associated with a port (zero by default) which defines the initial number of samples available in a port when the simulation starts.
MDVP Hierarchical Approach
Since our master-slave semantics naturally fit with hierarchical behavior, it is only rational that SystemC MDVP should rely on a hierarchical heterogeneity approach. This allows us to take full advantage of the interaction mechanism between Models of Computation. Starting with the flattened representation of the system (provided by SystemC), the framework creates a hierarchical tree with respect to the design and the master-slave interactions. This means that the framework constructs a hierarchical abstraction of the system wherein each node represents a Model of Computation. Building SystemC MDVP upon SystemC should be interpreted as SystemC being the master of the entire SystemC MDVP environment with respect to our interaction semantics. From a framework point-of-view, we need to respect SystemC semantics and SystemC has to be the root of the hierarchical tree. This hierarchical tree acts as an efficient representation which allows us to easily identify the scope of a Model of Computation and, therefore, to handle automatically the interactions between MoCs since the master-slave semantics are respected at all points in the hierarchy.
The scope of a Model of Computation represents all the interconnected modules belonging to the same MoC; it also includes the modules belonging to a slave MoC. This scope represents a node in the hierarchical tree of the system and we refer to it as a cluster. To detect the scope-limits associated with a Model of Computation, we identify special ports – the converter ports. As previously mentioned these ports provide compatibility among MoCs and represent their borders. Regarding the hierarchical tree, regular ports are inside a hierarchical node whereas converter ports are at the border of a node in order to enable communication with the higher hierarchical node.
Table of contents :
List of Figures
List of Tables
List of Algorithms
List of Listings
1 Introduction
1.1 Context
1.2 Thesis Organization
2 Problem Statement
2.1 Introduction
2.2 Heterogeneous Systems Virtual Prototyping Challenges
2.2.1 Smooth Management of Heterogeneity
2.2.2 Sound Management of Interacting Entities
2.2.3 Flexible Virtual Prototyping Environment
2.2.4 Multi-Disciplinary Monitoring
2.3 Contributions
2.4 Conclusion
3 Related Work
3.1 Introduction
3.2 Coupled Simulation
3.3 Frameworks
3.3.1 Ptolemy II
3.3.2 ModHel’X
3.3.3 Modelica
3.3.4 Matlab
3.3.5 Metropolis
3.4 SystemC-based Frameworks
3.4.1 SystemC-A
3.4.2 SystemC-H
3.4.3 HetSC
3.4.4 SystemC AMS
3.5 Multi Disciplinary Monitoring Mechanism
3.5.1 Aspect-Oriented Programming (AOP)
3.5.2 LLVM – Clang
3.6 Conclusion
4 SystemC MDVP: Principles
4.1 Introduction
4.2 Models of Computation
4.2.1 Discrete Event (DE)
4.2.2 Timed Data Flow (TDF)
4.2.3 Bond Graph (BG)
4.2.4 Electrical Network (EN)
4.2.5 Abstract representation of a MoC
4.3 Interaction Mechanism
4.4 MDVP Hierarchical Approach
4.5 User Profiles
4.5.1 Simulator Architect
4.5.2 MoC Architect
4.5.3 SoC Architect
4.6 Conclusion
5 SystemC MDVP: Implementation
5.1 Introduction
5.2 SystemC MDVP Kernel Representation
5.2.1 SystemC MDVP MoC Abstraction
5.2.2 SystemC MDVP core classes
5.3 Elaboration Phase
5.3.1 Composability / Static Analysis Sub-phase
5.3.2 Clustering Sub-phase
5.3.3 Solver Instantiation Sub-phase
5.3.4 Basic Behavior Block Elaboration Sub-phase
5.3.5 Port and Channel Elaboration Sub-phase
5.3.6 Elaboration conclusion
5.4 Simulation Phase
5.4.1 Simulation Mechanism
5.4.2 Simulation Opportunities
5.5 Conclusion
6 SystemC MDVP: Monitoring
6.1 Introduction
6.2 Principles
6.2.1 SystemC Monitoring
6.2.2 SystemC MDVP Monitoring
6.3 Monitoring Mechanism
6.3.1 Monitor Handler Instantiation
6.3.2 Monitor Slot Instantiation
6.3.3 Initialization
6.3.4 kernel Routine
6.3.5 End of Simulation
6.4 Conclusion
7 New MoC Integration Methodology
7.1 Introduction
7.2 New MoC integration methodology
7.2.1 Interfacing Step
7.2.2 Implementation Step
7.2.3 Interaction Step
7.3 Application to SPH MoC
7.3.1 Interfacing Step
7.3.2 Implementation Step
7.3.3 Interaction Step
7.4 Conclusion
8 Validation Case Studies
8.1 Introduction
8.2 Application Based on SPH
8.2.1 Case Study Description
8.2.2 Results
8.3 Application based on RFID
8.3.1 Case Study Description
8.3.2 Results
8.4 Conclusion
9 Conclusion
9.1 Conclusion
9.2 Perspective
Publications
Bibliography
