A co-design methodology based on model driven

ARTICLE IN PRESS Mathematical and Computer Modelling (

)

–

Contents lists available at ScienceDirect

Mathematical and Computer Modelling journal homepage: www.elsevier.com/locate/mcm

A co-design methodology based on model driven architecture for real time embedded systems Stéphane Lecomte a,b,∗ , Samuel Guillouard a , Christophe Moy b , Pierre Leray b , Philippe Soulard c a

Technicolor, Research & Innovation, 1 avenue de Belle Fontaine, 35576 Cesson-Sévigné, France

b

SUPELEC/IETR, Avenue de la Boulais, CS 47601, 35576 Cesson-Sévigné, France

c

Sodius, 6 rue de Cornouaille, 44300 Nantes, France

article

info

Article history: Received 1 November 2009 Received in revised form 7 February 2010 Accepted 16 March 2010 Keywords: Modeling UML MARTE MDA SoC HDL

abstract This paper presents the MOPCOM design methodology, developed to enable the efficient design of real time embedded systems, in particular radio (such as software defined radio) communication and video processing equipment. Based on UML and the model driven architecture approach, it could be advantageously applied for the design of a system on a chip or a system on a programmable chip. The MOPCOM methodology defines a set of rules for building UML models for embedded systems, from which Hardware Description Language code is automatically generated by means of a set of model transformations. The MARTE profile is used to describe real time properties and to perform platform modeling. A wireless communication demonstrator is presented to illustrate the methodology and the tooling. © 2010 Elsevier Ltd. All rights reserved.

1. Introduction The design of future telecommunication equipment introduces new design challenges as new expectations of their functionality arise. One of these is flexibility, mostly known in the radio domain for instance as software defined radio (SDR) [1], or through the reconfigurable video coding (RVC) standardization effort in the video processing domain [2]. In the SDR context, this provokes the convergence of multi-layer processing inside the same kinds of processing units, as radio processing is ported into programmable or reconfigurable devices [3]. More and more demanding capabilities are required at design time in order to build such equipment. The complexity of such systems is increasing so fast that questions are raised in terms of complex modeling, hardware/software (HW/SW) partitioning, HW/SW co-design, integration, etc. In terms of integration, thanks to the ever-increasing performance of digital electronics, an embedded system can be integrated on a single chip: a system on a chip (SoC) or a system on a programmable component (SoPC) inside FPGA reconfigurable components. But in parallel, to catch up with this hardware capacity, a dramatic enhancement of hardware design facilities is required to fill the productivity gap [4]. Another important challenge, induced by the design of SoC/SoPC, consists in reducing time-to-market and the cost due to the rapid evolution of the technology. To achieve those goals, SoC/SoPC design methodologies have to tackle co-design issues such as design space exploration, reuse of intellectual property (IP) components and high level synthesis. Besides electronic system level (ESL) modeling approaches, Unified Modeling Language (UML) [5], originally dedicated to software development, has extended its scope to real time embedded (RTE)

∗

Corresponding author at: Technicolor, Research & Innovation, 1 avenue de Belle Fontaine, 35576 Cesson-Sévigné, France. E-mail addresses: [email protected], [email protected] (S. Lecomte), [email protected] (S. Guillouard), [email protected] (C. Moy), [email protected] (P. Leray), [email protected] (P. Soulard). 0895-7177/$ – see front matter © 2010 Elsevier Ltd. All rights reserved. doi:10.1016/j.mcm.2010.03.035 Please cite this article in press as: S. Lecomte, et al., A co-design methodology based on model driven architecture for real time embedded systems, Mathematical and Computer Modelling (2010), doi:10.1016/j.mcm.2010.03.035

ARTICLE IN PRESS 2

S. Lecomte et al. / Mathematical and Computer Modelling (

)

–

system development, including hardware design [6]. As the development of SoC/SoPC components covers system, software and hardware engineering activities, from the system requirement capture, down to the fine analysis of the hardware logic timing, a SoC/SoPC development methodology should take advantage of these capabilities, such as the UML MARTE profile [7]. MARTE has been standardized by OMG. Following an MDA methodology also contributes to capitalizing, also, the achievements of the ESL community. Moreover, model driven architecture (MDA) [8] derived from model driven engineering (MDE), promotes a development methodology based on model transformations at several levels of abstraction and that follows the well-known Y-chart co-design approach. This paper proposes a design methodology based on an MDA-oriented high level design approach for the design of reconfigurable RTE equipment. The proposed methodology covers the design steps from high level modeling down to low level Hardware Description Language (HDL) code generation. This work has been performed within the MOPCOM project [9] – Modélisation et spécialisatiOn de Plates-formes et COmposants MDA – for the design of SDR and video processing equipment. The first results on a radio application are proposed hereafter. The following section presents the state of the art of the modeling approaches for co-design conception of RTE systems. In the third section, we show the different model types identified in the MOPCOM methodology based on MDA and UML. The next section presents a wireless communication demonstrator to illustrate the different levels of this approach. In Sections 5 and 6, an overview of the MOPCOM tooling environment is presented. The tests, first results of code generation and comparison with the usual design process are detailed in the last section. 2. Related works The developments of SoC/SoPC and RTE systems strongly need the availability of reliable methodology, which represents a wide research topic for the ESL community. Such a methodology, based on appropriate languages and tools, can help to handle simultaneously market pressure (time-to-market, competitiveness), fast changing technology grades as well as migration towards more complicated/sophisticated standards [10]. In order to address the market constraints and obsolescence issues, separation of concerns is needed to allow the concurrent development of applications and execution platforms. This kind of approach was first proposed in the Gajski and Kuhn Y-chart model [11], generalized by the model driven development (MDD) approach and standardized via the MDA OMG standard. Moreover, in order to allow faster design space exploration, the system under study must be modeled and validated at several levels of abstraction [12]. Several languages enable the description of behavioral or structural parts and the allocation of the system under development. The most important factors influencing the choice of a language in a modeling or analysis activity are its expressiveness power and its tooling. For instance, SystemC [13] is a language allowing functional and platform modeling at several levels of abstraction, and is supported by several free or commercial tools dedicated to analysis or compilation/synthesis. In addition to separation of concerns and definition of levels of abstraction, there is a need to favor reusability in order to improve reliability and productivity. Developments of RTE systems include modeling activities, using languages based on either grammars or metamodels, as well as analysis activities such as formal validation or simulation. The main issues when modeling RTE systems are the description of concurrency/communication, execution platform, possibly represented at several levels of abstraction, and quality of service (QoS). Modeling and analysis activities must be placed in the context of a well-defined methodology. For that, there are two different approaches:

• use several domain specific languages (DSL) fitting for each modeling or analysis activity; • use a general purpose modeling language, such as UML, with dedicated profiles to support the required concepts. Additional mechanisms such as annotations are also required in order to add relevant information needed by analysis tools (example: resource usage for schedulability analysis). On the basis of the use of selected formalisms, several methodologies and tools have been developed for supporting RTE systems development. A few examples are given below. The Ptolemy environment from UC Berkeley [14] allows description of systems mixing several models of computation (MoC) through the notions of actors and directors. A director defines a domain of execution for its actors enabling the mixing of several models of computation in the same model. This is an important issue because real time systems usually mix analog and digital devices and possibly several time domains. The MCSE methodology (Méthodologie de Conception des Systèmes Electroniques), proposed in [15], enables design space exploration through the use of the SystemC TLM language. This methodology is supported by the ESL design tool ‘‘Cofluent Studio’’ [16] based on the Eclipse environment. In the context of UML, several profiles have been proposed for extending UML capabilities in order to handle modeling and analysis of RTES or SoC. Among them, we can list:

• the UML4SOC OMG profile is dedicated to describing the system on a chip [17]; • the UML for SystemC profile proposed in [18] gathers the capabilities of UML and SystemC; • the MARTE OMG profile can be viewed as an improvement of the SPT profile [19]. Please cite this article in press as: S. Lecomte, et al., A co-design methodology based on model driven architecture for real time embedded systems, Mathematical and Computer Modelling (2010), doi:10.1016/j.mcm.2010.03.035

ARTICLE IN PRESS S. Lecomte et al. / Mathematical and Computer Modelling (

)

–

3

On the basis of the use of UML profiles, examples of RTE systems or SoC design environments are given below:

• The ACCORD/UML methodology [20], supported by the Eclipse-based PAPYRUS tool [21], aims at using UML concepts to design RTE systems.

• In [22], the authors propose a development process for embedded systems and SoC called the unified process for embedded systems (UPES), based on UML for a SystemC profile.

• The Gaspard methodology [23], based on the MDA approach, is intended to provide a framework for developing parallel and distributed applications implemented on SoC. 3. MOPCOM methodology The MOPCOM methodology is a refinement of the MDA Y-chart dedicated to design for space exploration and platformbased design. MDA techniques coupled with UML are used to perform code generation (VHDL, C/C++ for high level synthesis (HLS) and SystemC). It takes as input functional, non-functional and allocation requirements expressed in SysML [24]. Fig. 1 gives an overview of the process, highlighting three modeling levels:

• The abstract modeling level (AML) is intended to provide the description of the expected level of concurrency and pipeline through the mapping of functional blocks onto a virtual execution platform.

• The execution modeling level (EML) is intended to provide the topology of a generic platform defined in terms of execution, communication or storage nodes in order to proceed to coarse grain analysis.

• The detailed modeling level (DML) is intended to provide a detailed description of the platform in order to proceed to fine grain analysis. It allows Register Transfer Level (RTL) code generation for hardware (VHDL) and software (C language) parts including glue code (drivers). The MOPCOM methodology provides the rationale for using all the MARTE concepts in a consistent manner. Indeed to enforce the definition of the proposed methodology, we select some MARTE elements for each abstraction level. We have defined the usage scope of those concepts by adding constraints to the metatype of the UML/MARTE language. This set of specialized constraints are capitalized into the model of the process itself. In the next section we present each level of our MDA process, with its associated set of MARTE concepts, through an example of a wireless communication demonstrator. 4. The modeling level This section details each level of the MOPCOM process through the design of one sub-part of the baseband digital processing of a wireless communication demonstrator. The use case developed by Technicolor (ex-Thomson) Corporate Research implements a wireless stack [25] based on the 802.16 standard and uses the time division multiple-access (TDMA) and MIMO/orthogonal frequency division multiplexing (OFDM) technologies. The MOPCOM methodology has been applied to multiple-input–multiple-output (MIMO) processing at the receiver side. Fig. 2 shows a synoptic diagram of the MIMO decoder. The radio system can be configured by the user before starting the transmission, or the system can reconfigure itself, depending on the properties of the received signal. The target platform is a based on a configurable component, an FPGA Altera Startix III [26], whose main characteristics are: 338k Logic Elements, 16 272 kbits of RAM memory, 12 PLL and 576 multipliers. 4.1. The abstract modeling level The highest level of our design process, the abstract modeling level (AML), aims at modeling the functional architecture of the system and at specifying the concurrency of the different tasks of the system in order to make relevant analyses like performance analysis or deadlock detection. As shown at the top of Fig. 1, the most abstract level of the design process is called AML. AML modeling consists in three different models: a platform independent model of the application, an abstract model of the platform and an allocated model. Let us detail each one in the following. 4.1.1. The platform independent model in AML In the platform independent model (PIM), the system engineer models the functional architecture of the equipment or system. Figs. 3 and 4 are examples for the PIM of the MIMO decoder demonstrator. Fig. 3 shows the interaction between the actors and the system. As in Fig. 2, the source corresponds to the input signals of the MIMO decoder, channel estimation and the RX signal, while the sink corresponds to the decoded RX data at the output. Fig. 4 shows the different functions of the MIMO decoder. The itsDecoderMIMO object (an instance of the Decoder_MIMO class) controls the steps of the decoding, with a state chart. The itsPreprocChannel, itsPrepocData and itsDemapper objects are pure computing objects (no control). And the itsStackDecoder object is composed of computing and control. 4.1.2. The platform model in AML In this high modeling level, the platform model (PM) is virtual. However, in order to execute the functional architecture, and to execute concurrency, appropriate concepts are needed: models of computation (MoC). A MoC defines the semantics Please cite this article in press as: S. Lecomte, et al., A co-design methodology based on model driven architecture for real time embedded systems, Mathematical and Computer Modelling (2010), doi:10.1016/j.mcm.2010.03.035

ARTICLE IN PRESS 4

S. Lecomte et al. / Mathematical and Computer Modelling (

)

–

Fig. 1. MOPCOM process overview.

Fig. 2. Synoptic diagram of the MIMO decoder.

Fig. 3. Interaction view, between actors and system. Please cite this article in press as: S. Lecomte, et al., A co-design methodology based on model driven architecture for real time embedded systems, Mathematical and Computer Modelling (2010), doi:10.1016/j.mcm.2010.03.035

ARTICLE IN PRESS S. Lecomte et al. / Mathematical and Computer Modelling (

)

–

5

Fig. 4. Objects model diagram of MIMO decoder.

rules for concurrent behaviors and communications. A metamodel of MoC is given in [27] for two MoCs: communicating sequential processes (CSP) and the Kahn process network (KPN). The MARTE profile provides all those missing features through the notion of the RtUnit in the high level application modeling (HLAM) sub-profile. The hhRtUnitii stereotype can be used to classify a set of concurrent objects having real time characteristics. Communications between hhRtUnitii instances are point-to-point and occur through connectors (stereotyping hhRteConnectorii) in the context of their own classifier. Ports and connectors implement the high level primitives that support communication mechanisms. Fig. 5 shows a sample of the PM of the MIMO decoder demonstrator (PM in AML corresponding to the MIMO decoder). ¬ specifies that the different components of the virtual platform are concurrent and ­ specifies the semantic of the communication with the appropriate MoC (CSP, KPN, etc.). For instance, the itsStackDecoder object (function) of the MIMO decoder is allocated to the itsExecStackDecoder concurrent component of the virtual platform. 4.1.3. The allocated model in AML The third model of the Y-chart is the result of allocation of functional architecture to the components of the virtual platform (Fig. 6). The resulting model of Fig. 7 is called the platform specific model (PSM). The hhAllocateii stereotype of the MARTE Alloc sub-profile is used, applied to a dependency link between functional elements and components of the Please cite this article in press as: S. Lecomte, et al., A co-design methodology based on model driven architecture for real time embedded systems, Mathematical and Computer Modelling (2010), doi:10.1016/j.mcm.2010.03.035

ARTICLE IN PRESS 6

S. Lecomte et al. / Mathematical and Computer Modelling (

)

–

Fig. 5. Sample of PM in AML.

platform. The kind of allocation is specified: spatial or temporal for instance (the temporal allocation is used if the system is reconfigurable). 4.2. The execution modeling level The execution modeling level (EML) is made up of three different models as shown in middle of Fig. 1. The main goal of this level is to model the topology of the virtual hardware platform and to analyze, for instance, the system scheduling and the real time performance. The platform and allocation are defined as regards trade-offs between implementation performance and cost. In the context of design space exploration, all of these aspects must be checked by a top-down refinement analysis. 4.2.1. The platform independent model in EML The PIM of EML is the output model of the AML. So the PIM model in EML is composed of MoC components on which functions of the application are allocated as in Fig. 7. A refactoring of PIM in EML is possible if necessary. We can transform the functional architecture in order to allocate the PIM onto PM. In fact, analysis feedbacks drive potential refactoring on the platform as well as on the MoC or the functional architecture. Actually, those refactorings depend mainly on the skill of the engineers to proceed to the right adjustments. 4.2.2. The platform model in EML In EML, PM only represents the topology of the virtual hardware platform based on high level generic components. Indeed, the objective of the virtual platform is to hide the physical platform to the application. This PM divests itself of superfluous details such as the protocols description, and the kinds of computing resources and storage resources used in the physical platform model. The first interest of such a modeling is to represent the nodes of computation, storage, communication, as well as the services offered by the platform to the application. In fact, PM for EML design emphasizes the number of processing elements, organization of data or communication media and their characteristics. Interfaces between connected elements and communication protocols are considered from a high level perspective: data are bit true and inaccurately timed. A natural modeling concept of PM in EML is a transactional level modeling, as promoted by Gajski and SystemC community in general. Thus the communications between the components of the platform are represented by calls of functions and not by a detailed modeling of the protocol and the connectivity which are represented in the RTL level. To model the PM, we use the class/object diagram or the component diagram of UML associated with the MARTE generic resource modeling (GRM) sub-profile. Fig. 8 shows an example of PM with the following stereotypes of MARTE: hhComputingResourceii, hhStorageResourceii and hhCommunicationMediaii. Each resource of PM is characterized by these services and several non-functional properties such as latency, frequency, and data-path width. 4.2.3. The platform specific model in EML The PSM allocation model is built to allocate the functionalities of the PIM model into the components of the virtual hardware platform (PM). This is the same approach as for the previous level (AML). The link of allocation between an MoC component (concurrency virtual component) of PIM and a component of PM is done using a UML dependency. This dependency is characterized by the hhAllocateii stereotype of the MARTE Alloc subprofile. Thus this stereotype helps in specifying whether it is a space or temporal allocation. More than one MoC of one virtual component of the platform can be allocated. Please cite this article in press as: S. Lecomte, et al., A co-design methodology based on model driven architecture for real time embedded systems, Mathematical and Computer Modelling (2010), doi:10.1016/j.mcm.2010.03.035

ARTICLE IN PRESS S. Lecomte et al. / Mathematical and Computer Modelling (

)

–

7

Fig. 6. Allocation of PIM into PM.

Moreover, the mapping of PIM onto the PM to form the PSM must not damage the semantic of the MoC. Actually, if more than two MoC components are mapped onto one component of the PM, the semantics of the point-to-point communication between the MoC components is not affected. But if two MoC components, which communicate to each other, are mapped onto two different components of the PM, the semantic is not ensured because the communication between both hardware components can be done through a bus and not necessarily via a simple point-to-point link. Therefore, the semantics have to be guaranteed for bus communication. 4.2.4. The analysis model In order to analyze the scheduling and the performances of the system, some information must be added to the models of this level. The schedulability analysis provides the ability to evaluate time constraints and to guarantee a worst-case behavior of a real time system. For the schedulability analysis, MARTE sub-packages, schedulability analysis modeling (SAM) and performance analysis modeling (PAM) are used. Analysis scenarios have to be defined. For each scenario the context and the parameters are modeled, thus requiring an indication of the type of scheduling resource of each element of the model as shown in Fig. 9. For example, analysis scenarios emphasize data rates and latencies as well as memory size or context switching in the case of dynamic reconfiguration. Please cite this article in press as: S. Lecomte, et al., A co-design methodology based on model driven architecture for real time embedded systems, Mathematical and Computer Modelling (2010), doi:10.1016/j.mcm.2010.03.035

ARTICLE IN PRESS 8

S. Lecomte et al. / Mathematical and Computer Modelling (

)

–

Fig. 7. PSM, the output model of AML, and the input model of EML.

Fig. 8. Platform model in EML. Please cite this article in press as: S. Lecomte, et al., A co-design methodology based on model driven architecture for real time embedded systems, Mathematical and Computer Modelling (2010), doi:10.1016/j.mcm.2010.03.035

ARTICLE IN PRESS S. Lecomte et al. / Mathematical and Computer Modelling (

)

–

9

Fig. 9. PSM with SAM stereotypes of MARTE.

When the model analysis is completed, several possibilities for analyzing the different scenarios are possible. We can use a dedicated analysis tool. Another possibility consists in generating the equivalent model in SystemC in order to simulate the analysis scenarios. In both approaches, it should be noted that the metamodels of UML and MARTE might be different from the metamodel of the syntax used in the selected analysis tool or SystemC language. Thus, it is necessary to translate the EML model into another syntax. This transformation could be done with © MDWorkbench (cf. Section 5). 4.3. The detail modeling level At shown at the bottom of Fig. 1, the detail modeling level (DML) aims at describing the platform with more accuracy than for the previous level (EML) in order to generate the final RTL code. The topology that has been defined in the EML level is refined. At this level, hardware specification is finalized, relying on generated hardware components or the existing IP block. 4.3.1. The platform model in DML At that level, the MARTE hardware resource modeling (HRM) sub-profile is used to define which kinds of elements each node represents and its characteristics (by completing the associated tags to the stereotype). As shown in Figs. 10 and 11, computing nodes are turned into processors, programmable logic devices (PLDs), e.g. FPGAs, or application specific integrated circuits (ASICs), and storage nodes become RAM or ROM. All components of the platform must be stereotyped with MARTE HRM elements. A platform is defined as a set of components connected through ports. For each port, a stereotype, which defines a communication protocol, is attached. A library is associated with each protocol stereotype used in code generation. For instance, the DDR2 memory of the hardware platform is modeled with a class which is stereotyped hhHwRAMii from MARTE HRM sub-profile. Associated with this stereotype, some tags enable one to specify the characteristics of this memory, such as its capacity, the size of data and the address bus or its latency. A component with an hhHwClockii stereotype must be present in the platform to allow performance analysis and code generation for the synchronous component. Fig. 11 shows an overview of the internal architecture of the FPGA Altera Stratix III. The dark block represents reused external VHDL IP (from previous project or third parties) while clear bright blocks are specifically designed for this project. An Avalon bus connects the different components together. Note that Figs. 10 and 11 represent the global target platform of the wireless communication demonstrator and only the MIMO decoder subpart. 4.3.2. The allocation in DML Allocation at this level involves defining where functional components (MoC components) are placed into platform components (MARTE HRM stereotyped components) as shown in Fig. 10. Application components are logical units with behavior. Such behavior will be executed in/by a platform component. It is important to remark that a component whose behavior definition contains a state machine must be allocated to a component connected to a clock or to a processor. The MIMO decoder subpart of baseband processing is allocated on the PHY_MIMO_IP component which supports the transmit (Tx) and receive (Rx) MIMO processing. Please cite this article in press as: S. Lecomte, et al., A co-design methodology based on model driven architecture for real time embedded systems, Mathematical and Computer Modelling (2010), doi:10.1016/j.mcm.2010.03.035

ARTICLE IN PRESS 10

S. Lecomte et al. / Mathematical and Computer Modelling (

)

–

Fig. 10. Sample of a target platform model.

Fig. 11. Internal architecture of the FPGA.

5. Tooling support The MOPCOM process relies on tools related to OMG standards (MDA, UML, MOF, and XMI) and Eclipse (EMF, EMOF, and ECore):

• The KerMeta language from INRIA [28] is used to formalize and validate the metamodels (concepts and constraints). • The Rhapsody UML Modeler [29] is used to model applications as well as platforms according to the defined levels. • The Sodius © MDWorkbench tool [30] is used to transform models (model-to-model) and generate code or documentation from models (model-to-text). The generator is delivered as a white-box add-on, where all transformations and generation rules are available for any customization. Please cite this article in press as: S. Lecomte, et al., A co-design methodology based on model driven architecture for real time embedded systems, Mathematical and Computer Modelling (2010), doi:10.1016/j.mcm.2010.03.035

ARTICLE IN PRESS S. Lecomte et al. / Mathematical and Computer Modelling (

)

–

11

Fig. 12. MOPCOM process tool interactions.

RTE systems modeling requires an action language for low level expressions to complete the high level UML semantics and diagrams, and to specify operation bodies, trigger/guard/action on transition and states as well as data declarations. The selection of the right action language raises questions about textual or graphical notation, and general versus HDL specific language accessible to designers, taking into account learning curves. The C++ language turned out to be a convenient choice and only a C++ subset is used in the models (along with some macros for event and port handling). C++ expressions are parsed for VHDL generation thanks to a C++ syntactic metamodel allowing grammar to model transformations. Kermeta is only used by MOPCOM partners for the methodology definition. Future users of MOPCOM design flow are only concerned with a UML modeler and a transformation tool. We propose in Fig. 12 one possible instantiation of this flow with the Rhapsody UML modeler and © MDWorkBench transformation tool. 6. Code generation The MOPCOM process associated with MOPCOM tools offers three different generations of code: VHDL, C/C++ for HLS tools, and SystemC. These different languages correspond to different modeling levels and to the purpose targeted by the designer at different steps of the design. VHDL and C++ for HLS clearly target the implementation code generation at the lower level of the design process: DML. SystemC code generation may be done at all three levels, depending on the modeling needs and the desired level of abstraction in the analysis. 6.1. UML towards a VHDL code generator VHDL code generator input is a DML model, i.e. the lowest abstraction level within the process (Fig. 1), which includes the application and platform packages, as well as the allocation of the application class instances on the platform class instances. Structural parts are derived from the platform model, where VHDL entities are derived from the hierarchy of instances. UML ports are translated to VHDL ports thanks to communication protocols and data. Behavioral parts are derived from application models, where VHDL architectures are mainly issued from attributes, operations and state machines. So this generator is mainly used to generate the hardware architecture, the skeleton of each entity and the VHDL code for state machines. This topic is however beyond the scope of this paper. 6.2. A C/C++ code generator for the HLS tool In order to reuse an external IP, a VHDL black box can be generated with the right interface of system element. VHDL IP blocks come from IP libraries, or from an HLS tool, such as Catapult Synthesis [31], which generates a VHDL IP from C/C++ code. So the UML for C/C++ generator code is based on the C++ description of an algorithm in the functional (PIM) model. Then C/C++ for the HLS code generator generates only the code for the element of the model tagged with hhHLSii. This means that, for a pure computing function, an additional code generator, especially optimized to generate efficient and synthesizable code, is used. Please cite this article in press as: S. Lecomte, et al., A co-design methodology based on model driven architecture for real time embedded systems, Mathematical and Computer Modelling (2010), doi:10.1016/j.mcm.2010.03.035

ARTICLE IN PRESS 12

S. Lecomte et al. / Mathematical and Computer Modelling (

)

–

Fig. 13. HLS tool integration in the MOPCOM process.

Fig. 13 shows the integration of an external HLS tool within the MOPCOM process. In the next section, Section 7, results for this case are presented. 6.3. The SystemC generator The UML models, independently of the modelers, cannot be executed. However, the models must be validated. SystemC language could be used to perform the simulation. SystemC is based on C++ language, and can model software and hardware at different levels of abstraction: an untimed model down to bit accurate model. This requires a generation (from the UML model to System C code), which has been developed and integrated in the MOPCOM methodology. For each of the three levels of the MOPCOM process, we transform the UML models to SystemC models and the resulting models are simulated in order to validate the UML models. But this is beyond the scope of this paper. 7. Tests, results and comparison So far, the process has been validated by the following three steps:

• Modeling of our MIMO decoder example system. • Generating the C++ code for the HLS tool. • Generating the VHDL synthesizable code with the HLS tool. The modeling of our testing system has been depicted in Section 4. We illustrated the MOPCOM modeling flow with some samples of UML and MARTE profile modeling of a sub-part of a wireless communication demonstrator. The model under test contains 80 classes in the three levels and 21 diagrams. 20 different stereotypes of the MARTE profile have been used. For the second step, i.e. the generator from UML to C++ for HLS tools and the integration of the © CatapultC tool in the MOPCOM flow, we focus on three functions of the MIMO decoder (Fig. 2) that are only composed of algorithmic processing (without any control). The first results of code generation are consistent: C++ code from the UML model has been successfully generated. A comparison has been made with the C++ optimized handwritten code. Only a few differences were observed, in particular the initialization of multidimensional tables (an issue related to the modeling tool). After correction, we obtain the same simulation results as were validated towards achieving a © Matlab reference model. The third step of the evaluation consists in generating synthesizable VHDL IP from C++ code. For that we use an HLS tool. The CatapultC tool has been chosen. This tool requires a good control of the hardware concepts and the different settings that the user can configure in order to obtain a synthesizable VHDL IP for the target. In this approach, it is important to pay attention to the interfaces of the components connected to each other so that integration succeeds. A VHDL IP is obtained quickly from a class C++ code. So its functionality can be validated with the integrated verification flow of the tool. It compares the outputs of the C++ model and the VHDL IP with the same C++ testbench (no need for a specific VHDL testbench). After functional behavior checking, we analyze the final hardware performances: for that purpose, the simulation diagram is used. In order to improve the timing performances a GANT diagram is proposed, in CatapultC, to optimize the architecture of the IP (unroll loop, parallel loop, stage pipeline). The main advantage of such an HLS tool is that the engineer doesn’t concentrate any more on the writing of VHDL code of component, but only on the architecture of this one: the design effort moves to a high level modeling phase. Coding errors are completely removed, which increases the productivity. Such VHDL code is hard to read. While in practice, designers still want to have control of it, in the near future one can expect no designers to impose such a requirement. The last step for ensuring the validation of our methodology is comparing the results of the synthesis. An FPGA Altera Stratix III is targeted. We intend to study the numbers of memory blocks used, the numbers of LUT used, and the number of DSP blocks used. This task is currently ongoing: in particular, we perform optimization via the HLS VHDL generator to get competitive results versus handwritten coding. However even if we do not have finished experiments yet, we can compare our methodology and the methodologies currently used to develop real time embedded systems. With such an approach, we have the same environment for the system, software engineer and hardware engineer. So the understanding between teams is better. Errors can be detected more quickly in the process than with usual well-known methodologies. The modeling on three levels makes it possible to distinguish the functional and architecture concerns. In Please cite this article in press as: S. Lecomte, et al., A co-design methodology based on model driven architecture for real time embedded systems, Mathematical and Computer Modelling (2010), doi:10.1016/j.mcm.2010.03.035

ARTICLE IN PRESS S. Lecomte et al. / Mathematical and Computer Modelling (

)

–

13

addition, the automatic generation of VHDL code associated with HLS tools brings about an undeniable productivity gain, in particular limiting the errors inherent in manual coding. The highest difficulty of such an approach is the understanding and the learning of the modeling concept for an electronic engineer. In fact, it remains too far away from their current concerns. 8. Conclusion We have presented a new design flow, MOPCOM, for telecommunication software engineering. Radio design is indeed becoming more and more a software issue, as software defined radio becomes a standard approach for radio communication devices. The main objective of MOPCOM is to offer a design methodology for RTE systems based on model driven architecture, using UML and the MARTE profile. This process emphasizes application and platform modeling at different levels of abstraction and the allocation of the application models to the platform models. For each level, the selected MARTE stereotypes and the related constraints have been presented. This process has been applied to a wireless communication demonstrator, for which a C/C++ code and a synthesizable RTL code have been generated. The overall progress of our experiments does not permit us to definitely conclude yet in an exhaustive way as regards the improvements of such a methodology compared to usual design processes. These expected results should come soon. Anyway, we have clearly noted the advantages of the model approach. Provided the handling is effective, the automatic generation of VHDL code improves development speed and quickly. Moreover, such a methodology permits one to move the challenges of the real time embedded systems co-design: instead of manual coding, the engineers can focus on the choice of the best architecture (software and hardware) and detect more rapidly, during the process, the errors and the wrong directions. Our future work, first, consists in improving the integration between UML flow and code generators (especially the generator UML, towards SystemC), to improve the flow in other domains and with other tools. Then, we target expanding the methodology to integrate the modeling of the partial reconfiguration (PR) of FPGA. Acknowledgements The UML/MDA approach presented above is experimented on in the RNTL06 research program MOPCOM SoC/SoPC supported by the French National Research Agency (ANR – contract 2006 TLOG 022 01), the ‘‘cluster of clusters’’, ‘‘Media and Networks’’ and the Brittany and Pays de la Loire regions. We also thank all MOPCOM participants for their contribution to this work. References [1] J. Mitola, The software radio, in: IEEE National Telesystems Conference, 1992, doi:10.1109/NTC.1992.267870. [2] S.S. Bhattacharyya, J. Eker, J.W. Janneck, C. Lucarz, M. Mattavelli, M. Raulet, Overview of the MPEG reconfigurable video coding framework, Journal of Signal Processing Systems (July) (2009) doi:10.1007/s11265-009-0399-3. [3] M. Raulet, F. Urban, J.F. Nezan, C. Moy, O. Deforges, Y. Sorel, Rapid prototyping for heterogeneous multicomponent systems: an MPEG-4 stream over an umts communication link, Eurasip Journal on Applied Signal Processing, Article ID 64369 (special issue on Design Methods for DSP Systems, Kluwer Academic Publishers), 2006. [4] ITRS, Design, Technical Report, International Technology Roadmap for Semiconductors, 2007. [5] OMG, UML 2.1 Infrastructure, Report num. ptc/06-04-03, Object Management Group, 2006. [6] S. Rouxel, J.P. Diguet, N. Bulteau, J. Carre-Gourdin, J.E. Goubard, C. Moy, UML framework for PIM and PSM verification of SDR systems, in: SDR Forum Technical Conference’05, Anaheim, USA, November, 2005. [7] OMG, UML profile for MARTE, Beta 2, report num. ptc/2008-06-08, Object Management Group, 2008. [8] OMG, MDA guide version 1.0.1, Report num. omg/2003-06-01, Object Management Group, 2003. [9] MOPCOM, Partners, MOPCOM SoC/SoPC Project, www.mopcom.fr, 2007. [10] S. Gerard, F. Terrier, UML for real-time: which native concepts to use?, in: ACM, vol. 13, Kluwer Academic Publishers, 2003, pp. 17–51. [11] D.D. Gajski, R.H. Kuhn, New VLSI Tools, IEEE Computer 16 (12) (1983) 11–14. [12] A. Sangiovanni-Vincentelli, L. Carloni, F.D. Bernardinis, M. Sgroi, Benefits and challenges for platform-based design, in: Proceedings of the 41st Annual Conference on Design Automation, DAC, New York, USA, ACM, 2004, p. 409–414. [13] OSCI, IEEE standard SystemC language reference manual, Report num. IEEE Std. 1666-2005, IEEE Computer Society, 2005. [14] J. Buck, S. Ha, E.A. Lee, D.G. Messerschmitt, Ptolemy: a framework for simulating and prototyping heterogeneous systems, in: IEEE, vol. 10, Kluwer Academic Publishers, 2002, pp. 527–543. [15] J. Calvez, The MCSE methodology overview, Report, Cofluent Design, 2008. [16] Cofluent Design, Cofluent Studio, www.cofluentdesign.com. [17] OMG, UML profile for system on a chip, Report num. formal/06-08-01, Object Management Group, 2006. [18] E. Riccobene, P. Scandurra, A. Rosti, S. Bocchio, A SoC design methodology involving a UML 2.0 profile for SystemC, in: Proc. of the Conference on Design, Automation and Test in Europe (DATE), IEEE Computer Society, Munich, Germany, March,2005, pp. 707–709. [19] OMG, UML Profile for schedulability, performance, and time, Report num. formal/2005-01-02, OMG, 2005. [20] S. Gerard, F. Terrier, Y. Tanguy, Using the model paradigm for real-time systems development: ACCORD/UML, in: Advances in Object-Oriented Information Systems, in: Lecture Notes in Computer Science, vol. 2426/2002, Springlink, 2002, pp. 260–269. [21] CEA, Papyrus UML modeler, www.papyrusuml.org. [22] E. Riccobene, P. Scandurra, A. Rosti, S. Bocchio, Designing a unified process for embedded systems, in: The 4th international Workshop on MOdel-based Methodologies for Pervasive and Embedded Software (MOMPES), IEEE Computer Society, Braga, Portugal, March,2007. [23] E. Piel, R.B. Atitallah, P. Marquet, S. Meftali, S. Niar, A. Etien, J.L. Dekeyser, P. Boulet, Gaspard 2: from MARTE to SystemC simulation, 2008. [24] OMG, Systems modeling language, Report num. ptc/2008-05-16, Object Management Group, 2008. [25] F. Le Bolzer, S. Guillouard, C. Guguen, P. Fontaine, R. Monnier, Prodim@ges - A new video production environment based on IP wireless and optical links, in: NEM’SUMMIT, Saint-Malo, France, October, 2008. Please cite this article in press as: S. Lecomte, et al., A co-design methodology based on model driven architecture for real time embedded systems, Mathematical and Computer Modelling (2010), doi:10.1016/j.mcm.2010.03.035

ARTICLE IN PRESS 14 [26] [27] [28] [29] [30] [31]

S. Lecomte et al. / Mathematical and Computer Modelling (

)

–

Altera Corporation, Stratix III family, www.altera.com/products/devices/stratix-fpgas/stratix-iii/st3-index.jsp. A. Koudri, J. Champeau, D. Aulagnier, D. Vojtisek, Processus de codesign UML/MARTE, Neptune, Paris, France, May, 2009. INRIA, KerMeta meta-programming environment, www.kermeta.org. Telelogic, An IBM Company, Rhapsody UML modeler, www-01.ibm.com/software/awdtools/rhapsody/. SODIUS, MDWorkbench platform, www.mdworkbench.com. Mentor Graphics, Catapult synthesis tool, www.mentor.com.

Please cite this article in press as: S. Lecomte, et al., A co-design methodology based on model driven architecture for real time embedded systems, Mathematical and Computer Modelling (2010), doi:10.1016/j.mcm.2010.03.035