MADES-248864-D4.1 Model Transformation and Code Generation ...api.ning.com/files/4pPRWqdvtYmV0OY8U9tBFgAKMFJfu4d7NUdvFuQ… · In Chapter 2, a mapping scheme is ... D4.1 Model Transformation

D4.1 Model Transformation and Code Generation Tool Specification 11/2/2010

The research leading to these results has received funding from the European Community's Seventh Framework Pro-gramme (FP7/2007-2013) under grant agreement n° 248864.

MADES

Model-based methods and tools for Avionics and surveillance embeddeD SystEmS

FP7-ICT-2007 248864

D4.1 Model Transformation and Code Generation Tools Specification

Dissemination level

PU Public

PP Restricted to other programme participants (including Commission Services)

RE Restricted by a group specified by the consortium (including Commission Services)

CO Confidential, only for members of the consortium (including Commission Services) X

Work package: WP4 Lead participant: UoY Editor: Nicholas Matragkas Authors: Nicholas Matragkas, Ian Gray, Dimitrios Kolo-

vos, Richard Paige, Neil Audsley, Leandro Soares Indrusiak

Reviewers: Alessandra Bagnato, Gundula Blohm Date: 31th October, 2010 Version: 1.0


3(30)

The MADES Consortium

TXT e-solutions Via Frigia 27 20126 Milano Italy

Contact: Ms. Alessandra Bagnato E-mail: [email protected] Phone: +39 2 25771.725 Address: Via al Ponte Reale 5 16124 Genova, Italy

SOFTEAM 21 avenue Victor Hugo 75016 Paris France

Contact: Dr. Andrey Sadovykh E-mail: [email protected] Phone: +33.1.30.12.18.57

University of YorkHeslington York YO10 5DDUnited Kingdom

Contact: Prof. Richard PaigeE-mail: [email protected] Phone: +44 1904437222

Politecnico di Milano via Golgi, 42 20133 Milano Italy

Contact: Prof. Luciano BaresiE-mail: [email protected] Phone: +39 02 2399 3638

The Open GroupAvenue du Parc de Woluwe 56B-1160 BrusselsBelgium

Contact: Scott Hansen E-mail: [email protected] Phone: +32 2 6751136

EADS Deutschland Woerthstrasse 85 89077 Ulm Germany

Contact: Ms. Gundula Blohm E-mail: [email protected] Phone: +49 731 392 3757


4(30)

Executive Summary

This document constitutes the MADES project deliverable D4.1 “Model Transforma-tion and Code Generation Tools Specification”. The goal of this document is to de-fine and to describe the high level transformation rules to be used for model-to-model and model-to-text transformations in the context of the MADES project. One of the main characteristics of the MADES approach to software development for em-bedded systems is that it is model-driven and transformation-based. Model transfor-mations will be used as part of the approach to achieve tool interoperability and code generation. In Chapter 2, a mapping scheme is provided, which illustrates the vari-ous mappings between the artefacts of the MADES approach. In Chapter 3, these mappings are examined more closely and the input and output artefacts are de-scribed in more detail. We have identified the following transformation classes:

1. MADES design models to verification scripts 2. MADES design models to simulation scripts 3. MADES design models to hardware architecture description 4. MADES design models to architecture agnostic source code 5. MADES design models to software/hardware mappings for compile time virtu-

alization 6. MADES design models to hardware architecture description for compile time

virtualization 7. Platform-specific source code generation with compile time virtualization

The first two transformation classes will be implemented in order to make the verifi-cation and simulation tools interoperable with the modeller. The goal of the rest of the transformation classes is to enable the generation of platform-specific code as well as the generation of hardware architecture descriptions. The implementation of the various transformations will be based on the Epsilon framework due to its extensibility mechanisms as well as due to its unique features such as the interactive transformations. A dedicated traceability engine will provide the traceability support for the various transformations.


5(30)

Table of contents

MADES ............................................................................................................................... 1 Model‐based methods and tools for Avionics and surveillance embeddeD SystEmS................... 1

D4.1 Model Transformation and Code Generation Tools Specification ............................... 1

Executive Summary ............................................................................................................ 4

Table of figures................................................................................................................... 6

1 Introduction................................................................................................................ 7 1.1 Role of this deliverable .................................................................................................10 1.2 Structure of this document ...........................................................................................10 1.3 Relationship to other MADES deliverables....................................................................10 1.4 Contributors .................................................................................................................11

2 Model transformations in MADES............................................................................. 12 2.1 MADES Approach .........................................................................................................12

3 MADES Model Transformations and Code Generation.............................................. 15 3.1 Design models to Zot scripts (1) ....................................................................................15 3.2 Design models to Hardware (3).....................................................................................15 3.3 Design models to Architecture‐Agnostic Code (4) .........................................................17 3.4 Design models to Hardware/Software Mappings Model (5)..........................................18 3.5 Design models to Hardware Architecture Description (6)..............................................18 3.6 Code Generation from CTV (7) ......................................................................................19

4 Traceability Support.................................................................................................. 25

5 Enabling Technologies............................................................................................... 26

6 Conclusions............................................................................................................... 27

7 Glossary .................................................................................................................... 28

8 Bibliography.............................................................................................................. 29


6(30)

Table of figures

Figure 1 Development of Embedded Systems ................................................. 8 Figure 2 Typical Code Generation Scenario..................................................... 9 Figure 3 Model Transformation Pattern [10] ...................................................12 Figure 4 MADES Mapping Scheme ................................................................13 Figure 5 Design Models to Zot Scripts transformations..................................15 Figure 6 Hardware Diagram to VHL Transformation Chain............................17 Figure 7 Generation of Architecture -Agnostic Code ......................................18 Figure 8 Generation of Hardware / Software Mappings for CTV....................18 Figure 9 Generation of Hardware Architecture Description for CTV ..............19 Figure 10 The CTV code generation framework.............................................20


7(30)

1 Introduction

Modern real-time and embedded systems are becoming increasingly complex, offer-ing more functionality while attempting to satisfy very heterogeneous requirements such as fault-tolerance, timing constraints and determinism [2]. Design and mainte-nance of such systems is complex, time consuming and error prone processes. Fur-thermore, “critical systems” have to respect predefined safety properties throughout their utilization. Implementing such systems requires guaranteeing at design time that they will operate with respect to these properties. Due to the unique nature of embedded systems, developers face a number of critical challenges. Sangiovanni-Vincentelli [1] discusses these challenges in detail. Based on his findings, a set of requirements has been identified as a basis for defining well-suited practices for designing such systems [2]. These requirements are the follow-ing: [R1] Need to deal with Parallelism: Currently, parallelism for embedded systems is addressed by teams of experts, who have a deep knowledge of the various hard-ware and software parts of the system. Utilizing this knowledge, these experts deal with parallelism at very low levels of abstraction. According to the relevant literature [2], hand-coding is not the most efficient development method of large and complex embedded systems, since it is considered to be tedious, error-prone and expensive. An alternative way to deal with parallelism is the use of general parallel programming models such as the Message Passing Interface (MPI) [3] and the shared memory model (OpenMP)[4]. Such programming models assume the existence of an ab-straction layer between the application level and the hardware architecture level, which serves as an execution support for the parallelization. Although using parallel programming models is considered a better approach than hand-coding, it is still considered sub-optimal method of dealing with parallelism. This is due to the fact, that these approaches lack the mechanisms to support data distribution to different hardware components. Moreover, these models need complex optimizations in order to perform satisfactory for the programming of large and complex parallel embedded systems [2]. A solution to the aforesaid problems is the ability to define at high level of abstraction all the potential parallelism that is inherent to software components and hardware architectures. These definitions could be then used to generate the low-level implementations. [R2] Need for Abstract Models: The development of embedded systems is charac-terized by increasing complexity due to the increasing number of parts of the system (states, functions, components, code lines, etc) and dependencies between the parts. Due to this complexity, simulation and validation of the behaviour of the sys-tem before its realization is of paramount importance. Domain-specific design ab-stractions offer a possible solution to address the aforementioned issues. The issue of complexity is addressed by utilizing models that capture multiple viewpoints so that designer is able to focus on specific aspects. Moreover, such models can be used in conjunction with dedicated model checkers to validate important properties of the system without having the actual implementation of the system. [R3] Need for Seamless Methodologies: The development of embedded systems usually starts with the co-design of both software and hardware architecture. Then the software part is mapped onto the hardware part during the integration phase. This process is illustrated in figure 1. Following [2], the different aspects of this proc-


8(30)

ess are handled by different domain experts, who use different notations and differ-ent development appraoches. The efficient communication between these experts is a substantial and growing issue since the increasing complexity makes such com-munication difficult. As a consequence, design space exploration can become an issue since design space exploration requires the integration of the “different” world views of the domain experts. Hence, a methodology and toolset which supports bet-ter communication between the various actors involved in a project is desirable.

Figure 1 Development of Embedded Systems

MADES proposes a holistic, model-driven approach, which addresses the issues raised above. The MADES approach covers all phases from design to code genera-tion and deployment. The aforementioned requirements are fulfilled in the following ways: [R1] Need to deal with Parallelism: TheMADES approach will deal with parallelism by providing a dedicated modelling language, which is described in detail in deliver-able D2.1. Using this language, parallelism can be modelled at a high level of ab-straction and then code can be generated from the various models. In order to facili-tate the code generation, appropriate code generators will be developed from gen-eral-purpose technology. Moreover, models will not be directly transformed to platform specific code. Model transformations will be used to target a virtual platform (VP), which will then generate the platform specific code. The VP provides a com-pile-time abstraction over the complex target platform (i.e., including multiple CPUs, non- uniform memory and communications hierarchies, function accelerators). Unlike conventional virtualization approaches, this method will enable the abstract devel-opment process (i.e. the modelling at high levels of abstraction) to influence the characteristics of the VP, in order to develop more efficient implemented systems. Using a VP will eventually help to reduce the complexity of the code generators. This is due to the fact, that the generated code will be generic and not architecture specific. Additionally, it will provide an effective mechanism for design space explora-tion, since it will allow designers with minimal effort to change the hardware architec-ture on which software will run without having to adopt the software code to the new architecture.


9(30)

[R2] Need for Abstract Models: The MADES approach will provide a dedicated modelling language with which engineers will be able to model different viewpoints of the system under development. Dedicated code generators will be used to target an appropriate VP, which will then generate the platform specific source code. Model transformation and code-generation techniques will also be used to transform the system models in appropriate notations for the validation tools. [R3] Need for Seamless Methodologies: MADES provides a seamless develop-ment process, which is described in deliverable D2.1. The proposed approach will deal with the gap of communication between experts from different domains by pro-viding the MADES modelling language. Transforming the various system models into appropriate input for a VP will facilitate design space exploration. This VP abstracts the complexities of the targeted hardware architecture; hence communication be-tween domain experts takes place by using high level models expressed in the MADES language. As is evident from the above discussion, model-to-model and model-to-text trans-formation techniques will play a central role in the MADES approach. The purpose of such techniques will be twofold. First, they will be used to allow the different tools of the MADES toolset to interoper-ate. In the MADES context, the different standards and formats followed by the vari-ous tools of the toolset make tool interoperability a challenge. Model transformations are considered to be a very effective technique for dealing with this problem [5]. In this approach, the different formats supported by the various tools are captured as abstract definitions of data structures (i.e., metamodels), and transformation rules map from one representation to another. This will result to an integrated MADES Tool suite, which will use the MADES notation and it will be used by the different domain experts. Second, model-to-model and primarily model-to-text transformations will be used for code generation. By code generation we mean the technique of writing programs that build application code. Automated code production can deliver several benefits to a development process including reduced effort, enhanced architectural consis-tency and improved maintainability [12]. A typical code-generation scenario is illus-trated in figure 2. Since, MADES is concerned with the development of embedded systems, code generation is augmented with compile-time virtualization (CTV) tech-nology. By doing so will make the code generators more flexible in the sense that they will be able to target non-standard hardware architectures. CTV is discussed in more detail in section 3.6.

Figure 2 Typical Code Generation Scenario


10(30)

1.1 Role of this deliverable This document constitutes the MADES project deliverable D4.1 “Model Transforma-tion and Code Generation Tools”. The role of this document is to define and to de-scribe the high level transformation rules to be used for model-to-model and model-to-text transformations in the context of the MADES project for tool interoperability and code generation. This document does not specify the MADES instances of model transformations. The MADES instances of the model transformations will be defined in the deliver-ables D4.2 “Model Transformation and Code Generation Tools Initial Version”, which is due by the 12th month of the project, D4.3 “Model Transformation and Code Gen-eration Tools Interim Version”, which is due by the 18th month of the MADES project and D4.4 “Model Transformation and Code Generation Tools Final Version”, which is due by the 24th month of this project. Furthermore, this document does not specify algorithms to solve model transformations, i.e., to find feasible or optimal instances of output models and design decisions for given instances of input models.

1.2 Structure of this document In chapter 2of this document, an overview of the MADES approach is provided from a transformational point of view. That is, a mapping scheme is provided, which iden-tifies the main MADES artefacts and the mappings between them. In chapter 3, the identified mappings are examined one by one. The type of the transformation is specified and the required artefacts are defined. Chapter 4 discusses briefly the traceability needs for the various transformations of the MADES approach, while chapter 5 presents the technologies which will be used for implementing the neces-sary transformations. Finally, chapter 6 summarizes the main points of this document whereas in section 8 a glossary with common terms is provided.

1.3 Relationship to other MADES deliverables This document is strongly related to other MADES deliverables of the MADES pro-ject belonging both in WP4 as well as in other work packages. The list of the related deliverables is the following:

1. D2.1 MADES Modeling Language Specification 2. D2.2 MADES Modeling Tools Architecture 3. D3.1 Domain-specific and user-centered verification (POLIMI) 4. D4.2 Model Transformation and Code Generation Tools Initial Version 5. D4.3 Model Transformation and Code Generation Tools Interim Version 6. D4.4 Model Transformation and Code Generation Tools Final Version


11(30)

1.4 Contributors The main contributor of this deliverable is the University of York. All partners have contributed indirectly by providing input or feedback to it.


12(30)

2 Model transformations in MADES

Model transformations, also called mappings, are used to transform one or more in-put specifications into one or more output specifications. Model transformation lan-guages are used to specify a model transformation. These model transformation languages are defined in a metamodel level and establish the relationship between source metamodel elements and target metamodel elements (figure 3).

Figure 3 Model Transformation Pattern [10]

The purpose of this section is to identify the high level MADES artefacts as well as the different mappings between them. This information will be then used to specify the various transformations used in the proposed approach

2.1 MADES Approach One of the main characteristics of the MADES approach to software development for embedded systems is that it is model-driven and transformation-based. A conceptual model of the different interrelationships between the various artefacts of the MADES approach is illustrated in figure 3. The purpose of this section is to summarize the artefacts used in the MADES approach.


13(30)

Figure 4 MADES Mapping Scheme

Since the proposed approach is model-driven, every development effort starts with building the relevant design and analysis models. These models are expressed in the MADES modelling language and they are considered as first class artefacts. As such, they guide the rest of the development process by being used as input to the various tools of the MADES toolset such as the verification tool Zot [16] and the code generation with CTV tool. MADES diagrams are able to model different viewpoints and different levels of abstraction. They are able to describe the structure and the behaviour of the system, as well as time system constraints. Hence, all the system aspects of interest can be modelled using the MADES notation. Any additional information required by the transformation engines can be provided by attaching annotations on the system models or by user input.

Verification and simulation play a key role in the MADES approach. Such activities materialize in:

a) the verification of key properties on designed artefacts b) the closed-loop simulation based on detailed models of the environment c) the verification of designed transformations

In order to provide verification and simulation in the MADES toolset, the Zot tool [16] will be used. There are three kinds of artefacts that are required by Zot in order to perform verification and simulation. The input to Zot depends on the action the tool is required to perform. In the case of verification Zot needs a verification script and user input, which will specify the properties to be verified. In the case of simulation


14(30)

the input to Zot is a simulation script. Zot uses Common Lisp as internal scripting language of the tool. The second set of artefacts is related to code generation and the use of CTV tool. CTV is a technique developed to support the development of software for complex embedded architectures using a single-program model without requiring the devel-opment of new languages or compilers. Three different artefacts are needed for CTV to generate platform specific code. Firstly, CTV needs normal architecturally-neutral code with distributed operating system features such as threading, shared memory, cache coherency etc. Because CTV is a language-agnostic technique, any source language that supports the required features for concurrent, embedded real-time systems can be used. The task of representing the language in terms of MADES’ modelling framework is relatively simple and a wide range of languages can be sup-ported easily through the use of existing compiler/parser frameworks such as LLVM [13] and SUIF [14]. Currently, we are considering Real Time Specification for Java (RTSJ) [7] as the target programming language. Our use of the RTSJ is not exclu-sive, other languages can easily be used, but it is by far the best language to dem-onstrate the full power of our techniques. C++ does not have concurrency as a part of the language, and C# relies on the use of a monolithic closed-source library (.NET) so these languages naturally restrict what can be achieved. This does not mean they will not be incorporated into the work as front-ends for different languages can be generated as needed. However, focussing on these languages will limit our scope and applicability in the long-term. Second, CTV needs the target architecture description, which provides a high-level view of the target architecture. Finally, the CTV tool needs a set of hardware to soft-ware mappings of the system model. These mappings are responsible for mapping constructs from the input software to hardware features. Finally, the output of the CTV is platform specific code, which is written in the same language as the input ar-chitecturally neutral code, i.e. Real Time Java. Finally, the last artefact of the MADES approach has to do with the generation of the hardware descriptions. The Xilinx tool platgen from Xilinx's Embedded Design Kit [9] is then used as an underlying HDL generator, as it can take an Microprocessor Hardware Specification (MHS) [11] description and generate a set of synthesisable VHDL files for implementation on an FPGA. The use of MHS files and Xilinx FPGAs is not required by the MADES tool chain, but are useful to work with as they already have robust industrial-quality tool support available. If a different language or implementation fabric is required (such as ASICs, or FPGAs from a different vendor) another model-to-text transformation can be used. The purpose of this section is to identify the main artefacts used in the MADES ap-proach. In the next section we will specify the various transformations between the aforementioned artefacts.


15(30)

3 MADES Model Transformations and Code Generation

The purpose of this section will be to describe the various mappings used in the MADES approach as they are defined in the mapping scheme presented in figure 3.

3.1 Design models to Zot scripts (1) This set of model-to-text transformations will take as input models defined in the MADES language, as well as user input and it will generate Zot Scripts. These scripts could be either Verification scripts or Simulation scripts expressed in Com-mon Lisp. In this scenario, we will need a set of transformations since the Zot scripts can be derived from different inputs. To generate the Zot scripts one or a combina-tion of the behavioural diagrams of the MADES language will be needed, particularly State diagram, Sequence diagram, Activity diagram, etc. A specification of the struc-ture of the system is also needed. This information will be derived from the Class diagram. Moreover, timing information is required, which will be derived from the Time diagram of the MADES language defined in deliverable D2.1 “MADES Model-ling Language Specification”. Finally, to produce the scripts, information about the dynamics of the environment of the system is needed such as characteristics of its physical part. Such information will be added by using appropriate annotations or by asking for user input, depending on the scenario.

Figure 5 Design Models to Zot Scripts transformations

3.2 Design models to Hardware (3) The next transformation chain will lead to the generation of the hardware description. This model-to-text transformation will take as input models defined in the MADES language and it will generate a hardware architecture expressed in an appropriate


16(30)

hardware description language. The MADES tool chain allows for the generation of implementable hardware descriptions of the target architecture. As detailed in deliv-erable 2.2, the following model hierarchy is used:

• H2: A high-level model of the target architecture that is equivalent to the input architecture description to CTV (detailed in the previous sections). Accord-ingly, its constituent elements are processors, memory spaces, channels, and custom hardware elements and it can be directly generated from the CTV ar-chitecture description or vice versa. This level does not describe any lower-level details (such as addresses or bus topologies).

• H1: A refinement of H2, H1 is a lower-level model which codifies the busto-pology of the system and specifies I/O. Does not still define the specific types of hardware instance. For example, at this level the model will still denote “processor” rather than “Arm9”.

• H0:The lowest level model that describes hardware in terms of the MHS lan-guage. Generated by model-to-model transformation from H1 using transfor-mation rules and in-place refinement, known as ‘polishing rules’.

H0 demonstrates an equivalent level of abstraction to that of the MHS language used by Xilinx Corporation’s FPGA Development Tools. MHS files are generated by the MADES tools from a H0 model using a model-to-text transformation. The Xilinx tool ‘platgen’ is then used as an underlying HDL generator, as it can take an MHS description and generate a set of synthesizable VHDL files for implementation on an FPGA. Generating a hardware description from a high-level deployment model therefore in-volves translating an H2 model to H0. An MHS description can then be generated from H0 using a model-to-text transformation. Moving from H2 to H0 adds extra de-tail, so a translation has a lot of freedom over implementation-specific details. The following information must be provided either though designer-guided refinement or an automated design exploration framework:

• Hardware features (e.g. processor, memory) are translated to corresponding Xilinx IP cores (e.g. Microblaze, BlockRAM respectively).

• The connectivity of the system must be determined. H2 does not specify the target bus topology so this information is introduced by the translation to H1. This is done in two stages, memory connectivity and communications connec-tivity. Memory connectivity specifies how memory spaces are accessed by the processors of the system (dedicated, shared bus, etc.) and communications connectivity determines the type of interprocessor communications provided by the architecture.

• Once the connected items for each processor have been determined, the processor’s address map must be built. Each peripheral has a required ad-dress size, which can be determined automatically by checking the definition of the IP core. This can be performed automatically.


17(30)

• Finally, interrupts must be connected. If a processor does not provide enough native interrupt lines then an interrupt controller instance must be created and connected appropriately by instantiating a pre-built processor-specific tem-plate.

This transformation chain is illustrated in figure 6.

Figure 6 Hardware Diagram to VHL Transformation Chain

3.3 Design models to Architecture-Agnostic Code (4) This model-to-text transformation will take as input models defined in the MADES language and it will generate skeleton architecture agnostic code written in Real Time Java. The generated code will then be refined manually by the developers and it will be provided as one of the inputs to the CTV tool. By doing so, all the complexi-ties of targeting a non-standard architecture will be hidden from the developer. This can result in increased productivity as well as in code of higher quality. For this transformation behavioural diagrams and Class diagram will be required. The gen-eration of architecture agnostic code is illustrated in figure 7.


18(30)

Figure 7 Generation of Architecture -Agnostic Code

3.4 Design models to Hardware/Software Mappings Model (5) This model-to-model transformation will take as input the allocation diagram of the MADES language and will generate a Hardware/Software Mappings model, which is a notation used by the CTV tool. This model captures the mapping constructs from the input software to hardware features (for example, threads to processors or data items to memory spaces). This transformation scenario is shown in the figure below.

Figure 8 Generation of Hardware / Software Mappings for CTV

3.5 Design models to Hardware Architecture Description (6) The last artefact required by a CTV tool in order to generate architecture-specific source code is a hardware architecture description. The purpose of this is to provide the CTV code generation with enough information to generate architecture-specific code from the architectural-neutral input code generated by the system models. The hardware architecture description is a small dedicated domain specific language, which is used by the CTV tool, and is defined in existing CTV literature [15]. This no-


19(30)

tation has four constructs, namely processing elements, communication channels, memory spaces and other hardware. Models expressed in this domain specific lan-guage are derived from the Hardware diagram of the MADES notation using a model-to-model transformation. This transformation scenario is illustrated in figure 9.

Figure 9 Generation of Hardware Architecture Description for CTV

3.6 Code Generation from CTV (7) This section documents the CTV code generation and refactoring process. The pur-pose of this process is to take a single program description of the application and refactor it into a set of programs that are specifically targeted at the processors of the implementation platform. The aim is to produce a low overhead implementation that is suitable for use in a resource-constrained embedded system. The process can be broken down into the following steps:

• Parse input program: Cast the input program in terms of the CTV input model.

• Code splitting: Split the single input program into a set of programs, one for each target processor.

• Build architecture-specific libraries: Build a shared memory system, ser-vices required by the language model (such as threading, mutual exclusion etc.) and custom hardware drivers. These libraries are processor-specific so a set is generated for each target processor.

• Refactor processor-specific programs: to use the libraries generated in the previous stage.

• Compile: Using standard tools. For example, a CTV system based on C or C++ could use gcc.

This is depicted as follows and described in more detail in the following sections.


20(30)

Figure 10 The CTV code generation framework

3.6.1.1 Parse Input Program This stage must parse the incoming source code so that it can be represented in terms of the CTV system model (defined in deliverable D2.2). This involves extract-ing the concurrent objects (threads, tasks), shared objects (mutexes, protected ob-jects, etc.), and shared data items that are present in the application.

3.6.1.2 Code Splitting The code splitting stage is the phase of the refactoring process that splits the input program (expressed using a single-program model) into a set of processor-specific output programs, one for each target processor of the system. The hard-ware/software mappings provided to CTV state which processors the threads of the system should be mapped to, and to which memory spaces items of shared data should be mapped. The callgraph of the input program is built and used to perform reachability analysis in order to determine the subset of the input program, which is accessible, by each thread. In this way, each processor-specific program will only contain the code for threads mapped to that processor, and any shared libraries that those threads ac-cess. It will not contain the code of the other threads of the system. If multiple threads are mapped to the same processor then the use of an embedded microkernel is assumed to provide threading and scheduling services.


21(30)

3.6.1.3 Build Architecture-Specific Libraries The output programs of the code splitting stage will not execute correctly if they ref-erence non-local shared memory or use language features, which the language run-time does not expect to be distributed over a complex architecture (such as thread-ing, communication etc.). To solve these problems, four architecture support libraries are built that handle these problems. These were defined in detail in section 7.1.7 of deliverable D2.2, but to recap they are as follows:

• A distributed communications library • A shared memory system • Implementation of features required by the language specification • Driver code for hardware elements

These libraries are automatically-generated according to the input program, target hardware, and the mappings between the two. Then, the code of each processor-specific program is refactored to make appropriate use of the newly created libraries. The libraries are described in the following sec-tions.

3.6.1.4 Communications Layer The VP generates a universal communications layer that allows all threads to com-municate transparently (which is assumed by all modern concurrent languages). The communications layer is generated at compile-time, optimized specifically for the cur-rent target architecture. In CTV, threads are generally allocated offline, however it is possible to support run-time migration of threads between a pre-determined set of processors. This informa-tion is used by the communication layer to route messages. The layer is implemented with a compile-time multistage permutation routing system. Each processor of the system that is involved in a communication has a small com-munications kernel added to its interrupt handler to allow the processor to fetch and forward messages. In complex architectures, some processors will be used as routers, forwarding messages between otherwise separate areas of the architecture. Routes are calculated offline between static elements so impose minimal overhead. Dynamic elements (such as migrating threads) require that they update the commu-nications layer each time they migrate.

3.6.1.5 Shared Memory System The primary goal of the shared memory system is to allow the VP to present a single logical address space to the source language because this is the memory model as-sumed by most standard languages (such as C, C++, C#, Java, Ada etc.). This re-quires the implementation of an object-based distributed shared memory system that can allow the threads of the system to share data efficiently and coherently. In all cases it is assumed that the architecturally-neutral program already exhibits correct concurrent behaviour without race conditions. The shared memory library is required to ensure correct behaviour in the following two situations:

• A thread is accessing data that is not locally addressable (i.e. it is not directly connected to the memory bus of the processor) and may be shared between


22(30)

multiple threads. The system must cooperate to pass data between the proc-essors of the system to give the illusion that all data is available to each thread.

• A thread is accessing data, which is locally addressable, but is shared be-tween multiple processors. Cache coherency must be considered in this case.

The generated library [3.6.1.3] implements algorithms to pass shared data elements using the communications layer. Small communications kernels added to the proc-essors of the system cooperate to provide a distributed system without bottlenecks that can scale to large multicore systems.

3.6.1.6 Distributed OS Services The generated code must also provide services that are presumed by the source programming model. As CTV is a language-agnostic technique – therefore it may be used on a range of languages. When used with a C-POSIX application, the VP is re-quired to expose POSIX constructs that are implemented over the target architec-ture. In practice, this requires implementation of inter-thread communications and coordination features such as mutexes and condition variables. In a language such as Ada, the language model requires distributed implementations of the inter-task rendezvous, protected objects, and other such features. The generation of this library is therefore dependent on the chosen target language. If different languages are used in the same system, libraries must be generated for each source language. The communications layer and shared memory system gen-erated previously are used to provide the majority of the implementation.

3.6.1.7 Hardware Drivers The final generated library involves the inclusion of drivers for custom hardware ele-ments that are exposed as part of the VP. Driver code is not generated by CTV; in-stead a library of pre-written drivers for common hardware types is consulted. Driv-ers for the hardware elements that are part of the target architecture are included in the generated code. The drivers are used by the communications layer to operate the communications channels and I/O devices of the target system.

3.6.1.8 Refactoring The refactoring stage operates on the set of processor-specific programs (the output of the code splitting stage). Section 3.6.1.5 These programs will not execute cor-rectly if they reference non-local shared memory or use language features, which the language runtime does not distribute, over the target architecture. The final code generation stage must therefore refactor the processor-specific programs to call the architecture-specific libraries, which implement these features. This is done is three phases:

• Shared memory: The refactoring process analyses the source code of the processor-specific programs for locations where shared data is accessed. Calls to the shared memory library are injected at these points to fetch the shared data and coordinate with other users of the data object. Cache coher-ency is also considered for processors that use data caches.


23(30)

For example, consider the following pseudocode:

Thread mythread { Add 1 to variable X; }

If variable X is an item of shared data, the refactoring process will refactor the code as follows:

Thread mythread { Fetch the current value of X and lock it so other threads cannot access it. Add 1 to variable X; Write back the new value of X and unlock it.}

• OS services: Any calls to OS services in the processor-specific programs are

replaced with calls to the generated version that can operate over the target architecture.

• Custom hardware: Calls to custom hardware drivers are inserted at points where the processor-specific program interacts with any unique hardware fea-tures of the target architecture. For example, the programmer may indicate that their target architecture contains a function accelerator that they would like to access. The drivers for that feature will be included in the stages above, and calls to those drivers injected accordingly.

3.6.1.9 Compile The output of the CTV code generation phase is as follows:

• One set of source files per target processor of the original application. Gener-ated by the code splitting phase and refactored to call functions from the gen-erated libraries.

• One set of source files per target processor that implement the architecture-specific libraries. Includes the communications layer, shared memory system, OS services, and any hardware drivers that are used by the application.

• A custom linker script per processor generated by the shared memory system to place shared data items at the correct section of memory.

CTV does not require the use of any custom compilers or tools, apart from the CTV tool itself. The generated code is entirely compliant with the source language, so it can be compiled using that language’s normal compiler (for example, gcc for C). Be-cause the target architecture may contain many different types of processor, an ap-propriate compiler must be available that can output object code for each processor type.


24(30)

The refactored processor-specific programs and each processor-specific library are all separately compiled to object files using an appropriate compiler. Then, for each target processor its object code is linked against its specific libraries using any cus-tom link scripts generated by the shared memory library. The result of this is a single executable for each target processor. The executables can then be used in a variety of ways depending on the target application. They might be programmed directly into on-chip flash-based storage, stored on disk, transmitted into dynamic RAM during a bootstrap phase, or in the case of FPGAs, merged into the FPGA's configuration bit-stream.


25(30)

4 Traceability Support

Due to the transformation-based nature of the MADES approach traceability is of paramount importance. Traceability refers to the capability of tracing different arte-facts along a set of chained operations. Generating and maintaining traceability in-formation will help control and manage the wealth of the different artefacts of the MADES development process, since it can help developers understand the many dependencies that exist between the various aforesaid artefacts. To accomplish full traceability support, a dedicated traceability engine will be pro-vided as part of the MADES toolset defined in deliverable D2.1 “MADES Modelling Tools Architecture”. This traceability engine will generate trace links as a side effect of applying the various transformations between the different MADES artefacts.


26(30)

5 Enabling Technologies

The Epsilon platform [17] shall be used as the basis to implement both the model-to-model and model-to-text transformations. Epsilon, standing for Extensible Platform of Integrated Languages for mOdel maNagement, is a platform for building consistent and interoperable task-specific languages for model management tasks such as model transformation, code generation, model comparison, merging, refactoring and validation. We are considering Epsilon as the platform on top of which we will implement the various transformations for two main reasons. First, Epsilon is built having extensibil-ity in mind. Epsilon provides a platform atop which uniform, interoperable and reus-able languages can be built .Therefore, providing code generation support tailored to the needs of the MADES project can be done without duplicating existing facilities of the platform. This is due to the fact that any future additional features to the Epsilon will be interoperable with the other components of the framework such as the model navigation or model validation facilities. Moreover, the transformation facilities of Ep-silon provide some interesting features such as model transformations with user in-teraction or interactive in-place updates.More information on Epsilon as well as on the transformation languages used is provided in deliverable D.2.1 “Modelling Lan-guage Specification”. As mentioned earlier, it is anticipated that we may need to consider additional features to be added to Epsilon to provide more tailored support for code generation to the embedded system platform.


27(30)

6 Conclusions

This document described the various artefacts, which will be used in the MADES ap-proach. Moreover, it presented a mapping scheme, which Table 1 MADES artefacts mappingsIn this table, if there is an X at the intersection of a row and a column, this means that the artefact of the column is generated by a transformation which takes as input the artefact of the row. Defining the instances of model transformations is out of the context of this document. Such instances will be defined in the remaining deliverables of WP4.

Table 1 MADES artefacts mappings

1 2 3 6 7 9 10 11 12 13 14 15 4 X X X X 5 X X X X 7 X 8 X 9 X X 10 X 11 X 12 X X X X

1. Class Diagram 2. Behavioural Diagram 3. Time Diagram 4. Verification Scripts 5. Simulation Scripts 6. User Input 7. MHS 8. VHDL

9. Platform Agnostic Code 10. Software/Hardware Mappings 11. Hardware Architecture Description 12. Platform Specific Code 13. Hardware Diagram 14. Allocation Diagram 15. Drivers & Libraries


28(30)

7 Glossary

Compile Time Virtualisation (CTV) - CTV is a technique to support the development of software for complex embedded architectures without requiring the development of new lan-guages or compilers. CTV allows the programmer to write normal architecturally-neutral code with distributed operating system features such as threading, shared memory, cache co-herency etc. and to distribute that program over a complex target architecture automatically. CTV is used in the MADES framework to facilitate the targeting of code to complex archi-tectures [15].

Embedded Systems - "Embedded systems can be defined as information processing systems embedded into enclosing products such as cars, telecommunication or fabrication equipment. Such systems come with a large number of common characteristics, including real-time con-straints, and dependability as well as efficiency requirements. Embedded systems technology is essential for providing ubiquitous information, one of the key goals of modern information technology" [19].

In-place Update – It is an in-place model transformation on user-selected model elements. It is used mainly for automating recurring model editing tasks (e.g. refactoring, applying pat-terns or constructing subtrees consisting of similar elements).

Model transformation - It is the automated process, which takes one or more source models as input and produces an output [20]. In the case of a model-to-model transformation the out-put is one or more target models. In the case of model-to-text transformation, the output is one or more textual specifications.

Real-Time - A real-time computing system is the term given to a general class of computing systems which are subject to timing constraints. In most systems a low latency from stimulus event to output result is desirable, but in a real-time system this time affects the correctness of the system. That is: "The correctness of real-time systems depends not only on the logical result of the computation, but on the time at which the results are produced" [18]. Examples of real-time systems are flight control systems, braking systems, and safety cut-out systems.

Transformation Chain – A model transformation can be decomposed into a sequence of sub-transformations, i.e. a transformation chain, each addressing a limited set of concerns [21]. Transformation chains are used as a way to modularize a large and complex transfor-mation.

Virtual Platform (VP) - The VP is a virtualisation layer placed between programmer's code and the target hardware when using CTV. The VP presents an idealised view of the hardware with a programming model that is compatible with the development language. Use of a VP insulates the programmer's code from hardware changes and facilitates development and code reuse. CTV allows for potentially many VPs to be present in the same system. Each VP may present a different view of the underlying hardware; either to support different source lan-guages, or to provide isolation and separation of user code.


29(30) Copyright © MADES Consortium

8 Bibliography

[1] Alberto Sangiovanni-Vincentelli, 2007. Quo vadis, SLD? reasoning about the trends and Challenges of system level design. In Proceedings of the IEEE. pp. 467-506.

[2] Abdoulaye Gamatié et al., 2008. A Model Driven Design Framework for High Perform-ance Embedded Systems, Research Report INRIA, No 6614, Available at: http://hal.inria.fr/inria-00311115/en. [3] Foster I., N.K., 1998. A Grid-Enabled MPI: Message Passing in Heterogeneous Distrib-uted ComputingSystems. In SC'98.

[4] OpenMP Architecture Review Board, The OpenMP API speciffication for parallel programming. Available at: http://openmp.org/wp/about-openmp/.

[5] Yu Sun et al., 2009. A Modell Engineering Approach to Tool Interoperability. In Software Language Engineering: First International Conference, SLE 2008, Toulouse, France, September 29-30, 2008. Revised Selected Papers. 178-187.

[6] Common Lisp, Available at: http://clisp.cons.org

[7] Sun, Real Time Java, Available at: http://java.sun.com/javase/technologies/realtime/index.jsp

[8] Douglas C. Schmidt & Angelo Corsaro, 2010. The Design and Performance of the jRate Real-Time Java Implementation. In On the Move to Meaningful Internet Systems, 2002 - DOA/CoopIS/ODBASE 2002 Confederated International Conferences DOA, CoopIS and ODBASE 2002.

[9] Xilinx, Available at: http://www.xilinx.com/tools/platform.htm

[10] J. Bezivin, 2004. In search of a basic principle for model-driven engineering. In UP-GRADE.

[11] Xilinx, Platform Specification Format Reference Manual Embedded Development Kit EDK, Available at: http://www.xilinx.com/support/documentation/sw_manuals/edk10_psf_rm.pdf.

[12] S. Kelly, J.T., 2008. Domain-Specific Modeling. Enabling Full Code Generation, John Wiley & Sons, Inc.

[13] The LLVM Compiler Infrastructure - http://llvm.org/

[14] The SUIF Compiler System - http://suif.stanford.edu/


30(30) Copyright © MADES Consortium

[15] Gray, I. & Audsley, N. Exposing Non-Standard Architectures to Embedded Software Using Compile-Time Virtualisation International Conference on Compilers, Architecture, and Synthesis for Embedded Systems (CASES '09), 2009 [16] M. Pradella, A. Morzenti, & P. S. Pietro, Refining Real-Time System Specifications through Bounded Model- and Satisfiability-Checking, in 23rd IEEE/ACM International Con-ference on Automated Software Engineering (ASE 2008), (L’Aquila, Italy,, 2008). [17] D. S. Kolovos, L. Rose & R. F. Paige, 2010, Extensible Platform for Specification of Integrated Languages for mOdel maNagement (Epsilon), http://www.eclipse.org/gmt/epsilon [18] A. Burns, & A. Wellings, Real-Time Systems and Programming Languages - Fourth Edition, Addison Wesley, 2009 [19] P. Marwedel, Embedded Systems Design, Kluwer Academic Publishers, 2003 [20] A.Kleppe, J. Warmer& W. Bast, MDA Explained, The Model-Driven Architecture: Practice and Promise. Addison Wesley, 2003 [21] B. Vanhooff, et al., UniTi: A Unified Transformation Infrastructure, Model Driven Engi-neering Languages and Systems, Lecture Notes in Computer Science, Volume 4735/2007, 31-45, 2007

Documents

MADES-248864-D4.1 Model Transformation and Code Generation ...api.ning.com/files/4pPRWqdvtYmV0OY8U9tBFgAKMFJfu4d7NUdvFuQ… · In Chapter 2, a mapping scheme is ... D4.1 Model Transformation