Architectural Optimization & Design of Embedded Systems based on AADL Performance Analysis

Transcription

1 Amercan Journal of Computer Archtecture 2012, 1(2): DOI: /j.ajca Archtectural Optmzaton & Desgn of Embedded Roberto Varona-Gómez 1,*, Eugeno Vllar 1, Ana Isabe l Rodrígue z 2, Francsco Ferrero 2, Elena Alaña 2 1 Unversty of Cantabra, 39005, Santander, Span 2 GMV Aerospace and Defence S.A.U., 28760, Tres Cantos, Span Abstract Due to the ncreasng complexty of embedded systems, new desgn methodologes have to be adopted, snce tradtonal technques are no longer effcent. Model-based engneerng enables the desgner to confront these concerns usng the archtecture descrpton of the system as the man axs durng the desgn cycle. Defnng the archtecture of the system before ts mplementaton enables the analyss of constrants mposed on the system from the begnnng of the desgn cycle untl the fnal mplementaton. AADL has been proposed for desgnng and analyzng SW and HW archtectures for real-t me msson-crtcal embedded systems. Although the Behavoural Annex mproves ts smulaton semantcs, AADL s a language for analyzng archtectures and not for smulatng them. AADS s an AADL smulaton tool that supports the performance analyss of the AADL specfcaton throughout the refnement process from the ntal system archtecture untl the complete, detaled applcaton and executon platform are developed. In ths way, AADS enables the verfcaton of the ntal tmng constrants durng the complete desgn process. AADS supports the performance analyss of the AADL specfcaton, enrched wth behavour specfcatons. AADS-T s Ravenscar Computatonal Model (RCM) complant as part of the TASTE toolset and has been used to assst n co-desgn. Keywords AADL, Performance Analyss, Smulaton, Ravenscar Computatonal Mode, HW/SW Co-Desgn, AADS, POSIX, SCoPE 1. Introducton Nowadays, embedded systems must support the deployment of heterogeneous applcatons wthn heterogeneous archtectures. In most cases, the executon platform s not fxed and must be desgned and optmzed n conjuncton wth the applcaton SW. Therefore, early estmaton of the system performance on the executve platform, under real-tme constrants, s desrable. Ths analyss requres a unfed model of the applcaton and the archtecture, and effectve means to defne the mappng of applcaton functons onto archtecture resources and servces. Archtecture Analyss and Desgn Language (AADL) [1-3] provdes such a modellng framework. It was developed as a standard of the Socety of Automotve Engneers (SAE) to enable the descrpton of task and communcaton archtectures fo r real-tme, embedded, fault-tolerant, secure, safety-crtcal, SW-ntensve systems. However, AADL does not support the expresson of behavour n detal. At most, t s possble to specfy the * Correspondng author: roberto@tesa.uncan.es (Roberto Varona-Gómez) Publshed onlne at Copyrght 2012 Scentfc & Academc Publshng. All Rghts Reserved non-determn stc behavour of a thread as a set of subprogram calls, and applcaton behavour reles man ly on source code wrtten n source languages. The behavoural annex[4] has ntroduced hgh-level composton concepts and a rcher state representaton than the standard AADL mode automata[48]. The behavour s specfed usng extended automata that may trgger a transton by an event, a Boolean expresson, etc. A transton may trgger one or more actons such as assgnment of values to varables, sendng data, events, etc. The annex manly declares states and transtons wth guards and an acton part. Guards and actons can access ports and data subcomponents declared n the AADL component to whch they are attached. The Automated proof-based System and Software Engneerng for Real-Tme systems (ASSERT) project[5] resulted n a new development process for dstrbuted embedded real-tme software, and a set of methods and tools supportng the process. The process s based on separaton of concerns, automatc code generaton and property preservaton. An mportant feature of the ASSERT process s the adherence of the concurrency model to the RCM[6], a restrcted taskng model that enables statc response tme analyss of real-tme systems. The model restrcts the concurrency model to a statc set of perodc and sporadc threads communcated by means of a statc set of shared data objects, protected by mutual excluson

2 22 Roberto Varona-Gómez et al.: Archtectural Optmzaton & Desgn of Embedded synchronzaton. There are two varants of the ASSERT software process: Hard Real-Tme Unfed Modelng Language (HRT-UML) and AADL tracks. The ASSERT Set of Tools for Engneerng (TASTE)[7] toolset s an open source toolset supportng the latter. The LEON2[8] processor was desgned by the European Space Agency (ESA) as a 32-bt syntheszable processor core based on the SPARC V8 archtecture. The core s hghly confgurable, and partcularly sutable for System-on-Chp (SOC) desgns. There s a commonly recognzed need for new development frameworks that enable desgners to perform effcent exploraton of desgn alternatves and analyze system propertes throughout the desgn cycle. Some system propertes can be obtaned by statc analyss. Many other propertes can only be obtaned through smulaton. In any case, system smulaton s needed for performance analyss under real executon condtons. System smulaton and performance analyss can valdate the correct dmensonng of the system and detect locks, mssed deadlnes and other potental problems rased by the complex nteracton among components that can be found n a real system. The earler all these problems are detected, the lower the cost of correctng them[9]. Evolutonary prototypng s now becomng a well-accepted development approach n Model-Drven Engneerng (MDE)[10]. The desgn flow s based on a central model that s refned unless t s satsfactory. Programs can be generated from ths model and consttute ntermedate versons of the product. The last refned model corresponds to the fnal system. A prototypng-based desgn process s benefcal for the earlest possble verfcaton of the mpact of deployment decsons, or the use of a partcular HW/SW component n the system. Ths document deals wth AADS[12] an AADL smulaton and performance analyss framework, ncludng a behavoural annex compatble wth the RCM. The tool can support prototype-based desgn allowng the functonal and non-functonal (executon tmes, power consumpton, etc.) verfcaton of the system whle t s beng refned untl the fnal mplementaton. Based on SystemC, the framework supports the seamless ntegraton of HW component and an easy optmzaton of the executve platform. SystemC has become a relevant standard language for modelng and smulaton of HW/SW embedded systems[11]. HW/SW parttonng s a phase of co-desgn n whch the partton of the specfcaton nto two parts s acheved. One part wll be mplemented n HW and the other part wll be mplemented n SW. HW/SW parttonng s the process of decdng, for each subsystem, whether the requred functonalty s more advantageously mplemented n HW or SW to acheve a partton that wll gve us the requred performance wthn the overall system requrements (n sze, weght, power, cost, etc.). Parttonng nto HW and SW affects overall system cost and performance[45]. There are two parttonng approaches: Startng frst wth all the functonalty n SW and movng parts, whch are tme-crtcal and cannot be allocated to SW, nto HW (ths s known as SW centrc parttonng) or startng frst wth all the functonalty n HW and movng parts nto the SW mplementaton (ths s known as HW centrc parttonng). AADS extracts the necessary nformaton for the SCoPE tool to perform a smulaton at system level fro m the AADL models. The smulaton and performance analyss results wll gude the system desgner through the selecton of the most adequate partton soluton (see Fgure 1). The contents of the paper are as follows. The followng two sectons make a summary of AADL and SCoPE respectvely. The next secton revews the related work. In the next two sectons, AADS and AADS-T are descrbed, wth a bref descrpton about performng the smulaton on a LEON2 processor. Ne xt, we explan the Case Study: How AADS-T has been used n the ESTEC 22810/ 09/ NL/JK HW-SW CODESIGN project[46] to assst n HW/SW parttonng. Then we state the conclusons and fnally, we nclude acknowledgements and referenced documents. F gure 1. AADS and SCoPE n the HW/SW co-desgn process 2. AADL The SAE AADL standard provdes formal modellng concepts for the descrpton and analyss of applcaton system archtecture n terms of the dstnct components and ther nteractons. The AADL ncludes software, hardware,

3 Amercan Journal of Computer Archtecture 2012, 1(2): and system component abstractons to specfy and analyze real-tme embedded systems, complex systems of systems, and specalzed performance capablty systems, and to map software onto computatonal hardware elements. The AADL s especally effectve for model-based analyss and specfcaton of complex real-tme embedded systems. In AADL, a component s characterzed by ts dentty (a unque name and runtme essence), possble nterfaces wth other components, dstngushng propertes (crtcal characterstcs of a component wthn ts archtectural context), and subcomponents and ther nteractons. In addton to nterfaces and nternal structural elements, other abstractons can be defned for a component and system archtecture. For example, abstract flows of nformaton or control can be dentfed, assocated wth specfc components and nterconnectons, and analyzed. These addtonal elements can be ncluded through core AADL language capabltes (e.g. defnng new component propertes) or the specfcaton of a supplemental annex language. The component abstractons of the AADL are separated nto three categores: Applcaton software, executon platform (hardware) and composte. Applcaton software can be a thread (actve component that can execute concurrently and be organzed nto thread groups), thread group (component abstracton for logcally organzng thread, data, and thread group components wthn a process), process (protected address space whose boundares are enforced at runtme), data (data types and statc data n source text) and subprogram (concepts such as call-return and calls-on methods, modelled usng a subprogram component that represents a callable pece of source code). Executon platform (hardware) can be a processor (schedules and executes threads), memory (stores code and data), devce (represents sensors, actuators, or other components that nterface wth the external envronment) and bus (nterconnects processors, memory, and devces). Composte can be a system (desgn elements that enable the ntegraton of other components nto dstnct unts wthn the archtecture). System components are compostes that can consst of other systems as well as of software or hardware components. The AADL standard ncludes runtme semantcs for mechans ms of exchange and control of data, ncludng message passng, event passng, synchronzed access to shared components, thread schedulng protocols, tmng requrements and remote procedure calls. In addton, dynamc reconfguraton of runtme archtectures can be specfed usng operatonal modes and mode transtons. The AADL can be used to model and analyze systems already n use and desgn and ntegrate new systems. The AADL can be used n the analyss of partally defned archtectural patterns (wth lmted archtectural detal) as well as n fu ll-scale analyss of a complete system model extracted from the source code (wth completely quantfed system property values). AADL supports the early predcton and analyss of crtcal system qualtes, such as performance, schedulablty, and relablty. For example, n specfyng and analyzng schedulablty, AADL-supported thread components nclude the pre-declared executon property optons of perodc, aperodc (event-drven), background (dspatched once and executed untl completon), and sporadc (paced by an upper rate bound) events. These thread characterstcs are defned as part of the thread declaraton and can be readly analyzed. Wthn the core language, property sets can be declared that nclude new propertes for components and other modellng elements (e.g. ports and connectons). By utlzng the extenson capabltes of the language, addtonal models and propertes can also be ncluded. For example, a relablty annex can be used that defnes relablty models and propertes of components facltatng a Markov or fault tree analyss of the archtecture. Ths analyss would assess archtecture s complance wth specfc relablty requrements. Collectvely, these AADL propertes and extensons can be used to ncorporate new and focused analyses at the archtectural desgn level. These analyses facltate trade off assessments among alternatve desgn optons early n a development or upgrade process. F gure 2. AADL graphcal notaton AADL components nteract exclusvely through defned nterfaces. A component nterface conssts of drectonal flow through data ports for un-queued state data, event data ports for queued message data, event ports for asynchronous events, synchronous subprogram calls and explct access to data components. Interactons among components are specfed explctly. For example, data communcaton among components s specfed through connecton declaratons. These can be md-frame (mmedate) communcaton or phase-delayed (delayed) communcaton. The semantcs of these connectons assures determnstc transfer of data streams. Determnstc transfer means that a thread always receves data wth the same tme delay; f the recevng thread s over- or under-samplng the data stream, t always does so at a constant rate. Applcaton components have propertes that specfy tmng requrements such as perod, worst-case executon

4 24 Roberto Varona-Gómez et al.: Archtectural Optmzaton & Desgn of Embedded tme, deadlnes, space requrements, arrval rates, and characterstcs of data and event streams. In addton, propertes dentfy source (code and data that mplement the applcaton component beng modelled n the AADL) and constrants (for bndng threads to processors, source code, and data onto memory). The constrants can lmt bndng to specfc processor or memory types (e.g., to a processor wth DSP support) as well as prevent co-locaton of applcaton components to support fault tolerance. 3. SCoPE The SCoPE[24] tool provdes the technology to perform MPSoC HW/SW co-smulaton wth Network on Chp (No C). It enables the e xplo raton of the desgn space to choose the rght processors and HW/SW partton for embedded systems. It also allows the smulaton of dfferent nodes connected through a NoC n order to analyse the behavour of large systems. Commonly, these tools are based on slow ISSs. The dfferentatng feature of ths technque s that SCoPE obtans the performance estmatons at source code level. Ths level of abstracton enables the smulaton tme to be reduced sgnfcantly whle mantanng good accuracy. SCoPE s a C++ lbrary that wthout modfcaton extends standard language SystemC to perform co-smulaton. On the one hand, t smulates C/C++ software code based on two dfferent operatng system nterfaces (POSIX and McroC/OS). On the other hand, t co-smulates these peces of code wth hardware descrbed n SystemC. An engneer wth ths tool can smulate specfc software over a custom platform and obtan estmatons of: number of thread and context swtches, runnng tme and use of CPU, nstructons executed and cache msses, energy and power (of core and nstructon cache). Ths lbrary models the detaled behavour of the RTOS ncludng concurrency (among tasks n the same processor), parallelsm (among tasks n dfferent processors), schedulng and synchronzaton. Although the SystemC kernel executes processes followng a non pre-emptve schedulng polcy wthout prortes, SCoPE models pre-empton under dfferent schedulng polces based on prortes. SCoPE ntegrates a POSIX-based API that enables the executon of a large number of software applcatons that follows ths standard. POSIX s the man operatng system nterface nowadays, but t s not the only one. Thus, SCoPE has been mproved to support extensons for other types of nterfaces. An example s the ntegraton wth the McroC/OS nterface. Ths s a demonstraton of the scalablty of the tool, n terms of software support. The desgn of embedded systems requres not only software handlng but also hardware communcaton. For ths reason SCoPE ncludes a set of more than a hundred drver facltes to mplement ths communcaton. One of the most extensvely used operatng systems n ths sector s Lnu x, so these drver facltes are based on the Lnux kernel verson 2.6. Furthermore, SCoPE s able to smulate the loadng of kernel modules and the handlng of hardware nterruptons and ther correspondng schedulng. SystemC s the language used for the modellng of the hardware platform due to the easness of mplementaton (C++ extenson) and ts smulaton kernel. For the purpose of smulatng dfferent platforms SCoPE ncorporates some generc hardware modules: A bus based on TLM2 used for the communcaton wth perpherals and the transmsson of hardware nterruptons, a DMA for copyng large amounts of data, smple memory for the smulaton of cache and DMA traffc, a hardware nterface for smple custom hardware connecton, a network nterface that works as a net card for the NoC and an external network smulator to mplement the NoC connected to SCoPE. System smulaton comprses Mult-computaton and Modular structure. Mult-computaton: One of the advantages of ths tool s the possblty of nterconnecton among ndependent nodes and smulatng the nteracton among them. Modular structure: Each RTOS component s an ndependent object that does not share any data wth the others. Furthermore, each process s solated from the rest of the system, thus a process wth global varables can be replcated n many nodes wthout data collson problems. That s, each process has a separate memory space. 4. Related Work F gure 3. Block dagram of SCoPE Smulaton and performance analyss of AADL models represent an mportant stage n MDE. Dfferent approaches address ths ssue. ADeS s one of the most powerful smulaton tools yet t requres the envronment n whch the system evolves[15] to be taken nto account. Another way to tackle the problem s translatng AADL to another language. Cheddar[16] s a set of Ada packages that enables the desgn of a new scheduler and drect nterpretaton usng the Cheddar envronment. The Furness toolset[17] translates models nto the real-tme process algebra ACSR to explore the state space lookng for

5 Amercan Journal of Computer Archtecture 2012, 1(2): volatons of tmng requrements. M. Yassn Chkour et al. propose n[18] a translaton from AADL models to BIP models to enable smu laton. Ocarna[10] s a tool sute that uses code generaton facltes n Ada and C to analyze the AADL model. ADAPT[19] translates an AADL archtectural model nto a dependablty evaluaton model n the form of a Generalzed Stochastc Petr Net (GSPN). T. Abdoul et al.[20] produce an IF tmed automata model whch s the entry pont of the valdaton process, processng t wth the IFx framework. E. Jaher et al.[21] translate the archtecture nto a non-determnstc synchronous model to whch the SW components n Scade or Lustre can be ntegrated, to smulate t wth Lurette. Annex D of the AADL standard gves gudelnes to translate AADL SW components nto source code (C, Ada). S. Gu et al.[22] use the lnear hybrd automata n the desgn phase statcally to abstract the semantcs of the SW components of AADL exp lctly. M. Brun et al.[23] translate to OIL confguraton code and to C code whch s compatble wth the OSEK/VDX RTOS. Several authors have consdered the behavoural annex n ther research on AADL. Some of ther papers were wrtten n the ntal stage of the behavoural annex so they were ntended to evaluate, promote and dssemnate t. P. Dssaux et al.[29] present a proposal for a behavoural annex to the AADL standard. They explan how to mplement the behavoural annex wth the Stood tool, a graphcal AADL edtor that can mport and export AADL textual specfcatons. R. Bedn et al.[30] evaluate the behavoural annex through a flght software desgn n the ArchDyn project. Ths requres new synchronzaton prmtves for AADL runtme and support usng edton and analyss tools for the behavoural annex. J. P. Bodevex et al.[31] propose an AADL behavoural annex and a technque to perform compostonal real-tme verfcaton of AADL models through the use of a method whch translates envronmental constrants nto behavour. Other papers, such as the latter one, nclude the behavoural annex n ther verfcaton process of AADL models. B. Berthomeu et al. descrbe n[32] a formal verfcaton tool chan for AADL wth ts behavoural annex avalable n the Topcased envronment. They translate the AADL model to Facre and verfy the behavour wth a Tme Petr Net Analyzer (Tna). C. Ponsard et al. explore n[33] the nterplay of requrements and archtecture n a model-based perspectve by defnng a mappng and a constructve process takng nto account specfcs of embedded systems, especally the mportance of non functonal requrements. To generate the behavoural part of a system they frst generate a fnte state machne and then an AADL mode-transton. A way to approach AADL and ts behavoural annex s translaton to another language. To allow smulaton M. Yassn Chkour et al. propose n[34] a translaton fro m AADL models to BIP models. They take nto account behavour specfcatons allowng state varables, ntalzaton, states and transtons sectons to be defned and translatng them nto BIP. DUALLY[35] s an automated framework that allows archtectural language nteroperablty through automated model transformaton technques. I. Malavolta et al. analyze the feasblty of ntegratng AADL and OSATE n DUALLY. They map AADL behavoural annex sectons of states, composte states and transtons. Several authors have consdered ASSERT and the RCM n ther research. Some of ther papers deal wth the ASSERT Vrtual Machne (VM), the executon platform on whch ASSERT applcatons run, based on the RCM. J. A. de la Puente et al.[36] and J. Zamorano et al.[37] are good examples of ths. M. Bordn et al.[38] propose some gudelnes to generate RCM-complant Ada code from HRT-UML. S. Mazzn et al.[39] explan a MDE methodology for the development of hgh-ntegrty real-tme systems. However usng UML does not enable a low-level descrpton of the system. Moreover, the dfferent vews of the system use dfferent formalsms, so one must modfy all vews on each change of the system to get a coherent model, hnderng rapd prototypng. J. Kwon et al.[40] propose Ravenscar-Java, a hgh-ntegrty profle for real-tme Java. However we thnk that Java s not a good hgh-ntegrty programmng language due to ts object-orented programmng features, ts automatc garbage collecton, and the proposed lmtatons to the extenson of real-tme mult-threadng that cause confuson. Ocarna[10] s a tool sute that uses code generaton facltes n Ada and C to analyze AADL models. The code generated s compatble wth the RCM. In[50] M.B. Abdelhalm, S.E.-D. Hab b develop a new hgh-level hardware/software parttonng methodology. In[51] K. La mpka et al. present a compostonal and hybrd approach for the performance analyss of dstrbuted real-tme systems. After analyzng the related work, t appears that no approach uses SystemC, whch s a recognzed standard for modellng HW/SW platforms, wth ts great potental for ntegraton of processors, buses, memores and specfc platform HW. The aforementoned solutons cannot model the HW platform so they do not permt HW/SW co-desgn. Apart from[23] none of the approaches models AADL over a RTOS. Our soluton makes HW/SW co-desgn easer because of the use of SystemC. SCoPE s a C++ lbrary that extends standard language SystemC[25] wthout modfyng t. It smulates C/C++ SW code based on two dfferent operatng system nterfaces (POSIX[26-27] and McroC/OS). Moreover, t co-smulates these peces of code wth HW descrbed n SystemC. SCoPE generates a fle wth ths SystemC descrpton of the model. SCoPE has proven to be an effcent tool for desgn space exploraton[49]. AADS supports AADL smulaton n SystemC, thus allo wng the modellng of the HW platform and permttng HW/SW co-desgn. The AADL model s based on POSIX,

6 26 Roberto Varona-Gómez et al.: Archtectural Optmzaton & Desgn of Embedded so t supports many dfferent RTOS. In prevous work[42-44] we have talked about AADS, nevertheless, n ths paper we show the complete methodology wth a complex ndustral case study. 5. AADS AADS s an AADL smulaton tool wrtten n Java, whch was developed as a plug-n[13] of Eclpse[14]. AADS enables the modellng of a subset of AADL for purposes of mplementaton and smulaton. The startng pont of the smulator s a functonal AADL specfcaton wthout detaled code. For each component, the correspondng tmng constrants are defned. Ths ntal AADL specfcaton supports the verfcaton of the global performance constrants of the system based on the specfc tmng constrants of the dfferent components. The AADL model s parsed usng AADS and a model sutable for smulaton wth SCoPE s produced, n order to check whether the AADL constrants are fulflled. As the desgn process advances and, on the one hand, the actual functonalty s attached to the SW components usng the correspondng source code and, on the other, the functonalty s mapped onto specfc platform resources, a more accurate performance estmaton s acheved. These refned propertes wll be added to the AADL model and a new model s generated by AADS. By comparng the ntal tmng constrants wth these refned, tmng estmat ons, t s possble to verfy the non functonal correctness of the desgn process at any refnement step. AADL enables the specfcaton of both the archtecture and functonalty of an embedded real-tme system. AADS translates both to SystemC (see Fgure 4). It parses the AADL model so the functonalty s translated to an equvalent POSIX model and the archtecture s represented n XM L[28]. The equvalent POSIX model and the archtecture can be mplemented easly as an embedded system. The functonalty of an embedded real-tme system s translated as follows: Thre ads. An AADL thread s a concurrent schedulable unt of sequental executon through source code and multple threads represent concurrent executon paths. A POSIX thread s an executon thread n a program and an applcaton can have multple executon threads runnng concurrently. An AADL thread translates seamlessly nto a POSIX thread. In POSIX, a thread attrbute object must be defned and ntalzed wth the default value for all of the ndvdual attrbutes used by a gven mplementaton. AADS determnes how the other schedulng attrbutes of the created thread are to be set, that s that the schedulng polcy and assocated attrbutes are to be set to the correspondng values. Thus AADS can now call the POSIX functon to create a new thread wth the specfed attrbutes. The specfed routne s then launched as a startng routne. F gure 4. Translaton, refnement and mplement at on wth AADS Perodc threads. A thread s perodc f repeated dspatches occur durng a specfc tme nterval. An AADL perodc thread has ts Dspatch_Protocol property set to Perodc and ts Perod property set, for example, to 20 ms. These two propertes are translated puttng the source code of the POSIX thread nto an nfnte loop. At the begnnng of the loop the current tme s obtaned. At the end of the loop the current thread s suspended untl ether the tme value of the clock reaches the absolute tme specfed (the current tme plus the perod), or a sgnal s delvered to the callng thread and ts acton s to nvoke a sgnal-catchng functon, or the thread s termnated. By dong ths t wats to repeat the loop for exactly the tme specfed n the Perod property. Port connectons translate nto message queues, sgnals and global varables: Message queues. An AADL event data port models message communcaton wth queung of messages at the recpent. Message arrval may cause dspatch of the recpent and allow the recpent to process one or more messages. POSIX message queues allow threads to exchange data n the form of messages. Messages placed n the queue are stored untl the recpent retreves them. An AADL event data port connecton between threads translates nto a POSIX message queue between threads. The attrbutes of the message queue must be set. The value of the maxmum number of messages s taken from the AADL property Queue_Sze of the destnaton port f t exsts. The AADL property Queue_Processng_Protocol s set to FIFO as corresponds to a message queue. The message queue s created to both send and receve messages n non-blockng mode. The thread correspondng to the AADL source/destnaton thread of the event data port connecton should add/receve a message of the specfed length to/from the message queue specfed wth the prorty ndcated. Sgnals. An AADL event port acts as an nterface for the communcaton of events rased by subprograms, threads, etc. that may be queued. An example of use of an event port ncludes alarm communcatons that may be queued at the recpent, where the recpent may process the queue content. A sgnal s a lmted form of nter-thread communcaton used n POSIX-complant operatng systems. Essentally, t s an asynchronous notfcaton sent to a thread n order to notfy t of an event that occurred. When a sgnal s sent to a thread, the operatng system nterrupts the thread's normal flow of executon. If the

7 Amercan Journal of Computer Archtecture 2012, 1(2): thread has prevously regstered a sgnal handler, that routne s executed. Otherwse, the default sgnal handler s executed. An AADL event port connecton between threads translates nto the sendng of POSIX sgnals between threads. The sgnals used are the user-defnable real-tme sgnals. The structure type of an object used to represent sets of sgnals must be used wth the POSIX functons that ntalze and empty a sgnal set, add a sgnal to a sgnal set and examne and change blocked sgnals before creatng the thread. The source/destnaton POSIX thread that corresponds to the AADL source/destnaton thread of the event port connecton sends/wats for the sgnal (zero tmeout for no blockng f there s no sgnal receved). Gl obal var ables An AADL data port acts as an nterface for typed state data transmsson among components wthout queung. Data ports are represented by typed varables n source text. A global varable s a varable that s accessble n every scope. Global varables are used extensvely to pass nformaton between sectons of code that do not share a caller/called relaton such as concurrent threads. An AADL data port connecton between threads translates nto a global varable between threads. The data type of ths global varable s derved from the type of ports connected. The source/destnaton thread that corresponds to the AADL source/destnaton thread of the data port connecton, can wrte/read a value n/from that global varab le. The AADL propertes are translated as followed: Schedulng_Polcy and Prorty of threads. An AADL property set called UC wth two propertes POSIX_Schedulng_Polcy and Prorty has been defned. The frst s an enumeraton of the values SCHED_FIFO, SCHED_RR, SCHED_SPORADIC and SCHED_OTHER, and the second s an nteger fro m 0 to 32. The frst s obvously used to set the schedulng polcy of the treads. The second s used wth the approprate mnmum value for the schedulng polcy specfed to set the schedulng parameter attrbutes of the threads. Compute_Executon_ T me (mn, max). The mnmum tme causes a call to a functon that consumes that processng tme to assure that at least that tme s consumed. Ths functon s adjusted at the begnnng of the applcaton to assure that the exact tme s consumed. Thus the mnmum executon tme s the tme establshed by ths property for ths thread. The maxmum tme requres the creaton of a tmer that s set wth ths tme untl the next expraton of the tmer. Therefore, the tmer expres n a maxmum tme nanoseconds from when the call s made. When ths tmer expres, one of the last real-tme sgnals s sent and a functon called. Ths functon lowers the prorty of the thread and wats for a whle before restorng the ntal prorty of the thread usng the same method. When the prorty of the thread s low, the scheduler avods executng the thread and other threads can be processed. Thus we assure that the maxmum executon tme s the one of ths property for ths thread. Names. Property Actvate_Entrypont of a thread s the name of the C++ functon that contans the source code of that thread. Thus, ths s the name of the functon executed as a startng routne when creatng the thread. Source_Text of a thread s the name of the C++ fle contanng the source code of that thread. Intalze / Fnalze_Entrypont. The name of the routne called at the start/end of the start routne of the correspondng thread s derved from ths property. Intalze / Fnalze_Executon_Tme (mn, max). The mnmum tme causes the call to a functon that consumes that processng tme to assure that at least that tme s consumed. It checks the maxmum tme, to see f ths amount of tme has elapsed and return f t has been. The ssues related to the subprograms are the fo llo wng: Subprogram. An AADL subprogram component abstracton represents sequentally executable source text, a callable component, wth or wthout parameters, that operates on data or provdes server functons to components that call t. A routne s a porton of code wthn a larger program, whch performs a specfc task and s relatvely ndependent of the remanng code. An AADL subprogram translates nto a routne. Subprogram calls. In AADL there are two types of subprogram calls: Call sequences and remote calls. The local call from a thread or from another subprogram wthn the same thread to a subprogram s made n AADL through the sub-clause call and s translated nto drect calls from the thread start routne or from the routne respectvely. The remote clent-server call from a subprogram n a thread to another subprogram n another thread s made through the sub-clause call and the property Actual_Subprogram_Call. Ths remote call translates nto a call from one routne to another. Subprogram parameters. A parameter represents call and return data values or references to data passed nto and out of a subprogram, so t can be by value or by reference. In AADL the data values are n or out parameters and references are requres data access. Connectons must be establshed between the ports of the thread (or the subprogram) and the ports of the subprogram. The data type of the AADL out parameter, f any, determnes the data type of the routne; f there s no out parameter the type s vod. Thus, the AADL parameters translate nto parameters of the subprogram by value or reference. The translaton permts data exchange among subprograms. AADL data are managed as follows: Data type. The AADL data abstracton represents statc data and data types. Data component declaratons are used to represent: applcaton data types, the substructure of data types va data subcomponents wthn data mplementaton declaratons and data nstances. In general, a data type defnes a set of values and the allowable operatons on those values. Smple ndependent AADL data gves rse to a data type. These data types wll be used later to defne the type

8 28 Roberto Varona-Gómez et al.: Archtectural Optmzaton & Desgn of Embedded of a global varable, a message, etc. The name of the data type can be nferred from the name of the AADL data. Ths translaton takes nto account the property Source_Data_Sze. In the case of data types, t specfes the maxmum sze requred to hold a value of an nstance of the data type. Smple Data. A smple AADL data subcomponent of a thread or a process gves rse to a smple global varable. The name and type can be nferred from the name and the AADL data type. Composte Data. Composte AADL data are data that have one or more subprograms as features and/or one or more datum as subcomponents. These data generate a C++ class of data wth ts methods and/or member data. The name of the class can be nferred from the name of the AADL data. The names and types of the methods and members can be nferred from the AADL subprograms and data. The composte data subcomponents of a thread or a process gve rse to a global varable whose type s that class. The name can be nferred from the name of the AADL data. The AADL behavoural annex mproves the specfcaton of a component s behavour. AADS parses the AADL model so the annex behavour_specfcaton sectons are translated to an equvalent POSIX model. The behavoural annex descrbes a transton system (an extended automaton) usng optonal sectons: State varables. The state varables secton declares typed dentfers. Types are data classfers of the AADL model. AADS translates these state varables declarng varables wth ther correspondng type n the C++ source code of the thread or subprogram tself. Intalzaton. The state varables must be ntalzed n the ntalzaton secton usng a sequence of assgnments. AADS translates ths ntalzaton by nt alzng the varables wth ther correspondng value where they were declared. States The states secton declares automaton states whch can be qualfed as ntal, complete, return, urgent or composte. AADS uses ths secton to know whch states have been defned. Transtons The transtons secton defnes system transtons from a source state to a destnaton state. The transton can be guarded wth events or Boolean condtons. An acton part can be attached to the transton. It can perform subprogram calls, message sendng or assgnments. AADS translates the transtons secton nto swtch and case statements to transt from one state to another. It starts n the ntal state and moves to the next state when the guard of the transton s true. Thus the guard of the transton translated by AADS acts as a condton to execute the sentence/s of the state and to change the state. Ths sentence/s s the acton of the transton translated by AADS. If there s no guard there s no condton to check. The guard can be an expresson as smp le as on < 5, so AADS wll translate t d rect ly. Dependng on the content of the guard and the acton of the transton, AADS translates them nto the correspondng sentences of source code: Sendng / recevng messages. Messages are sent / receved through event or event data ports. If p s an nput port: p? de-queues an event port varable, p?x de-queues a datum on an event data port n the varable x. If p s an output port: p! calls Rase_Event on an event port, p!d wrtes data d n the event data port and calls Rase_Event. In the frst case the guard of a transton s p1?x (where p1 s an n event data port) and the acton of that transton s p2!(x+1) (where p2 s an out event data port). AADS translates ths case, checkng whether a varable arrves at the POSIX message queue assocated wth port p1. Then the varable s sent through the POSIX message queue assocated wth port p2, n ths case after addng 1 to t. In the second case the guard of a transton s p1? (p1 s an n event port) and the acton of that transton s p2! (p2 s an out event port). AADS translates ths case, checkng whether the correspondng POSIX sgnal assocated wth port p1 has been receved. Then the correspondng POSIX sgnal assocated wth port p2 s sent. Subprograms. A behavour expressed by the annex can be attached to a subprogram mplementaton. The behavour can refer to the subprogram parameters and to varables. The automaton specfyng the subprogram mplementaton has one or more return states ndcatng the return to the caller. Whle the AADL control flows defne the call sequences produced by a subprogram, the annex enables the expresson of dependences between the control flows and state varables or parameters. A subprogram specfcaton can express other calls or notfcaton of events. In the frst case the guard of a transton s p1? (p1 s an n event port) and the acton of that transton s subp! (subp s a subprogram). AADS translates ths case checkng whether the correspondng POSIX sgnal assocated wth port p1 has been receved. If the sgnal has been receved then the correspondng prevously defned subprogram s called. Parameters can be passed to called subprograms. The acton of that transton could be subp!(5->x,2->y) where x and y are two n parameters of the subprogram subp. Then AADS translates t nto a call to the subprogram wth those two parameters as subp(5,2). Usng the AADL behavoural annex, t s possble to ndcate n the acton of a transton that the out parameter of a subprogram s the n parameter modfed n some way. It could be po!(p+1), where po s the out parameter and p the n parameter. AADS translates ths case, creatng the source code n the subprogram that sums one to the n parameter and assgns the result to the out parameter. In the last case the guard of a transton s on p (p s an n parameter of a subprogram) and the acton of that transton s a call to a standard functon such as std::cout!. To translate ths transton AADS generates the C++ source code that checks whether the n parameter s true and, f t s, calls the standard functon cout.

9 Amercan Journal of Computer Archtecture 2012, 1(2): Control structures. Control structures support condtonal executon of alternatve actons (f, else, end f), condtonal repetton of actons (whle), and applcaton of actons over all elements of a data component array, port queue content, or nteger range (for). The For structure represents an ordered teraton over all elements. Wthn for structures the element can be referenced by element_varable_dentfer, whch acts as a local varable wth the name scope of for structure. In the case that the acton of a transton contans a condtonal structure of the type: f (logcal value expresson) behavour_actons[else behavour_actons] end f, AADS translates t producng the source code wth the analogous f else structure n C++, adaptng the dfferences between them. The same can be sad about for and whle structures of the type: for (element varable dentfer n values) {behavour_actons} and whle (logcal value expresson) {behavour_actons}. AADS translates them producng the source code wth the analogous for and whle structure n C++, adaptng the dfferences between them. Arrays. To declare collectons of data whch are consdered to be ordered the noton of multplcty s used. AADS translates multplcty nto a C++ array of data. The type of the array s the same n both AADL and C++. The HW archtecture s structured through the XML fle generated by AADS. It s used as part of the confguraton parameters of SCoPE and s dvded nto: HW_Platform, SW_Platform and Applcaton. HW_Platform. Any AADL mplementaton of a processor, memory, bus or devce must be specfed wth ts category and name n the HW_Components subsecton of HW_Platform. The AADL property Assgn_Byte_Tme s used to set the frequency parameter n the XML fle. For memores we use the propertes Read_Tme and Wrte_Tme. These propertes have ther values n tme unts (ns, ms and so on) and must be transformed nto MHz. To know the mem_sze of a memory, both Word_Count and Word_Sze AADL propertes are requred. Fnally the mem_type of a memory s derved from Memory_Protocol n the AADL model. If the component s a processor, proc_type must be specfed. The HW_Archtecture and Computng_groups subsectons of HW_Platform are next n the XML fle. To know the start_addr of a memory we take the AADL property Base_Address. The component and name are nferred from the AADL model. HW components are grouped by buses as they are connected to them n AADL through the connectons bus access and the features requred bus access. SW_Platform. Ths secton has two subsectons: SW_Components and SW_Archtecture. Ths secton takes nto account the buses that are defned to make the equvalent nodes. In ths secton the operatng systems are specfed. Applcaton. Ths secton has two subsectons: Functonalty and Allocaton. Fllng the Functonalty secton s straghtforward from the AADL model usng the property of a thread Actvate_Entrypont for the functon and Source_Text for the fle. The name s the same as the one of the thread. For the Allocaton secton we need to know the property of a thread Actual_Processor_Bndng, and fnd out whch bus the processor s bound to and then fnd out whch node that bus corresponds to. The AADL name of the thread s used for the name and the component. 6. AADS-T AADS-T s a verson of AADS that admts AADL models that nclude the AADL Behavoural Annex and generates a source code compatble wth the Ravenscar Computatonal Model. The real-tme behavour specfcaton of ASSERT models s based on the RCM, a model of concurrency for hgh-ntegrty systems that enables formal analyss of the temporal propertes of a system usng response-tme analyss technques. The model ncludes a statc set of concurrent threads of executon, communcatng by means of shared protected data wth mutually exclusve read and wrte access, and a restrcted form of condtonal synchronzaton. The model s smple enough to be mplemented by a smple, s mall-sze real-tme kernel, thus easng the way to the eventual certfcaton of real-tme systems based on t. Twelve propertes must be fulflled to be RCM-complant; the source code generated by AADS-T obeys all of them. These propertes are stated n an nternal document of the project ttled R1-4 Evaluaton of Complance wth the ASSERT Process, wrtten by J. A. de la Puente and J. Zamorano. Basc elements. There are two man elements n the RCM: Threads and protected objects (PO). A thread s the basc unt of executon, whch can be executed concurrently wth other threads on a sngle processor. POs are an abstracton of shared data, synchronzaton, and nterrupt handlng. There are a statc number of threads and POs. Therefore, threads and POs can only be created at system ntalzaton tme. RCM 1 A real-tme system conssts of: A statc set of N threads, T = { t }, 1..N; and a statc set of M POs, O = { q }, 1..M. The set O may be empty (M = 0), n whch case the system s sad to have only ndependent threads. In the source code generated by AADS-T all the threads and POs are created callng pthread_create and as objects of the correspondng classes respectvely at system ntalzaton tme. Propertes of threads. A thread s a concurrent unt of executon wth the followng propertes: RCM 2 Threads are non-termnatng. They exhbt an endless repettve behavour, alternatng between the followng states (see Fgure 5): Suspended (a suspended

10 30 Roberto Varona-Gómez et al.: Archtectural Optmzaton & Desgn of Embedded thread s not elgble for executon) and Ready (a ready task can be executed when the processor s allocated to t). F gure 5. States of RCM threads RCM 3 Threads have a sngle actvaton pont. An actvaton pont s a pont n the executable code of a thread at whch ts state changes from Suspended to Ready. When actvated, a thread becomes ready and then executes a pece of sequental code (thread actvty), after whch t becomes suspended awatng the next actvaton. Threads of the source code generated by AADS-T use whle(true) to be non-termnatng. They are suspended after executng the sequental code n a clock_nanosleep and when sleepng tme has passed they become ready at ther sngle actvaton pont. RCM 4 The actvty of a thread s a sequence of code wth a bounded and known worst-case executon tme (WCET). The W CET of thread t s C. AADS-T utlzes the AADL property Compute_Executon_Tme to know the WCET of a thread. The source code generated checks that ths WCET s not exceeded. Ths property mples that a thread does not execute any operaton that could result n ts becomng suspended other than the suspenson mmedately before the actvaton pont, and nether do the threads created by AADS-T. RCM 5 A thread can be actvated only by one of the followng two knds of events. One s by a tmng event whch s ssued perodcally by the envronment. In ths case the thread s sad to be perodc or tme-drven wth T t perod. The other s a synchronzaton event ssued when the barrer of a synchronzaton PO s opened (see RCM 8 below). In ths case, the thread t s sad to be sporadc. The synchronzaton event must have a mnmum nter-arrval tme assocated to t,.e. a mnmum elapsed tme nterval between two consecutve occurrences of the event, T. AADS-T uses the AADL propertes Perod and Devce_Dspatch_Protocol to know the perod and the type of a thread respectvely. It accepts only perodc and sporadc threads and not aperodc or background threads. The dfference between the codes generated s that a sporadc thread wats for an event from an event or eventdata port connecton after nvokng a synchronzaton operaton n the actvaton pont. In both cases clock_nanosleep wats a tme. T Propertes of protected objects. A PO s an object whch encapsulates a set of data and a set of assocated operatons (protected operatons). The value of the data makes up the state of the object. The state can only be read or changed by nvokng one of the operatons of the PO. If q s a PO: q.s denotes ts state, q.s S, where S s an approprate data doman; q. Pk denotes the k -th operaton of q. Notce that a PO must have at least one operaton; otherwse ts state s naccessble. The notaton t f q wll be used to denote that t nvokes one or more operatons of q. Smlarly, t f q. P means that t calls the operaton q. P. AADS-T generates an object of the correspondng class whch s a PO n the source code for each AADL data, event and eventdata port connecton. Classes generated by AADS-T have the approprate data members to acheve the communcaton of data and/or events between threads. Each class has a constructor and member functons read and wrte to ntalze and access data members. POs have the followng propertes: RCM 6 Only one thread can be executng an operaton of a gven PO at any gven tme,.e. protected operatons are mutually exclusve. Consequently, f a thread nvokes a protected operaton at a tme when another thread s already executng an operaton of the same object, t has to wat. When the protected operaton that was beng executed s completed, the watng thread s allowed to execute the operaton t had nvoked. Notce that a thread that s watng to begn a protected operaton s not consdered to be suspended. In consequence, a thread actvty can nvoke protected operatons wthout volatng RCM 4. Each class produced by AADS-T defnes a mutex that s locked when a member functon s called and unlocked when t ends, ensurng complance wth mutual excluson. RCM 7 All protected operatons have a bounded and known WCET. The WCET of the protected operaton. P k s C, k. Agan, ths property mples that no operatons that could result n a thread beng suspended can be nvoked from a protected operaton. AADS-T uses the ad hoc defned AADL propertes PO_read_WCET and PO_wrte_WCET for each port connecton to know the WCET of each member functon. The source code generated checks f these WCETs are exceeded. Moreover, no member functon calls any suspendng operaton. RCM 8 A PO can have at most one synchronzaton operaton that has an assocated barrer, whch s a Boolean varable that s part of the object state. When the value of the barrer s true, the barrer s sad to be open, and otherwse t s sad to be closed. The behavour assocated wth synchronzed operatons s as follows: When a thread nvokes a synchronzaton operaton, f the barrer s open the executon proceeds as wth an ordnary protected operaton; but f the barrer s closed, the thread s suspended. At most one thread can be q

11 Amercan Journal of Computer Archtecture 2012, 1(2): suspended at a barrer at any gven tme. A thread that s suspended at a barrer s resumed whenever the barrer becomes true (as the result of the executon of another protected operaton by some other thread). Invokng a synchronzaton operaton s a potentally suspendng operaton, and thus cannot be done wthn a thread actvty; ths can only be used to mplement the actvaton events of sporadc threads. In the source code produced by AADS-T only the objects correspondng to event and eventdata port connectons have a synchronzaton member functon because a sporadc thread s dspatched by an event as stated above. Only sporadc threads nvoke the synchronzaton. The barrer s ntalzed as false n the constructor, then set to true n the wrte member functon, then checked to see whether t s false n the synchronzaton to suspend the thread on a nanosleep, and fnally set to false after resumng t. Schedulng. The RCM s assocated wth an nstance of the fxed-prorty pre-emptve schedulng (FPPS) method, together wth the mmedate celng prorty nhertance protocol (ICPP). The schedulng model s defned by the followng propertes: RCM 9 Each thread t has a basc prorty, P P Z, where Z s the set of the nteger numbers. The basc prorty of a thread s fxed,.e. t s never changed. AADS-T uses the ad hoc AADL property Prorty to create a thread at system ntalzaton tme wth sched_prorty at that prorty, whch s never changed. RCM 10 Each PO q has a celng prorty CP whch s the maxmum of the basc prortes of all the threads nvokng any of ts operatons: CP =ma x Pj,t j f q. As basc prortes of all threads are fxed, so too are the celng prortes of all POs. RCM 11 At every nstant of tme, each thread has an actve prorty. The actve prorty of a thread s the maxmum of the basc prorty of the thread and the celng prorty of all POs that contan an operaton that s currently beng executed by the thread. Therefore, whenever a thread nvokes a protected operaton, t mmedately nherts the celng prorty of the enclosng PO. In the source code generated by AADS-T the functon pthread_mutexattr_setprotocol s used wth the value PTHREAD_PRIO_PROTECT and the functon pthread_mutexattr_setprocelng wth the maxmum of the prortes of the two threads communcatng through a port connecton. Ths s done when ntalzng the mutex of the object correspondng to that connecton at system ntalzaton tme guaranteeng the fulfllment of RCM 10 and RCM 11. RCM 12 Ready threads are conceptually grouped nto ready queues. There s a ready queue for each prorty level n P. Threads are added to and removed from prorty queues accordng to the followng rules: When a suspended thread becomes ready, t s added at the tal of the prorty queue for ts actve prorty. When the processor s dle, the thread whch s at the head of the non-empty ready queue wth the hghest prorty s dspatched for executon and removed from the queue. Whenever there s a non-empty ready queue wth a hgher prorty than the prorty of the currently runnng thread, the thread s pre-empted from the processor and t s added at the head of the ready queue for ts actve prorty. Notce that accordng to the prevous rule, the thread at the head of the ready queue that caused the pre-empton s dspatched for executon mmedately afterwards. AADS-T admts only SCHED_FIFO for the ad hoc AADL property POSIX_Schedulng_Polcy of a thread, to set so sched_polcy n the source code. The above model specfes a concurrent system wth a predctable, analyzable temporal behavour. Snce the executon tme of threads s bounded (RCM 4, RCM 7) and the schedulng method s FPPS wth ICPP, well-known response-tme analyss technques can be appled to statcally guarantee that the system satsfes ts temporal requrements. 7. Expermental Results 7.1. Case Study The proposed method mplemented n AADS-T was tested assstng n the HW/SW parttonng of the case study shown n Fgure 6. It s a space applcaton of dgtal mage processng that conssts of dfferent components: HW Controller, Image Processng, Image Flter, Control, Start-up, Housekeepng, Montorng, Image Processng Management, Event Generaton, Connecton test and Stub Smulatng Ground. HW Controller s n charge of recevng mages (btmap mages) from the Camera Smulator as well as sendng the fltered mages back to Ground. Image Processng receves the mage from HW Controller pxel by pxel, ncludng the paddng when t s needed, forwardng them to Image Flter to process them. Image Processng also receves the pxels already fltered by Image Flter whch are subsequently sent to the HW Controller component. Image Flter s n charge of flterng the pxels receved accordng to the flter selected. Control manages the Image Applcaton Software based on OBSW commands n order to store mage statstcs, to confgure mage flterng functon and to control the mage processng status. Start-up smulates the ntalzaton routne and starts the next OBSW functonalt es. Housekeepng perodcally reports the number of mages correctly fltered. Montorng checks the status of the Image Processng Applcaton Software and f the status s set to erroneous, an event s sent to Stub Smulatng Ground through Event Generaton. Image Processng Management selects the flter to be appled and starts/stops the applcaton. Event Generaton smulates the OBSW event reportng servce to nform ground about all asynchronous events occurrng on-board. Connecton test

12 32 Roberto Varona-Gómez et al.: Archtectural Optmzaton & Desgn of Embedded lets operators test the OBSW applcaton presence and state. Stub Smulatng Ground requests the OBSW to perform the alve-test by sendng the correspondng telecommand. Fgure 7 s the AADL graphcal notaton of the Case study wth the memores (two DRAMs, one for the FPGA and another for the LEON2), processors (FPGA and LEON2), buses (RS232, FPGA memory bus, and LEON2 memory bus), threads, event ports and eventdata ports generated wth OSATE v AADL provdes many benefts for HW/SW co-desgn. It contans constructs for modelng both HW and SW components. Ths language supports early and repeated analyses of system archtecture wth respect to performance-crtcal propertes through an extendable notaton, a tool framework and precsely defned semantcs. F gure 6. Case study functonal descrpton F gure 7. AADL graphcal notaton of the Case study

13 Amercan Journal of Computer Archtecture 2012, 1(2): AADS extracts from the AADL models the necessary nformaton for the SCoPE tool to perform a smulaton at system level. The smulaton results wll gude the system desgner through the selecton of the most adequate partton soluton LEON2 Modellng n SCoPE SCoPE has been modfed to nclude the LEON2 processor at 50 Mhz, 15.4 MIPS and nj of energy consumed per nstructon n ts processors.xml confguraton fle. It was necessary to specfy the data and nstructon cache szes too. A sze of 8192, a sze of lne of 8 and an assocatvty of 1, consderng an nstructon sze of 4 (32 bts), was consdered for both. Another confguraton fle of SCoPE, memnst.xml, was modfed to nclude the operaton codes of the LEON2. The GNU cross-compler for LEON2 used s the GNAT for the LEON C compler so the source code produced by AADS-T has to comply wth certan characterstcs. The optons POSIX_THREADS, POSIX_THREAD_PRIORITY_ SCHEDULING, POSIX_THREAD_PRIO_PROTECT, LEO N_2 and POSIX_TIMERS have to be actvated. The functon clock_nanosleep must be explctly declared Archtectural Desgn The parttonng process s performed followng a SW centrc approach. Frstly, t s assumed that all system functons are SW components. If ths assumpton s not fulflled due to the volaton of the desgn crtera, new parttons are proposed n order to accommodate system functons to other platform resources. In ths case, dfferent allocatons of system functons to platform resources are possble. The decson about whch parts are mapped to HW s based on the analyss of whch mplementaton best meets the desgn crtera (derved from the requrement analyss results) n terms of performance and functonal behavor. The nformaton about how a component wll be mplemented (HW or SW) s added as an AADL property, Actual_Processor_Bndng. The parttonng s generated by the ASSERT Model Transformaton (AMT) tool developed by GMV. In the context of a SW centrc approach, ntally all system functons wll be mapped onto the same processng node, whose mp lementaton s a LEON2 mcroprocessor. We consdered a stuaton where t s necessary to re-allocate system functons from SW to HW (.e. mappng from processng elements whose technologcal mplementaton s a mcroprocessor to other processng elements such as DSP, PLD, FPGA, etc): The system performance mght ndcate that the CPU exceeds the maxmum performance lmts mposed n the requrements. HW/SW models were generated n AADL by AMT and n SystemC wth AADS-T/SCoPE, to perform the HW/SW parttonng. The system-level performance tool (AADS-T/SCoPE) was used to analyze the system performance and non-functonal requrements such as use of CPU, tmng or energy consumpton for a gven HW/SW partton. After system performance analyss, some HW/SW parttons were proposed and evaluated. The fles produced by AADS-T were compled wth SCoPE to smulate the model and the results obtaned were used to compare the dfferent parttons. The smulaton executed the source code of the threads and the protected objects enabled communcaton among the threads. In the followng table we can see the comparson between the sxteen magntudes evaluated by SCoPE n the average of the smulatons carred out wth ffty-sx evaluated parttons, and the one whch allocates the components Control and Image_processng to HW. In nearly all the magntudes the selected partton obtans the best performance results. Table 1. Comparson between smulatons' metrcs of the selected partton and the average of the others Control & Average of other Tot al User t me I P s s Total Kernel s s Number of h d h Runnng tme ns ns Use of CP U % % Instructons Instructon cache d Core Energy e+08 nj E+09 nj Core Power mw mw Instructon cache E+08 nj E+09 nj Instructon cache mw mw Bus access t me ns ns Idle t me ns ns Number of Instructon mss Bus Load bytes bytes In the followng fgure we can see one magntude (Use of CPU fro m a total of sxteen magntudes evaluated by SCoPE) of the smulatons carred out wth SCoPE wth the ffty-seven evaluated parttons. Among all the parttons, one obtans the best performance results and so t s selected; the one that allocates to HW the components Control and Image Processng because they consume most of the resources. In the fgure frst we can see the parttons that allocate one component to HW, then we can see the parttons that allocate two or more components to HW. Allocatng only one component to HW was not enough to fulfl the ntal constrant as we wll see below, so more than one component had to be allocated to HW. However we had to take nto account that allocatng to HW s more expensve than allocatng to SW so we could not allocate all the components to HW. We had to mantan a trade-off between the cost of allocatng all the components to HW and the use of CPU caused by allocatng the components to SW.

14 34 Roberto Varona-Gómez et al.: Archtectural Optmzaton & Desgn of Embedded F gure 8. Use of CP U (%) of the parttons In order to check how the performance analyss results vary dependng on the WCET, the AADL model was manually modfed settng very strct WCET (close to the deadlnes). In ths case study the deadlnes of the threads were 20 % of the perods. So the WCET were 20 % of the values from the nterval of 40 ms to 100 s whch were the mnmum and the maxmum perods respectvely for the dfferent threads. Regardng only the Use of CPU, the ntal partton whch consders that all components were allocated to SW consumed % wth the ntal WCET values. Ho wever wth the WCET close to the deadlnes, the Use of CPU had a sgnfcant ncrease up to