MoPCoM Methodology: Focus on Models ofComputation

Ali Koudri, Joel Champeau, Jean-Christophe Le Lann, and Vincent Leilde

ENSIETAfirstname.lastname@ensieta.fr

Abstract. Today, developments of Real Time Embedded Systems haveto face new challenges. On the one hand, economic laws require a re-liable development process allowing quick design space exploration. Onthe other hand, rapidly developing technology, as described by Moore’slaw, requires techniques to handle the resulting productivity gap. In aprevious paper, we have presented our Model Based Engineering basedmethodology addressing those issues. In this paper, we make a focus onModels of Computation design and analysis. We illustrate our approachon Cognitive Radio System development implemented on an FPGA. Thiswork is part of the MoPCoM research project (http://www.mopcom.fr)gathering academic and industrial organizations.

1 Introduction

Recently the market of System-on-Chip (SoC) has grown rapidly. It is expectedto worth $56 billion in 2012, which represents almost 24% annual growth rate.As the technology evolves rapidly, according to the Moore’s law, entire sys-tems, made of processors, memories or sensors, can now be integrated on SoCor System-on-Programmable-Chip (SoPC) like Field Programmable Gate Array(FPGA). Indeed, only reliable methodologies, based on well-adapted formalismsand tools, can handle the growing design complexity of such systems.

On the one hand, the challenges posed by design of SoC/SoPC consist mainlyin reducing TTM (time-to-market), costs and productivity gap due to the rapidevolution of technologies [1]. To achieve those goals, SoC/SoPC design method-ologies have to tackle co-design issues such as Design Space Exploration, reuseof IPs (Intellectual Property), Platform Based Design (PBD) or High Level Syn-thesis. On the other hand, Model Based Engineering (MBE) adds valuable con-tributions to SoC/SoPC Design [2]: analysis enhancement, communication andtraceability improvement, technology breakpoints reduction, platform indepen-dent approach, etc.

In this paper, through a presentation of the MoPCoM methodology, we em-phasize the use of a communication model between the platform elements toclarify the execution model dedicated to receive the application. In this context,the hardware platform is abstracted and virtualized by the execution of commu-nication model, i.e. the Model of Computation. Our methodology is based on

the use of the MARTE profile (Modeling and Analysis of Real Time EmbeddedSystems [3]) for UML and has been tooled in the Rhapsody modeling tool. Weillustrate the use of this methodology on the design of a Cognitive Radio Systemimplemented on a Xilinx ML-506 FPGA platform.

The paper is organized as follow: the second section provides a generaloverview of the MoPCoM methodology; the third section discusses the inte-gration of models of computation to the system specification, the fourth sectionpresents illustration and tooling of our methodology, the fifth section places ourwork in the context of related work, and the conclusion discusses the relevancyof our work and presents future works.

2 Process and Application Overview

The MoPCoM methodology is a refinement of the MDA Ychart [4] dedicatedto Design Space Exploration, reuse of IPs and Platform Based Design [5]. Ittakes as input functional, non-functional and allocation requirements expressedin SysML complemented by MARTE for non-functional properties expression.

Fig. 1. MoPCoM Process Overview

Figure 1 gives an overview of the process, highlighting 3 modeling levels whichare detailed in [6]:

– The Abstract Modeling Level (AML) is intended to provide the descriptionof the expected level of concurrency and pipeline through the mapping offunctional blocks onto an abstract platform,

– The Execution Modeling Level (EML) is intended to provide the topologyof the execution platform defined in terms of execution, communication orstorage nodes in order to proceed to coarse grain analysis,

– The Detailed Modeling Level (DML) is intended to provide a detailed de-scription of the platform in order to proceed to fine grained analysis. Itallows Register Transfer Level (RTL) code generation for hardware (VHDL)and software (C) parts including glue code (drivers).

We illustrate application of the methodology on a Cognitive Radio System.A Cognitive Radio [7, 8] is a system that adapts its behavior to enhance the useof electro-magnetic environment in order to provide a best quality of service forcommunications handling. Actually, we have applied our methodology on a realuse case which consists in locating emitting RF sources in the electromagneticspectrum, from specification to implementation. This application is used as areference application in an industrial context. In the next section, we discussallocation of the functional design (PIM - Platform Independent Model) onto anAML platform, capturing first implementation choices in terms of communica-tion and concurrency.

3 Abstract Modeling Level

Modeling concurrency and communications can be achieved by several means.For instance, concurrency in UML can be expressed at several levels. At thebehavioral level, one can use for example AND states (state machines) or forknodes (activity). At the structural level, the meta-attribute “isActive” of theUML Class bears the notion of concurrent entity. In the MARTE profile, con-currency can be captured through the notion of RTUnit which adds real-timefeatures to the UML active class. Unfortunately, execution semantics and com-munication are not well addressed either in the UML or the MARTE profile.For instance, execution semantics in UML is described informally allowing toolproviders the responsibility to define the way models should be executed [9]as well as solving semantic variation points of the UML specification [10]. InMARTE, communications are point-to-point and occur through “RTeConnec-tors” between “RTUnits” instances in the context of their owning classifier. Evenif the MARTE profile allows a better modeling of communications, especially inreal time features modeling, we think work of designers could be facilitated ifsome of the well known communication schemes could be reused and integratedmore easily.

The aim of the abstract modeling level is to allocate business blocks ontoa virtual platform representing choices about concurrency and communication(MoC - Model of Computation) and proceed to relevant analysis like deadlockor starvation detection based on model simulations.

Then, more information is required in order to achieve more deterministicexecution enabling uniform simulations and analysis. Regarding the lack of UMLand MARTE to model MoC, we propose a metamodel called Cometa dedicated

to the capture and the analysis of high level MoC. The goals of this metamodelare: to provide a better separation between computation and communication, toease decisions related to allocation of the application on the execution platform,and to preserve the application behavior through allocations in order to easeverification activities.

Indeed, an AML platform is made of interconnected units of concurrencycommunicating via specific connectors providing data transport services. It isactually a point-to-point network in which all entities are interconnected throughports and channels having different natures. At this level, the platform is con-sidered ideal as it does not make any assumption about resource limitations.

Fig. 2. MoC Component and Domains

MoCs provide different capabilities in terms of design and analysis, and oneof the goals of system designers is to select appropriate MoC and proceed torelevant analysis, taking into account heterogeneity of modeled systems. In thiscontext, tools supporting execution of heterogeneous MoCs like Ptolemy [11] areuseful to analyze systems combining heterogeneous parts (analog, digital, GALS,etc).

For this purpose, we propose a metamodel called Cometa dedicated to de-scription of MoC domains. A Cometa model saves definition of MoC domains intoshareable libraries. A domain is mainly characterized by: its behavioral schemedefining kind of supported behavior definitions (state based, ODE, etc.), its tem-poral scheme defining the underlying model of time (causal, discrete, continuous,etc.), its data scheme defining the kind of data manipulated (abstract data types,bit vectors, etc.), and its communication scheme defining mechanisms supportingcommunications and synchronizations. Examples of MoC domains are numerousin the literature: Concurrent Sequential Process (CSP), Kahn Process Network(KPN), etc. Our goal is to propose a dedicated formalism (DSML - DomainSpecific Modeling Language) to describe and to execute them.

In our metamodel, the notion of concurrency is represented by the conceptof “MoCComponent”. A MoC component has the responsibility to adapt partsallocated from the application design with respect to the chosen model of com-putation. More precisely, A MoC component is unit of concurrency composedof heterogeneous “MoCPart” interconnected by “MoCConnector” through “MoC-Port” (figure 2). All those elements define the structural aspect of a model ofcomputation and heterogeneity can be handled through components hierarchies.

Fig. 3. Excerpt of Domain Definition

Domain applied to a MoC Component binds semantics for each of thosestructural features. For instance, behavioral scheme of the chosen domain definesan execution pattern for each of the AML platform structural feature (figure3). Behavioral patterns are defined in respect to other orthogonal schemes ofthe domain, e.g. data, time and communication and can be checked throughOCL constraints. In the same way, communication scheme defines more preciselyconstraints related to communication specification (interfaces and protocols) ordetailed support mechanisms (FIFO, shared memory, etc.).

Yet, RTES modeling requires an action language for low-level expressions tocomplete the high-level UML semantics and diagrams, and to specify operationbodies, trigger/guard/action on transitions and states as well as data declara-tions. The selection of the right action language raises questions about textualor graphical notation, and general versus HDL-specific language accessible todesigners, taking into account learning curves. The C++ language was a con-venient choice and only a C++ subset is used in the models (along with somemacros for event and port handling).

4 Experiments and Tooling

The Cometa metamodel has been tooled into the Eclipse environment and weprovide a set of transformation rules in order to reuse model execution capabili-ties provided by the Rhapsody UML modeling tool and its execution framework

OXF (Object eXecution Framework). The OXF framework provides a discreteevent engine onto which several MoCs can be executed. The approach adoptedis quite similar to the approach presented in [12] in the context of the SystemCframework. The flow associated to the utilization of the metamodel is summa-rized in the figure 4.

Fig. 4. Flow for Tooling a New MoC

Initially, a designer captures the properties of a model of computation usingthe Cometa metamodel. Then, a model-to-model transformation takes as inputthe captured model and generates a model library of usable and configurableMoC components for the Rhapsody framework. Those components can be thenassembled to build an AML Platform which can be woven with the applicationmodel to generate an executable model.

For instance, figure 5 shows an allocation of the business design 1© to anAML platform 2© , which mixes two models of computation: KPN (Kahn ProcessNetwork) and CSP (Concurrent Sequential Process).

The allocated platform 3© is generated through model-to-model transfor-mation and contains additional artifacts (communication and synchronizationresources) needed to achieve correct simulations.

Figure 6 focuses on the ”Echo Removing” block and shows the adaptation ofthe spectral analysis block to support KPN execution. This generated block actsas a local scheduler and controls event sending and reception as well as executionof allocated functional blocks. The KPN adapter adapts system interfaces toMoC interfaces which exhibit high level communication primitives (non-blockingwrite, blocking read, etc.) and implements high level communication protocols.Analyses at this level are based on the observation of the simulation traces thatcan be compared to expected traces defined by the specification.

Fig. 5. Functional to AML Platform Allocation

Fig. 6. AML Allocated Platform Excerpt

For instance, the figures 7 and 8 show traces of 2 different mappings of thesame application. The first one targets a platform implementing KPN commu-nications while the second one target a platform implementing CSP communi-cations. Briefly, in the first figure (KPN), Application 2 locks until data hasbeen produced by Application 1 1©. When Application 1 produces a data 2©, itsends it to the connector 3© and continues its job. Then, availability of a newdata unlocks Application 2 which consumes it 4©. In the second figure (CSP),Application 2 locks until data has been produced by Application 1 1©. When

Application 1 produces a data 2©, it locks until the Application 2 has consumedit 3©.

Fig. 7. KPN Simulation with Rhapsody

5 Related Works

Transforming customer requirements into implementations making good trade-offs between performance and cost requires relevant analysis activities basedon appropriate languages and tools. Real Time Embedded Systems (RTES) areheterogeneous as they generally mix analog or digital sub-systems with differentcharacteristics related to specific domains (signal processing, image processing,etc.). Therefore, such heterogeneity must be handled at design and analysis timeusing dedicated formalisms and tools through several abstraction levels and welldefined processes.

Several approaches have been applied by ESL (Electronic System Level) andMBE communities in order to tackle issues posed by economic laws and rapidevolution of technology. Among them:

Fig. 8. CSP Simulation with Rhapsody

– High Level Synthesis [13] aims at transforming high level behavior specifica-tion into optimized architecture,

– IP reuse aims at building systems assembling IPs which requires standardinterfaces or wrappers [14],

– Platform Based Design [15] consists in configuring a generic platform con-taining configurable components like microprocessors or FPGA to suit aspecific kind of application,

– Separation of concerns is one of main features of the MBE techniques as itmakes a clear separation between domains.

MBE adds valuable contributions to SoC/SoPC Design: analysis enhance-ment, communication and traceability improvement, technology breakpoints re-duction, etc. Related works on MBE based RTES methodologies and associ-ated tools are numerous. For instance, in [16], the authors present a method-ology based on the use of UML and Platform Based Design called Metropolis.They highlight the necessary orthogonalisation of several aspects: computationand communication, function and architecture, behavior and performance. Theyprovide a set of stereotypes and a dedicated framework supporting function /platform mapping, refinements and code generation. In [17], the authors presentan object oriented methodology based on the use of UML: the HASoC method-ology (Hardware and Software Object on Chip). They first provide an abstractmodel of the system that is executable (uncommitted model) and proceed to thepartition into hardware and software parts taking into account implementationconstraints (committed model). In [18], the authors combine the visual featuresof UML with the simulation and debugging features of the SystemC languagein a methodology called UPES (Unified Process for Embedded Systems). This

“specify-simulate-debug-refine” methodology is based on the use of the UML forSystemC profile and allows users to capture behavioral and structural aspectsof the system at several levels of abstraction. The Gaspard methodology [19] isdedicated to Multi-Processors Systems-on-Chip (MPSoC) design. It is based onthe use of a dedicated profile called “Gaspard Profile” allowing regular repetitivestructure platform modeling. The Gaspard environment provides TLM and RTLcode generation and bridges to several analysis tools. Finally, the Harmony/ESW(Embedded System Workflow) [20] is a Rational Unified Process (RUP) basedmethodology dedicated to RTES design. It describes the rationale that guideRTES development from requirements capture to implementation using SysML[21] and SPT [22] profiles.

According to the MDA specification [4], using models to represent businessdomain (problem / specification), platform (solution) and the allocation (imple-mentations choices) is really helpful because it makes explicit what was previ-ously made implicitly. But as we mentioned in [6], the current MDA specificationis mainly related to software development as it represents only one level of ab-straction of the platform and according to the ESL community, there is a need torepresent the platform at several levels of abstraction in order to handle designspace exploration [23]. Among main issues addressed by the ESL community,choices related to concurrency and communication issues should be explicitlycaptured by high level Models of Computation. Several approaches have beenproposed to handle MoC heterogeneity. For instance, the authors in [16, 24] high-light the necessary orthogonalisation of several aspects of MoCs: computationand communication, function and architecture, behavior and performance. Ad-ditionally, in [2], the authors discuss MoCs and semantics metamodel and showthat MBE is a good candidate to address those issues. Actually, Models of Com-putation are present at each level of abstraction, and from the idea (specification)to the realization (implementation), they exhibit different properties, related tothe kind of analysis that has to be performed.

6 Conclusion and Future Works

In this paper, we have presented our SoC/SoPC Design Flow based on the useof UML and dedicated profiles. Although some improvements can be done, par-ticularly in the MoCs support, we have shown that MBE techniques, based onthe use of UML for MARTE profile, can fit into Co-Design through an exampleof Cognitive Radio Application implemented on FPGA. This MBE approach re-fines the MDA Y-Chart in order to tackle achievements of the ESL community.In addition to the use of the UML for MARTE profile, we have implemented ametamodel called Cometa to specify and tool models of computation.

The following table gives some model metrics for the processed use case(Locate RF Source).

Metrics including the number of MoC used, allow us to understand theirsignificance in the Cognitive Radio example, and more generally in systems in-corporating concurrency and communication. Thanks to the generative approach

System Size AML Size

Package 46 Package 19

Requirement 174 MoC Comp. 12

Use Case 8 RTUnit 15

Actor 8 Interface 2

Block 13 Event 7

Interface 11 Data Type 0

Event 22 Signal 0

Data Type 10 Inheritance 8

Signal 2 Realization 14

Inheritance 11 Association 4

Realization 73 Allocation 34

Association 4 MoCConnector 25

Dependency 94 RteConnector 61

FSM 21 FSM 5

Diagram 27 Diagram 17

Table 1. Design Metrics

presented in our paper, MoC type or architecture changes lead to a minimal im-pact on efforts and designing time of platform architects. This work is part of theMoPCoM project (http://www.mopcom.fr), gathering academic and industrialorganizations and supported by the French Agence Nationale de la Recherche(RNTL 2006 TLOG 022 01), the ”Media and Networks” ”cluster of clusters” andBrittany and Pays de la Loire regions.

References

1. ITRS: Design. Technical report, INTERNATIONAL TECHNOLOGY ROADMAPFOR SEMICONDUCTORS (2007)

2. Sangiovanni-Vincentelli, A., Shukla, S.K., Sztipanovits, J., Yang, G., Mathaikutty,D.A.: Metamodeling: An emerging representation paradigm for system-level design.IEEE Des. Test 26(3) (2009) 54–69

3. OMG: UML profile for MARTE, beta 1. Technical Report ptc/07-08-04, ObjectManagement Group (2007)

4. OMG: MDA guide version 1.0.1. Technical report, Object Management Group(2003)

5. Sangiovanni-Vincentelli, A.: Defining platform-based design. EEDesign of EE-Times (February 2002)

6. Ali Koudri, Joel Champeau, D.A., Soulard, P.: MoPCoM/MARTE process appliedto a cognitive radio system design and analysis. In: Model Driven Architecture,Foundations and Applications. (2009)

7. Mitola Joseph, I.: Cognitive radio for flexible mobile multimedia communications.Mob. Netw. Appl. 6(5) (2001) 435–441

8. Hachemani, R., Palicot, J., Moy, C.: A new standard recognition sensor for cogni-tive radio terminals. In: EURASIP, KESSARIANI, GREECE (2007)

9. Varro, D., Pataricza, A.: Metamodeling mathematics: A precise and visual frame-work for describing semantics domains of UML models. In: Proc. Fifth Inter-national Conference on the Unified Modeling Language – The Language and itsApplications, Springer-Verlag (September 30 – October 4 2002) 18–33

10. Chauvel, F., Jezequel, J.M.: Code generation from UML models with semanticvariation points. In: Models UML. (2005)

11. Buck, J., Ha, S., Lee, E.A., Messerschmitt, D.G.: Ptolemy: a framework for simu-lating and prototyping heterogeneous systems. IEEE 10 (2002) 527–543

12. Herrera, F., Sanchez, P., Villar, E.: Modeling of CSP, KPN and SR systems withSystemC. Languages for system specification: Selected contributions on UML,SystemC, system Verilog, mixed-signal systems, and property specification fromFDL’03 (2004) 133–148

13. Stitt, G., Vahid, F., Najjar, W.: A code refinement methodology for performance-improved synthesis from c. In: ICCAD ’06: Proceedings of the 2006 IEEE/ACMinternational conference on Computer-aided design, New York, NY, USA, ACM(2006) 716–723

14. Koudri, A., Meftali, S., Dekeyser, J.L.: IP integration in embedded systems mod-eling. In: 14th IP Based SoC Design Conference (IP-SoC 2005), Grenoble, France(December 2005)

15. Sangiovanni-Vincentelli, A., Carloni, L., Bernardinis, F.D., Sgroi, M.: Benefits andchallenges for platform-based design. In: DAC ’04: Proceedings of the 41st annualconference on Design automation, New York, NY, USA, ACM (2004) 409–414

16. Chen, R., Sgroi, M., Lavagno, L., Martin, G., Sangiovanni-Vincentelli, A., Rabaey,J.: UML and platform-based design

17. Edwards, M., Green, P.: UML for hardware and software object modeling. UMLfor real: design of embedded real-time systems (2003) 127–147

18. Riccobene, E., Scandurra, P., Rosti, A., Bocchio, S.: Designing a unified processfor embedded systems. In: In the Fourth International Workshop on Model-BasedMethodologies for Pervasive and Embedded Software (MOMPES), Braga, POR-TUGAL, IEEE Computer Society (March 2007)

19. Piel, E., Attitalah, R.B., Marquet, P., Meftali, S., Niar, S., Etien, A., Dekeyser,J.L., Boulet, P.: Gaspard2: from MARTE to SystemC simulation. Proceeedingsof the DATE’08 friday workshop on Modeling and Analyzis of Real-Time andEmbedded Systems with the MARTE UML profile (March 2008)

20. Douglass, B.P.: Real-Time Agility: The Harmony Method for Real-Time and Em-bedded Systems Development. Addison-Wesley Professional (2009)

21. OMG: Systems modeling language specification v1.1. Technical Report ptc/2008-05-16, Object Management Group (2008)

22. OMG: UML profile for schedulability, performance, and time, version 1.1. TechnicalReport formal/2005-01-02, Object Management Group (2005)

23. Ghenassia, F.: Transaction-Level Modeling with SystemC. Springer (2005)24. Jantsch, A.: Modeling Embedded Systems and SoC’s. Systems on Silicon (2004)