Section: New Results
Rapid Prototyping of Heterogeneous Real-time Systems
Participants : Loïc Besnard, Hamoudi Kalla, Saïd Lankri, Jean-Pierre Talpin.
Importing C components
The ESPRESSO team has pursued his effort on importing C components into Signal [21] . This work is based on the GCC compiler starting from its version 4. The compiler takes an arbitrary C source code, does the compilation and outputs a tree called GNU TREE SSA (SSA - Single Statement Assignation ) which represents the original C source code in a sort of high level assembler instructions. The importer takes the resulting tree and produces Signal code. This approach is convenient for reusing the many existing C components and performing static code verification by the means of the Signal compiler.
In an alternative approach, we focus on a particular form of C components, specifically those who have a strong algorithmic part. This type of C code is declined most of the time with computational parts that are not compatible with the synchronous hypothesis (single assignment) and command parts. The aim is to split the imported C component into two parts : the control parts are extracted and translated into Signal formalism, the computational part is left in the C formalism and embedded in the resulting Signal component.
Many reasons are motivating this type of import. First, we do not really need to translate computational parts, which are very well handled in the originating C language and cannot be simply imported. In addition, Signal is not well designed for such type of programming. Second, the control/command part can be easily handled in Signal, after the import we obtain a component whose 'decisional' parts are written in Signal and computational parts embedded as C code.
This import relies on standard technologies. The C component is first translated into its corresponding XML structure with the help of a tool called srcML , then a set of transformation rules are applied in order to obtain Signal code and embed the computational parts. We have chosen a W3C standard, XSLT for these rules.
Importing Simulink components
Simulink has become the de facto standard tool largely used in the design of discrete-time systems. In order to make the Signal language as a heterogeneous formalism integrator, we need to have correct translations from Simulink to Signal. In this transformation, we offer a way of translating discrete-time Simulink models to Signal, preserving by the way the component structure and hierarchization. We focus of discrete systems using a fixed-step simulation in order to get a Signal model which is semantically equivalent.
Each Simulink 'box' is translated into a Signal process and the known Simulink types are mapped to their corrsponding types in Signal. Types are not mandatory in Simulink, in that case, we let the type-inference system of Signal guess the types of the inputs and outputs.
In addition, we have written a Signal library of many discrete Simulink components. The translated models make use of this library which is organized the same way libsimulink is in Matlab .
Both the library and the transformation rules are extensible and the addition of new known Simulink components is easy. As for C import, we first translate Simulink models into their XML representation, and apply a set of rules to get a Signal code. We use the same XSLT standard in which transformational rules are expressed.
