Section: New Results
Participants : Rabie Ben Atitallah, Pierre Boulet, Jean-Luc Dekeyser, Cédric Dumoulin, Abdoulaye Gamatié, Frédéric Guyomarc'h, Antoine Honoré, Sébastien Le Beux, Philippe Marquet, César Moura, Éric Piel, Safouan Taha, Julien Taillard, Huafeng Yu.
A MARTE compliant Gaspard2 profile
As part of the recently voted OMG standard MARTE, we have developped the Hardware Resource Model (HRM), which is an open framework for UML-based hardware modeling. HRM adapts the wide range of UML constructs to hardware and provides different modeling views corresponding to logical and physical abstractions [Oops!] . It also covers many detail levels. MARTE handles the heterogeneity of embedded systems by adopting the Y-model that is equivalent to the Gaspard2 one including three models, the application model of the system functionalities, the resource model of the execution platform, which is in turn, composed of three models (generic + software + hardware) and finally the allocation model that maps the application to resources. An appropriate methodology was also developped to apply HRM during the hardware design process [Oops!] . Such a methodology is recommended to get an efficient use of the HRM and benefit from its features. This methodology is incremental and bottom-up. It starts from elementary components and with successive compositions it reaches the whole platform model. The final model is then instantiated to get the real world platform. For cost, time and flexibility reasons, it is a common practice to simulate virtually the modeled hardware and test its adequacy to provide a sufficient execution platform for the embedded application. A code generation from HRM models was developped to interface simulation tools like Simics  we have selected for this study. To be conform with this new standard, the Gaspard2 profile was adapted as an extension of the MARTE profile. Now, it uses HRM for hardware modeling, RSM (Repetitive Structure Modeling) for repetitive structures and GCM (Generic Component Modeling) as a base for component modeling. Other concepts, which are part of the Gaspard2 profile but not in MARTE, are kept as is. In the future, some of the Gaspard2 concepts would be suggested for an integration in MARTE.
The notion of Deployment Specification has been previously introduced in order to generate compilable code from the SoC model. For that, it is necessary for the designer to specify which IP (or function) must be used to implement an elementary component. The Deployment Specification package proposes concepts which (i) allows to describe the relation between a Gaspard2 representation of an Elementary component (a box with ports) to a text-based code (a function with arguments) and (ii) allows to inform the Gaspard compiler and platform of specific behaviours of each component (such as average execution time, power consumption...) in order to generate a high abstraction level simulation in adequacy with the real system.
The Gaspard2 metamodel now offers mechanisms to separately represent IPs from the rest of the model, in a library, and later deploy application and hardware components on them. To demonstrate the usage of those mechanisms and help the first users of Gaspard2, we have built such a library, the GaspardLib. It currently contains a dozen of hardware IPs (such as a MIPS core, a memory, a bus...) and approximately twenty software IPs (such as a DCT, an FFT, a sum of vectors...).
When it was possible, the descriptions of he IPs relay on the notion of abstract implementation of the Gaspard2 metamodel which allows to specify several versions of an IP having the same functionalities but implemented at various levels of abstraction or in different programming languages [Oops!] . This in turn permits to use the IPs defined in GaspardLib independently from the transformation target. For instance one can associate a processor component to a MIPS core, and generating, without modifications in the SoC model, simulations at the TLM PVT level and at the TLM CABA level.
OCL constraints in Gaspard
The Gaspard2 design framework has been extended with an OCL-based verification functionality in order to early check design errors during model definition. This enables to reduce some errors so that transformations can be applied to safe models towards lower abstraction levels.
More precisely, we added OCL constraints to the Gaspard2 profile and developed a plugin called " GaspardValidation " that allows the user to check the syntactic correctness of described models with respect to their construction rules as stated in Gaspard2. This verification currently applies to the concepts relying on the Application metamodel. Future works aim at extending the applicability to all concepts of Gaspard2.
A study has been started to assess the need of defining parameterizable elements in the Gaspard's modeling process, so that Gaspard's elements may be only partially defined in a first moment, leaving some "blanks" to be defined in a later time, but still in the modeling phase (in other words, before instantiating these elements). This would enable the creation of component libraries, increasing reuse.
Discussion focus on the prospective applications of parameterizable elements; on how the "parameterization" concept could be explored using existing tools, namely UML tools (e.g. MagicDraw, Papyrus,etc.); and finally on the benefits and disadvantages of adding it to the Gaspard's modeling process.
A few approaches have been envisaged aimed at putting into practice parameterizable elements. This has been discussed under two different levels:
UML: since UML tools are the front-end interface used in the Gaspard2 modeling process, it is important to provide users with ways of expressing parameterizable models.
Gaspard2 metamodel: once a parameterizable model has been created using UML tools, the next step is to express the same model in the Gaspard2 metamodel. Consequently, Gaspard2 itself needs to offer support to parameterizable models.
In either case, we scrutinized some points concerning both notation and implementation of parameterizable elements.
The allocation of application functionalities to hardware or software resources is an important point in the SoC design. Such allocation is both is spatial distribution and a temporal schedule of computations to computing resources, of data to memories, of data dependencies to communication resources.
We have introduced a distribution notation of repetitive application components onto repetitive hardware resources that also uses a compact notation to allow specifying High Performance Fortran like distributions such as block , cyclic or block-cyclic distributions. We have included this notation in the MARTE profile [Oops!] .
The Gaspard2 framework is particularly adapted for the design of embedded systems that compute large amounts of data in a regular fashion. However, it does not allow to deal with aspects such as temporal constraints imposed by system environment, or control in computations according to different modes or configurations. So, we proposed an extension of that takes into account control features by considering mode automata and synchronous equations.
The resulting automata-based control holds a semantics that combines sequential automaton transitions and parallel repetitions, through the inter-repetition dependency defined in Gaspard2. Compared to the previous status of this work [Oops!]  , a complete syntax and formal semantics for this combination are under definition. While such an extension of Gaspard2 with control features increases its expressivity, more complex behaviors will become possible to describe. Validation techniques such as model-checking or discrete controller synthesis can therefore be very useful to check system properties.
An extension of the transformation chain developed in Gaspard2 towards synchronous code in Gaspard2 with control features is to be implemented soon. It could rely on an existing simplified version of a metamodel considered for the integration of control features in VHDL code.
This work is done in collaboration with Eric Rutten from the Pop-Art team-project at INRIA Rhône-Alpes in Grenoble.
A semantics for the Array-OL language
Starting an effort to provide more formal foundations to our work, we have defined a denotational semantics for the Array-OL model of computation. We have also defined a subset of Array-OL, named static Array-OL, that exhibits the good property of allowing a fully static verification of the determinism of the models.