Model Driven Engineering for MPSoC Design Space Exploration · the use of meta-modeling concepts. The DaRT proj-ect defines MOF-based meta-models to specify appli-cation, architecture,

13Journal Integrated Circuits and Systems 2008; v.3 / n.1:13-22

Model Driven Engineering for MPSoC Design SpaceExploration

Marcio F. da S. Oliveira, Eduardo W. Brião, Francisco A. Nascimento, Flávio R. Wagner

Instituto de Informática, Universidade Federal do Rio Grande do Sul (UFRGS), Porto Alegre, Brazile-mail: [email protected]

1. INTRODUCTION

With the rising complexity of embedded soft-ware and the power/thermal constraints, MPSoC(Multi-Processor System-on-Chip) platforms haveemerged as the only feasible solution to meet thestrong constraints imposed to embedded systemdesign, such as pressures to reduce the time-to-marketof new products as well as system energy consump-tion. Dealing with this ever-growing challenge only bydesigner’s expertise is not feasible. Observing a designexample where 17 tasks must be allocated to a six-processor platform with four different voltage settingsfor each processor, resulting in a design space withmore than 100,000 alternatives, is enough to realizethat Computer-Aided Design (CAD) tools are imper-ative to automate one of the most costly design activ-ities, namely the Design Space Exploration (DSE) ofalternative solutions.

Two approaches have been proposed to copewith this problem. In first place, meet-in-the-middlestrategies, such as Platform-based Design (PBD) [19],are used to maximize the reuse of pre-designed com-ponents and to achieve the best customization of thedesign according to system requirements. This influ-

ences even more the need for automated DSE tools.Secondly, the new generation of embedded systemdesign tools relies on the Model Driven Engineering(MDE) approach [21] to raise the design abstractionlevel and to provide mechanisms to improve theportability, interoperability, maintainability, andreusability of models. In addition, MDE helps toabstract platform complexity and to represent differ-ent concerns of the system [10].

Moving the development focus from imple-mentation to model suggests the support to a fastDSE in the early design steps, where the design effortis now concentrated and modeling decisions can leadto substantially superior improvements. In this con-text, this work proposes an MDE approach using aUML-based estimation tool called SPEU (SystemProperties Estimation with UML) [16] and an auto-matic multi-objective DSE mechanism implementedby the H-Spex (High-Level Design SpaceExploration) tool. Our MDE approach is supportedby the ModES framework [14], which provides effi-cient meta-models to capture the system structure andbehavior, representing system concerns in separateddimensions - application, platform, mapping, andimplementation. Moreover, ModES provides a trans-

ABSTRACT

This paper presents a Model Driven Engineering approach for MPSoC Design Space Exploration(DSE) to deal with the ever-growing challenge of designing complex embedded systems. Thisapproach allows the designer to automatically select the most adequate modeling solution for appli-cation, platform, and mapping between application and platform, in an integrated and simultaneousway and at a very early design stage, before system synthesis and code generation have been per-formed. The exploration is based on high-level estimates of physical characteristics of each candi-date solution. In an experimental setting, the DSE tool automatically performs four design activities:it selects the number of processors, maps tasks to processors, allocates processors to bus seg-ments, and sets the voltage of each processor. Experimental results, extracted from a DSE scenariofor a real application, show that the proposed estimation and exploration approach may find a suit-able solution regarding the design requirements and constraints in a very short time, with an accept-able accuracy, without relying on costly synthesis-and-simulation cycles.

Index Terms: Design space exploration, multi-processor system-on-chip, model driven engineering.

02-Oliveira-v3n1-AF 07.07.08 16:35 Page 13

Model Driven Engineering for MPSoC Design Space ExplorationOliveira, Brião, Nascimento & Wagner

14 Journal Integrated Circuits and Systems 2008; v.3 / n.1:13-22

formation engine, which interacts with the H-Spextool to allow both the verification of requirements andthe final model generation after the exploration step.These model transformations are actions performedon the models, following a set of rules produced byH-Spex and/or extracted from system requirementsspecified in the models. Following the proposedapproach, a designer can automatically select the mostadequate modeling solution for application, platform,and mapping between application and platform, in anintegrated and simultaneous way and at a very earlydesign stage, before system synthesis and code gener-ation have been performed. The exploration is basedon high-level estimates of physical characteristics ofeach candidate solution, performed directly fromhigh-level UML models.

In an experimental setting that validates ourapproach, we consider a platform with up to sixprocessors, each one with four different voltage set-tings and mapped to two distinct bus segments. Inthis context, H-Spex automatically performs fourdesign activities: it selects the number of processors,maps tasks to processors, allocates processors to bussegments, and sets the voltage of each processor.Experimental results, extracted from a DSE scenariofor the design of a real application, show that the pro-posed estimation and exploration approach may find asuitable solution regarding the design requirementsand constraints in a very short time, with an accept-able accuracy, without relying on costly synthesis-and-simulation cycles. Besides, the use of an MDEapproach promotes the reusability of application andarchitecture models and allows a designer to performearly DSE.

The remaining of this paper is organized as fol-lows. Section 2 discusses related work on model-basedapproaches. Section 3 introduces the basic concepts ofour DSE approach. Section 4 presents the requiredinfrastructure for DSE, including the MDE infrastruc-ture and a model-based estimation tool. The DSEmethod is presented in Section 5. A real case study,which illustrates and validates our DSE method, isdescribed in Section 6. Finally, Section 7 draws mainconclusions and proposes future research directions.

2. RELATED WORK

There are many recent research efforts onembedded systems design using an MDE approach.The adoption of model-based design and the inde-pendent specification of platform/application usingUML have been vastly investigated.

As a complete environment for DSE, theMILAN [1] / DESERT [15] framework is worth ofmention. The focus of MILAN is on the simulation of

embedded systems, so that it evaluates pre-selectedcandidate solutions. The DESERT tool uses models ofaggregated system sub-components and constraints toautomatically compose the embedded system throughOrdered Binary Decision Diagrams and based on acomplete pre-characterization of components.

The ARTEMIS [18] / SESAME [17] frame-work provides methods for modeling and simulationat different abstraction levels, aiming at an automaticDSE of heterogeneous embedded SoCs for multime-dia applications. However, this framework does notuse MDE, relying instead on lower level languagessuch as C/C++ and a specific API to represent a Kahnprocess network. Besides, the designer must specifyseparated models for implementation and evaluation.

Metropolis [2] is an infrastructure for elec-tronic system design, in which tools are integratedthrough an API and a common meta-model.Following the platform-based approach and the Y-chart methodology, the Metropolis’ infrastructurecaptures application, architecture and mapping usinga proposed UML-platform profile [5]. Furthermore,its infrastructure is general enough to support differ-ent models of computation (MoCs) and accommo-date new ones. Non-automatic support for designspace exploration is provided by Metropolis, whichproposes an infrastructure to integrate differenttools. Nevertheless, the current simulation and veri-fication tools integrated into Metropolis and theproposed refinement process can be used to performsome manual architectural explorations (task map-ping, scheduling, hardware/software partitioning)and component configurations. Moreover, therefinement process allows the explicit exploration ofapplication algorithms, that implement a higher-levelspecification.

The DaRT (Data Parallelism to Real Time) [4]project proposes an MDA (Model-DrivenArchitecture) - based approach for SoC design thathas many similarities with our approach in terms ofthe use of meta-modeling concepts. The DaRT proj-ect defines MOF-based meta-models to specify appli-cation, architecture, and software/hardware associa-tions and uses transformations between models ascode transformations to optimize an associationmodel. In doing so, it allows the re-factoring of anapplication model in order to better match it with agiven architecture model. In DaRT, no DSE strategybased on these transformations is implemented, andthe focus is mainly the code generation for simulationat TLM (Transaction Level Model) and RT (RegisterTransfer) levels.

Koski [8] is a UML-based framework to sup-port MPSoC design. It is a library-based method,which implements a platform-based design. Koskiprovides tools for UML system specification, estima-




tion, verification, and system implementation onFPGA. Following the design flow, the application,architecture and the initial mapping are specified asUML 2.0 models. A UML interface handles thesemodels and generates an internal representation,which is used for architectural exploration. The archi-tectural exploration is performed in two steps; the firstone is static, fast and less accurate; the second one isdynamic. At the end of the design flow, the UMLmodels are used to generate code, and the selectedcomponents from the platform are linked to build thesystem.

Compared to our approach, no related worktakes advantage of the MDE notion of transformationbetween models to represent, delimitate, and explorethe design space. Furthermore, the proposed DSEmethodology is combined with SPEU, a model-basedestimation tool, allowing a designer and/or the H-Spex tool to verify possible implementations for agiven application on a specified platform at a highabstraction level.

3. EXPLORATION APPROACH

As most DSE approaches, we follow the Y-chart [10] to represent the complete design space thatwill be explored. Three domains are proposed to rep-resent the design space – Application, Platform, andMapping – for which a designer can explore a largenumber of configurations. A fourth domain, theImplementation one, is proposed to represent thedecision resulting from the DSE process. Figure 1illustrates these concepts.

In the Application Domain, the designerexpresses the application concepts using a modelinglanguage, such as UML. A designer may investigateissues such as the distribution of responsibilitiesbetween classes, the encapsulation of functionalityinside objects, the aggregation of objects inside inde-pendent threads, and strategies for the interactionbetween objects.

The platform components are represented inthe Platform Domain. In this domain, a designer canexplore different implementations of the same com-ponent, the allocation of processors, the individualparameter settings of each selected component, thecommunication structure, and others.

The Mapping Domain expresses the mappingbetween application and platform concepts. In thisdomain, a designer may explore the mapping of tasksto processors, the mapping of hardware resources to acommunication structure, and the software binding.The result of the DSE process is expressed in conceptsat the Implementation Domain, which contains thenecessary information to generate/synthesize anembedded system.

4. DESIGN SPACE EXPLORATIONINFRASTRUCTURE

The pre-condition to implement the automaticsupport to design space exploration is the utilizationof appropriate models to represent the problem andthe solution for each activity. The infrastructure,which allows the interaction between the automaticexploration tool and the user, is also important. Thisinfrastructure allows the specification of models,exploration parameters, and system constraints /requirements (functional and non-functional require-ments). It also supports the integration betweenexploration activities, including models and sharing ofresults.

An important requirement in this infrastructureis the automatic mechanism for the evaluation of alter-native solutions, which must be performed at a high-level of abstraction in order to be effective. If assess-ing each candidate solution would require its detailedsynthesis and cycle-accurate simulation, design timewould be prohibitive.

Therefore, the proposed work is integrated inan efficient infrastructure, which provides therequired support for MDE-based design of embeddedsystems. Moreover, a model-based estimation tool isintegrated to this infrastructure in order to allow earlyand fast evaluation of design alternatives, still at a veryhigh abstraction level.

A. MDE Infrastructure

Based on the presented DSE concepts, theModES (Model-driven Embedded System design)framework [14] has been implemented to provide anMDE infrastructure. This infrastructure is composedby a set of four meta-models, one for each domain:Internal Application, Internal Platform, Mapping, andImplementation Meta-model. All concepts in theFigure 1. Design space exploration domains.




meta-models are specified as UML classes and thenconverted into Eclipse/EMF models [6].

The MDE infrastructure provides a Java API,automatically generated by the EMF tool, to handlemeta-models instances. The models specified by thedesigner are loaded into the MDE infrastructure bymeans of model-based transformations implementedas QVT (Query, Views, Transformations) resources,standardized by OMG [13].

The designer must specify the application mod-els using any UML 2.0 compliant tool that allows thegeneration of the appropriate XMI files. The mostimportant UML diagrams used in our approach tospecify the system are Use Cases and Sequence, Class,and Deployment Diagrams. Using the UML profilefor Scheduling, Performance and Time (UML-SPT)[22], the designer can extend the application modelwith constraints or requirements. The structural andbehavioral aspects of the Application Model are cap-tured into the Internal Application Meta-model(IAMM) (shown in Figure 2).

Using the Internal Application Meta-model, asystem specification captures the functionality of anapplication in terms of a set of modules that are com-posed of concurrent communicating processesand/or sub-modules. The module behavior is cap-tured in terms of actions represented by a ControlData Flow Graph (CDFG) that captures the data andcontrol flow between the actions. The Actions wereremoved from Figure 2, due to the reduced space.The CDFG corresponds to the UML actions of thescenarios (sequence diagrams) that are related to theprocess, according to its active object. The adoptedconcepts correspond to CSP-like languages, whichare able to express any kind of concurrent, distrib-uted system.

In a platform-based design environment, alarge number of hardware and software componentsare provided and can be reused in the system develop-ment. To evaluate different solutions at a high abstrac-tion level and perform DSE, the reused componentsmust be pre-characterized in terms of performance,energy, memory footprint, and others.

The software component characterization isperformed after the component code is compiled forthe target architecture, since at this time a simula-tion/estimation tool can capture architectural infor-mation with high accuracy. Likewise, hardware com-ponents are characterized for a specific technology.

In the ModES framework, the informationabout the characterization is stored in an instance ofthe Internal Platform Meta-model, whose data modelis based on the General Resource Model from UML-SPT, identifying the services offered by the platformand the related quality-of-service values. As for appli-cation models, in order to have a standard representa-tion, the Platform Meta-Model is translated into anInternal Platform Meta-Model (IPMM), shown inFigure 3.

Providing an extensive component repositoryrequires a significant effort. However, normally a largeamount of system components can be reused from dif-ferent component providers or as a sub-product fromprevious system developments [20].

Therefore, the platform repository creation isbased on the accumulation of components producedor acquired in previous product developments.Currently, the platform repository contains informa-tion on processing units (different versions of a Javamicrocontroller [7]), scheduling and timer services, areal-time communication API [23] implemented ontop of the Java microcontroller, and a math andimage-processing library.

As additional architectural aspects, informationis stored about the supported data types and instruc-tion set, such as size, number of execution cycles, andenergy consumption for each instruction. Aspects ofprogram and data memory allocation are also consid-ered, including dynamic frame allocation, reservedmemory, data type, and method allocation rules.

To add new IP (intellectual property) resourcesto the platform repository, the IP provider mustattach this architectural information to his/her IPs.After the repository is populated with adequate infor-mation on the platform components, the designer justneeds to map the application into the platform model.This allows the evaluation of a general applicationmodel (Platform Independent Model – PIM), when

Figure 2. Internal Application Meta-model (IAMM). Figure 3. Internal Platform Meta-model (IPMM).




mapped to a specific platform that corresponds to thePlatform Specific Model (PSM), according to theMDA [11] approach.

The Mapping Meta-model describes the rulesused to transform instances of the InternalApplication Meta-model and Internal Platform Meta-Model into an instance of the Implementation Meta-model, as shown in Figure 4.

In the proposed approach, the Mapping Meta-model is based on a set of transformations, where eachtransformation is composed by a set of rules that limitthe possible mappings between application and plat-form, thus guiding the H-Spex tool or the designer tobuild a candidate Implementation Model. This allowsthe evaluation of possible implementations during theDSE phase. Besides, the task mapping, processor allo-cation, and software binding can also be expressed asUML deployment diagrams, reflecting a designrestriction on the DSE process.

A transformation engine can be invoked to tra-verse the set of transformation rules, in order to selectand apply the ones that are enabled at that momentand to produce a hardware/software mapped archi-tecture in the form of an Implementation Model. Ourtransformation engine is implemented using MDDi-QVT (Model Driven Development integration -Query, View, Transformation) [12], which is an open-source implementation of the QVT standard. MDDi-QVT provides a QVT parser, which reads a textualQVT specification and builds a model conforming tothe QVT meta-model [13], and a QVT compiler thatgenerates an API in Java from a QVT model, whichcan be used to perform transformations betweenmodels. Thus, in order to use the current version ofMDDi-QVT, we generate a textual QVT specificationfile from the application, platform, and mapping mod-els conforming to our meta-models. Then we applythe QVT parser and compiler to obtain a Java API.The H-Spex tool calls this API, which implements thetransformation engine.

The Implementation Meta-model allows therepresentation of the models that can implement thesystem specification without violating the systemrequirements. Figure 5 shows the ImplementationMeta-model class diagram.

The Implementation Meta-model can bedescribed as a list of selected platform components,application components, and associations betweenthem. Furthermore, it also represents the design deci-sions about component configuration, task mapping,and resource allocation. An instance of theImplementation Meta-model is used, together withinstances of other proposed meta-models, by a tool thatgenerates partial embedded software source code,scripts for a hardware synthesis, and system deploymentscripts. As explained in the next section, other tools,such as an estimation one, can use an instance of theImplementation Meta-model in order to estimate theproperties of a candidate implementation model beforethe development process is continued.

B. Model-based Estimation Tool

The SPEU tool [16] provides analytical esti-mates about physical system properties (executioncycles, energy/power consumption, volume of com-munication data, and memory footprint). These prop-erties are directly obtained from instances of the meta-models, with estimation errors as low as 5%, when thereuse of repository components is largely employed bya PBD approach.

The estimation is performed by using the information extracted from UML application structure/behavior models and stored in the InternalApplication Meta-model as a CDFG (Control andData Flow Graph). To improve the estimation accura-cy, the information specified in the Platform Model isused to compute the costs of pre-designed compo-nents and added in the final estimation. An ILP(Integer Linear Programming) formulation is used forthe identification of best-case and worst-case execu-tion paths on the CDFG. In order to reduce the com-plexity, each ILP formulation is solved in a hierarchi-cal fashion, such that each task has one ILP formula-tion to be solved. This avoids problems for MPSoCswith a large number of tasks. This estimation toolallows H-Spex to rapidly evaluate each candidate solu-tion during the DSE process, without depending oncostly synthesis-and-simulation evaluation cycles.After that, the estimated properties are used to com-pute the solution cost in a parameterized multi-objec-tive function, which is optimized by the explorationalgorithm.

Figure 4. Mapping Meta-model (MMM). Figure 5. Implementation Meta-model (IMM).




5. EXPLORATION METHOD

The model-based exploration method is imple-mented by H-Spex (High-level design SPaceEXploration), a tool for automatic multi-objectivedesign space exploration. H-Spex is supported byMoDES, which provides the required MDE infra-structure. H-Spex is also supported by SPEU (SystemProperties Estimation with UML), which provides theestimation values needed for evaluation of alternativesolutions during design space exploration.

The DSE mechanism of H-Spex adopts aheuristic approach to investigate the space of possiblearchitectural solutions, which is currently based onsimulated annealing [9]. The implemented simulatedannealing uses a probabilistic perturbation function,whose values were experimentally selected. The per-turbation function is responsible for looking for asolution that minimizes the communication, energy,power, performance, memory footprint, or any com-bination of these properties, under hard real-timeconstraints, meeting design restrictions such as theprocessing capacity of each processor (which dependson its frequency/voltage setting). These metrics areused to calculate the solution cost using an objectivefunction, which the simulated annealing algorithmtries to minimize. H-Spex reads the constraints speci-fied using UML-SPT in the Application Model (andcaptured by the Internal Application Model) andcompares them with the results obtained by SPEU,the model-based estimation tool. At each moment, H-Spex takes design decisions and incorporates the cor-responding information in the conditions of the trans-formation rules of the mapping model. Then, H-Spexinvokes the transformation engine provided by theMDE infrastructure, so that it produces candidateImplementation Models, which will be evaluated inorder to select the final solution. Figure 6 shows theinteraction between H-Spex and the infrastructure fordesign space exploration.

The current DSE prototype selects the mostappropriate solution by taking several design deci-sions: it selects the number of processors in theMPSoC, partitions tasks between processors, mapsprocessors to a communication structure (currently,only a segmented bus), and schedules the voltage levelfor each processor. Therefore, H-Spex is automatical-ly exploring both the Platform and MappingDomains. The Application Domain could also beexplored, but this is currently manually performed bythe designer, as described in [16].

The exploration flow is depicted in Figure 7.Firstly, H-Spex randomly generates an initial solution.When all design decisions for a candidate solutionwere taken, the transformation engine is invoked totraverse the set of transformation rules of the MappingModel, so as to select and apply the ones that areenabled at that moment, in order to produce a plat-form-specific model in the form of an ImplementationModel. This model is the input to SPEU, which sup-ports model evaluation for early and fast DSE.

6. CASE STUDY

A DSE scenario for the design of a real applica-tion, concerning the automated control of a wheel-chair with functions such as movement control, colli-sion avoidance (ultrasound and stereo vision), andnavigation, has been developed. The applicationmodel contains 17 tasks, which have communicationdependences between them. The platform model isbased on a Java microcontroller [7], upon which anAPI and operating system components [23] for real-time behavior and communication support are avail-able. Figure 8 illustrates the task graph extracted fromthe Application Model, which has been specified inUML and loaded into the Internal Application Meta-model.

Figure 6. Tools integration for MDE design space exploration. Figure 7. Exploration algorithm.




To implement the movement control, severalcomponents provided by the platform can be reused,such as a mathematical library to solve the controlequations, a real-time Java API, and RTOS compo-nents [23]. Consequently, the platform aspects con-sidered in the estimation methodology also take intoaccount costs that are related to the real-time sched-uler. Table 1 shows some of the available componentsof the platform model and corresponding services.

The component Math:API has many services,as for example sin:Service, cos:Service, atan:Service,and sqrt:Service. All these services are used for theimplementation solutions. The RestoreContext:Serviceis a service of the scheduler EDFScheduler:OS, whichrestores the processor state and gives control back toa previous thread. The waitForNextPeriod:Servicepasses the control from a real time thread to the OS atthe end of its execution. The FemtoJavaMCRTC(Multi-cycle, RealTime Clock) is one of the versionsof a Java microcontroller available in the platform[23]. It has instructions that are not available in the

simplest version of the Java microcontroller, but thatare needed to support the RealtimeThread:API.

Table 2 lists some of the transformation rules ofthe mapping model. The transformation rules specifythe possible mappings from elements of the wheel-chair application model to elements of the FemtoJavaplatform, including the actions that will generate ele-ments in the implementation model.

As specified by the transformation rules, themodules can be implemented either by a simpleFemtoJava or by a multi-cycle real-time FemtoJava. Inthe implementation model, a memory component willbe instantiated for program code and data, and a buswill be instantiated to connect the processor to thememory. Other transformation rules state that: a)processes in the application can make use of the Mathand RTThread APIs; b) actions in the thread of theprocesses may use services to suspend the execution(waitForNextPeriod and waitForCycles services); c)actions can have access to static and dynamic objectattributes (get/set Static/Dynamic ObjectField servic-es); d) mathematical operations can be implementedby the Math API; and e) scheduling of processes andthreads can be implemented by different kinds ofschedulers from a given operating system.

Given the platform, application, and mappingmodels, the DSE process takes design decisions aboutthe partitioning, allocation, and binding of applicationelements to platform elements and incorporates theinformation on the mapping model.

H-Spex selects the number of processors andmaps tasks to them in order to minimize the overall

Figure 8. Application model task graph.

Table 1. Part of Platform Model

Component Service Prog. mem. Data mem. Perf. Energy(bytes) (bytes) (cycles) (switching activity)

Math:API Sin:Service 14 4 53 73,815EDFScheduler: OS RestoreContext: Service 4 0 883 8,117.3Realtime Thread: API waitNextPeriod: Service 243 13 5721 1,254.3Femtojava MCRTC: Processor int_tf0:Service 2 32 124 187.45

Table 2. Part of Mapping Model

Source IAMM Target IPMM Condition Actionmod: p:Processor, p.name=FemtoJava32 or new Processor( ),Module m:Memory, p.name=FemtoJavaMCRTC new Memory( ),

b:Bus new Bus( )proc: a:API a.name=Math or new API( )Process a.name=RTTrheadthreadctrl: s:Service s.name=waitNextPeriod or new Service( )Action s.name=waitForCyclesinteraction: s:Service s.name=interactionStatic or new Service( )Action s.name= interactionDynamicgetObjectField: s:Service s.name=getStaticObjectField or new Service( )Action s.name=setStaticObjectField or

s.name=setDynamicObjectFieldmathoper: s:Service s.name=sqrt or s.name=sin or new Service( )Action s.name=cos or s.name=s.atansched: s:OS s.schedtype=EDFScheduler or new OS( )OS s.schedtype=FixedPriority or

s.schedtype=RMScheduler




communication costs between tasks. Tasks with ahigher communication bandwidth between them tendthus to be grouped in the same processor, if possible.The candidate task partitioning can neither violate thetask deadlines nor exceed the processing capacity ofeach node. If necessary, H-Spex adds another proces-sor to the system. Simultaneously, H-Spex mapsprocessors to the communication structure, such thatthe overall communication cost is again minimized.Therefore, processors with a higher communicationbetween them (because of the tasks assigned to eachone) tend to be mapped to the same bus segment. Inorder to reduce the energy consumption, H-Spex alsoselects the minimal voltage for each processor, butavoiding task deadline violations. Realistic energy,voltage, performance, and memory costs for HW andSW platform components and services (such as taskscheduling), extracted by using the SPEU model-based estimation tool, have been used to guide theexploration.

The number of design alternatives in this DSEscenario is huge, so that the utilization of an automat-ed DSE approach at very high abstraction level is fullyjustified.

Figure 9 shows a chart with the final solutionfound by H-Spex for different combinations of opti-mization objectives. In this chart, the values of solu-tion properties were normalized with regard to theworst solution, so that they could be presented in thesame chart. The “x” axis is organized by objective ofoptimization - energy, power, memory, energy-power-cycles-memory (epcm), energy-power-cycles (epc),and energy-power-memory (epm).

The DSE results for energy optimization pres-ent a good load distribution between the six proces-sors. This parallel execution reduces the number ofexecution cycles, directly contributing to energy sav-ings. Because of data and code replication in the vari-ous processors, the values for memory and powerwere not optimized. In order to minimize the power,H-Spex mapped simple tasks to the same processorwith low voltage settings. Processors with high uti-lization require higher voltage settings.

In order to reduce the memory size, H-Spexmapped tasks that exchange large amounts of data tothe same processor, reducing in this way the datareplication and communication structures (packagesand messages).

In the last three results in Figure 9, the chartpresents DSE results using multi-objective functions.Due to the hard real-time constraints, H-Spex couldnot reduce the cycles by mapping many tasks to thesame processor and thus reducing the communicationcost, because this would cause task deadline violations.However, by distributing tasks in different processorsand setting low voltages for each processor, the DSEtool could get better results for power, which domi-nates the optimization process.

Better optimizations could be achieved if theApplication Domain was also explored by H-Spex.This exploration could result in reduced values forexecution cycles, for instance by changing the interac-tion between objects and the interaction of the objectswith the platform services (reducing service calls), orby looking for a new distribution of responsibilities, inorder to arrange the functionalities in a way toimprove the parallelism.

Figures 10-13 show the property values esti-mated for 19 candidate solutions found by H-Spex, byoptimizing the objectives energy, cycles, power, andmemory, respectively. In each chart, the Y-axis showsthe property values for the entire system. The X-axispresents the candidate solutions. The presentedresults were obtained after evaluation of 1000 candi-date solutions. In our experiments, H-Spex takes 1hour to evaluate each 1000 solutions, using an AMDAthlon 1.8 GHz with 512 Mbytes of RAM and SPEUas the estimation tool.

In order to illustrate the accuracy of the model-based estimation tool, components responsible for thewheelchair movement control were implemented onthe target platform using two different solutions.These solutions differ in the objects' structure (num-ber of classes, objects, and threads) and behavior(interaction between application calls to platformservices). These changes were selected to emphasizethe impact of model decisions on the final systemphysical properties. The values estimated by themodel-based estimation tool were compared to theresults obtained through cycle-accurate simulationusing the CACO-PS power simulator [3].

Table 3 shows the exact differences betweenproperty values of two alternative solutions, obtainedby CACO-PS in a cycle-accurate simulation, and theestimated differences, obtained by SPEU. Both per-formance and energy were estimated in terms of best-case (BC) and worst-case (WC) executions.

The table shows that the estimated differencesbetween property values are very close to the exact dif-Figure 9. DSE results for different objectives.




ferences. The time spent to simulate each solution atcycle-accurate level was approximately 23 minutes,while the model-based estimation provided by SPEUspent less then 4 seconds, both times measured withthe same host machine configuration described before.

The results in Table 3 show that the secondalternative solution is better than then first one in all

system properties according to both the estimated andexact evaluation methods. Observing the results, wecan conclude that the model-based estimation toolprovides quantitative information about physical sys-tem properties to support a very fast and reasonablyaccurate exploration of the impact of these choices onthe final system implementation.

This case study illustrates a design space explo-ration scenario for a real application presenting a largedesign space. Through the Model Driven Engineeringapproach for Multi-objective Design Space Explorationpresented in this work, a designer can specify the sys-tem using UML models at high abstraction level(without source coding/generation) and look for thebest alternative to be implemented, early in the devel-opment process, without relying on costly synthesis-and-simulation evaluation cycles.

7. CONCLUSIONS AND FUTURE WORK

A Model-Driven Engineering (MDE) approachfor MPSoC design space exploration and the H-Spextool, which implements this approach, were present-ed. This approach adopts a meta-modeling infrastruc-ture with specific meta-models for the application,platform, mapping, and implementation domains.The MDE fundamental notion of transformationbetween models is used to represent and delimitatethe design space of possible implementations of theapplication on the specified platform. A set of trans-formation rules defines the possible mappings fromapplication into platform. By evaluating these rules, anexploration tool builds a model solution, selecting thenumber of processors, mapping application tasks tothe selected processors, mapping processors to a com-municating structure, and reducing the energy con-sumption by voltage scaling.

To support this approach, the SPEU toolimplements a UML-based estimation, which allowsthe evaluation of models while exploring the designspace, in order to find a model that better fulfills theapplication requirements. This high-level estimationapproach allows a fast comparison of the various mod-els without having to generate executable code, hence

Figure 10. Energy values for 19 candidate solutions.

Figure 11. Execution cycles for 19 candidate solutions.

Figure 12. Memory size for 19 candidate solutions.

Figure 13. Power values for 19 candidate solutions.

Table 3: Differences between two alternative solutions

Second x First SolutionProperty Estimated ExactProgram memory -69.83% -66.98%BC Data memory -36.47% -36.08%WC Data memory -36.47% -36.08%BC Performance -95.42% -93.36%WC Performance -65.82% -65.32%BC Energy -99.61% -93.31%WC Energy -66.57% -65.51%




without any costly hardware and softwaresynthesis/simulation steps.

Experimental results show that the proposedestimation and exploration approach may find a suit-able solution regarding the design requirements andconstraints in a very short time, with an acceptableaccuracy, without relying on costly synthesis-and-sim-ulation cycles. Besides, the use of UML and MDEpromotes the reusability of application and platformhigh-level models.

One of the future directions to be considered isthe meta-modeling improvement, in order to repre-sent more complex applications, platforms, and map-pings. We also intend to test different optimizationalgorithms in order to improve the design spacesearch. Moreover, we shall extend the explorationtool, by adding new architectural exploration activitiesand automating the exploration activities in theApplication Domain, as proposed in [16].

REFERENCES

[1] Agrawal, A. et al. “MILAN: A Model Based IntegratedSimulation Framework for Design of Embedded Systems”.LCTES, 2001.

[2] Balarin, F.; Watanabe, Y.; Hsieh, H.; Lavagno, L.; Passerone,C.; Sangiovanni-Vincentelli, A. “Metropolis: An IntegratedElectronic System Design Environment”. Computer, Vol. 36,No. 4, 2003.

[3] Beck, A.C et al. “CACO-PS: A General Purpose Cycle-Accurate Configurable Power Simulator”. SBCCI, 2003.

[4] Bondé, L.; Dumoulin, C.; Dekeyser, J.-L. “Metamodels andMDA Transformations for Embedded Systems”. FDL, 2004.

[5] Chen, R.; Sgroi, M.; Lavagno, L.; Martin, G.; Sangiovanni-Vincentelli, A.; Rabaey. J. “UML and Platform-Based Design”.In: Martin, G. (ed.), UML for Real: Design of Embedded Real-Time Systems. Boston, Kluwer Academic Publishers, 2003.

[6] EMF - Eclipse Modeling Framework http://www.eclipse.org/emf

[7] Ito, S. A. et al. “Making Java Work for MicrocontrollerApplications”. IEEE Design & Test of Computers, Vol. 18, No.5, 2001.

[8] Kangas, T et al. “UML-based Multi-Processor SoC DesignFramework”. Transactions on Embedded ComputingSystems, Vol. 5, No. 2, 2006.

[9] Kirkpatrick, S.; Gelatt, C. D.; Vecchi Jr., M.P. “Optimization bySimulated Annealing”. Science, No. 4598, May, 1983.

[10]Kreutzer, K. et al. “System-Level Design: Orthogonolization ofConcerns and Platform-Based Design”. IEEE Trans. on CADof Integrated Circuits and Systems, Vol.19, No.12, 2000.

[11]MDA Guide Version 1.0.1, OMG, doc. n.: omg/2003-06-01,June 2003

[12]MDDi-QVT: Model Driven Development integration-Query,View, Transformation. <http://www.modelware-ist.org>

[13]MOF QVT - QueryViews/Transformations. OMG doc.ptc/2005-11-01, Nov. 2005.

[14]Nascimento, F.A. et al. “ModES: Embedded Systems DesignMethodology and Tools based on MDE”. MOMPES, 2007.

[15]Neema, S. et al. “Constraint-Based Design-SpaceExploration and Model Synthesis”. EMSOFT, 2003.

[16]Oliveira, M.F.S. et al. “Early Embedded Software DesignSpace Exploration Using UML-based Estimations”. RSP,2006.

[17]Pimentel, A.D.; Erbas, C.; Polstra, S. “A Systematic Approachto Exploring Embedded System Architectures at MultipleAbstraction Levels”. IEEE Trans. on Computers, Vol.55, No. 2,2006.

[18]Pimentel, A.D. et al. “Exploring Embedded-SystemsArchitectures with Artemis”. IEEE Trans. on Computers, Vol.34, No. 11, 2001.

[19]Sangiovanni-Vicentelli, A.; Martin, G. “Platform-based Designand Software Design Methodology for Embedded Systems”.IEEE Design and Test of Computers, Vol. 18, No. 6, 2001.

[20]Shandle, J.; Martin, G. “Making Embedded SoftwareReusable for SoCs”. EEDesign, March 2002.<http://www.eedesign.com/story/OEG20020301S0104>.

[21]Schmidt, D. C. “Model-driven Engineering”. IEEE Computer,Vol. 39, No.2, 2006.

[22]UML SPT - UML Profile for Schedulability, Performance, andTime. Object Management Group (OMG) doc. ptc/02-03-02,2000.

[23]Wehrmeister, M.A.et al. “An Object-Oriented Platform-basedDesign Process for Embedded Real-Time Systems”. ISORC,2005.


Documents

Model Driven Engineering for MPSoC Design Space Exploration · the use of meta-modeling concepts. The DaRT proj-ect defines MOF-based meta-models to specify appli-cation, architecture,