System Modeling Language (SysML) is a Unified Modeling Language (UML) profile that allows the creation of standard descriptions of a system. However, this profile is too generic to address embedded and real-time system design. The Modeling and Analysis for Real-Time and Embedded Systems (MARTE) UML profile attempts to fill this gap by providing elements from both embedded software and hardware engineering. Unfortunately, it remains mainly descriptive in nature, because no commercial tools are available to simulate the models and extract performance data. CoFluent Design has therefore developed a methodology for UML to provide a comprehensive framework and guidelines for the joint use of UML, SysML and MARTE. The methodology offers simulation of multicore/multiprocessor hardware/software embedded system and chip models, enabling designers to observe system behavior and analyze performance properties. The CoFluent methodology delivers modeling rules and methods with tool support.
This paper presents the CoFluent Design methodology for the Unified Modeling Language (UML) and associated tool support. The methodology is based on UML with the Systems Modeling Language (SysML) and the Modeling and Analysis for Real-Time and Embedded Systems (MARTE) profiles. It allows automatic model transformation from this format to the CoFluent domain-specific language (DSL).
The methodology can be described as a set of modeling rules and restrictions applied to SysML/MARTE. These rules enable the simulation of multicore/multiprocessor hardware/software (HW/SW) system models for behavioral and performance data prediction without restricting the expressiveness of SysML and MARTE. The CoFluent methodology for UML does not add new elements to standard profiles. It does, however, offer an optional profile to represent several features related to CoFluent DSL and necessary for efficient embedded system modeling and simulation.
An example of a model for a multimedia application is used to illustrate the design flow. It is a high-level description of an audio-video decoder running on a generic platform. The generic platform consists of a processor and a hardware accelerator.
The model packaging reflects the separation between the application and platform models. The application or functional model includes elements of the environment-generating stimuli for system simulation under specific scenarios or use cases. The application model is mapped onto the platform model to add generic physical constraints. The result is a refined virtual system model.
- Functional architecture describes applicative structures with timed behaviors. Functions execute in full parallelism. They synchronize through events and exchange data.
- Physical architecture describes a generic execution platform, including processing units such as a CPU or IC, physical links such as bus or routing network, storage units including memories, and firmware such as schedulers. In this view, the platform is ‘empty’ in the sense that a CPU executes no instructions and an IC is not yet wired with logic.
- Virtual system architecture is the result of a mapping step that consists of allocating functions to processing units and data to storage units, and of routing inter-processor data on physical links. This mapping or allocation can be seen as a model itself. The obtained virtual system model is the functional architecture with execution constraints such as scheduling, bus arbitration and memory size.
Packaging is also important to maximize both reuse and model readability. Figure 1 shows the proposed ‘package’ hierarchy. The package named Functions contains functions of the application model. These may be reused in other models. ComponentsLib contains components of the platform model, which also may be reused in other models. Application and Platform packages contain models themselves. The Allocation package contains the allocation model, using elements from application and platform models.
Package diagram of the model
Two other packages can be defined containing the data types and the functional relations (data communication and synchronization elements between functions). It is merely illustrative packaging, since only Application, Platform and Allocation packages are mandatory.
The application model is a set of functions exchanging data and/or synchronizing through events, shared variables and message queues. Functions can be internal to the system under design or pertain to the environment, and thus contribute to exercising the chosen use-case scenario by interacting with the system under a stimuli/responses scheme. There are two different aspects in an application model.
- The structural aspect encapsulates the different functions and the relations, or data paths, between them.
- The behavioral aspect is the control flow used to process data and synchronize functions.
Functions encapsulating other functions are called container functions. Functions defined at the lowest hierarchical levels are called leaf functions.
A SysML internal block diagram (IBD) is used to represent the applicative structure of the system. A top-level SysML ‘block’ is used as a root container. Functions of the lower hierarchical level are all ‘properties’ of the top-level blocks. Blocks appearing in the Application ‘package’, or in an imported package, define the ‘types’ of these properties. Sub-functions of these blocks are also represented as properties, and so on.
The block definition diagram (BDD) in Figure 2 (p. 23) shows the functional hierarchy. This representation is not required in order to correctly represent the CoFluent model: an IBD is sufficient. However, a BDD aids in understanding functional hierarchy in the application, particularly the distinction between leaf and container functions. Moreover, a BDD is compliant to existing UML modeling methodologies and most designers feel more comfortable having both a BDD and an IBD.
BDD of the application
Leaf functions are the lowest hierarchical level functions defined in the Functions package of the SysML model. Using these blocks as types for the container functions properties enables reuse, as other properties can be typed with these blocks. The blocks can be reused in the same model or in other application models.
The connections between application elements are represented in the IBD of the top-level block, named AppliStruct for the example as shown in Figure 3. Relational elements are represented by properties with two input and output ‘ports’. The types of these properties are SysML blocks defined in the FunctionalRelations package with the following ‘stereotypes’ from the MARTE profile:
IBD of the application
- ‘NotificationResource’: event enabling synchronization between functions (equivalent to an ‘event’ in CoFluent);
- ‘SwMutualExclusionResource’ with ‘SharedDataComResource’: shared variable enabling asynchronous data read/write (equivalent to a ‘shared variable’ in CoFluent); and
- ‘MessageComResource’: enabling synchronous buffered data exchanges (equivalent to a ‘message queue’ in CoFluent).
There are ‘assembly connectors’ between ports of different properties. ‘Delegation connectors’ are used for ports forwarding between external and internal functions. Data types are defined by blocks in the Application package or imported from other packages. The data types are carried by the ports. Ports are MARTE ‘FlowPorts’, with directions ‘in’, ‘out’, ‘inout’.
Figure 4 shows the type of the selected flow port. Here, the data type DefVideoSequence is a block defined in the DataTypes package. As shown on the IBD, an application is composed of three main parts.
Port type definition
- The scenarioController (bottom left-hand corner) provides the videoSequence and controls execution of video and MP3 players.
- The videoPlayer (top) decodes the video-Sequence.
- The mp3Player (bottom) decodes the MP3 encoded sound contained in the videoSequence.
(At this point, it is worth making an important observation about stereotypes applications. The models described in this article make an extensive use of MARTE stereotypes. It is also possible to apply optional CoFluent stereotypes. Stereotypes applied to blocks may be also applied to properties typed by these blocks. Stereotypes can even be applied only to properties. For instance, it is possible to apply a stereotype to a property of a container function in the application model, independently from the stereotype applied to the block defined in the function library as type of the property. If both block and property are stereotyped with the same stereotype, ‘tagged values’ from the property will be used when transforming to the CoFluent model).
Leaf function types are blocks that can contain a ‘behavior’. An ‘activity diagram’ can describe this behavior. Placing the activity under the block in the hierarchy of the SysML model is sufficient to express that the activity is representing the behavior of the block. However, this link can be explicitly described by setting the ‘ClassifierBehavior’ property of the block.
Figure 5 depicts an example of an activity, MP3DecoderAct. Inputs and outputs of the activity are ‘activity parameter nodes’, allocated to corresponding ports of the application structure via the MARTE ‘Allocate stereotype’.
SysML activity diagram
‘Input’ and ‘output’ pins allow read/write on ports in behaviors. ‘Opaque actions’ model operations to be performed, (e.g., data read/write and processing). ‘Decision node/fork’ and ‘join/fork’ and ‘merge’ can be used in the control flow description. In Figure 5, the first decision node represents an infinite loop, whereas the second is a loop with condition, where LoopIndex < NbSamples.
SysML activity diagram
For opaque actions, the MARTE stereotype ‘TimedProcessing’ can be used in order to set the duration of an operation. C/C++ is used as the action language. Code can also be added in the opaque action body for SystemC-based simulation within CoFluent Studio after model transformation.
CoFluent Application Profile
Use of the CoFluent profile is optional. The Application package of the CoFluent profile provides access to the following CoFluent features.
- Specific model element attributes. These include read and write times for relations and specific CoFluent functions such as sampled function, clock generator, divider, dynamic function, and message routing function.
- Specific C/C++ code. These include global declarations, pre-processing and post-processing code, local declarations for each function, and type definitions.
- Generic parameters and variables. These are used to change values in the model at simulation time.
There are four stereotypes for generic parameters: ‘EnumerationGP’ for enumerations, ‘IntegerGP’ for integers, ‘FloatGP’ for floats and ‘DoubleGP’ for doubles.
In order to add an integer generic parameter to the UML model, the parameter must first be defined with a block to which the right stereotype is applied. Then, ‘attribute’ values of the parameter can be set. Lastly, a property must be added in the block to which the parameter is applied. The type of this property is the generic parameter block previously defined. If the generic parameter is global, a property typed by the generic parameter block must be added to the root block of the application.
Tools: UML modelers and CoFluent Studio integration
The CoFluent Application profile and associated CoFluent plug-in are currently available for No Magic’s MagicDraw UML modeling tool. The SysML/MARTE application model can be captured in MagicDraw and then imported from CoFluent Studio. MagicDraw can also be directly integrated into CoFluent Studio as an Eclipse plug-in, with one-click integration for the user, in order to work within a single modeling environment.
MagicDraw customization has been developed to ease the modeling guidelines application and use of the CoFluent profile. A MagicDraw validation module for CoFluent is available to ensure that the SysML/MARTE model is compliant with the methodology and can be transformed into a CoFluent model. All these elements are part of the CoFluent plug-in for MagicDraw.
(With regard to attributes and algorithms capture, the CoFluent model attributes (calibration data) and algorithms that are not captured in the SysML model can be edited in CoFluent Studio).
The CoFluent profile, which includes Application, Platform and Allocation packages, is also available for the Papyrus UML modeling environment. However, a Papyrus-to-CoFluent Studio model transformation is not commercially available.
Application model execution in CoFluent Studio
The SysML/MARTE application model can be automatically transformed into a CoFluent model. The transformation is implemented with Java and the Eclipse Modeling Framework (EMF). The output is a tool-compatible model compliant with the CoFluent meta-model. The CoFluent meta-model conforms in turn to Ecore, Eclipse’s Meta-Object Facility (MOF).
In CoFluent Studio, the obtained Ecore model is used to automatically generate a SystemC transaction-level model (TLM) that includes the user-defined C/C++ code. The generated code uses CoFluent SystemC 2.2 and the TLM 2.0-based simulation library. SystemC models can be generated for various environments such as the OSCI SystemC library, CoWare, Synopsys Innovator, Synopsys System Studio and Mentor Graphics Questa. This feature enables reuse of CoFluent-generated SystemC models as test cases for further verification and validation within a wide range of virtual platform environments.
Once the SystemC model is generated and compiled, the model can be run to extract behavioral and timing information. Deadlocks or conflicts in data accesses can be identified. Latencies can be measured. It is also possible to change generic parameter values and see how the changes impact model execution.
Figure 6 (p. 26) shows the model simulation results in CoFluent Studio. The user monitors the activity of the different functions, as well as the data exchanges between the functions, in the timeline (TL) window. With this feature, the user can clearly recognize the messages that are sent to the two players. The different functions and message queues related to the MP3 player are represented in the upper part of the window. The video player is located in the lower part.
CoFluent Studio behavioral model simulation results
The CoFluent Studio timeline is similar to a UML sequence diagram displayed horizontally (time runs from left to right). It offers additional capability as well. The state of each function—running, blocked and idle—can be observed and analyzed in detail. Computation and data read/write transaction durations can be precisely observed since the model execution is fully timed.
The Report window displayed below the timeline in Figure 6 (p. 26) is used to print text information during the simulation. Just as software programmers can add ‘printf’ statements in their code for printing information during the program execution, CoFluent users can also monitor and print out information during the simulation execution in this window.
CoFluent Studio behavioral model simulation results
Image processing on the right side of the screen shows the different steps of image processing through the video channel. The first picture represents the input picture that is processed. Next, the content of the destImage message queue is shown. Finally, the output picture that is available in videoOutput is displayed. It is also possible to plot variables against the execution time to monitor their values, such as the audio output level of the mp3Player in the window shown in the lower right section of the screen.
The platform is a set of computation and storage resources connected by physical links. It is represented using the ‘Hardware Resource Model’ from the MARTE profile. The platform structure is described by an IBD. A top-level SysML block is used as a root container.
Components of lower hierarchical levels are properties of the top-level blocks. Types of these properties are defined by MARTE stereotyped blocks, appearing in the Platform package or in an imported package. Sub-functions of these blocks are also represented as properties, and so on.
Schedulers can be allocated to the MARTE ‘HwProcessor’ using the MARTE allocate stereotype. The schedulers are defined as blocks stereotyped with MARTE ‘GaExecHost’.
Blocks are defined in the imported Components package. A MARTE stereotype is used for each one. The package contains computation resources (UserComputer, CoProcessor), communication resources (Bus, USB, SPI), memories (DisplayEnv, Source, Mem) and a scheduler (Scheduler).
Figure 7 depicts the IBD of the platform. Ports are MARTE ‘hwEndPoints’. Assembly connectors are used to connect end points to buses. Delegation connectors are used for ports forwarding between different hierarchical levels. Schedulers are allocated to hardware processors using Assign stereotype from MARTE.
Composite diagram of the platform
To obtain an allocated virtual system model, functions of the application are mapped onto computation resources of the platform, while shared variables and exchanged data are mapped onto memories and physical links. ‘Assign’ from the MARTE profile is used to model this mapping or allocation.
Software mapping is achieved by assigning functions from the application to tasks (blocks stereotyped with the MARTE ‘schedulable resource’). The schedulers of the platform schedule tasks.
Hardware mapping is done by directly assigning functions to ICs of the platform.Link mapping is the allocation of functional relations to physical links or memories of the platform.
Allocated model execution in CoFluent Studio
The descriptions were created with CoFluent DSL. Unlike results available for the behavioral simulation, the model execution results include the activity of the processors, buses and interfaces. This feature is useful to evaluate whether resources of the system under study are overloaded. It also will help determine if the software partitioning is adequately done. Additionally, the ability of a software-processing unit to perform several tasks and the impact of a bus to transfer can be monitored.
Figure 8 shows the performance profiling windows obtained at the end of the simulation. The first window displays a global results table, and the second window displays the dynamic load of selected resources.
Performance profiling windows in CoFluent Studio
Performance profiling results include power, resource utilization (loads in percentage of Mcycles/s) and memory. For instance, the simulation indicates a CPU use of 70.84% and a Bus use of 56.26%.
If the CoProcessor was not used and all the functions were mapped onto the CPU, the CPU utilization would increase and the bus utilization would decrease. This kind of mapping change is easily done in CoFluent Studio, enabling fast what-if analysis.
This paper describes an embedded system architecting flow that utilizes virtual system models obtained from SysML/MARTE specifications. The specifications are translated into executable SystemC transaction-level models. Virtual system technology overcomes many of the limitations of virtual platforms, since it is accessible when specialized hardware and software IP models or code are not yet available. It provides the simulation capability for performance analysis, behavioral and architectural verification, and use cases and tradeoff analysis.
The use of standard notations of SysML/MARTE profiles to describe virtual systems enables system architects to store and exchange design information internally and between third parties in a standard format. Furthermore, virtual systems allow fast and accurate evaluation of different use cases and design scenarios by facilitating the execution of UML specifications. Automatic SystemC TLM code generation enables model reuse in other SystemC-based virtual platform and verification environments.
Thomas Robert is a consultant in ESL for CoFluent Design. He was educated at the Polytech’Nice-Sophia.
Vincent Perrier is CoFluent’s co-founder and chief technical officer.
2290 N. First Street
San Jose, CA 95131
W: Cofluent Design portfolio (now part of Intel)