Designing a Unified Process for Embedded Systems

Elvinia Riccobene, Patrizia ScandurraUniversità di Milano

Dip. di Tecnologie dell’Informazione, Italy{riccobene,scandurra}@dti.unimi.it

Alberto Rosti, Sara BocchioSTMicroelectronics

AST Lab R&I, C.d.Colleoni Agrate Brianza, Italy{alberto.rosti,sara.bocchio}@st.com

Abstract

In the Embedded Systems and SoC (System-on-Chip)area, we defined a model-driven design methodology basedon UML 2.0, UML profiles and SystemC. In this paper, wepresent the development process UPES (Unified Process forEmbedded Systems) that we define to foster our methodol-ogy in a systematic and seamless manner according to theplatform-based design principles.

1 Introduction

The Embedded System (ES) and System-on-Chip (SoC)design area covers a lot of different viewpoints: the soft-ware application modelling by the aggregation of functionalcomponents, the assembly of existing physical components,as the simulation and verification of the overall system in-cluding both HW and SW components, as the synthesis ofa complete end-product integrated into a single chip. In-tegrating hardware and software components on a singlechip, while meeting the needs of system architects, design-ers of application-specific integrated circuits (ASICs) andsoftware engineers, is a challenging goal.

Recently, this increasing technological complexity cou-pled with requests for more performance and shorter timeto market have produced a high interest for new methods,languages and tools capable of operating at higher levels ofabstraction in the Embedded System design process.

Since the first versions 1.x, an increasing number of in-dustrial and academic groups from the EDA, embeddedsoftware and hardware systems, have been taking to theUML (Unified Modeling Language) [35] with enthusiasm.As electronic systems design moved towards software en-gineering, there is emerging interest for UML within thehardware community and different UML diagrams, withthe enhancements of the standardization UML2, and theirvariations found their application in: requirements spec-ification, testbenches, architectural descriptions, and be-havioural modelling.

The UML and its extension mechanism is receiving sig-nificant interest as standard approach to define family oflanguages targeted to specific application domains and lev-els of abstraction, while providing unification. This isconfirmed by current standardization activities controlledby the OMG such as: the Schedulability, Performance,and Timing Analysis (SPT) profile [31]; the recent UMLfor SoC Forum (USoC) [36] in Japan founded by Fujitsu,IBM/Rational, and CATS to define a set of UML extensionsto be used for SoC design; the SysML proposal [32] whichextends UML towards the Systems Engineering domain,and the recent MARTE (Modeling and Analysis of Real-Time Embedded systems) profile initiative [29]. More-over, several reported experiences and contributions to thetheme UML for Embedded Systems exist in literature (see[13, 15, 9]).

In accordance with the OMG Model-driven Architecture(MDA) [16] – a framework for Model-driven Engineering(MDE) [6, 5] –, in [24, 26] we defined a model-driven co-design methodology for Embedded Systems which involvesthe UML 2.0, a UML 2.0 profile for the C and the SystemClanguages [33], and some other UML profiles related to thehigh-level modelling of the system. The co-design flow sup-ports the platform-based design principles in [39, 14], animportant paradigm for the future embedded system devel-opment based on the reuse of generic hardware platforms.In this paper, we propose the design process UPES (UnifiedProcess for Embedded Systems), an adaptation of the UP(Unified Process)1 [1], to foster our methodology in a sys-tematic and seamless manner. We focus, in particular, onthe platform implementation flow presenting a sub-processof UPES called UPSoC (Unified Process for SoC) which isused for refining the embedded system platform.

The remainder of this paper is organized as follows. InSect. 2, we give an overview of the platform-based designapproach. In Sect. 3, we briefly describe our model-baseddesign flow. In Sect. 4, we present the design process

1The UP is an open software engineering process from the authors ofUML. The RUP (Rational Unified Process) is the most widely used com-mercial variant of UP.

UPES. In Sect. 5, we describe the sub-process UPSoC. InSect. 6, we present the architecture of a design environ-ment that we developed to assist the designer across the re-finement steps in the UML modelling activity starting froma high-level functional model of the system down to RTL(Register Transfer Level). In Sect. 7, we provide a sim-ple application of our methodology. In Sect. 8, we discusssome industrial case studies. In Sect. 9, we quote some re-lated work. Finally, in Sect. 10, we conclude the paper andsketch some future directions of our contribution.

2 Background on Platform-based Design

According to [39, 14], a platform is an abstract repre-sentation of a set of possible implementations of a physi-cal hardware architecture and of the services offered via thesoftware layer to the system built on the top of it. A plat-form model is used by the software application designers (orsystem designers) as target implementation technology, andis furnished by the platform provider. A particular platforminstance can be then derived from a platform by choosing aset of components from the platform library and setting pa-rameters of configurable components. In a platform-basedapproach, the design is therefore carried out as a meet-in-the-middle process, where successive refinements of systemspecifications meet with abstractions of potential platforminstances at precisely defined levels.

In [39, 14], the authors identify two important layersin providing platform definitions: the micro-architectureplatform and the application programming interface (API)platform. A micro-architecture platform is defined as aspecific family of micro-architectures, possibly oriented to-ward a particular class of problems, which can be modi-fied (extended or reduced) by the system developer. It in-cludes a multiplicity of computational HW resources andperipherals such as microprocessors, memories, ASICs, FP-GAs (Field Programmable Gate Arrays), I/O devices andinter-connectors. An example is the AMBA/ARM platform.The API platform usually consists of a software layer thatwraps the essential parts of the architecture platform (hid-ing the architecture details) and defines the services thatthe platform offers. It includes, among other things, RTOSand device drivers. Examples of platforms are VxWorks,OSEK, etc. These platform layers are extremely important;they determine the joint points at the intersection betweenthe system and its mapping on a particular architecture.

3 A model-based co-design flow

Fig. 1 summarizes the most significative phases of ourdesign flow. Essentially, the UML – or the Systems Mod-eling Language (SysML) [32] or the MARTE proposal [29]

Figure 1. A Model-driven Design Flow for ES

– in a platform-independent manner is used as schematicentry to provide a first specification of the system in termsof an executable model suitable to perform high-level func-tional validation and eventually performance analysis.

At this point, an available generic hardware platform forthe physical architecture is chosen and then the mapping –dictated by the sense and experience of expert engineers –of the software components on the given hardware platformis done. This mapping phase is a meet-in-the-middle pro-cess and is carried out through an iterative activity: the plat-form model is iteratively configured according to a givenHW/SW partitioning and executed to check whether theQoS requirements (delays, power consumption, hardwareresources, real-time and embedding constraints) imposedby the system requirements are satisfied. At UML level,as explained later in Sect. 4, the mapping of the applicationmodel on the given platform model is intended as modelweaving, i.e. an operation which establishes semantic linksbetween models at specific joint points.

After mapping, two different design flows start for thesoftware and the hardware parts respectively. The hardwareplatform is modelled at different abstraction levels (func-tional untimed/timed, transactional, behavioural, bus cy-cle accurate) on top of the RTL ((Register Transfer Level))level by constructs from the UML profile for SystemC[23, 25]; so it can be refined down to the RTL, modellingthe details of the implementation platform.

The application can be modelled in software at three lev-els of abstraction: functional, transactional or instruction

level 2. At functional level, the C application is divided inthreads running on a host machine – Host Functional simu-lation: in this first phase the SW designer decides the threadpartition according to the inner application parallelism. Attransactional level, the application is modelled using thesame UML profile for SystemC. In this case, it works asa library encapsulated in a SystemC module; processes areassociated to the software functional description to sustainits concurrent activity within the system, whereas commu-nication is implemented by transactions that model the in-teractions with the hardware architecture – Transactionalsimulation. This level allows testing the correctness of theapplication on a high level description of the hardware, fo-cusing on the communication and performances. Finally,the application can be also represented at instruction levelby integrating an instruction set simulator (ISS) of the targetprocessing unit within the SystemC environment, to executethe compiled application code together with the model ofthe hardware – cycle-accurate HW-SW co-simulation. Inthis last case, the application software can be viewed as or-ganized in different layers on top of the micro-architectureplatform. The lower layer provides the driver and the archi-tecture controller: this layer is the application programminginterface (API) platform and it’s typically provided by theplatform designer. The upper layer are the OS and the SWapplication developed by the SW designer.

4 The UPES (Unified Process for ES)

The UPES drives the designer during the platform-basedconstruction of an embedded system from the analysis ofthe informal requirements (i.e. written in natural language)to the physical implementation. The UPES process is anMDA style of the classical Y-development cycle (see Fig.2). It consists on one side of the conventional UP processfor software development to define a first executable modelof the system (the Application model or System model), andon the other side of the selection process of an availablehardware platform (the Platform model) modelled with anappropriate language (e.g., a particular UML extension forSoC design).

The intersection, which is intended in MDE as modelweaving, is the mapping of the application model on thegiven platform model to establish semantic links betweenmodels at specific joint points. As input, this task requiresalso a reference model of the mapping (the Mapping modelor Weaving model) to try, which is specified in terms ofUML component and deployment diagrams to denote andannotate the partitioning of the original system in HW andSW components. This mapping model establish the rela-

2This does not necessarily imply a software refinement path, but just amapping on more detailed platforms to analyze better the performances ofthe overall application.

Figure 2. The UPES Y-chart

tionships (joint points) of the platform resources and ser-vices with the application-level functional components. Thecomponents assigned to the HW partition are mapped di-rectly onto a HW resource (i.e. a HW node in the UML de-ployment diagram) of the micro-architecture platform. Thecomponents in the SW partition are implemented by theSW designer as SW tasks that use the services provided bythe API platform; this is reflected at UML level by the in-terface usage/realization dependencies between the applica-tion components and the components of the API platform.

This meet-in-the-middle process is an iterative activity asdepicted in Fig. 3 using the SPEM (Software Process En-gineering Metamodel) [30] notation. The platform modelis configured appropriately according to a given HW/SWpartitioning, and then executed to check whether the QoSrequirements (delays, power consumption, hardware re-sources, real-time and embedding constraints) imposed bythe system requirements are satisfied. The result is a partic-ular platform instance with software embedded (the Embed-ded System platform model) at a specific level of abstraction(functional untimed/timed, transactional, behavioural, bus-cycle accurate, RTL) depending on the amount of details ofthe provided platform model.

The UPSoC sub-process, an UP extension for SoC de-sign (see next section), is then followed to accurately re-fine the embedded system platform by using the language ofthe platform model. The final refinement step of this sub-process produces the RTL model of this platform, whichserves as input to the lower level VLSI design flow, wherelogic simulation and synthesis are performed leading to thefinal product. It should be noted that the UPSoC processcan be also adopted by platform providers to design off-linedetailed models of platforms3 at different abstraction levels.

Concerning the UP process used to develop the appli-

3Detailed platform models comprise a structural view (provided, e.g.,by UML composite structure diagrams) and a behavioural one. Componentand deployment diagrams can be used then to provide a black-box view ofthe API layer and the micro-architecture layer, respectively.

cation model, fundamental time ranges in a system life-time are called cycles. A cycle generally ends with a re-lease of the system and can be in one of four phases: In-ception, Elaboration, Construction, and Transition. Eachphase can consist of a number of iterations. During eachiteration (generally associated with a project), several ac-tivities are performed in parallel called workflows. Follow-ing an entity-centered view of the UP, the design work iscarried out through a set of models developed by sequen-tial and iterative activities. Typically, models can containother models, packages, and subsystems. The applicationdevelopment follows the core workflows of UP, namely re-quirements (or use cases), analysis, design, implementationand testing. It should be noted, however, that the behaviour(or functionality) of a system comprises both computationand communication. Specifying the functionality of the sys-tem requires, therefore, to identify a number of functionalcomponents (functional decomposition), select a model ofcomputation (MoC) that defines the semantics of their in-teraction, and specify the behaviour of each component. AUML extension or profile which supports standard MoCs(such as Kahn Process Networks, Synchronous Dataflowetc.) and elementary communication building blocks (likebuffers, protocols etc.) could be used for this purpose, in ad-dition to the ones provided by the standard UML (e.g., therun-to-completion step semantics). The behaviour of indi-vidual components is specified using graphical (State Ma-chine or Activity Diagrams) or textual notation. For moredetails about the UP, see [1].

5 The UPSoC (Unified Process for SoC)

The UPSoC drives system and platform designers dur-ing the refinement of the embedded system platform, af-ter the mapping phase, and therefore after the componentsassigned to the HW partition have been mapped directlyonto a HW resource of the selected platform. The UP-SoC can be used also by platform designers for the con-struction from scratch of an abstract hardware platform –from the analysis of informal requirements about the archi-tecture elements (HW resources and processing elements)to the physical implementation. The model of this genericplatform could be then reused and targeted accordingly (asin the previous case) to implement a specific hardware plat-form to embed a given system. In both cases, the resultingplatform model can be delivered at different levels of ab-stractions: functional untimed/timed, transactional (TLM),behavioural, bus cycle accurate), and RTL.

The UPSoC adapts the UP to the SoC domain by extend-ing the design and implementation workflows, while keep-ing the use case and analysis workflows. Useful consider-ations about use case analysis in the context of systems en-gineering and SoC design can be found in [37]. The design

and implementation models in the UPSoC can be definedat different abstraction levels and with different modellingguidelines. Fig. 4 shows the workflow schema for thesemodels using the SPEM [30] notation. The letter L in thefigure denotes a specific level of abstraction from the set{functional, TLM, BCA, Behavioural, RTL}; so, there arefive design/implementation workflows. As in the UP, also aTesting model (not shown in the figure) can be provided bycreating test cases and test procedures housed outside of themodelling tool, but traced back to the models.

Figure 3. The UPES – Mapping and Testingworkflow

From the TLM level to the RTL, precious refinementguidelines [33, 7] can be followed to bridge refined ele-ments with more abstract elements like those regarding theintroduction of wrappers and adaptors, and to restrict thedesign for the hardware modelling. They are consideredout of the scope of this paper; however, below in Sect. 7we provide an example of communication refinement. Aconcise description of each of the five workflows follows.

Functional design/implementation After analysis, thedesign phase starts by defining the components of the plat-form as a set of UML subsystems and interfaces. A subsys-tem is a type of UML component whose functionality is ex-posed to the outside environment in the form of one or moreinterfaces representing operational contracts (a message-based interface communication concept).

The architectural design is performed in an incremen-tal way, by creating a subsystem that corresponds to eachanalysis package (output of the analysis workflow) and thenrefining those subsystems. UML package diagrams can beused to show the subsystems. Then details are added in eachsubsystem, dividing each subsystem into a specification and

Figure 4. The UPSoC – L-Design, Implemen-tation and Testing workflow

a realization part. The former contains design use cases ob-tained refining the use cases of the corresponding analysispackage. The latter contains design classes and interfacescoming from the analysis classes and from an analysis ofthe design use cases. UML class diagrams are built to showinterfaces, classes and relationships, and UML compositestructure diagrams to represent structural hierarchies usingparts with ports as basic structure elements, and the nota-tion of provided/required interfaces to denote interface us-age/realization dependencies.

The functional design is then performed by identifyingoperations and dynamic behaviour of each class. For thispurpose, UML state machine diagrams and UML activitydiagrams are used, while UML interaction diagrams areuseful to get a better understanding of objects interactions.Finally, subsystems are refined to ensure they are as cohe-sive and loosely coupled as possible, and that they providethe functionality denoted by their specification part.

At the end of the design phase, a draft architecture andits functionality is available. This model corresponds to theinitial functional un-timed model of the embedded systemplatform as shown in the SoC design flow in Fig. 1. Itdescribes the pure system functionality, and the structuralelements do not correspond to blocks in the physical im-plementation, no time information is provided, and com-munication is modelled point to point. In order to makeit executable and timed, the implementation phase has tobe carried out, where a precise action semantics and timemodel have to be adopted. An action (or surface) languagecan be used, supported by a proper execution engine, andthe behavioural diagrams can be enriched with actions ex-pressed according to the adopted action and time seman-tics. Timing diagrams, and annotate interaction diagrams

with time-related constraints4 may be also included. Typi-cal execution engines for the SoC design are those used forprogramming languages like C/C++, SystemC, etc. UMLprofiles targeted to these execution engines and model com-pilers provide painless and automatic paths towards theseenvironments.

Transactional design/implementation In a transactional-level model (TLM), the details of communications amongprocessing elements are separated from the details of com-putation. Communication is modelled by channels, whiletransaction requests take place by calling interface func-tions of these channel elements. Transactions are protocolsexchanging abstract data between blocks, with associatedtiming information. Elements of a TLM model can cor-respond or not to blocks in the physical implementation.Channels’interfaces encapsulate low-level details to enablehigher simulation speed than pin-based interfaces and alsoto speed up the modelling task.

To make a transactional model executable (implemen-tation model), UML profiles for languages like SpecC andSystemC supporting the transaction level model can be con-sidered. Similar considerations apply to the next levels.

Behavioural design/implementation A behaviouralmodel is pin and functionally accurate at its boundaries. Itis not cycle accurate, i.e. internal and I/O events are notscheduled in a cycle accurate manner. There is a certainfreedom left to implement the model in a certain number ofclock cycles.

BCA design/implementation A Bus Cycle Accurate(BCA) model is pin accurate and functionally accurate. Itis also cycle accurate at its boundaries, i.e. in the numberof clock cycles it takes to perform its functionality (I/O in-teractions are scheduled at the proper clock cycle, internalevents are not scheduled).

RTL design/implementation At RTL level the hardwareis described in terms of transfers among registers thoughfunctional units (adders, multipliers, ALUs, etc.). Themodel is accurate at the clock cycle level, both at the bound-aries and internally (all actions are scheduled at the appro-priate clock cycle), and also pin accurate.

6 Design environment for UpSoC

For industrial applications, the availability of appropri-ate tool support is crucial. To support the UPSoC process,we developed a design tool which works as front-end for

4The SysML language and the SPT profile provide a set of standardstereotypes for expressing time related aspects in UML models.

consolidated lower level co-design tools. A more detaileddescription of this tool is provided in [27]. Fig. 5 showsthe tool architecture. Components visualized inside dashedlines are still under development. The tool consists of twomajor parts: a development kit (DK) with design and devel-opment components, and a runtime environment (RE) rep-resented by the SystemC execution engine. The DK con-sists of a UML 2.0 modeler supporting the UML profile forSystemC [23], translators for the forward/reverse engineer-ing to/from C/C++/SystemC, and an abstraction/refinementevaluator to guarantee traceability and correctness alongthe refinement process from the high-level abstract descrip-tion to the final implementation. This last component is un-der development.

The Modeler It is based on the Enterprise Architect tool[8] by SparxSystems, but any other tool supporting UML2.0 can be used. The open API of Enterprise Architect al-lows us to settle the modelling environment to cover thefull spectrum of the UPSoC by using C/C++ and SystemCas action languages.

We introduced the SystemC UML profile definitionwithin the EA. Stereotypes for the SystemC building con-structs (modules, interfaces, ports and channels) are avail-able for use in UML structural diagrams such as UML classdiagrams and composite structure diagrams to represent hi-erarchical structures and communication blocks. Fig. 6shows an example of a SystemC module having a multi-port, an array port, and a simple port, together with the porttype and interface definitions of the simple port.

Figure 5. Tool architecture

UML class diagrams are used to define modules, inter-faces and channels. The internal structure of compositemodules, especially the one of the topmost level module(which represents the structure of the overall system), iscaptured by UML composite structure diagrams; then, fromthese diagrams several UML object diagrams can be createdto describe different configuration scenarios. This separa-tion allows the specification (also partial) of different HW

Figure 6. A module class

platforms as instances of the same parametric model (i.e.the composite structure diagram).

Behaviour is modelled by the use of special state and ac-tion stereotypes which lead to a variation of the UML statemachine diagram, the SC Process State Machines. This for-malism has been appositely included in the profile defini-tion to model the control flow and the reactive behaviourof SystemC processes (methods and threads) within mod-ules. A finite number of abstract behaviour patterns ofstate machines [22] have been identified.Fig. 7 depicts oneof these behaviour patterns together with the correspondingSystemC pseudo-code for a thread that: (i) is not initial-ized, (ii) has both a static (the event list e1s, . . . , eNs) and adynamic sensitivity (the wait state), and (iii) runs contin-uously (by the infinite while loop).

Figure 7. A Thread Process pattern

Fig. 8 shows a module class count_stim contain-ing a thread process stimgen, two input ports dout andclock, and two output ports load and din. In particular,clock is a behaviour port since it provides events that trig-ger the stimgen thread process within the module. Thestimgen thread state machine is shown in Fig. 9. It is arealist example of the behaviour pattern presented in Fig. 7.

Fig. 10 shows a screenshot of EA. The SystemC datatypes and predefined channels, interfaces, and ports aremodelled with the core stereotypes, and are available in theProject View with the name SystemC_Layer1.

Figure 8. The count_stim module example

Figure 9. The stimgen thread state machine

The Translators The Enterprise Architect (EA) supportsforward/reverse engineering to/from C++. We added to theEnterprise Architect the capability to generate complete Cand SystemC code from UML models for both structuraland behavioural aspects. There is, therefore, a unique codegenerator that makes use of translators to transform partsof the UML model either to SystemC or to C/C++. Thegeneration flow is complemented by a reverse engineeringflow that transforms a mixed C/C++/SystemC program intoa UML model. These add-ins were implemented exploit-ing the automation/scripting interface and the XMI (XMLMetadata Interchange) format supported by the EA tool.

7 A case study example

To give an idea on how to perform refinement at UMLlevel by the use of the SystemC UML profile, we showhere how to apply a refinement strategy to refine the com-munication aspects of a simple abstract (functional timed)producer/consumer system taken from [33]. In general, inthe refinement process we not only refine the model’s in-ternal structures, its timing, or the data-types being used;we also need to think about how components communicatewith their environment. Communication refinement refersto mapping an abstract communication protocol into an ac-tual implementation related to a given target architecture.

Before to take a closer look at the specific example, weclarify the process of communication refinement in a moregeneral way. To this purpose, we assume to have two highlevel modules M1 and M2 communicating over a channel Cvia some abstract protocol. As suggested in [33], one possi-ble approach to refining this basic communication scenariotowards an implementation consists of the following steps:

1. Select an appropriate communication scheme to imple-ment;

Figure 10. Generate SystemC code from EA

2. Replace the abstract communication channel C with arefined one CRefined which realizes the selected com-munication protocol;

3. Enable the communication of the modules M1 and M2over CRefined by either:(a) wrapping CRefined in a way that the resultingchannel CWrapped provides the interfaces required byM1 and M2 (wrapping), or(b) refining M1 and M2 into M1Refined andM2Refined, respectively, in order their required inter-faces match the ones provided by CRefined (adapter-merging).

The two cases (not the only ones) are similar. Both in-clude an intermediate step to build two further modules (i.e.two SystemC hierarchical channels), say adapters, to mapone interface to another: one, say A1, between M1 andCRefined, and one, say A2, between CRefined and M2.In the case (a), the resulting channel CWrapped enclosesCRefined and the two adapters; while, in the case (b) theseadapters are merged to the calling modules M1 and M2 re-sulting in the refined modules M1Refined and M2Refined.Deciding whether to use wrapping or merging depends onthe methodology and chosen target architecture.

We can now come back to our specific example. Thedesign of a working producer/consumer module that writesand reads characters to/from a FIFO channel is shown bythe UML composite structure diagram in Fig. 11. Thetop composite module is defined to contain one instance of

Figure 11. A producer/consumer design

the consumer module, one instance of the producer mod-ule, and one FIFO channel instance. The FIFO channelpermits to store characters by means of blocking read andwrite interfaces, such that characters are always reliably de-livered. Two processes, the producer and the consumer (seethe thread processes main within the producer and the con-sumer modules in Fig. 12), respectively feed and read theFIFO. The producer module writes data through its out portinto the FIFO by a sc_fifo_out_if interface, the consumermodule reads data from the FIFO through its in port bythe sc_fifo_in_if interface. These two interfaces are im-plemented by the FIFO channel (see the sc_fifo channel inFig. 12). Because of the blocking nature of the sc_fiforead/write operations, all data are reliably delivered despitethe varying rates of production and consumption.

Now, let’s assume to replace the (abstract) FIFO instanceabove with a (refined) model of a clocked RTL hardwareFIFO named hw_fifo<T> for an hardware implementation.The new hardware FIFO uses a signal-level ready/validhandshake protocol for both the FIFO input and output (see

Figure 12. Producer/consumer modules communicating via a primitive FIFO

Fig. 13). It should be noted that we cannot use hw_fifodirectly in place of sc_fifo, since the former does not pro-vide any interfaces at all, but has ports that connect tosignals, i.e. has ports that use the sc_signal_in_if andsc_signal_out_if interfaces.

Following the wrapper-based approach 3.b of the re-finement procedure described above, we can define a hier-archical channel hw_fifo_wrapper<T> (CWrapped) whichimplements the sc_fifo_out_if and sc_fifo_in_if interfacesand contains an instance of hw_fifo<T> (CRefined). Inaddition, it contains sc_signal instances to interface withhw_fifo<T> and a clock port (since hw_fifo<T> has also aclock port) to feed in the clock signal to the hw_fifo<T>instance (see Fig. 14). Finally, we need to add a hard-ware clock instance in the top-level design to drive the addi-tional clock port that is now on the hw_fifo_wrapper<T>instance (see Fig. 15). The hw_fifo_wrapper<T> imple-ments the required signal-level ready/valid handshake pro-tocol whenever a read or write operation occurs; this pro-tocol will properly suspend read or write transactions ifhw_fifo<T> is not ready to complete the operation. Detailson the SystemC code can be found in [33].

8 Industrial case studies

We have developed several different case studies, sometaken from the SystemC distribution like the Simple Busdesign, and some of industrial interest. The Simple Busdesign is a well-known transactional level example to per-form also cycle-accurate simulation. It is made of about1200 lines of code that implement a high performance, ab-stract bus model. The complete code is available at [20].We modelled the Simple Bus system entirely in a forwardengineering manner. The code generator has been testedprimarily on this example.

To test the expressive power of our profile in representinga variety of architectural and behavioural aspects, we mod-elled the On Chip Communication Network (OCCN)library [19]. The OCCN project [19] focuses on mod-elling complex on-chip communication networks by pro-viding a highly-parameterized and configurable SystemC li-brary. This library is made of about 14.000 lines of code andimplements an abstract communication pattern for connect-ing multiple processing elements and storage elements on asingle chip. The generic features of the OCCN modelling

approach involve multiple abstraction levels, separation ofcommunication and computation, and communication lay-ering. The OCCN design has been imported automaticallyfrom the C++/SystemC code into the EA-based modeler ex-ploiting the reverse engineering facility, then it was refinedusing the modelling constructs of the SystemC UML pro-file. We used this example to test the reverse engineeringflow.

In [2] we present an application example related to an802.11.a physical layer transmitter and receiver system de-scribed at instruction level (see Fig. 16). The hardware plat-form is composed of a VLIW processor developed in STM,called LX, with a dedicated hardware coprocessor that im-plements an FFT (Fast Fourier Transform) operation. Theprocessor acts as a master to the hardware module and thememory components, where code and data are stored. Thecommunication is implemented by a system bus: we usehere the OCCN SystemC model described above. The UMLmodel of the software application is a function library en-capsulated in a UML class, which provides through portsthe I/O interface of the SW layer to the HW system. Thisclass is then translated to C/C++ code and the resulting ap-plication code is executed by the LX ISS wrapped in Sys-temC to allow cycle accurate HW/SW co-simulation. TheUML wrapper of the LX ISS is modelled with the SystemCUML profile, in order to generate a SystemC wrapper forthe ISS and to allow a HW/SW co-simulation at transac-tional or cycle-accurate level.

All case studies mentioned above have not requiredany special refinement strategy. Currently, we are defin-ing a formal refinement methodology with precise abstrac-tion/refinement rules for the transactional-level modelling.To achieve this goal, we have been working to a revision ofthe SystemC UML profile to include the OSCI TLM 1.0library [20] and the new features provided by SystemC 2.1for modelling at the TLM level of abstraction and, specifi-cally, at a certain number of TLM sub-levels.

9 Related work

In this paper, we provide guidance on how to integrate aUP style of software development into the overall processfor Embedded Systems. The UPES reflects current industrybest practices and follows the platform-based design princi-ples [39, 14]. For the UPES definition, we have been taking

Figure 13. Clocked RTL HW FIFO

Figure 14. The hw_fifo_wrapper hierarchical channel

in consideration the work experiences in [14, 10, 40, 38] asfirst contributions to the definition of a development pro-cess for the Embedded Systems domain based on abstractand executable models and on the System-on-Chip (SoC)paradigm for the software-hardware convergence.

The possibility to use UML 1.x for system design [11]started since 1999, but the general opinion at that time wasthat UML was not mature enough as a system design lan-guage. Nevertheless significant industrial experiences usingUML in a system design process soon started leading to thefirst results in design methodology, such as the one in [34]that was applied to an internal project for the developmentof a OFDM Wireless LAN chipset. In this project SystemCwas used to provide executable models.

Later more integrated design methodologies were de-veloped. The paper in [21] proposes a methodology us-ing UML for the specification and validation of SoC de-sign. It defines a flow, parallel to the implementation flow,which is focused on high-level specs capture and validation.In [14], a UML profile for a platform-based approach toembedded software development is presented. It includes

stereotypes to represent platform services and resourcesthat can be assembled together. The authors also presenta design methodology supported by a design environment,called Metropolis, where a set of UML diagrams (use cases,classes, state machines, activity and sequence diagrams) canbe used to capture the functionality and then refine it byadding models of computation. Another approach to theunification of UML and SoC design is the HASoC (Hard-ware and Software Objects on Chip) [10] methodology. It isbased on the UML-RT profile [28] and on the RUP process[12]. The design process starts with an uncommitted modeland after a committed model is derived by partitioning thesystem into software and hardware, and then mapped ontoa system platform. From these models a SystemC skeletoncode can be also generated, but to provide a finer degree ofbehavioural validation, detailed C++ code must be added byhand to the skeleton code. All the works mentioned abovecould greatly benefit from the use of UML 2.0.

SysML [32] is a conservative extension of UML 2.0 fora domain- neutral representation (i.e. a PIM model as inMDA [16]) of system engineering applications. It can be

Figure 15. A clocked producer/consumer design

Figure 16. 802.11a TRX block diagram

involved at the beginning of the design process, in place ofthe UML, for the requirements, analysis, and functional de-sign workflows. So it is in agreement with our UML profilefor SystemC, which can be thought (and effectively made) acustomization of SysML rather than UML. The standardiza-tion proposal [36] by Fujitsu, in collaboration with IBM andNEC, has evident similarities with our SystemC UML pro-file, like the choice of SystemC as a target implementationlanguage. However, their profile does not provide buildingblocks for behaviour modelling and any time model.

Some other proposals already exist about extensions ofUML towards C/C++/SystemC. All have in common theuse of UML stereotypes for SystemC constructs, but notrely on a UML profile definition. In this sense, it is appre-ciable the work in [4] attempting to define a UML profilefor SystemC; but, as all the other proposals, it is based onthe previous version of UML, UML 1.4. Moreover, in allthe proposals we have seen, no code generation, except in[18], from behavioural diagrams is considered.

Refinement is another key concept in MDA. However,compared with the refinement techniques available for for-mal methods like Z, B, and ASMs [3], few work has beencarried out towards for languages, like UML, used in MDA.

10 Conclusions and future directions

The definition of the UPES process is part of our on-going effort to enact design flows that start with systemdescriptions using UML-notations and produce full imple-

mentations of the SW and HW components as well as theircommunication interfaces. Our goal is raising the level ofabstraction and developing more complex systems by ma-nipulating models only.

The UPES process is intended to assist the designersacross the UML modelling activity from a high-level func-tional model of the system down to a RTL model by sup-porting current industry best practice and the platform-based design principles [39, 14]. Its architecture-centric anditerative backbone makes it highly consistent with the MDAconcepts [16]. These last are primarily aimed at providingexecutable models and at supporting automation of the pri-mary UPES activities. This MDA-style separation of mod-els, however, demands more support for model evolution ac-tivities such as model refinement/abstraction, model refac-toring, model inconsistency management, etc. Today, onlya limited support is available in model-based developmenttools for these evolution activities [17]. We need tools en-dowed with means to switch to a new technology platformthrough automatic model transformations – a key point ofMDE – while re-using the software application models.

We are still exploring, therefore, the possibility to imple-ment MDA-style transformations to allow a PIM to be trans-formed into a PSM, and an abstract PSM to be transformedinto a refined PSM according to the levels of abstraction:functional, transactional, behavioural, BCA, and RTL. Weare defining a formal refinement methodology with preciseabstraction/refinement rules for this purpose. In particu-lar, we are focusing on the transactional-level modeling, to

model the communication aspects at a certain number ofTLM sub-levels. This implies also a revision of the Sys-temC UML profile to include the OSCI TLM 1.0 library[20] and the new features provided by SystemC 2.1 (likesc_export ports, the event_queue mechanism, dy-namic processes, fork/join synchronization) for modellingat the TLM level of abstraction.

References

[1] J. Arlow and I. Neustadt. UML and the Unified Process. Ad-dison Wesley, 2002.

[2] S. Bocchio, E. Riccobene, A. Rosti, and P. Scandurra. A SoCdesign flow based on UML 2.0 and SystemC. In InternationalDAC Workshop UML–SoC’05.

[3] E. Börger and R. Stärk. Abstract State Machines: A Methodfor High-Level System Design and Analysis. Springer Verlag,2003.

[4] F. Bruschi and D. Sciuto. SystemC based Design Flow start-ing from UML Model. In Proc. of European SystemC UsersGroup Meeting, 2002.

[5] J. Bézivin. In search of a basic principle for model drivenengineering. CEPIS, UPGRADE, The European Journal forthe Informatics Professional, V(2):21–24, 2004.

[6] J. Bézivin. On the unification power of models. Software andSystem Modeling (SoSym), 4(2):171–188, 2005.

[7] L. Cai and D. Gajski. Transaction Level Modeling: anOverview. In Proc. of CODES+ISSS’03, Newport Beach,California, USA.

[8] The Enterprise Architect tool: www.sparxsystems.com.au/.

[9] ECSI Institute Workshop: UML Profiles for EmbeddedSystems, March 27-28, 2006. http://www.ecsi-association.org/ecsi/.

[10] M. Edwards and P. Green. UML for hardware and softwareobject modeling. UML for real design of embedded real-timesystems, pages 127–147, 2003.

[11] G.Martin. UML and VCC. White paper, Cadence DesignSystems, Inc, Dec. 1999.

[12] P. Kruchten. The Rational Unified Process. Addison Wesley,1999.

[13] L. Lavagno, G. Martin, and B. Selic. UML for Real Designof Embedded Real-Time Systems. Kluwer, 2003.

[14] L. Lavagno, G. Martin, A. S. Vincentelli, J. Rabaey, R. Chen,and M. Sgroi. UML and Platform based Design. UML forReal Design of Embedded Real-Time Systems, 2003.

[15] G. Martin and W. Mueller. UML for SoC Design. ISBN0-387-25744-6, Springer, July 2005.

[16] OMG. The Model Driven Architecture (MDA). http://www.omg.org/mda/.

[17] T. Mens, M. Wermelinger, S. Ducasse, S. Demeyer,R. Hirschfeld, and M. Jazayeri. Challenges in Software Evo-lution. In Proc. of the International Workshop on SoftwareEvolution. IEEE, 2005.

[18] K. Nguyen, Z. Sun, P. Thiagarajan, and W. Wong. Model-Driven SoC Design: The UML-SystemC Bridge. UML forSOC Design, 2005.

[19] OCCN Project: http://occn.sourceforge.net/.[20] The Open SystemC Initiative. http://www.systemc.

org.

[21] Q.Zhu, R.Oishi, T.Hasegawa, T.Nakata. System-on-ChipValidation using UML and CWL. In Proc. of CODES, 2004.

[22] E. Riccobene and P. Scandurra. Modelling SystemC ProcessBehaviour by the UML Method State Machines. In Proc. ofRISE’04. Springer.

[23] E. Riccobene, P. Scandurra, A. Rosti, and S. Bocchio. AUML 2.0 Profile for SystemC. ST Microelectronics Techni-cal Report, AST-AGR-2005-3.

[24] E. Riccobene, P. Scandurra, A. Rosti, and S. Bocchio. ASoC Design Methodology Based on a UML 2.0 Profile forSystemC. In Proc. of Design Automation and Test in Europe.IEEE Computer Society, 2005.

[25] E. Riccobene, P. Scandurra, A. Rosti, and S. Bocchio. AUML 2.0 profile for SystemC: toward high-level SoC de-sign. In EMSOFT ’05: Proceedings of the 5th ACM inter-national conference on Embedded software, pages 138–141.ACM Press, 2005.

[26] E. Riccobene, P. Scandurra, A. Rosti, and S. Bocchio. AModel-driven Co-design Flow for Embedded Systems. InFDL ’06: Proceedings of Forum on Specification and DesignLanguages, 2006.

[27] E. Riccobene, P. Scandurra, A. Rosti, and S. Bocchio. Amodel-driven design environment for embedded systems. InDAC ’06: Proceedings of the 43rd annual conference on De-sign automation, pages 915–918, New York, NY, USA, 2006.ACM Press.

[28] B. Selic. A Generic Framework for Modeling Resourceswith UML. In Proceedings of the 16th Symposium on Inte-grated Circuits and Systems Design (SBCCI’03), 33:64–69,2000, IEEE Computer Society.

[29] R. D. Simone and et al. MARTE: A new Profile RFP for theModelling and Analysis of Real-time Embedded Systems. InUML for SoC Design workshop at DAC’05.

[30] OMG. SPEM, formal/05-01-06.[31] OMG. UML profile for Schedulability, Performance, and

Time, formal/03-09-01.[32] SysML Partners web site. http://www.sysml.org/.[33] T. Gröetker and S. Liao and G. Martin and S. Swan. System

Design with SystemC. Kluwer Academic Publisher, 2002.[34] T.Moore, Y.Vanderperren and G.Sonck and P.van Oostende

and M. Pauwels and W. Dehaene. A Design Methodology forthe Development of a Complex System-On-Chip using UMLand Executable System Models. In Forum on Specificationand Design Languages, ECSL, 2002.

[35] OMG. The Unified Modeling Language (UML). http://www.uml.org.

[36] Fujitsu Limited, IBM, NEC. A UML Extension for SoC.Draft RFC to OMG, 2005-01-01.

[37] Y. Vanderperren and W. Dehaene. A Model-Driven Devel-opment Process for Low Power SoC Using UML. UML forSOC Design, 2005.

[38] Y. Vanderperren, M. Pauwels, W. Dehaene, A.Berna, andF. Ozdemir. A SystemC Based System On Chip Modellingand Design Methodology. SystemC : Methodologies and Ap-plications, 2003.

[39] A. S. Vincentelli. Defining Platform-based Design.EEDesign, February 2002.

[40] Q. Zhu, A. Matsuda, S. Kuwamura, T. Nakata, and M. Shoji.An object-oriented design process for system-onchip usingUML. In Proc. of the 15th international symposium on Sys-tem Synthesis, Kyoto, Japan, 2002.