Team DaRT

Members
Overall Objectives
Scientific Foundations
Application Domains
Software
New Results
Contracts and Grants with Industry
Other Grants and Activities
Dissemination
Bibliography

Section: Scientific Foundations

Keywords : Modeling, UML, MDE, Transformation, Model, Metamodel.

Co-modeling for HP-SoC design

The main research objective is to build a set of metamodels (application, hardware architecture, association, deployment and platform specific metamodels) to support a design flow for SoC design. We use a MDE (Model Driven Engineering) based approach.

System-on-Chip Design

SoC (System-on-Chip) can be considered as a particular case of embedded systems. SoC design covers a lot of different viewpoints including the application modeling by the aggregation of functional components, the assembly of existing physical components, the verification and the simulation of the modeled system, and the synthesis of a complete end-product integrated into a single chip. As a rule, a SoC includes programmable processors, memory units (data/instructions), interconnection mechanisms and hardware functional units (Digital Signal Processors, application specific circuits). These components can be generated for a particular application; they can also be obtained from IP (Intellectual Property) providers. The ability to re-use software or hardware components is without any doubt a major asset for a codesign system.

The multiplicity of the abstraction levels is appropriate to the modeling approach. The information is used with a different viewpoint for each abstraction level. This information is defined only once in a single model. The links or transformation rules between the abstraction levels permit the re-use of the concepts for a different purpose.

Model-driven engineering

Because of the vast scope of the encountered problems, of the quick evolution of the architectures, we observe a very great diversity regarding programming languages. Ten years ago each new proposed model (for example within the framework of a PhD) led to the implementation of this model in a new language or at least in an extension of a standard language. Thus a variety of dialects were born, without relieving the programmer of the usual constraints of code development. Portability of an application from one language to another (a new one for example) increases the workload of the programmer. This drawback is also true for the development of embedded applications. It is even worse, because the number of abstraction levels has to be added to the diversity of the languages. It is essential to associate a target hardware architecture model to the application specification model, and to introduce also a relationship between them. These two models are practically always different, they are often expressed in two different languages.

From this experience, one can derive some principles for the design of the next generation of environments for embedded application development:

We believe that the Model Driven Engineering  [77] can allow us to propose a new method of system design respecting these principles. Indeed, it is based on the common UML modeling language to model all kinds of artifacts.

The Model Driven Engineering (MDE) approach advocates the use of models at different levels of abstraction. A model represents an abstract view of the reality, it is defined by a metamodel specifying the available concepts and the relationship between them. A common MDE development process is to start from a high level of abstraction and to go to a targeted model by flowing through intermediate levels of abstraction. Usually, the high level models contain only domain specific concepts, while technological concepts are introduced smoothly in the intermediate levels. The targeted levels are used for different purposes: code generation, simulation, verification, or as inputs to produce other models, etc.

The clear separation between the high level models and the technological models makes it easy to switch to a new technology while re-using the old designs. Transformations allow to go from one model at a given abstraction level to another model at another level, and to keep the different models synchronized. Related models are described by their metamodels, on which we can define some mapping rules describing how concepts from one metamodel are to be mapped on the concepts of the other metamodel. From these mapping rules the transformations between any models conforming to the metamodels are deduced.

The MDE is based on proved standards: UML 2  [39] for modeling and the MOF (Meta Object Facilities  [73] ) for metamodel expression. Some profiles, i.e. UML extensions, have been defined in order to express the specificities of a particular domain. In the context of embedded system, the MARTE profile in which we contributed follows the OMG standardisation process. From a technical view point, metamodels and models are realized with the Eclipse ECore modeling language, an implementation of MOF provided by EMF [56] .

Models of computation

We briefly present our main models of computation that consist of the Array-OL language and the synchronous model. The former allows us to express the parallelism in applications while the latter favors the formal validation of the design.

Array-OL

The Array-OL language  [50] , [51] , [48] , [47] gives a mixed graphical-textual language dedicated to express multidimensional intensive signal processing applications. It relies on the following basic principles:

The semantics of Array-OL is that of a first order functional language manipulating multidimensional arrays. It is not a data flow language but can be projected on such a language.

Synchronous model

The synchronous approach [44] proposes formal concepts that favor the trusted design of embedded real-time systems. Its basic assumption is that computation and communication are instantaneous (referred to as “synchrony hypothesis”). The execution of a system is seen through the chronology and simultaneity of observed events. This is a main difference from visions where the system execution is rather considered under its chronometric aspect (i.e., duration has a significant role).

There are different synchronous languages, which have strong mathematical foundations. These languages mainly differ from their programming styles. For instance, the Esterel language [45] adopts an imperative style. It is well-suited for the design of control dominated applications. Other languages such as Lustre [49] or Signal [66] rather adopt a declarative style. More specifically, Lustre is functional while Signal is relational. These two languages are well-adapted for dataflow-oriented applications. All these languages are associated with formal tool-sets that have been successfully used in several critical domains (e.g. avionics, automotive, nuclear power plants, etc.).

In the context of the DaRT project, we consider the last family of languages (i.e. declarative languages) to model various refinements of Array-OL descriptions in order to deal with the control aspect as well as the temporal aspect present in target applications. The first aspect is typically addressed by using concepts such as mode automata, which are proposed as an extension mechanism in synchronous declarative languages. The second aspect is studied by considering temporal projections of array dimensions in synchronous languages based on clock notion.

The resulting synchronous models can be then analyzed using the formal techniques and tools provided by the synchronous technology.

Contributions of the team

Our proposal is partially based upon the concepts of the “Y-chart”  [58] . The MDE contributes to express the model transformations which correspond to successive refinements between the abstraction levels.

Metamodeling brings a set of tools which will enable us to specify our application and hardware architecture models using UML tools, to reuse functional and physical IPs, to ensure refinements between abstraction levels via mapping rules, to ensure interoperability between the different abstraction levels used in a same codesign, and to ensure the opening to other tools, like verification tools, thought the use of standards.

The application and hardware architecture are described by different metamodels. Some concepts from these two metamodels are similar in order to unify and so simplify their understanding and use. Models for application and hardware architecture may be done separately (maybe by two different people). At this point, it becomes possible to map the application model on the hardware architecture model. A third metamodel, called association metamodel, allows us to express this mapping.

All the previously defined models, application, architecture and association, are platform independent. No component is associated with an execution, simulation or synthesis technology. Such an association targets a given technology (OpenMP, SystemC/PA, VHDL, Lustre, etc.). Once all the components are associated with some technology, the deployment is realized.

This is done by the refinement of the association model to the deployed model first, and then to further abstraction levels (e.g. polyhedron, loop in figure 1 ).

The diversity of the technologies requires interoperability between abstraction levels and simulation and execution languages. For this purpose we define an interoperability metamodel allowing to model interfaces between different abstraction levels.

Mapping rules between the deployment metamodel, and interoperability and technology metamodels can be defined to automatically specialize the deployment model to the chosen abstraction levels. From each of the resulting models we could automatically produce the execution/simulation code and the interoperability infrastructure.

The simulation results can lead to a refinement of the application, the hardware architecture, the association or the deployment models. We propose a methodology to work with these models. The stages of design could be:

  1. Separation of application and hardware architecture modeling.

  2. Association with semi-automatic mapping and scheduling.

  3. Selection of IP for each element of application/architecture models.

  4. Deployment (choice of simulation or execution level and platform for each component).

  5. Automatic generation of the various platform specific simulation or execution models.

  6. Automatic simulation or execution code generation.

  7. Refinement at the highest level given the simulation results.

Figure 1. Overview of the metamodels for the “Y” design
GaspardY-20061206
Gaspard2 foundations

The abstract syntax of application and hardware architecture are described by different MOF metamodels. Some concepts from these two meta-models are similar, in order to simplify their understanding and use.

They share a common modelling paradigm, the component oriented approach, to ease reusability. Reusability is one of the key point to face the time to market challenge faced by the designers of embedded systems.

The two meta-models also share some common construction mechanisms, to express repetitive constructs in a compact way. This kind of compact expression makes them more comprehensible for a compiler or an optimisation tool.

To express the mapping of an application model on a hardware architecture model, a third meta-model named association is introduced. This meta-model imports the concepts of the two previously mentioned meta-models.

The definition of the Gaspard2 profile (a detailed specification can be found in [Oops!] ) is oriented by the few guiding ideas mentioned in section 2. It offers a high level modeling environment for high performance systems on chip, and includes UML extensions (formally the UML view point of the profile) as well as an abstract syntax expressed in EMOF (Domain view point). The main evolutions according to past versions of the profile are:

Application metamodel

The application metamodel focuses on the description of data dependencies between components. Components and dependencies completely describe an algorithm without addition of any parasitic information. Actually any compilation optimization or parallelization technique must respect the data dependencies. This gives many benefits:

Application components represent some computation and their ports some data input and output capabilities. Data handled in the applications are mainly multidimensional arrays, with one possible infinite dimension representing time.

The application metamodel introduces three kinds of components : Compound, DataParallel, and ElementaryComponents.

A compound component expresses task parallelism by the way of a component graph. The edges of this graph are directed and represent data dependencies.

A data parallel component expresses data parallelism by the way of the parallel repetition of an inner component part on patterns of the input arrays, producing patterns of the output arrays. Some rules must be respected to describe this repetition. In particular, the output patterns must tile exactly the output arrays.

Elementary components are the basic computation units of the application. They have to be defined for each target technology.

Finally, the application metamodel has been extended with a few concepts that allow one to describe reactive control based on the notion of execution mode.

Hardware architecture metamodel

The purpose of this meta-model is to satisfy the growing need of embedded system designers to specify the hardware architecture of the system at a high abstraction level. It enables to dimension the resources of the hardware in a precise enough way to be pertinent, while abstracting irrelevant details so that efficient decisions can be taken.

A mechanism similar to the one used in the application meta-model enables to specify repetitive architectures in a compact way. Regular parallel computation units are more and more present in embedded in systems, especially in SoCs. There are two main reasons for that:

  1. Time-to-market constraints are becoming so tight that massive reuse of computation units is one of the only ways to get the computation power needed for next generation embedded applications.

  2. Using massive parallel repetitions of simple computation units is the only way to get the required computation power density for high performance embedded applications.

  3. Parallelism is a good way to reduce power consumption in SoCs. Indeed at equal computing power, a chip able to run several computations simultaneously is clocked at a lower frequency than a chip able to run less computations in a given cycle. As frequency is square in the power consumption equation, this leads to important gains.

The repetitive constructs we propose can be used to model parallel computation units, such as grids, but also complex static or dynamic interconnection networks, or memory banks.

Association metamodel

The association metamodel allows to express how the application is projected and scheduled on the architecture. This metamodel imports the application and architecture metamodels in order to associate their components. The association model associates application components with architecture components to express which hardware component executes which functionality. If the hardware component is programmable, the application components associated with this component are implemented in software, otherwise, they are synthesized as hardware. The dependencies between application components are associated with communication routes. These routes are built as sequences of data paths, components and represent the route of data from one memory to another via processor or DMA initiated data exchanges. The input and output of the functional components are mapped into memories.

As the application and hardware architecture models, the association model takes advantage of a repetitive and hierarchical representation to allow to view the association at different granularities and to factorize its representation.

The association model is the input and the output of the optimization algorithm. Indeed, the optimization can be seen as a refactoring of the association model. Code transformations allow to refactor the application to map it more easily on the target hardware architecture. Once refactored, each application component can be mapped to a corresponding hardware architecture component. The repetitive application components can be distributed to a repetitive hardware architecture component. The association metamodel allows at least the regular mapping strategies of classical data-parallel languages as High Performance Fortran.

Deployment metamodel

The deployment metamodel has been identified last year. It allows one to describe the choice of IPs after the association phase in figure 1 . It is now defined (see Section 6.1.2 for more details).

A metamodel based on polyhedra

In order to simplify and factorize the work on model transformations, a metamodel has been defined which is a common denominator of several of the outputs metamodels. Consequently, this metamodel permits representation of a Gaspard2 model, with no “loss” of information for the model implementations, while being at a lower level of abstraction. The goal of the metamodel is to make the notion of association implicit. Instead, the application part of the model is dispatched over the processors (for the tasks) and the memories (for the data). In order to represent the information of which repetition of a task is on which instance of a processor, expressed by the user using the association, the metamodel uses the concepts of polyhedra parametrized by the processor indices. Polyhedron representation has been selected for, at the same time, being able to represent every possible association written by the user and being easily transformed into code.

A metamodel based on loops

This metamodel is used after the one based on polyhedra. It is the last common metamodel before targeting implementation platforms. This metamodel is closed to the polyhedron one. It is used to refine model toward code generation. Polyhedra expressions are transformed into loops expressions using CLooG (Chunky Loop Generator)  [43] . CLooG is a tool that generates loops for scanning Z-polyhedra. For each polyhedron, CLooG is called by transformation rules and polyhedra information are replaced by LoopStatements in the loop metamodel. Loops, which are parametrized by the processor indices, indicate which repetition of a task is executed by which processor. So each processor has the same code. Then, we can target SoC simulation or high performance computing.

A metamodel for procedural language with OpenMP statement

We focused on shared memory computers in order to first simplify the transformations. So we do not have to manage communication between processors. This metamodel is used before code generation for high performance computing. It permits the representation of a code written with procedural language (Fortran and C) with OpenMP statement   [74] . So, we have a representation close to the code, which can be used to target different languages. Finally, code generation is a just "pretty printer" for this metamodel.

A RTL metamodel

The RTL metamodel proposed in Gaspard2 is used for the generation of VHDL code, which is further synthesized on FPGAs. It is entirely defined this year (see Section 6.2.1 for more details).

Synchronous metamodel

The metamodel for synchronous languages serves as a common format for automatic code generation in declarative languages such as Lustre, Lucid Synchrone and Signal. Its implementation has been made complete this year (see Section 6.2.2 for more details).


previous
next

Logo Inria