embedded systems specification and design languages外语英文电子书

《embedded systems specification and design languages外语英文电子书》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

EmbeddedSystemsSpecificationandDesignLanguagesSelectedcontributionsfromFDL’07 LectureNotesinElectricalEngineeringEmbeddedSystemsSpecificationandDesignLanguagesVillar,Eugenio(Ed.)2008,Approx.400p.,HardcoverISBN:978-1-4020-8296-2,Vol.10ContentDeliveryNetworksBuyya,Rajkumar;Pathan,Mukaddim;Vakali,Athena(Eds.)2008,Approx.400p.,HardcoverISBN:978-3-540-77886-8,Vol.9UnifyingPerspectivesinComputationalandRobotVisionKragic,Danica;Kyrki,Ville(Eds.)2008,28illus.,HardcoverISBN:978-0-387-75521-2,Vol.8SensorandAd-HocNetworksMakki,S.K.;Li,X.-Y.;Pissinou,N.;Makki,S.;Karimi,M.;Makki,K.(Eds.)2008,Approx.350p.20illus.,HardcoverISBN:978-0-387-77319-3,Vol.7TrendsinIntelligentSystemsandComputerEngineeringCastillo,Oscar;Xu,Li;Ao,Sio-Iong(Eds.)2008,Approx.750p.,HardcoverISBN:978-0-387-74934-1,Vol.6AdvancesinIndustrialEngineeringandOperationsResearchChan,AlanH.S.;Ao,Sio-Iong(Eds.)2008,XXVIII,500p.,HardcoverISBN:978-0-387-74903-7,Vol.5AdvancesinCommunicationSystemsandElectricalEngineeringHuang,Xu;Chen,Yuh-Shyan;Ao,Sio-Iong(Eds.)2008,V,615p.,HardcoverISBN:978-0-387-74937-2,Vol.4DigitalNoiseMonitoringofDefectOriginAlievT.2007,XIV,223p.15illus.,HardcoverISBN:978-0-387-71753-1,Vol.2Multi-CarrierSpreadSpectrum2007Plass,S.;Dammann,A.;Kaiser,S.;Fazel,K.(Eds.)2007,X,106p.,HardcoverISBN:978-1-4020-6128-8,Vol.1 EugenioVillarEditorEmbeddedSystemsSpecificationandDesignLanguagesSelectedcontributionsfromFDL’07 EditorProf.EugenioVillarUniversityofCantabriaSpainSeriesEditorsSio-IongAoLiXuIAENGSecretariatZhejiangUniversity37–39HungToRoadCollegeofElectricalEngineeringUnit1,1/FDepartmentofSystemsScience&HongKongEngineeringPeople’sRepublicofChinaYu-QuanCampus310027HangzhouPeople’sRepublicofChinaISBN978-1-4020-8296-2e-ISBN978-1-4020-8297-9LibraryofCongressControlNumber:2008921989©2008SpringerScience+BusinessMedia,B.V.Nopartofthisworkmaybereproduced,storedinaretrievalsystem,ortransmittedinanyformorbyanymeans,electronic,mechanical,photocopying,microfilming,recordingorotherwise,withoutwrittenpermissionfromthePublisher,withtheexceptionofanymaterialsuppliedspecificallyforthepurposeofbeingenteredandexecutedonacomputersystem,forexclusiveusebythepurchaserofthework.Printedonacid-freepaper987654321springer.com PrefaceFDListhepremierEuropeanforumtopresentresearchresults,toexchangeexperiences,andtolearnaboutnewtrendsintheapplicationofspecificationanddesignlanguagesaswellasofassociateddesignandmodelingmethodsandtoolsforcomplex,heterogeneousHW/SWembeddedsystems.Modelingandspecificationconceptspushthedevelopmentofnewmethodologiesfordesignandverificationtosystemlevel;thusprovidingthemeansformodeldrivendesignofcomplexinformationprocessingsystemsinavarietyofapplicationdomains.TheaimofFDListocoverseveralrelatedthematicareasandtogiveanopportunitytogainup-to-dateknowledgeinthisfastevolving,essentialareainsystemdesignandverification.FDL’07wasthetenthofaseriesofsuccessfuleventsthatwereheldinLausanne,Lyon,Tübingen,Marseille,FrankfurtamMain,LilleandDarmstad.FDL’07washeldbetweenSeptember18and20,2007atthe‘CasadeConvalescència’,themainCongressfacilitiesofthe‘UniversitatAutònomadeBarcelona’inthecitycenterofBarcelona,thecapitalcityofCatalonia,Spain.ThehighnumberofsubmissionstotheconferencethisyearallowedtheProgramCommitteetoprepareahighqualityconferenceprogram.Thebookincludesaselectionofthemostrelevantcontributionsbasedonthereviewmadebytheprogramcommitteemembersandthequalityofthecontentsofthepresentationattheconference.Theoriginalcontentofeachpaperhasbeenrevisedandimprovedbytheauthorsfollowingthecommentsmadebythereviewers.FDL’07wasorganizedagainaroundfourthematicareas(TA)thatcoveressentialaspectsofsystem-leveldesignmethodsandtools.Thebookfollowsthesamestructure:PartI,C/C++BasedSystemDesign,containssevenchapterscoveringacomparisonbetweenEsterelandSystemC,modelingofasynchronouscircuits,TLMbusmodels,SystemCdebugging,qualityanalysisofSystemCtestbenchesandSystemCsimulationofacustomconfigurablearchitecture.PartII,Analog,Mixed-Signal,andHeterogeneousSystemDesign,includesthreechaptersaddressingheterogeneous,mixed-signalmodeling,extensionstoVHDL-AMSforpartialdifferentialequationsandmodelingofconfigurableCMOStransistors.v viPrefacePartIII,UML-BasedSystemSpecificationandDesign,presentssixcontributionscomparingAADLwithMARTE,modelingreal-timeresources,proposingmodeltrans-formationstosynchronouslanguages,mappingUMLtoSystemC,definingaSystemCUMLprofilewithdynamicfeaturesandgeneratingSystemCfromStateCharts.PartIV,FormalismsforProperty-DrivenDesign,iscomposedofthreechapterspresentingmethodsformonitoringlogicalandtemporalassertions,fortransactor-basedformalverificationandacasestudyinproperty-basedsynthesis.Thecollectionofcontributionstothebookprovidesanexcellentoverviewofthelatestresearchcontributionstotheapplicationoflanguagestothespecification,designandverificationofcomplexEmbeddedSystems.ThepaperscoverthemostimportantaspectsinthisessentialareainEmbeddedSystemsdesign.Iwouldliketotakethisopportunitytothankthememberoftheprogramcom-mitteewhomadeatremendouseffortinrevisingandselectingthebestpapersfortheconferenceandthemostoutstandingamongthemforthisbook.Specially,thefourTopicChairs,FrankOppenheimerfromOFFIS,responsibleofC/C++BasedSystemDesign,SorinHussfromTUDarmstad,responsibleofAnalog,Mixed-Signal,andHeterogeneousSystemDesign,PierreBouletfromLilleUniversity,responsibleofUML-BasedSystemSpecificationandDesignandDominiqueBorrionefromTIMA,responsibleofFormalismsforProperty-DrivenDesign.Iwouldliketothankalsoalltheauthorsfortheextraworkmadeinrevisingandimprovingtheircontributionstothebook.TheobjectiveofthebookistoserveasareferencetextforresearchersanddesignersinterestedintheextensionandimprovementoftheapplicationofdesignandverificationlanguagesintheareaofEmbeddedSystems.EugenioVillarFDL’07GeneralChairUniversityofCantabria ContentsPartIC/C++BasedSystemDesign1HowDifferentAreEsterelandSystemC........................3JensBrandtandKlausSchneider2TimedAsynchronousCircuitsModelingandValidationUsingSystemC..............................................15CédricKoch-HoferandMarcRenaudin3OnConstructionofCycleApproximateBusTLMs...............31MartinRadetzkiandRaufSalimiKhaligh4CombinatorialDependenciesinTransactionLevelModels.........45RobertGuenzel,WolfgangKlingauf,andJamesAldis5AnIntegratedSystemCDebuggingEnvironment.................59FrankRogin,ChristianGenz,RolfDrechsler,andSteffenRülke6MeasuringtheQualityofaSystemCTestbenchbyUsingCodeCoverageTechniques...........................73DanielGroße,HernanPeraza,WolfgangKlingauf,andRolfDrechsler7SystemC-BasedSimulationoftheMICASArchitecture............87DragosTruscan,KimSandström,JohanLilius,andIvanPorresPartIIAnalog,Mixed-Signal,andHeterogeneousSystemDesign8HeterogeneousSpecificationwithHetSCandSystemC-AMS:WideningtheSupportofMoCsinSystemC......................107F.Herrera,E.Villar,C.Grimm,M.Damm,andJ.Haasevii viiiContents9AnExtensiontoVHDL-AMSforAMSSystemswithPartialDifferentialEquations.......................................123LeranWang,ChenxuZhao,andTomJ.Kazmierski10Mixed-LevelModelingUsingConfigurableMOSTransistorModels..........................................137JürgenWeber,AndreasLemke,AndreasLehmler,MarioAnton,andSorinA.HussPartIIIUML-BasedSystemSpecificationandDesign11ModelingAADLDataCommunicationswithUMLMARTE......155CharlesAndré,FrédéricMallet,andRobertdeSimone12SoftwareReal-TimeResourceModeling........................169FrédéricThomas,SébastienGérard,JérômeDelatour,andFrançoisTerrier13ModelTransformationsfromaDataParallelFormalismTowardsSynchronousLanguages.............................183HuafengYu,AbdoulayeGamatié,EricRutten,andJean-LucDekeyser14UMLandSystemC–AComparisonandMappingRulesforAutomaticCodeGeneration...............................199PerAnderssonandMartinHöst15AnEnhancedSystemCUMLProfileforModelingatTransaction-Level........................................211S.Bocchio,E.Riccobene,A.Rosti,andP.Scandurra16SC2StateChartstoSystemC:AutomaticExecutableModelsGeneration.........................................227MarcelloMuraandMarcoPaolieriPartIVFormalismsforProperty-DrivenDesign17AsynchronousOn-LineMonitoringofLogicalandTemporalAssertions....................................243K.Morin-Allory,L.Fesquet,B.Roustan,andD.Borrione Contentsix18Transactor-BasedFormalVerificationofReal-TimeEmbeddedSystems.........................................255D.Karlsson,P.Eles,andZ.Peng19ACase-StudyinProperty-BasedSynthesis:GeneratingaCacheControllerfromaProperty-Set........................271MartinSchickel,MartinOberkönig,MartinSchweikert,andHansEveking Chapter1HowDifferentAreEsterelandSystemCJensBrandt1andKlausSchneider2AbstractInthispaper,wecomparetheunderlyingmodelsofcomputationofthesystemdescriptionlanguagesSystemCandEsterel.Althoughtheselanguageshavearatherdifferentorigin,weshowthattheexecution/simulationofprogramswrittenintheselanguagesconsistsofmanycorrespondingcomputationsteps.Asaconse-quence,weidentifydifferentclassesofEsterelprogramsthatcanbeeasilytranslatedtoSystemCprocessesandviceversa.Moreover,weidentifyconceptslikepreemp-tioninEsterelthataredifficulttoimplementinastructuredwayinSystemC.KeywordsSynchronousLanguages,SystemC,ModelsofComputation1.1IntroductionSystemdescriptionlanguageslikeSystemC[11,13]andsynchronouslanguages[1,8]likeEsterel[2,4,5,12]arebecomingmoreandmorepopularfortheeffi-cientdevelopmentofmodernhardware-softwaresystems.Thecommongoaloftheselanguagesistoestablishamodel-baseddesignflow,wheredifferentdesigntaskslikesimulation,verificationandcodegeneration(forbothhardwareandsoftware)canbeperformedonthebasisofasinglesystemdescription.WhiletheoverallgoalofSystemCandEsterelisthereforethesame,therearemanydifferencesbetweentheselanguages.Inparticular,theselanguageshavedifferentunderlyingmodelsofcomputation.Asasynchronouslanguage,theexecutionofanEsterelprogramisdividedintomacrostepsthatcorrespondwithsinglereactionsthataretriggeredbyacommonclockofahardwarecircuit.Eachmacrostepisdividedintofinitelymanymicro-stepsthatareallexecutedinzerotimeandwithinthesamevariableenvironment.1EmbeddedSystemsGroup,UniversityofKaiserslautern,Email:brandt@informatik.uni-kl.de2EmbeddedSystemsGroup,UniversityofKaiserslautern,Email:klaus.schneider@informatik.uni-kl.deE.Villar(ed.)EmbeddedSystemsSpecificationandDesignLanguages,3©SpringerScience+BusinessMediaB.V.2008 4J.Brandt,K.SchneiderHence,theexecutionofEsterelprogramsaredriveninacycle-basedfashion.Duetotheinstantaneousreactionofmicrosteps,causalityproblemsmayoccurifactionsmodifyvariableswhosevaluesareresponsiblefortriggeringtheaction.Inordertoanalyzethecausalityofprograms,afixpointiterationmaybeperformedtocom-putethereactionofamacrostep.Itiswell-knownthatthisfixpointiterationistheternarysimulation[6]ofthecorrespondinghardwarecircuits.However,ithastoberemarkedthatEsterelcompilersusuallyperformthisfixpointanalysisatcompiletime,sothat(1)moreefficientcodeisgeneratedand(2)itisknownatcompiletimethattheiterationfinallyterminateswithknownvalues.SystemCfollowsthediscrete-eventsemanticsthatarewell-knownfromhard-waredescriptionlanguageslikeVHDL[9]andVerilog[10].ASystemCprogramconsistsofasetofprocessesthatruninparallel.SystemCdistinguishestherebybetweenthreeclassesofprocesses,namely‘methods’,asynchronousprocessesandsynchronousprocesses.Methodsarespecialcasesofasynchronousprocessesthatdonothavewaitstatements.Asynchronousprocessesaretriggeredbyevents,i.e.,bychangesofthevariablesonwhichtheprocessdepends,andtheyareexecutedaslongasvariablechangesareseen.Forthisreason,theexecutionoftheasynchro-nousprocessesisalsoafixpointcomputationthatterminatesassoonasafixpointofthevariables’valuesisfound.Afterthis,thesynchronousprocessesareexecutedoncetocompletethesimulationcycle.Ascanalreadybeseenfromtheabovecoarsedescription,theexecutionofsyn-chronouslanguageslikeEsterelandSystemChavemoreincommonasmayhavebeenexpectedifonlytheirmainparadigmswereconsidered.Clearly,therearealsomanydifferencesbetweentheselanguages:●ThesemanticsofEsterelisgiveninformofaveryconcisestructuraloperationalsemanticsthatcanbedirectlyusedasspecificationofasimulator.Incontrast,thesemanticsofSystemCisonlygivenintermsofnaturallanguage(exceptforsomeattemptslike[14,15,22]).●InEsterel,moststatementsarereducedtoasmallcorelanguageforwhichhard-wareandsoftwaregenerationisavailable.Nosignificantblow-upisobtainedbythisreduction(thisisduetotheso-calledwrite-things-once-principle).Incon-trast,SystemCisanextensionofC++byconstructsrequiredtodescribehard-waresystemslikebuilt-inconcurrency,wait/interruptmechanisms,andspecialdatatypeslikebitvectors.Asaconsequence,hardwaresynthesisisonlyavaila-bleforarathersmallsubsetofSystemC.●Esterelofferscomfortablepreemptionstatementsforabortingorsuspendingotherstatements.AfirstattempttowardspreemptionstatementswillbeobtainedbySystemC’swatchingstatement,thatdoeshowevernotyetreachthepowerofEsterel’sabortions.●Esterelhasspecialvariablesthatmodelevents.Thesevariablestakeadefaultvalueunlesstheyareassignedanothervalueinthecurrentmacrostep.●Esterelhasafullyorthogonalsetofstatements.Inparticular,concurrencyisanordinarystatementthatcanbecombinedwithallotherstatements,whileinSystemCprogramsconsistofasetofprocessesthatimplementsequentialcode. 1HowDifferentAreEsterelandSystemC5●SystemCoffersdifferentkindsofabstractionlevelslike‘untimedfunctional’,‘timedfunctional’,‘buscycle-accurate’,and‘cycle-accurate’modelingtosupportrefinementsfromtransactionlevelsdowntoregister-transferleveldescriptions.Hence,therearealsomanydifferencesbetweentheselanguages.Someofthesesdifferencemay,however,onlyexistinthecurrentversionsoftheselanguagesandmaydisappearinlaterversions.Inthispaper,weoutlinethedifferencesandsimilaritiesofsynchronouslanguageslikeEsterelandSystemC.Inparticular,wedefineclassesofsystemsthatcanbeeasilydescribedinbothlanguagesinawaythatallowsonetostructurallytranslatethesedescriptionsintoeachother.Thisistheresultofthesimilaritiesthatwehaveidentifiedbetweenthetwolanguages.Ontheotherhand,thedifferenceswewilloutlineinthefollowingmaybeinterestingforthosewhoworkonlaterversionsofbothlanguages.Withthispaper,wethereforehopetostimulatethediscussionbetweenthecommunitiesofSystemCandsynchronouslanguages.Therestofthepaperisorganizedasfollows:Inthenextsection,wedescribethelanguagesSystemCandEsterelinmoredetail.InSection1.3,wecomparetheexe-cutionofEsterelandSystemCprogramsinmoredetailandshowthattherearesomecorrespondences.Thesecorrespondencesgiverisetodefinesimpleclassesofprogramsthatcanbeeasilytranslatedbetweenbothlanguages.Inadditiontothis,welistdifferencesbetweenthetwolanguagesthatleadtoproblemsforthetransla-tionbetweenthelanguagesinSection1.4.Finally,weconcludewithashortsummaryinSection1.5.1.2EsterelandSystemCInthissection,wegivearoughoverviewofthemainconceptsandparadigmsofEsterelandSystemC.Section1.3outlinesthensomesimilaritiesbetweenthelan-guages,whileSection1.4outlinessomemajordifferences.1.2.1EsterelEsterel[2,4,5,12]isasynchronouslanguage[1,8]thatcanbeusedbothforhard-wareandsoftwaresynthesis.Asusualforsynchronouslanguages,thecomputationofanEsterelprogramisdividedintosinglereactions.Withineachreaction,newinputsarereadandnewoutputsaregeneratedfortheseinputswithrespecttothecurrentstateoftheprogram.Moreover,thereactiondeterminesthenextstateoftheprogramthatisusedinthenextreactionstep.Thestateoftheprogramisdeterminedbythecurrentvaluesofthevariablesandthecurrentsetofactivecontrolflowlocationsoftheprogram.Controlflowlocationsarestatementslikethepausestatementwherethecontrolflowmayrestforoneunitoftime. 6J.Brandt,K.SchneiderSinceEsterelstatementsincludetheparallelstatementS

S,itmaybethecasethat12thecontrolflowmayrestatseveralcontrolpointsatthesamepointoftime.Besidestheusualstatementslikeassignments,conditionals,sequencesandloops,Esterelprovidesalsomanystatementstoimplementcomplexconcurrentbehaviours.Inparticular,therearefourkindsofabortionstatementsthatrunsomeEsterelcodewhileobservinganabortionconditionineachmacrostep.Ifthecondi-tionholds,thenthecodeisabortedandtheabortionstatementterminates.OtherpreemptivestatementaresuspensionstatementsthatsuspendtheexecutionofanEsterelstatementifagivenconditionholdsinamacrostep.Itisveryimportantthatvariablesdonotchangeduringthemacrostep,i.e.,allmicrostepsareviewedtobeexecutedinzerotime.Therefore,allmicrostepsareexecutedatthesamepointoftimewiththesamevariableenvironment.Asaconsequence,thevaluesofthevariablesareuniquelydefinedineachmacrostep.Duetotheinstantaneousreaction,synchronousprogramsmaysufferfromcausalityconflicts[3,18,19].Thesecausalityconflictsoccurifanassignmentmodifiesthevalueofavariablethatisresponsiblefortheexecutionoftheassign-ment.Compilerscheckthecausalityofaprogramatcompiletimewithalgorithmsthatareessentiallythesameasthoseusedforcheckingthespeedindependenceofasynchronouscircuitsviaternarysimulation[6].Thesealgorithmsessentiallyconsistofafixpointcomputationthatstartswithunknownvaluesfortheoutputvariables,andsuccessivelyreplacestheseunknownvaluesbyknownones.Whilethisanalysisisusuallydoneatcompiletime,weconsiderthisfixpointiterationinthefollowingasbeingpartoftheexecutionthatisperformedwithinamacrostep.ThisisdonetooutlinesimilaritiestotheexecutionofSystemCprograms.Severalgenerationsofcompilationtechniques[7,20,24]havebeendevelopedforEsterelthatcanbeusedtogeneratehardwarecircuitsatthegatelevelaswellassoftwareinsequentialprogramminglanguagesfromthesameEsterelprogram.Moreover,someofthesecompilationtechniqueshavealreadybeenformallyverified[16,17].1.2.2SystemCSystemCisalanguageusedforthesimulationofcomplexhardwaresoftwaresys-tems.SystemCsimulationsmayrunupto1,000timesfasterthancorrespondingdescriptionsgiveninhardwaredescriptionlanguageslikeVHDLandVerilogduetothehigherlevelofabstractionthatisusedinSystemC.SystemCsupportsseverallevelsofabstractions,whichallowsonetodescribecompletelyuntimedsystemsdowntocycle-accuratedescriptionsofhardwarecircuitsatthegatelevel.SystemCisnotaself-containedlanguage;instead,itisaclasslibraryforthewell-knownC++programminglanguage[23].SystemCextendsC++bytypicaldatatypesusedforhardwarecircuitslikebitvectorsandarithmeticonbinarynumberswithaspecifiedbit-width.Moreover,SystemCoffersconcurrencyinasimilarwayashard-waredescriptionlanguages,i.e.,SystemCprogramsconsistofasetofconcurrentprocesses.Tothisend,SystemCfeaturesthreedifferentkindsofprocesstypes: 1HowDifferentAreEsterelandSystemC7●Methodsaretriggeredbysignalevents.Methodsareentirelyexecutedinasinglesimulationcycleandcorrespondtocombinatorialcircuits,i.e.,theirexecutiondoesnottaketime.●Asynchronousprocessesarealsotriggeredbysignalevents,buttheymaynotbeentirelyexecutedwithinonesimulationcycle.Instead,thecontrolmaystopatwaitstatementsandmayrestthereuntilitistriggeredbyanewevent.●Synchronousprocessesaretriggeredbyclocks.Likeasynchronousprocesses,synchronousprocessesmaynotbeentirelyexecutedwithinonesimulationcycle,andthecontrolmaystopatwaitstatementsoftheprocess.Incontrasttoasynchronousprocesses,theexecutionofsynchronousprocessesisonlytrig-geredbythenextclockevent.AlthoughSystemCshareswithVHDLthediscrete-eventbasedsemantics,itdoesnothavethepossibilitytoassignsignalassignmentswithdelay.Hence,progressoftimeisonlydrivenbyclocks.Betweenthesesimulationsteps,theoutputsignalupdatesthatareduetoassignmentsofsynchronousprocessesarenotcommittedimmediately.Instead,theyaredeferredtothebeginningofthenextsimulationstep.Incontrasttothis,localvariablescanalwaysbemodified,andtheeffectbecomesvisiblewithoutdelay.1.3SimilaritiesBetweenSystemCandEsterelFromageneralpointofview,SystemCandsynchronouslanguagesarebasedondifferentmodelsofcomputation:WhileSystemChasadiscrete-eventbasedseman-tics,synchronouslanguagesrelyonaglobalclocktriggeringtheoverallexecution,i.e.,acycle-basedsemantics.However,acloserlooktothefeaturesofeachlan-guagerevealsthattherearesimilaritiesthatallowustodefineacommoncoreofbothlanguages.Inparticular,theintegrationofsynchronousprocessesinSystemCprovidessomehookstoestablishlinksbetweenbothworlds.Firstofall,considerwhenvariableschange.InEsterel,thereareimmediateanddelayedassignmentsthatchangethevalueofavariableimmediatelyoronlyatthenextmacrostep.Similarly,theasynchronousprocessesofSystemCimmediatelyupdatevariablevalues,whiletheassignmentsofsynchronousprocessesarecom-mittedonlybeforethenextsimulationcycle.However,synchronouslanguagesfollowtheparadigmofperfectsynchrony,i.e.allvariableassignmentsaremadesimultaneouslyinamacrostep.Thishasthecon-sequencethatallvariablescanonlyhaveonevalueperclockcycle.Theperfectsynchronyalsohasanotherconsequence.Programsmaynotbeexecutedintheordergivenbytheprogrammer.Datadependenciesoftheprogrammayrequiretoexecutethestatementsinacompletelydifferentorderthanspecifiedbytheprogrammer.Thus,thesimulatordoesnotsimplyexecutethecodeofasynchronousprogramonce,butitreiteratestheexecutionanddeducesfromiterationtoiterationthevalueofmoresignalsuntilnofurthervaluescanbededuced.Asanexample,considerasequenceinwhichthefollowingoperationsare 8J.Brandt,K.Schneiderperformed:assignaavaluedependingonbandc,thenassignbavaluedependingoncandfinallyassigncsomeconstantvalue.Withoutreordering(whichisgener-allynotapplicable),thesimulatorneedsthreeiterationstocomputealloutputs.Figure1.1comparestheexecutionofaSystemCandanEsterelprogram.Thereareapparentsimilaritiesintheexecutionofbothtypesofprograms:Bothofthemstartwiththedeterminationofthetimeofthenextstep.InSystemC,thisisdeter-minedbythenextchangingclocksignal,whereasthelogicaltimeofEstereljustrequirestowaitforthenextclocktick.Then,bothsimulatorsenteraniteration.InSystemC,themethodsandasynchronousprocessesareexecutedaslongassomesignalschange.InEsterel,thereisasimilarcondition.Theoutputsarecomputedinafixpointoperationthatincrementallycomputesallsignalsofthecurrentstep.Subsequently,actionswithimmediateeffectsareexecuted,whicharefollowedbytheupdatescausedbydelayedactions.BothinSystemCandEsterel,theseupdatesstemfromthepreviousclockcycle.Iftheiterativepartofastepisfinished,theSystemCsimulatorexecutesthesynchronousprocessesthathavebeenscheduledinthepreviousstep.Similarly,theEsterelcompilerexecutesthecodeatthecurrentlyactivecontrolflowlocationswiththedeterminedsignalvalues.Bothprogramsnowscheduleprocessesandproducedelayedactionsforthenextclockcycle.ThiscomparisonshowsthatEsterelandthesynchronouspartofSystemCbasi-callyfollowthesameoverallexecutionscheme.However,asalreadymentionedabove,theexecutionoftheindividualprocessesisgenerallydifferent.SystemCprocessesaresequentialandthus,theyareexecutedasspecifiedbytheprogram-mer,whileEsterelisinherentlyparallel,anditsexecutionfollowsthedatadepend-encies.Hence,asynchronousprogramcannotbedirectlytranslatedtoSystemC,sincecausilityproblemsmustbeconsidered.functionSystemCStep()//determinenextchangingclocksignaldo//executeactivatedsc_methodsandsc_threads//updateoutputsofsc_methodsandsc_threads//updateoutputsofprevioussc_threadswhile(signalschange);//executescheduledsc_threadsfunctionEsterelStep()//proceedtonextmacrostepdo//execution:determiningcurrentsignals//updateimmediateoutputs;//updatedelayedoutputsofpreviousstepwhile(fixpointnotreached);//execution:preparenextmacrostepFig.1.1ComparingtheexecutionofSystemCandEsterelprograms 1HowDifferentAreEsterelandSystemC9Nevertheless,formostprogramsthatappearinreal-worldapplications,theproblemsarenotasdifficultasoutlinedbefore.Withrestrictingtoasubclassofsynchronousprogramsthatcoversmostimportantapplications,adirectstructuralmappingispossible.Basically,thefollowingclassescanbedistinguished.●Programsthatcontainonlydelayedaction:Noproblemsoccurifprogramsthatsolelycontaindelayedactionsaretranslated.Forthisclassofprograms,theiterativepartisalmostredundant:Onlytheoutputsfromthepreviousstepmustbecommittedonce.Thefixpointiterationcanbecompletelyomit-ted,sincenoactionsmanipulatetheminthecourseofthecurrentstepandthus,theyareallknowninadvance.Theactualexecutionoftheprogramcodeisdoneaftertheloop,whichisequivalenttoSystemCsynchronousprocesses.●Programsrequiringonlyonefixpointiteration:Inprinciple,theconditionfortheinputsetofprogramsdoesnothavetobeasstrictasdescribedabove:Theonlythingthatmustbeguaranteedisthatasingleiterationofisenoughtodeterminetheoutputvalues.Inthiscase,theexecutionschemeisagainanalogousandadirectlytranslatedprogramshowsthesamebehavior.Hence,programsmaycontainimmediateactionswhichmustbehoweversetbeforetheirusageinthestep.Inparticular,theindividualthreadsofaprogramhavetobeexecutedintherightorderthatrespectsinter-threaddatadependencies.●Allotherprograms:Thesetofprogramsforatranslationdoesnotneedtoberestrictedatall.ThecausalityanalysisofsynchronousprogramscanbesimulatedinSystemCwiththehelpofasynchronousprocesses.Eachprogramfragment(i.e.eitherequationsortheresultofthecompilationmethodpresentedinthenextsection)iswrappedinanasynchronousprocessthatcontainsallusedvariablesinitssensitivitylist.Likethis,itsexecutionistriggeredeachtimeavaluechanges.NotethatEsterelprogramthatarenotcausallycorrect,mayresultinSystemCprogramsthathaveanonterminatingsimulationcycle:Asynchronousprocessesmayinfinitelyoftentriggereachotherandthus,simulateanoscillatingwireinthecircuitdesigntheyrepresent.1.4DifferencesBetweenSystemCandEsterelTheprevioussectionshowedthatsynchronousprocessesinSystemCandEsterelprogramsshareacommoncore,whichcancomprehendmanypracticalsystems.WhilemostelementsofSystemCcanbemappedmoreorlessdirectlytoEsterel,someproblemsarisefortheotherwayaroundduetotherichsetofcontrolflowstatementsEsterelprovides.First,problemsoccurduetotheEsterel’sorthogonaluseofparallelism.SinceparallelandsequentialcodecanbearbitrarilymixedinEsterelbutnotinSystemC,threadsinsynchronousprogramsmustbereorganized.Second,therearemanypreemptionconstructsinEsterel,whichareallbasedonsomeprimitiveabortion 10J.Brandt,K.Schneiderandsuspensionstatements.AsSystemCdoesnotprovidepreemption,thispartmustbealsoremovedbeforeatranslationtoSystemCcode.Recently,wedevelopedanewcompilationschemeforourEsterel-variantQuartz,whichcompilesprogramstoanintermediatecode,whichrepresentsasmallsynchronousprogramminglanguageswithoutcomplicatedcontrolflowstatements[20,21].Thebasicbuildingblockofthisformatisajob.SuchajobJ=(x,S)isaxpair,wherexisalabelandSacodefragment.ThesejobsresemblesynchronousxprocessesinSystemC.Theoverallideaofcompilationisasfollows:Inafirststep,foreachcontrolflowlocation
oftheprogram,ajob(
,S)iscomputedthathasto
beexecutedifthecontrolflowresumestheexecutionfromlocation
.Definition1.[JobCodeStatements]Thefollowinglistcontainsthejobcodestatements.S,S,andSarealsojobcodestatements,
isalocationvariable,xis12aneventvariable,yisastatevariable,σisaBooleanexpression,andλisalockvariable:●nothing(emptystatement)●y=τandnext(y)=τ(assignments)●init(x)(initializelocalvariable)●schedule(
)(resumptionatnextreaction)●reset(λ)(resetabarriervariable)●fork(λ)(immediatelyforkjobλ)●barrier(λ,c)(trytopassbarrierλ)●if(σ)SelseS(conditional)12●S;S(sequence)12Theatomicstatementsnothing,y=τ,andnext(y)=τhavethesamemeaningasinordinarysynchronousprograms.Themeaningofconditionalsandsequencesisalsothesame.Thestatementinit(x)replacesalocalvariabledeclaration.Theschedule(
)statementinsertsthejobcorrespondingtocontrolflowlocation
tothescheduleofthenextstep.Thestatementsreset(λ),fork(λ),andbarrier(λ,c)areusedtoimplementconcurrencybasedonbarriersynchronization.Thestate-mentbarrier(λ,c)firstincrementstheintegervariableλandthencomparesitwiththeconstantc.Ifλ≥cholds,itimmediatelyterminates,sothatafurtherstatementScanbeexecutedinasequencebarrier(λ,c);S.Ifλadr)mod8){case0:out_ip.send(pkt);break;case1:case2:out_clk.send(pkt);break;case6:case7:out_cclk.send(pkt);break;default:out_frt.send(pkt);break;}}voidnode::process(){receive_req(l_pkt_req,l_in_dir);l_out_dir=route(l_pkt_req.adr_dest);forward_req(l_pkt_req,l_out_dir);receive_rsp(l_pkt_rsp,l_out_dir);forward_rsp(l_pkt_rsp,l_in_dir);Fig.2.7Circuitswitching}routerTheASCcodeoftheroutersusedinthisversionoftheOctagonissummedupinFig.2.7.Whenoneofthesenodesreceivesanewrequestpacket,itstoreswhichinputport(l_in_dir)transmittedthepacket.Asforthepreviousversion,thepacketisthentransmittedthroughtherightoutputport.However,thistimethenodedoesnotrestarttowaitforapacketonallitsinputports,butitwaitsontheinputportassociatedtotheoutputport(l_out_dir)whichwasusedtosendthepacket.Inthiswaythenextpacketreceivedbythisnodecanonlybetheresponsepacketofthepreviousrequestpacket.Whenthislastresponsepacketisreceived,itisforwardedthroughtheoutputportcorrespondingtotheinputportwhichreceivedtherequestpacket.Thus,inthismode,theentirepathbetweentheCPUwhichsendstherequestandtheCPUwhichreceivesitisreservedfortheresponsepacket.Inafirststep,theASCtracingfacilitiesenabledustovalidatethefunctionalbehaviorofthetwoversionsoftheOctagon.Forexample,theyhelpedustocheckthebehavioroftheroutersandtounderstandhowdead-lockswerehappeninginsuchaNoC.Tothisend,wehavereplacedtheCPUswithtrafficgeneratorproc-essesandtrafficconsumerprocesses.Inasecondstep,weaddedlatenciestothe 28C.Koch-Hofer,M.Renaudindifferentcomponents(consumers,producersandrouters)andtotheASCchannels.Bythisway,wewereabletoanalyzethecongestionsandlatenciesoftheNoCunderdifferentpatternoftraffic(uniform,hot-spotandrandom).2.5ConclusionThispaperpresentedatimemodelwhichcanbeusedtovalidateasynchronouscir-cuitmodelsusingalanguagebasedonCSP.ThistimemodelwasusedtodefinethetracingfacilitiesoftheASClibrary.ThesetracingfacilitiesproducetracesoftheASCprocessactivitiesovertheirconnectedchannels,whichcanthenbeusedtogeneratestandardVCD.However,theVCDformatisnotreallyadaptedtoasyn-chronouscircuits.Thus,wearecurrentlyinvestigatingothertraceformatslikeSCV.Wearealsoevaluatedthetimemodeloncomplexmultipleclocksystems.Finally,modelingandvalidatingasynchronouslogicwiththeASClibraryisthefirststeptowardsthesynthesis.OurfinalgoalistobeabletosynthesizethesemodelswiththeTASTframework[26].WearecurrentlyformallydefiningthesynthesisprocessofASCbasedmodelstoefficientlygenerategatelevelasynchro-nouscircuits.AcknowledgmentsTheauthorsthankY.Remondforinitiatingtheresearchonthistimemodel,andK.Morin-Alloryforreviewinginitialversionsofthedocument,andR.Solariforreviewingfinalversionsofthedocument.ThisworkispartiallysupportedbytheFrenchgovernmentintheMEDEA+framework,throughthe2A703NEVAproject(NetworksonChipsDesignDrivenbyVideoandDistributedApplications).References1.JantschA,TenhunenH(2003)Networksonchip.Kluwer,Boston,MA2.SparsøJ,FurberS(2001)Principlesofasynchronouscircuitdesign.Kluwer,Boston,MA3.NielsenSF,SparsøJ(2001)Analysisoflow-powerSoCinterconnectionnetworks.In:19thNorchip,pp77–864.EdwardsDA,TomsWB(2004)Design,AutomationandTestforAsynchronousCircuitsandSystems.TechnicalReportIST-1999-29119,3rdedn.WorkingGrouponAsynchronousCircuitDesign(ACiD-WG).http://www.scism.sbu.ac.uk/ccsv/ACID-WG5.CortadellaJ,KishinevskyM,KondratyevA,LavagnoL,YakovlevA(1997)Petrify:atoolformanipulatingconcurrentspecificationsandsynthesisofasynchronouscontrollers.In:IEICETransInf.andSyst,pp315–3256.FuhrerRM,NowickSM,TheobaldM,JhaNK,LinB,PlanaL(1999)Minimalist:AnEnvironmentfortheSynthesis,VerificationandTestabilityofBurst-ModeAsynchronousMachines.TechnicalReportCUCS-020-9.ColumbiaUniversity,ComputerScienceDepartment7.YunKY,DillDL(1992)Automaticsynthesisof3Dasynchronousstatemachines.In:ICCAD92,pp576–580.SantaClara,CA8.MartinAJ(1990)ProgramminginVLSI:fromcommunicatingprocessestodelay-insensitivecircuits.In:DevelopmentsinConcurrencyandCommunication,pp1–64.HoareCAR,UTYearProgrammingSeries 2TimedAsynchronousCircuitsModelingandValidationUsingSystemC299.EdwardsD,BardsleyA(2002)Balsa:anasynchronoushardwaresynthesislanguage.In:TheComputerJournal,Volume45,Issue1,pp12–1810.BerkelKV(1993)Handshakecircuits–anasynchronousarchitectureforVLSIprogramming.CambridgeUniversityPress,Cambridge11.QuartanaJ,FesquetL,RenaudinM(2005)ModularasynchronousNetwork-on-Chip:applica-tiontoGALSsystemrapidprototyping.In:VeryLargeScaleIntegrationSystems(VLSI-SoC’05).Perth,Australia12.Koch-HoferC,RenaudinM,ThonnartY,VivetP(2007)ASC,aSystemCextensionformod-elingasynchronoussystems,anditsapplicationtoanasynchronousNoC.In:1stInternationalSymposiumonNetworks-on-Chip(NoC’07).Princeton,NJ13.IEEEStd1666–2005,SystemCLanguageReferenceManual(2005)14.HoareCAR(1978)CommunicatingSequentialProcesses.In:CommunicationsoftheACM,Volume21,Issue8,pp666–67715.LamportL(1978)Time,clocks,andtheorderingofeventsinadistributedsystem.In:CommunicationsoftheACM,Volume21,Issue7,pp558–56516.AshkinazyA,EdwardsD,FansworthC,GendelG,SikandS(1994)Toolsforvalidatingasynchronousdigitalcircuits.In:1thInternationalSymposiumonAdvancedResearchinAsynchronousCircuitsandSystems(ASYNC’94),pp12–21.SaltLakeCity,UT17.ChakrabortyS,DillDL,YunKY,ChangKY(1997)Timinganalysisforextendedburst-modecircuits.In:3rdInternationalSymposiumonAdvancedResearchinAsynchronousCircuitsandSystems(ASYNC’97),pp101–111.Eindhoven,TheNetherlands18.KarlsenPA,RøinePT(1999)Atimingverifierandtimingprofilerforasynchronouscircuits.In:5thInternationalSymposiumonAdvancedResearchinAsynchronousCircuitsandSystems(ASYNC’99),pp13–23.Barcelona,Spain19.ViaudE,PêcheuxF,GreinerA(2006)AnefficientTLM/Tmodelingandsimulationenviron-mentbasedonconservativeparalleldiscreteeventprinciples.In:Design,AutomationandTestinEurope(DATE’06).Munich,Germany20.MartinAJ(1993)SynthesisofAsynchronousVLSICircuits.InternalReport,Caltech-CS-TR-93-28.CaltechInstituteofTechnology,Pasadena,CA.21.SutherlandIE(1989)Micropipelines.In:CommunicationoftheACM,Volume32,Issue6,pp720–73822.OpenSystemCInitiative(2007)SystemCv2.2.http://www.systemc.org/23.KarimF,NguyenA,DeyS,RaoR(2001)On-chipcommunicationarchitectureforOC-768networkprocessors.In:DesignAutomationConference(DAC’01).LasVegas,NV,pp678–68324.IEEEStd1364-2001,Behaviourallanguages–Part4:Veriloghardwaredescriptionlanguage(2001)pp349–37425.HelmstetterC,MaraninchiF,Maillet-ContozL,MoyM(2006)AutomaticGenerationofSchedulingsforImprovingtheTestCoverageofSystem-on-a-Chip.VerimagResearchReport,TR-2006-626.RenaudinM,RigaudJB,DinhDucAV,RezzagA,SirianniA,FragosoJ(2002)TASTCADTools.TIMAResearchReport.TIMA–RR-02/04/01—FR Chapter3OnConstructionofCycleApproximateBusTLMsMartinRadetzkiandRaufSalimiKhalighAbstractTransactionlevelmodels(TLMs)canbeconstructedatdifferentlevelsofabstraction,denotedasuntimed(UT),cycle-approximate(CX),andcycleaccu-rate(CA)inthiscontribution.Thechoiceofalevelhasanimpactonsimulationaccuracyandperformanceandmakesalevelsuitableforspecificusecases,e.g.vir-tualprototyping,architecturalexploration,andverification.Whereastheuntimedandcycle-accuratelevelshavearelativelyprecisedefinition,cycle-approximatespansawidespaceofmodellingalternativesbetweenUTandCA,whichmakesitaclassoflevelsratherthanasinglelevel.InthiscontributionwereviewthesemodellingalternativesinthecontextofSystemCandwithfocusonbusmodels,providequantitativemeasurementsonmajoralternatives,andproposeaCXmodel-linglevelthatallowstoobtainalmostcycleaccuracyandasimulationperformancesignificantlyaboveCAmodels.KeywordsTransaction-levelmodelling,SystemC,embeddedsystems3.1IntroductionTransactionlevelmodellinghasbecomeawidelyusedtechniqueinembeddedsystemsandsystemonchipdesign.AvarietyofsystemdesignlanguagessuchasSystemC[7]andSpecC[5]canbeusedformodellingattransactionlevel.However,transactionsandmanyothertypicalelementsoftransactionlevelmodels(TLMs)arenotavailableassyntacticlanguagefeatures.TheTLMcreatorsinsteadhavetocreatethetransactionlevelabstractionsthemselves,usinglanguagefeaturessuchaschannelsandinterfaces.ThisissupportedbymostlyinformaldescriptionsoftheTLMmethodology,e.g.[6],andbymethodology-specificlibraries,e.g.theSystemCTLMlibrary[10].InstitutfürTechnischeInformatik,Pfaffenwaldring47,70569Stuttgart,GermanyEmail:martin.radetzki@informatik.uni-stuttgart.deE.Villar(ed.)EmbeddedSystemsSpecificationandDesignLanguages,31©SpringerScience+BusinessMediaB.V.2008 32M.Radetzki,R.SalimiKhalighMethodologiesandlibrariesleavedegreesoffreedomtoimplementTLMsindifferentways.Thishasthepositiveeffectthatthetransactionlevelinfactspansmultiple(sub-)levelsofabstraction,facilitatingtrade-offsbetweensimulationaccu-racyandperformance.However,theselevels,subsequentlydenotedasuntimed(UT),cycle-approximate(CX)andcycleaccurate(CA),arenotformallydefinedbutrathercharacterizedbymodelproperties.ThelackofaformaldefinitionmakesitdifficulttodescribehowtosystematicallyconstructTLMsatagivenlevel.Despitethisdrawback,thereexistrelativelypreciseandconsistentcharacteriza-tionsofUTandCA,aswewillshowinSection3.2.CXmodels,however,cancoverawiderangebetweenUTandCA,andthereappearstobenoconsensusonthecharacteristicsofafavourableCXmodel.Wewillattemptthedefinitionofsuchamodelbasedontheconsiderationofmodellingalternatives.Forthispurpose,weusethefollowingnon-orthogonalcriteriacharacterizingTLMsinadditiontotheirtimingaccuracy:●Theunderlyingcommunicationmechanism,whichcanbeasubprogramcallwithtransferofcontrolflow(blocking)ormessagepassingwithdataflow(potentiallynon-blocking).●Theuseofconcurrencyinthemodel,namelythepresenceorabsenceofindi-vidualthreadsinthemodelledmaster,slave,andbuscomponents.Acomponentwith(without)athreadiscalledpassive(active).●Theprogrammingabstractionprovidedtotheusersofabusmodel,includingnoabstraction(directaccesstoport/channel),proceduralapplicationprogramminginterface(API),communicationmechanismsthatcouldbeadoptedfromconcur-rent/distributedsystems(e.g.RPC,CORBA).●Thebusfeaturescoveredbythemodel,includingsingletransfers,bursts,lockedtransfers,splittransfers,waitstates(insertedbyslave),busycycles(insertedbymaster),busphasesandpipelining,in-orderorout-of-ordercompletionoftrans-fers,andarbitrationpolicy.●Themodellingmechanismusedforarbitration,inparticulartheuseofeventstotriggerarbitration(noevents,oneevent,multipleevents).●Theusecasesofaparticularmodel,includingverification,exploration,virtualprototyping.Inthenextsection,wereviewtherelatedworkwithrespecttotheabovecriteria.Section3.3presentsconsiderationsandalternativestowardsaccurateCXmodels,andSection3.4investigatestheirperformance.3.2RelatedWorkDonlin[4]presentsthetransactionlevelterminologyusedbytheSystemCTLMworkinggroup.ItincludesaProgrammer’sView(PV)characterizedbyuntimedcommunicationandtheusecaseofprovidingafunctionallyaccuraterepresentationofhardwaresubsystemstosoftwareprogrammers.AProgrammer’sViewwith 3OnConstructionofCycleApproximateBusTLMs33Time(PV+T)resultsfromannotatingaPVmodelwithtimeandapproximatearbitration.ACycleAccurate(CA)viewischaracterizedbyfullybusprotocolcompliantarbitrationandtimingaccuratetothelevelofindividualcycles.IntheOCPterminology[9],threeTLMlayersaredefined:TheTransferLayer(L-1)ischaracterizedbycycle-truebehaviouranduseforverificationandprecisesimulation.AttheTransactionLayer(L-2),modellingabstractsfromthedetailsofabusprotocolbutcantakepropertieslikesplittransactionsandpipeliningintoaccount.TheMessagingLayer(L-3)isuntimedandenables1:1connectionsbetweeninitiatorsandtargets,abstractingfrombusaddressmapping.TheSpecCrelatedtaxonomyfrom[3]takesintoaccountthetimingaccuracyofcomputationasorthogonaltothecommunicationtimingaspectanddefinescycle-timed,approximately-timedanduntimedlevelsforbothdimensions.ConsideringthecommunicationdimensiononlyandfocusingonTLMmodels,wecanidentifyanuntimedcomponent-assemblymodel(CAM)whichmodelscommunicationbetweensystemcomponentsbymessagepassing,abusarbitrationmodel(BAM)witharbitrationpolicymodellingthatapproximatestimingbyonewaitstatementpertransaction,andacycle-timedbus-functionalmodel(BFM).TheGreenBusapproach[8]makesasignificantsteptowardsaconstructivedefi-nitionoftransactionlevels.Itidentifiesthreelevelsofgranularitycalledtransac-tions,atoms,andquarks.Atransactionisasequenceofuninterruptiblephases(atoms),andeachatomisacollectionofpayloadvalues(quarks).APVmodelapproximatestimingattransactionboundaries,abusaccurate(BA)modelatatomboundaries,andacyclecallable(CC)modelmustmodelallquarkupdateswithcycleaccuracy.Anuntimedmodelisnotdefined.Fromtheseconsiderations,itisapparentthattherestillexistsnounifiedterminol-ogyintheTLMfield.Table3.1classifiesthemodellinglevelsdescribedintheafore-mentionedapproacheswithrespecttotheirbuscommunicationtimingproperties.TheUTapproacheshaveincommontheprimaryusecaseofvirtualsystempro-totypingandthattheyresultinapurelyfunctionalsimulation.Thislimitstheavaila-blechoiceswithrespecttoourcharacterizationcriteriaaswellastheimpactoftheremainingchoicesonthesimulationresult.Subtledifferencesexist–forexample,theSpecCapproachfeaturesmessagepassingandactiveslavesattheCAMlevelwhereasSystemCPVusesfunctioncallsfrommastersintopassiveslaves–buttheseshouldnothaveimpactonthefunctionalresultofsimulationnorthenon-existenttiming(whereasanimpactonsimulationperformanceislikely).Anothersuchdif-ferenceiswhetherbusstructure,addressingscheme,andapproximatearbitrationaremodelled(SystemCPV)ornot(point-to-pointconnectionsinOCPL-3).Table3.1OverviewoftransactionlevelsAccuracyUTCXCASystemCTLMPVPV+TCAOCPL-3L-2L-1Cai/SpecCCAMBAMBFMGreenBus–PV(+T),BACC 34M.Radetzki,R.SalimiKhalighAsimilarsituationcanbeobservedattheCAlevel.Theprimaryusecasesareverificationreferenceandpreciseperformanceanalysis.Thepropertyofcycleaccuracystronglyrestrictsthemodellingspace.Allbusfeaturesmustbemodelled,communicationisnecessarilybynon-blockingdataflowbetweenconcurrentcom-ponents,andarbitrationistypicallyperformedineachcycle.Adetailedinvestiga-tionofCAmodelcodeoftenrevealsthatsomeinterfaceabstractionisprovided,but“underthehood”themodelimplementscommunicationatthelevelofthesignalsusedinthebusprotocol,evenifthesearebundledinaTLMchannel.Forexample,Table3.1in[8]showsthedirectcorrespondencebetweenGreenBusquarksandprotocolsignals.IntheSystemCbasedAMBAcycleaccuratesimulationinterface(CASI)[2],theCAAHBchannelusesadatastructurewhoseattributesareidenti-caltotheAHBsignals.Aproposalformoreabstractprotocolmodellingbasedonhierarchicalstatemachineshasbeenmadein[13].AttheCXlevelwiththeprimaryusecaseofsystemexplorationandperform-ance(busthroughputorlatency)estimation,amuchwiderrangeofmodellingalternativesexist.WithintheSystemCTLMandGreenBusPV+Tmodels,timingisapproximatedatthegranularityoftransactions,arbitrationabstractsfromtheprecisebusarbitrationpolicy,andtransactionscannotbepre-empted.Thus,fea-turessuchassplittransferscannotbemodelled.Ontheotherhand,theSpecCBAMandGreenBusBAmodelspermitpre-emptionoftransactionsandsubsequentbusre-arbitration.Thereby,moreprecisesimulationcanbeobtainedatthecostoflowersimulationperformancecomparedtoPV+T.AninterestingapproachtoCXmodellingispresentedin[14],wheretransac-tionsaresimulatedwiththeoptimisticassumptionofnotbeingpre-empted.Ifthisassumptionturnsouttofalseatalatersimulationtime,thetransactiondurationisextendedbythedurationofpre-emptingtransactions.Thisyieldsa100%accuratesimulationwithrespecttotheauthors’measureoftimingaccuracy.However,thedataofabursttransferaretransmittedinasingleoperationatthebeginningofthetransactionmodellingthattransfer.Thismeansthatindividualdatatransfersarenotcycleaccurateandtheinterleavingofdatafrompre-emptingtransferscannotbesimulated,whichmayaffectdata-dependentfunctionality.Intheremainderofthiscontribution,weinvestigatewhetheraCXmodelcanbedesignedtocoveramaximumofbusfeaturesandtocomeascloseaspossibletocycleaccuracy,includingaccuracyofthedatatransfers.Wewillalsoinvestigatemodellingdecisionsthatoptimizesimulationperformancewithoutimpactingaccu-racy.Theresultingmodelcanprovideratheraccurateestimatesforthepurposeofsystemexploration,complementingthesignificantlylessaccurateyetfasterPV+Tmodels.3.3ModellingAlternativesandDecisionsSincewetargetaSystemCmodelimplementation,wewillusetheSystemCTLMterminologyinthefollowingbutkeepthetermCXforourmodel. 3OnConstructionofCycleApproximateBusTLMs353.3.1ConcurrencyInmostPVandPV+Tmodels,slavesarepassiveandmastersareactivecomponents.Thislimitstheachievableaccuracybecausemasterandslavecannotoperateconcur-rently.Forexample,amastercannotpreparedataforthenexttransactionwhileaslaveprocessesthemaster’scurrenttransactionrequest.Toavoidthispossibledeviationfromdetailedsystemtiming,wechoosetomakeslavesactivecomponentsinourCXmodel.Anothermodellingalternativepertainstothemodellingofthebusasanactiveorpassivecomponent.Thisiscloselyrelatedtoarbitrationmodelling,discussedattheendofSection3.3.3.3.2CommunicationMechanismsPVandPV+Tmodelstypicallyemploytransferofcontrolflow(blockingsubprogramcalls)asamechanismforcommunicationbetweenmasterandslave.Thisisinconflictwiththedesiredconcurrencyofmasterandslaves.Therefore,weusedataflowtopassmessagesbetweencommunicatingblocks.However,forlargemessagepayloadssuchasburstdata,weuseasharedmemoryimplementationwhereonlyapointertotheshareddataispassedaspartofthemessage.Thereby,copyingofthepayloadisavoidedandsimulationperformanceincreased.Accessconflictsonthesharedmemoryareavoidedbylimitingaccessbythecommunicationpartners(master,slave,busmodel)todisjointphasesofthetransaction.Thedynamicmemorymanagementishandledbythemaster’sport,hiddenfromtheuser,toavoidmemoryleaksanddanglingpointers.Memoryisallocateduponstartofatransactionandfreedwhenthemasterhasobtainedthelastdataofatransactionresponseaccordingtotheprogrammingmodel(cf.nextsubsection).Wehavetriedtoavoidasuspectedoverheadduetorepeatedcreationanddele-tionofmemoryblocksbyreusingapoolofsuchblocks.Thishadnosignificantimpactonsimulationspeed;possiblybecausesuchoptimizationisalreadyimple-mentedintheC++runtimelibrary’sheapmanagement.AnothermodellingchoicemustbemadebetweenuseofstandardTLMchannels(tlm_fifo)toconnectmastersandslaveswiththebusmodelvs.directconnectiontointerfacesexportedbythebus.Thelatteroptionislikelytobemoreefficientbecauseitavoidstheoverheadofstoringandretrievingmessagesin/fromatlm_fifo.Moreover,themaster’sinterfacemethodcallswillgodirectlyintothebusmodel,enablinganimplementationthatreducesthenumberofcontextswitchesduringsimulation.Bothvariantshavebeenimplementedandtheirresultingsimula-tionperformanceiscomparedinSection3.4.3.3.3ProgrammingAbstractionInmostPVandPV+Tmodels,subprogramcallsserveasawell-understoodpro-grammingabstractionofcommunicationoperations.However,subprogramcalls 36M.Radetzki,R.SalimiKhalighcannotbeusedbetweenconcurrentordistributedmodelobjects.Remoteprocedurecalls(RPC)areamechanismthatcouldbeadaptedfromdistributedprogramming;however,inthepresenceofreturnparameters,theywouldblockthemasterwhichwouldcompromisetheaccuracyofourmodel.MechanismslikeCORBAenablenon-blockingcommunication,buttheyaretooheavyweightforuseinafasttrans-actionlevelsimulation.Asacompromise,wehaveadaptedforthepurposeofTLMtheactiveobjectdesignpatternknownfromconcurrentobject-orientedprogramming,seeFig.3.1.Akeyconceptofthispatternisthefutureobjectwhichisimmediatelyreturnedasresultofanon-blockingsubprogramcall.Inouradaptation,thecallmodelsanon-blockingcommunicationoperationandthefutureobjectcanlaterbeusedbythemastertoobtainresultsfromthatoperation(thetransactionresponse)atitsowndiscretion.Beyondthat,thefutureobjectisalsousedtoallowthemastertodelaythesupplyofvaluesthatbelongtothetransactionrequesttoatimeafterrequestinitiation.Therebywecanaccuratelymodelthatthemastermaysupply(retrieve)buswordnumberiupto(startingfrom)thei-thcycleafterthestartofabursttrans-ferinsteadofprovidingorreceivingallburstdataatthebeginningorattheendofatransaction.Anotheractiveobjectconceptistheguardwhichcanbedefinedindividuallyperoperationattheslaveside,cf.Fig.3.1.Weutilizetheguardasaprogrammingabstractionofabusfeaturethatallowsaslavetosplitatransferthatcannotbeservedimmediately,andtoresumethattransferwhenappropriate.Asanefficiencyimprovementover[12],wehavemodelledanevent-basedresumemechanismtoavoidpollingtheguardineachcycleduringwhichatransactionissplit.Moreover,Mi:MasterB:BusSj:Slaveputtransactiongettransactionf:Futuretx:Transactionexecuteguard?set_status(SPLIT)falsereadgetvaluevaluevalueFig.3.1ActiveobjectpatternforTLM 3OnConstructionofCycleApproximateBusTLMs37themodelspresentedinthiscontributionfacilitateforthefirsttimethesplittingofbursttransfersatthegranularityofthetransactionthatmodelsthetransferratherthansinglebuswordtransfers.3.3.4BusFeaturesThemostbasicbusfeaturesaresinglebuswordreadandwritetransfers(singletransfers).Successivetransferstoconsecutiveaddressescanbecombinedintoabursttransfer.Bursttransfersmayhaveafixedoruser-definedlength.Theymaybepre-emptibleornot(locked).Theburstaddresssequencemaywraparoundatblockboundaries(wrappingburst)ornot.Wemodelallthesetransfersandtheirpropertiesinanobject-orientedwayasC++transactionclassesandattributes(datamembers).Detailsaboutthismodellingstylecanbefoundin[11].Anotherfeaturefoundinmosthighperformancebusesispipelining.Toemploypipelining,transfersaredecomposedintophases,anddifferentphasesofsubse-quenttransfersareallowedtoexecuteinparallel.Wemodelthephaseasastateattributeofatransactionwhichiscontrolledbythebusmodel.Pipeliningcanbemodelledinacycleaccuratewaybyintroducinganumberofstagesintothebusmodelasshownin[13].OurCXmodelcoverspipeliningwithinasingletransac-tion(whichisrelevantforbursttransactions),butneglectsitattheboundarybetweendifferenttransactionsforperformancereasons.Wemodelsplittransfersusingtheguardmechanismforabstractionaspresentedintheprevioussubsection.TheOCPL-2modelistheonlyotherCXmodelknowntohavebuilt-insplittransfers.Anadvantageofourmodelisthatthankstothepro-grammingabstraction,thedesignerofabusmastermodelisrelievedoftakingcareofthesplittransferhandling.3.3.5ArbitrationModellingThissubsectionisconcernedwiththemechanismsemployedformodellingarbi-tration;thediscussionislargelyindependentofarbitrationpolicy.InCAmodels,atimeorclocktriggeredarbitrationprocessisexecutedoncepercycle.Aneffi-cientCXmodelcanlimitarbitrationundertheassumptionofatime-invariantarbitrationprotocolbecausethegrantdecisiondoesnotchangeunlessthestateofthewaitingandactivetransactionschanges.Re-arbitrationneedstobeperformedonlyinsimulationcyclesinwhichanewtransactionarrivestothebusorinwhichthecurrentlyactivetransactionisfinishedorsplit(allowingawaitingtransactiontobegrantedthebus).Re-arbitrationcanbemodelledwithoneoracombinationofthefollowingmeth-ods:Ifthebusmodelexportsaninterface,theinterfacemethods,executedwiththemasters’processes,mayperformarbitrationwithouttheneedforasimulationprocess 38M.Radetzki,R.SalimiKhalighFig.3.2ArbitrationtriggeringmechanismsM1M2event012345678activewaitingarbitrationtriggercontextswitch.Thiscomesatthecostofmultiplere-arbitrationifmultiplemastersissuetransactionsinthesamecycle,anditisnotpossibleifcommunicationisviachannels(e.g.tlm_fifo).Inthiscase,thebusmodelneedsaprocessthatistriggeredbyincomingtransactionmessagesandperformsarbitrationactively(cf.M1,M2inFig.3.2).Sinceeachchannelhasaneventofitsown,thisrequirestheoverheadofcreatingor-event-liststoactivatethearbitrationprocessinSystemC.Thenumberofeventscanbereducedtooneforallincomingtransactionsbyimplementingthebusmodelitselfaschannelwithinterfacemethodsthattriggeraninternalre-arbi-trationevent(cf.eventinFig.3.2).Splitorfinishedtransactionscantriggerthere-arbitrationeventoranindividualevent.3.4SimulationPerformanceResultsThebasicexperimentalsetupusedforperformanceevaluationofthebusmodelsincludestwomastersofdifferentpriorityandoneslave.Thehighprioritymasterissuestransactionsofincreasingburstlengththatmaybesplitbytheslave,aRAMmodel.TheparametersofthebusmodelarechosentoreflectthecycletimingoftheAMBAAHBprotocol[1],andprioritybasedarbitrationhasbeenmodelled.AllmodelshavebeencompiledwiththesameoptionsandhavebeensimulatedonacomputerwithPentiumM1.66GHz.Withthissetup,fourdifferentbusmodelshavebeensimulated:AmodelCX1atthePV+Tabstractionandacycle-accuratemodelCAasreferencepoints,andtwocycle-approximateversions,CX2andCX3usingdifferentchoicesoftheidentifiedalternatives.CX2isamodelusingtlm_fifosaschannelswhileCX3implementstheTLMinterfacesbyitself,usingasinglearbitrationevent.3.4.1ComparisonofDifferentModelsFigure3.3showsthesimulationperformance,measuredinthenumberof32bitbuswordswhosetransmissionissimulatedpersecondofCPUtime,forthefourmodelsandforburstsofdifferentsize.Notransactionshavebeensplitinthissimulation.Allmodelsexhibitaperformancethatincreaseswiththeburstsizeduetolesssimulation 3OnConstructionofCycleApproximateBusTLMs39CX1CX3CX2CA1e+071e+06Simulationperformance[cycles/s]100000110100Transfersize[words]Fig.3.3Performanceofmodelsatdifferentlevelsoverheadforarbitrationandswitchingbetweentransactionspertransmittedbusword.WecanseethattheperformanceofthemodelsCX2andCX3isconsistentlyhigher(byanaveragefactorofabout5)thanCA,andthatCX1(PV+T)exceedsCX2andCX3performancebyanaveragefactorofabout10.OnlyatveryshortburstlengthCX3performanceexceedsCX1;thereasonisthatCX1lackssomeoftheoptimizationsthathavebeenmadeinCX3.Atshortburstlength,modelCX3hasasignificantadvantageoverCX2,whichdiminishestowardslargerbursts.ThereasonforthismodelbehaviouristhattheCX3optimizationofavoidingtlm_fifosandusingjustasingleeventismoresignificantwhensimulatingshortburstsrequiringahigherrateofchannelaccessesandevents.3.4.2Pre-emptionDependencyDifferentfromPV+T,modelsCX2andCX3cansimulatethepre-emptionoftransactions.Tomeasuretheeffectofpre-emptiononsimulationperformance,wehaveparameterizedtheslavemodelsothatitrandomlysplitstransactions.Thepercentageofbuswordtransferswhicharesplit(i.e.,multiplesplitsofasingletransactionarepossible)hasbeenvariedfrom0%to50%.Figure3.4showstheresultingsimulationperformanceformodelCX2.Performancedegradeswithincreasingpre-emptionratio.Itisreducedbyafactorofupto10forlongburstsand50%pre-emption,comparedtothenon-preemptivecase.Performancedegradation 40M.Radetzki,R.SalimiKhaligh0%split5%split10%split15%split1e+0620%split30%split50%splitSimulationperformance[cycles/s]100000110Transfersize[words]Fig.3.4CX2performancewithpre-emptionbecomeslessastransfersizedecreasesbecausere-arbitrationduetoatransfersplitmoreoftencoincideswithre-arbitrationduetoarequestbytheothermaster.Sincethelatterhastobesimulatedanyway,thesplitdoesnotcauseasimulationoverheadinthiscase.ThesamemeasurementhasbeenperformedusingmodelCX3,withresultsshowninFig.3.5.PerformanceisgenerallyhighercomparedtoCX2,andthedeg-radationfactorduetopre-emptionofburstsisdowntoamaximumofabout3.ThisisagainduetotheoptimizedimplementationofmodelCX3,whichalsoreducestheoverheadofperformingre-arbitrationinthecaseoftransactionpre-emptionandcompletion.3.4.3BusComponentandCongestionDependencyInordertoevaluatesimulationperformanceinthepresenceofmorethantwomas-ters,modelCX3hasbeensimulatedinasetupwithanumberofmastersvaryingfrom1to16.Thenumberofslavesalsovaries;ineachofthesimulationsperformeditcorrespondstothenumberofmasterssothatnmastersaresimulatedtogetherwithnslavesandthebusmodel.Themastershavedifferentstaticpriorities.Inthesimu-latedscenario,themastersaresynchronizedsothatforeachsimulatedtransfersizeintherangeof1to64words,allmasterscancompletetheirtransfersofagiventransfersizeandthentogethermoveontothenexttransfersize.Figure3.6depictsthemodel’ssimulationperformanceundertheconstraintthattheslavesdonotsplittransfers.Generally,simulationperformancedecreasesasthe 3OnConstructionofCycleApproximateBusTLMs410%split5%split10%split15%split20%split30%split50%split1e+06Simulationperformance[cycles/s]100000110Transfersize[words]Fig.3.5CX3performancewithpre-emption1master2masters4masters8masters16masters1e+06Simulationperformance[cycles/s]100000110Transfersize[words]Fig.3.6CX3performancefordifferentnumbersofmasters(nosplittransfers)numberofmastersincreases.Thisisduetoanincreasedaverageoverheadforarbi-trationandduetothefactthatinthepresenceofmoremasters,transfersoflower-prioritymasterstendtobepre-emptedmoreoftenbythehigherprioritymasters.Thespreadbetweenthecurvesfor1masterand16mastersisbyafactorofabout2. 42M.Radetzki,R.SalimiKhaligh1master2masters4masters8masters16masters1e+06Simulationperformance[cycles/s]100000110Transfersize[words]Fig.3.7CX3performancefordifferentnumbersofmasters(25%splittransfers)Figure3.7showssimulationperformanceforasimilarscenariobutwith25%ofalltransfersbeingsplitbyaslave.3.5ConclusionsWehaveshownthedesignofacycle-approximatemodelthatcoversallbusfeaturesandrepresentsbustransfersbyabstracttransactionsinanalmostcycle-accurateway.Thesimulationperformanceofthismodelisbetweentheperformanceofacycle-accuratemodelandtheperformanceofaPV+Tmodelthatdoesnotcovertransactionpre-emption.WearguethatmodellingatanaccuracylevelbetweenPV+TandCAisusefulforarchitecturalexplorationbecauseitpermitssignificantlymorepreciseestimationthanPV+T.Therefore,aCXabstractionlevelshouldcomplementtheotherlevelsinsteadofbeingdropped,whichappearstohavehap-penedinSystemCTLMstandardization.References1.ARMLtd.:AMBASpecification(Revision2.0).DocumentID:ARMIHI011A,www.arm.com/products/solutions/AMBA_Spec.html,accessed7.11.2006.2.ARMLtd.:CycleAccurateSimulationInterface(CASI).www.arm.com/products/DevTools/Real_ViewESLAPIs.html,accessed11.10.2006. 3OnConstructionofCycleApproximateBusTLMs433.L.Cai,D.Gajski:TransactionLevelModeling:AnOverview.Proc.CODES+ISSS,2003.4.A.Donlin:TransactionLevelModeling:FlowsandUseModels.Proc.CODES+ISSS,2004.5.R.Dömer,A.Gerstlauer,D.Gaijski:SpecCLanguageReferenceManual(Version2.0).UniversityofCalifornia,Irvine,CA,www.ics.uci.edu/specc/reference/SpecC-LRM_20.pdf,accessed7.11.2006.6.F.Ghenassia(Ed.):Transaction-LevelModelingwithSystemC–TLMConceptsandApplicationsforEmbeddedSystems.Springer,Dordrecht,2005.7.IEEEStandard1666-2005:SystemC2.1LanguageReferenceManual.IEEE,2005.8.W.Klingauf,R.Günzel,O.Bringmann,P.Parfuntseu,M.Burton:GreenBus–AGenericInterconnectFabricforTransactionLevelModelling.Proc.43rdDesignAutomationConference(DAC).SanFrancisco,CA,2006.9.OCPInternationalPartnership:OpenCoreProtocolSpecification(Release2.1).www.ocpip.org,2006.10.OpenSystemCInitiative:TLM1.0APIandLibrary.www.systemc.org,2005.11.M.Radetzki:Object-OrientedTransactionLevelModelling.InS.Huss(Ed.):AdvancesinDesignandSpecificationLanguagesforEmbeddedSystems.Springer,Dordrecht,2007.12.M.Radetzki:ModellierungmitGuardedTransactionszumrobustenEntwurfvonHardware-Software-SystemeninSystemC.Proc.1.GMM/GI/ITGFachtagungZuverlässigkeitundEntwurf,München,2007.13.R.SalimiKhaligh,M.Radetzki:EfficientandExtensibleTransactionLevelModelingBasedonanObject-OrientedModelofBusTransactions.Proc.Int’lEmbeddedSystemsSymposium(IESS).Irvine,CA,2007.14.G.Schirner,R.Dömer:FastandAccurateTransactionLevelModelsusingResultOrientedModeling.Proc.Int’lConferenceonComputerAidedDesign(ICCAD).SanJose,CA,2006. Chapter4CombinatorialDependenciesinTransactionLevelModelsRobertGuenzel1,WolfgangKlingauf1,andJamesAldis2AbstractTransaction-levelmodeling(TLM)allowsforthedesignofvirtualprototypes,providingconsiderablyfastersimulationspeedthanRTLmodels.Butcombinatorialdependenciesareofteninexactlymodeledintermsofcycleaccuracy,leadingtoimprecisesimulationresults.If,however,preciseresultsaredesired,additionalcodingandsimulationeffortisrequired.Asaresult,simula-tionperformancedropsdown.ThispapersurveystheexistingtechniquestomodelcombinatorialdependenciesinTLMandpresentsanovelapproachbasedonsynchronizationlayers.ExperimentalresultswithSystemCproveourtechniquetoenablehighersimulationspeedthanthesurveyedapproaches,withoutinheritingtheirdisadvantages.KeywordsTransaction-levelmodeling,SystemC,Combinatorialdependencies,Cycleaccuracy4.1IntroductionTransaction-levelmodeling(TLM)enablesdesignerstoraisetheabstractionlevelofsystemmodels,narrowingtheproductivitygapsignificantly[3,5,6].WithTLM,hardwareandsoftwarecanbedescribedinavarietyofways,rangingfromuntimedmodelstocycleaccuratemodelswiththeinterfacesbeingjustasabstractasthemodelrequires[4].ThescopeofthispaperiscycleaccurateTLM(CATLM),whichpromisesbussesandnetworksonchiptobesimulatedmagnitudesfasterthanwithRTLmodels,whileachievingthesameaccuracyofsimulationresults.Tothisend,itisvitaltofullytakecombinatorialdependenciesintoaccount,whenextractingmoreabstractCATLMmodelsfromRTLmodels.1TechnicalUniversityofBraunschweig,DepartmentE.I.S.2TexasInstruments,FranceE.Villar(ed.)EmbeddedSystemsSpecificationandDesignLanguages,45©SpringerScience+BusinessMediaB.V.2008 46R.Guenzeletal.MostoftherecentlanguagesorlanguageextensionssupportingCATLMarebasedondiscreteeventsimulators(DES),likeSystemVerilog,SpecCorSystemC.DESusetheconceptofdelta-cyclesasinfinitesimallysmallamountsoftime.Asinglesimulationtimestepcanconsistofmanydelta-cycles,whosenumberdependsonthequantityofconsecutivesignalupdatesandeventnotificationsduringasimulationtimestep.AmajorprobleminCATLMiscombinatorialcalculation,suchascombinatorialarbitrationinbusses.InCATLM,modulesareconnectedviachannelsasanabstractionofRTLwires.ProcessesthatreadvaluesfromsuchTLMchannelsarenotawareoftheprocessexecutionorder,sothattheycannotknowwhethermodulesthatwritetothechan-nelarealreadyexecutedatthecurrentsimulationtimestep.Thus,thereadingmodulecannotidentifythevaluetobevalid.Figure4.1ashowsanexampleofcombinatorialarbitration(IBMCoreConnectOPB[7])inRTL.Allmastersissuetheirrequestsatthesamepointofsimulatedtimebuteachinanotherdelta-cycle,denotedas∆.InRTLthegrantsignalsgetre-evaluatedwitheverychangeofoneoftherequestsignalsandthusproducefalseintermediateresults.ApoorCATLMimplementationoftheOPBarbiterwouldequallygranteachincomingrequest,asitdoesnotknowwhetherhigherpriorityrequestwillarriveduringthesamecycle(Fig.4.1b).Ifonedoes,thenewgranttothehigherprioritymasterimpliestheremovalofthegranttothelowerpriorityone,whichcomplicatesthecode,renderingitlessabstractasnecessary.Ideallyagrantcallshouldonlyappearoncepercycletoobtainmaximumsimulationspeed.Tothisend,thesimula-tionprocessthatreadsalltheinputchannels,calculatestheresultofthearbitration,anddoesthegrantcall,shouldonlyexecuteafterallinputchannelscarryastablerequestvaluefortherecentcycle.Sothisprocesshastobesynchronizedwithalltheinputchannels.Inotherwordsitmustnotbeexecutedbeforeallprocessesthatmightrequestaccesstothebushavebeenexecuted(Fig.4.1c).abcFig.4.1OPBcombinatorialarbitration 4CombinatorialDependenciesinTransactionLevelModels47Intoday’ssystem-leveldesignlanguages,however,thiskindofmanuallycon-trolledpartialprocessexecutionorderisnotsupported.Section4.2willshowhowtheproblemistackledthroughoutacademiaandindustry.InSection4.3wewillintroduceanovelsolutionforthesynchronizationproblemandfinallySection4.4comparesalltheapproachesandweconcludeinSection4.5.4.2KnownSolutionsInthissectionalreadyexistingsolutionstothesynchronizationproblemaredescribedandtheiradvantagesanddisadvantagesarediscussed.Threeimportanttermsthatwillbeusedthroughoutthissectionarealterationcalls(AC),readoutcalls(RC)andthelengthofacombinatorialchain.InCATLMinterfacemethodcalls(IMCs)canbeclassifiedaseithercallsthatalterthestateoftheconnectedchannel(AC)orthatreadthestateoftheconnectedchannel(RC).Acombinatorialchainisconsideredasequenceofcombinatorialdependencies.Forexampleifasignalciscombinatoriallycalculatedoutofsignalsaandb,thelengthofthechainfromatocisone.Ifthereisalsoasignaldwhichgetscalcu-latedoutofasignaleandtheaforementionedsignalc,thelengthofthechainfromatodistwo.Tosimplifymatters,weassumethatthereareeventsthatgetnotifiedifaCATLMchannelchangeditsinternalstate,sotheconnectedmodulescanreacttothesechanges.ThisassumptionistrueformanyrecentTLMframeworks[8,9,11].4.2.1ExplicitRetractionThemostnaivewaysolvingthesynchronizationproblemistoimplementaretrac-tionjustlikeinRTLsimulations:ProcesseswillalwaysassumethatRCsreturnstablevaluesandperformthecorrespondingACs.Afterwardstheywilllistentoaneventindicatingachangeofthechannelstate,andincaseitoccurswillredotheACwithupdatedcontentorhavetoexplicitlyretracttheirpreviousAC(e.g.anOPBarbiterwouldhavetoretractagrantcall).SinceACshaveanimmediateinflu-enceonthemodule(s)connectedtothechannel,themoduleshavetobeimple-mentedexpectingmultipletransfersoverachannelduringasingleclockcycle.Thisintroducesacertainamountofimplementationoverheadandincaseoflargeorbranchingcombinatorialchainstheretractioncanconsumeasevereamountofsimulationtime,asitleadstomanyrecalculations.Furthermore,explicitretractionlimitsthewayinwhichtheCATLMmoduleinternalbehaviorcanbemoreabstractthantheRTLmodulebehavior,sincetheyhavetobeabletohandleglitch-likecom-munication,justasRTLmodulesdo. 48R.Guenzeletal.4.2.2NegativeEdgeExploitationAsintroducedin[6]thesynchronizationbetweencombinatoriallydependentmod-ulescanbedoneusingthenegativeedgeoftheclock.Usingthismethodology,RCsthataresupposedtoreturnstablevaluesshouldbeexecutedatthenegativeedgeoftheclockused,sinceallconnectedchannelswillgetupdatedattherisingedgeoftheclock.Thisschemeworkswellinsmallsystemsandintroducesclosetonoimplementationorsimulationoverhead,butabsolutelyfailswhencombinatorialchainsexceedthelengthofone,becausethedesignersimplyrunsoutofnegativeedges.4.2.3Delta-CycleWaitingAnotherapproachtosynchronizationiswaitinguntilthevaluetobereadbyanRCisknowntobestable.Hereweassumethatallmodulesknowforeachoftheirinputportsthenumberofdelta-cycle(aftertheclockedgehasbeenseen)untiltheinputcanbeconsideredvalid.Ifthisinformationisavailableasanumberrangingfromzero(thedelta-cycleoftheclockedge)toinfinity,eachmodulecandeterminethemaximumandminimumofthesenumbersnamelynandn.SinceinDESasingleprocesscannotdeter-minmaxminefromwhicheventitwasstarted,amoduleprocesssupposedtoperformtheRCsandtheresultingACwillstartduetotheoccurrenceofanyoneofthestatechangeeventsfromoneofitsinputsandthenwaitforn−n+1delta-cycles,maxmintherebyensuringthatalltheinputsarestableregardlesswhichonestartedtheproc-ess.Asaconsequence,thedelta-cycleinwhichthemodulewillperformtheACwilloccurn+1orn−n+1+ndelta-cyclesaftertheclockedgeorinmaxmaxminmaxbetweenthosetwovaluesdependingwhethertheprocesswasstartedbytheearli-est,thelatestorsomeotherevent.Theuncertaintyofthedelta-cycleinwhichtheACoccursiscalleddelta-cyclejitter.4.2.4TimeWaitingThesedrawbacksofdelta-cyclewaitingwerealsoidentifiedbytheOCP-IPSLDWG[9]andwereovercomebywaitingfortimeinsteadofdelta-cycles.Hereamoduledoesnotneedtobeawareofthedelta-cyclesaftertheclockedgeafterwhichtheinputsarestable,butthetimeatwhichinputsarestable.Thus,inputsthatarestableanarbitrarynumberofdelta-cyclesaftertheclockedgearetreatedtobestableasmallfractionofsimulatedtimeaftertheclockedge.ThatmeansthatACsthatoriginateincombinatorialmodulesoccurameasurabletimeaftertheclockedge.Soagainnandncanbeidentifiedandthetimetowaitminmax 4CombinatorialDependenciesinTransactionLevelModels49aftertheoccurrenceofanyinputchannelchangeeventcanbecalculatedas(n−maxn+1)*(periodfraction).Asaresult,thedelta-cyclewaitloopsoftheformerminmethodcanbereplacedbysingletimedwaits,reducingthesimulationoverheadsignificantly.Themajordrawbackofthisapproachis,thatnowadelaythatisnotamultipleoftheclockperiodisintroduced,whichhasnoequivalentintheRTLmodelorevensilicon.TheseadditionallyaddedlatenciescomplicatethecomparisonbetweenRTLandCATLMtraces.Itisimportanttonotethatboththedelta-cycleandthetimewaitingtechniquerelyonaninformationdistributionmechanismthatallowsmodulestoreceiveandsendinformationwhenchannelsgetstablevalues.4.2.5AlwaysTransmittingAfourthwayofsynchronizingisusedbythecycleaccuratesimulationinterface(CASI)ofARM’sRealViewESLAPI[1].InthisapproacheverymoduleperformsallitsACsduringaclockcycle,eitheralteringthestateofthetargetchannelorindi-catingthatnothingistobechanged.Asaconsequence,combinatorialmodulescansimplywaitforallinputchannelstobeupdatedbeforeissuingACsthemselves.Ofcoursethisintroducesasignificantsimulationoverhead,especiallywhenthereareonlyinfrequentrealupdatestochannelsandthereforemany‘no-change’-calls.4.2.6CycleBasedSimulationCyclebasedRTLorgatelevelhardwaresimulatorsareabletoreordereventandprocessexecutionsduetotheknownprocessexecutiondependenciesbasedonsig-nalsensitivities[10].Therebyallsimulationprocessesareexecutedatmostoncepercycle.Inotherwordsallprocessesaresynchronizedtoeachother.However,inCATLMthesimulatorcannotcreatesuchastaticprocessexecutionorderbecauseofthefactthataCATLMprocesscanreadchannelswithoutbeingdirectlyorindi-rectlysensitivetoanyofthechannel’sevents.Hence,thesimulatordoesnotknowwhichAConachannelmightaffectacertainprocesswithoutexecutingit.4.2.7ComparisonInconclusion,explicitretractionshouldbeavoidedasitpreventsthedesignertoraisetheabstractionoftheinternalbehaviorsufficientlyaboveRTL.Negativeedgeexploitationisnotanadequategenericapproachasitlimitscombinatorialchainstolengthone.Thedelta-cyclewaitingapproachproducescorrectresultsbyafair 50R.Guenzeletal.amountofcodeoverheadbutintroducesanunacceptablesimulationoverhead,whilethetimewaitingapproachrequiresonlysmallcodeandsimulationoverheadbutproducesundesirabledelays.Finallythealwaystransmittingtechniqueprovidesaccuratesimulationresultsandiswellsuitedfordesignsinwhicheachmodulecommunicatesintensively,butleadstosignificantsimulationperformancelossesifmodulescommunicateonlyinfrequently(seeSection4.4forexperimentalresults).Section4.2.6showedthatknowledgeaboutprocessexecutiondependenciesmayalsohelpsolvingthesynchronizationproblem.4.3ANovelSynchronizationApproachThecomparisonofcombinatorialcalculationtechniquesintransaction-levelmode-lingpointsout,thatallexaminedapproacheseitherlacksimulationperformanceorintroduceaconsiderableoverheadintermsofdevelopmenteffort.Themostappealingapproachesarethedelta-cyclewaitingandtimewaitingtechniques,astheyintroducedonlyasmallimplementationoverhead.BothachievesynchronizationbymovingthecalloftheRCtoadelta-cycleinwhichitisknownthattheRCwillreturnastablevalue.Whiledelta-cyclewaitingcreatesexactsimu-lationresults,itsmajordisadvantageisthatthesimulationoverheadquicklybecomessignificant.Anidealsolutionshouldbothprovidetheaccuracyofthedelta-cyclewaitandperformasfastasthetimedwait.Inthefollowingourapproachbasedonsynchronizationlayersispresented,whichmeetstheserequirementsandisbasedonprocessexecutionreorderingsimi-lartocyclebasedsimulation.4.3.1BasicDefinitionsBeforewedescribeourapproachindetail,somedefinitionsareneeded:AsstatedinSection4.2foreachchannelchinaCATLMsystemthereisasetofACsdenotedasAC(ch)andasetofRCsdenotedasRC(ch).Foreachgivenchan-nelinaCATLMmodelappliesthatachannelcanbereadandwritten:AC(ch)≠Ø&RC(ch)≠Ø.(4.1)FurthermoreforeachcŒAC(ch)thereisasetofRCswhosereturnvaluesgetalteredbycallingc,whichisdenotedasa(c,ch).TheremaybeIMCsthatareACaswellasRC,whichisonlyallowedifthecalldoesnotalterthevalueitreturns,inotherwords: 4CombinatorialDependenciesinTransactionLevelModels51cŒAC(ch)ÇRC(ch)ficÏα(c,ch)(4.2)ForeachmoduleminagivenCATLMmodelthereisasetofportsthatareownedbythismodule,denotedasπ(m).EachpŒπ(m)isboundtoexactlyonechannelch,sothateachIMConpaffectsch.Functioncon(p)returnsthechannelwhichpisconnectedto,functionpar(p)returnsthemodulethatownstheportp.ForeachIMCcandchannelch,π(c,ch)returnsallportswhichareconnectedtochandmayissuec.BecauseIMCsinCATLMhaveamappingtoRTLsignals,andRTLsignalsmaynothavemorethanonedriver,cŒAC(ch)fip(c,ch)=1.(4.3)AcombinatorialdependencybetweenanRCandanACinamodulecanbedefinedasapairoftriples((m,p,c),(m,q,d))wheremisamodule,pŒπ(m)andcŒRC(con(p))andchastoreturnastablevaluebeforedŒAC(con(q))withqŒπ(m)canbecalled.Inthefollowingm,p,c,dandqarealwaysdefinedasbeforeifnotstatedotherwise.Foreachsuchtriplet=(m,p,c)lett(t)bethesetofalltriples(m,q1,d1)…(m,qn,dn)thatfulfilltheaforementionedproperty.SotisbasicallythesetofACsthatwillbedirectlyexecutedaftertheRCconportpofmodulemhasbeencalled.ThesetofcombinatorialmodulesinagivenCATLMmodelmodiscalledk(mod),andforeachmŒk(mod)thereisatleastonetriplet=(m,p,c)suchthat:t(t)Ï∆.4.3.2SynchronizationLayersThenovelsynchronizationapproachwillbebasedonsynchronzationlayersthatcanbedefinedasapropertyofatriple(m,p,c)withmŒκ(mod),pŒπ(m)andcŒAC(con(p))ÈRC(con(p)).ThispropertycanbeassignedtoatripletbySL(t,newsl),wherenewslisanon-negativeintegerandcanbereadfromatripletbySL(t).Ifasynchronizationlayerofatripleisnotassignedyet,SL(t)willreturn0.Figure4.2showsasimplesystemwithtwocombinatorialarbiters.Mastersissuerequestsontheirchannelsandarbiterscombinatoriallyforwardthehigherpriorityrequesttotheiroutputs.Thetargetwillacceptrequestsandsignalsthisacceptancewithinthesamecycle.Thetargetisimplementedinawaythatitonlyexpectsasinglerequestpercycle,whichenablesahighsimulationperformanceasinternalhousekeepingcanbekeptsmall.WeassumethatthemastersandarbitersuseanACnamedstartReqtoputarequestonachannel.ThetargetandthearbitersuseanRCnamedgetReqtogetarequestfromachannel.ThenumbersannotatedonchannelsandportsinFig.4.2representthedesiredexecutionsequenceofthoseACsand 52R.Guenzeletal.Fig.4.2SynchronizationlayerdeterminationRCs.ThenumbersofthechannelsandoutputportsrelatetoACs,whilethenum-bersoftheinputportsrelatetotheRCs.Thesemanticisthatacallwithnumberxhastobecalledbeforeacallofnumbery>x,therebyensuringthatACsonachan-nelarealwayscalledbeforeRCs.Wedenotethesenumbersassynchronizationlayers.WiththedefinitionsfromSection4.3.1thefollowingfunctionscanbedefined:functionsetSLp(p,c,newSL);pisport;cisRC;newSLisinteger;setSLm(par(p),p,c,newSL+1);end;functionsetSLm(m,p,c,newSL);mismodule;pisport;cisRC;newSLisinteger;if(SL(m,p,c)WrapperStatement(reset.read(),"reset.read()",tIFELSE,10,125,12,203,22,419,"prog_count.cc","prog_count","next_state",this)){9pc=0;10}else{11...Fig.6.5Instrumentedcodeofthenextstatemethodinformationfortheelse-block,butonlytheendpositionoftheelse-blockisused;theelse-blockendsinline22atcharacterposition419.Then,thefilenamewherethemethodisimplemented(prog_count.cc),theclassname(prog_count),themethodname(next_state)andthethispointeraregiven.InaSWITCH-CASEstatementatthebeginningofeachCASE-blockweinstru-mentawrapperfunctionthathasasadditionalargumentthevalueofthecurrentcase.AfteraSWITCH-CASEstatementawrapperfunctioncallisinstrumentedthatenablesthepropagationofallpossibleCASEvalues.Notethattheapproachisabletohandlealsonestedvariantsofalltypesofcontrolstatements.Inthenextsectionthecoverageanalysisphaseisexplained.6.3.4CoverageAnalysisAfterthecompilationoftheinstrumentedSystemCcodethecoverageanalysisisexe-cutedduringsimulation.Basedontheinstrumentedwrapperfunctionstheinstanceofthecoverclasscollectsallthecoveragedata.ThemaindatastructuresinthecoverclassarebasedonStandardTemplateLibrary(STL)maps.Asuniquekeystheargu-mentsofthewrapperfunctionsaretransformedintoastringrepresentation.Toeachcoveragepointweassociatetwocounterstotrackthefrequencyoftheevaluationofthecorrespondingconditiontotrueorfalse.Forcasestatementsobviouslyonlyonecounterisneeded.Finally,inthecoveragereportthatisstartedbyacallfromsc_mainaftertheendofthesimulation,thecoveragedataisanalyzed.ForIF,IF/ELSEawarn-ingisgeneratediftheconditionwasalwaystrue/falseandthusablockwasneverexe-cuted.IncaseofFORloopsorWHILEloopsweinformtheuseriftheconditionwasfalseallthetimeandthereforetheloopbodywasskipped.ForSWITCH-CASEstate-mentseachcaseisidentifiedthatwasneveractivated.Intotalthisallowstoargueaboutthequalityofthetestsdefinedbythetestbench.Ifblockshavebeenidentifiedthathavebeenneverexecutedtheseblocksaredeadcodeorthetestbenchhastobeimproved. 80D.Großeetal.Inthefollowingexampletheresultsofthecoverageanalysisareshownfortheprogramcounter.Example3AtestbenchhasbeenwrittenfortheprogramcountershowninFig.6.3.Thetestbenchincludesthreetests.Weappliedourapproachforthisexample.TheautomaticallygeneratedcoveragereportisshowninFig.6.6.Ascanbeseenthesce-nariotoloadavalueintotheprogramcounterbysettingloadenabletoonewasnotexecuted.Weaddedanothertestforthisbehaviourandtherebyclosedthisgap.<>IF-ELSEStatement:*IF-BLOCKNOTEXECUTED*Filename:prog_count.ccClass:prog_countInstance:pcFunc.Member:next_stateCondition:le.read()IFstart:line14pos246IFend:line16pos322counttotal:87countTRUE:0countFALSE:87Fig.6.6Coveragereportforprogramcounter6.4CaseStudiesInthissectionweapplytheapproachtotwoexamples.Thefirstexampleisahard-wareorientedmodel,aRISCCPUisconsidered.Thesecondexampleisasystemforcolourregionrecognitioninvideodata.6.4.1HardwareModel:RISCCPUBeforeweapplyourmethodtotheRISCCPUthebasicdataoftheCPUisbrieflyreviewed(see[9]formoredetails).6.4.1.1SpecificationInFig.6.7thecomponentsoftheRISCCPUareshown.TheCPUhasbeendesignedasHarvardarchitecture.Thedatawidthoftheprogrammemoryandthedatamemoryis16bit.Thesizeoftheprogrammemoryis4kBandthesizeofthedatamemoryis128kB.Thelengthofaninstructionis16bit.Webrieflydescribethefivedifferentclassesofinstructionsinthefollowing:sixload/storeinstructions,eightarithmeticinstructions,eightlogicinstructions,fivejumpinstructionsandfiveotherinstructions.FortheRISCCPUacompilerhasbeenimplementedwhich 6MeasuringtheQualityofaSystemCTestbenchbyUsingCode81Fig.6.7RISCCPUincludingdataandprogrammemorygeneratesobjectcodefromanassemblerprogram.ThisobjectcoderunsontheSystemCmodel,i.e.themodeloftheCPUexecutesanassemblerprogram.6.4.1.2TestbenchQualityBasedonsuccessfulsimulationofeachcomponentthedesignerstartswiththesimu-lationatthesystemlevel.Forthispurposeusuallyahigh-leveltestbenchiscreatedthatenablesablack-boxtestofthedesign.FortheCPUsuchatestbenchcorre-spondstotheexecutionofasetofassemblerprogramsincludingtheanalysisofthesimulationresults.Inthefollowingwedescribehowthehigh-leveltestbenchwascreatedandhowthisprocesswasimprovedbyourapproach.TheSystemCmodeloftheRISCCPUwasautomaticallyinstrumentedwithcodetoanalyzecoverage.Thefollowingnon-trivialassemblerprogramwasformulatedtotesttheCPU. 82D.Großeetal.Example4TheassemblerprogramshowninFig.6.8convertsasetofnumbersintogray-code.Thegraycodeencodesnumberssuchthatinthebinaryencodingadjacentnumbershaveahammingdistanceof1.Thenumbernofelementstobeconvertedisgiveninthedatamemoryataddress0.AfterclearingtheregisterR[6]andR[2],nisloadedintoregisterR[3].Then,intheloopeachsinglenumberisconverted.Theideaistoinverteachbitifthenexthigherbitoftheinputvalue(readfromthedatamemoryintoregisterR[4])issettoone.ThereforetheinputisshiftedbyoneandabitwiseXORoperationisperformed.TheresultR[6]oftheconversionisstoredinthedatamemorytothesamepositionastheinput.1LDLR[6],02LDHR[6],03LDLR[2],04LDHR[2],05LDDR[3],R[2]6loop1:7ADDR[2],R[2],R[1]8LDDR[4],R[2]9ADDR[5],R[4],R[0]10SHRR[5],R[5]11XORR[6],R[4],R[5]12STOR[2],R[6]13SUBR[3],R[3],R[1]14JNZloop115HLTFig.6.8AssemblerprogramforgraycodeAftersimulationofthegraycodeprogramontheCPUourapproachreportedunexecutedcodefragmentsinthefollowingmodules:stack_point,mux4,mux5,mux6,mux7andalu.Thehandlingforthecasesofpushandpopoperationsinthestack_pointmodulewasnottested,sincetheinputsfromthecontrolunittothismodulehavebeenzeroduringthecompletesimulation.Totestthisbehaviouranotherprogramthatusespushandpopinstructionshastobeadded.Forthemultiplexormoduleswefoundthatinthemethoddo_selectwhichdescribesthefunctionalityofamultiplexoronlytheELSE-blockfortheselectconditionwassimulated.FortheCPUthisobservationcorrespondstothefactthattheselectinputsofthemultiplexorshavebeenzeroallthetimeandthusonlyonedatainputwasroutedtothemultiplexoroutput.AscanbeseeninFig.6.7allmul-tiplexorsbelongtothedatapathoftheCPU.ToalsotesttheeffectsontheCPUincaseofdatacomingthroughtheotherinput,adifferentdatapathhastobeacti-vated.Themultiplexormux5ispartofthestackpointerdatapathandthuswastestedbyusingstackpointeroperations(seeabove).Formux4andmux6thealter-nativedatapathisactivatedbyaddingaprogramthatusessub-routinecalls.Formux7wesettheselectinputtoonebyanadditionalprogramthatusesI/Oinstructions.IncaseoftheALUseveralCASEstatementsofthemainSWITCHstatementhavenotbeenexecutedsincenotalloperationsoftheALUareactivatedbythe 6MeasuringtheQualityofaSystemCTestbenchbyUsingCode83consideredassemblerprograms.Thereforewecreatedanotherprogramtochecktoremainingarithmeticoperations.Intotalbyaddingadditionalassemblerprogramstothetestbenchthequalityofthetestbenchwasimproved.HereourapproachsupportedtheverificationengineerbydirectlypointingtountestedfunctionalityoftheRISCCPU.6.4.2High-LevelModel:ColourRegionRecognitionInthesecondexampleweappliedourapproachtoahigh-levelSystemCmodelofavideoprocessorSystem-on-Chip.IncontrasttotheRISCCPU(whichhasbeenimplementedasanRTLdesign),thismodelresidesatthetransaction-levelofabstraction.6.4.2.1SpecificationTheconfigurablemodelEmVidconsistsofasetofSystemCcoresthatcanbeinte-gratedtobuildavideoprocessor.Forvideoinputandoutput,abstractTLMchannelsareused.ThevideoprocessingIPcoresusetheSystemCHigh-levelInterfaceProtocol(SHIP)[10]fordataexchangeoverthesechannels.Communicationwiththemainmemory(DDRRAM)isestablishedbyST’sTACprotocol[12].Inthefol-lowing,weconsideraSystem-on-ChipforcolourregionrecognitionthatisbasedonEmViDcores.Thesystemprocessesvideoframesinreal-timeanddrawsrectanglesarounddetectedregions.Ahigh-levelschematicofthesystemisshowninFig.6.9.ThesystemhasbeenconfiguredasapipelinedarchitectureandfortheconnectionFig.6.9Colourregionrecognitionschematic 84D.Großeetal.oftheDDRRAManIBMCoreConnectOn-ChipPeripheralBus(OPB)isused.Thecompletetransaction-levelinterconnect(includinganOPBsimulationmodel)issetupusingtheGreenBusTLMfabric[11].EmViDcanbefoundon[4].ThevideoprocessingstartsbyreadinginanMPEGvideoasvideoinput.Then,dilationanderosionisperformed.Inthelabellingstagetheregionsarerecognizedandtherectanglesareadded.Afterwardsthecoreoutputstheimagetoadisplay.6.4.2.2TestbenchQualityAsaconcreteapplicationwedecidedtodetectskinsinthevideodata.Wesetthecolourrangefortherecognitionaccordingly.Thesystemsegmentatestheprocessedvideodatainthelabellingphase.Thereforeadjacentpixelsareanalyzedandtheimageispartitionedintoasetofregionsusingthedefinedcolourinformation.Intheoverallvideoprocessorsystemthehigh-leveltestbenchconsistsofthevideodata(comingfromvideofilesoracamera).Weappliedourapproachtothesystem.Wesimulatedthesystemwithdifferentvideofilesandobservedthatdependingonthevideodatadifferentpartsofthesystemhavenotbeenexecuted.Forexample,inthemorph_segmmodule(labellingphase)thesegmentationalgo-rithmcheckstheminimumregionsizewithanIF-condition.Forvideodatathatcontainsnoskinsorverysmallareasnoregionsaredetected.Here,ourapproachpresentsdirectlytheSystemCfilewiththeexactsourcecodepositionoftheneverexecutedblock(s).Notethatthisimprovesthedebuggingduringthedevelopmentofsuchhigh-levelmodelssignificantly.Moreover,analyzingtheresultsofnestedcontrolstructures,ourapproachhelpstheverificationengineertotestthedesignthoroughly.Togiveanexample,theseg-mentationalgorithmisrealizedasastatemachinewith47states,whicharetra-versedindifferent(partial)executionordersdependingonthevideoinputdata.Withtheoutputofthecoverageanalysis,untakencontrolpathscanbediscoveredandthestimulusvideomaterialcanbeadjustedaccordingly.6.4.2.3FurtherDesignAnalysisDuringtheanalysisofthevideoprocessormodel,wealsoexperimentedwithdif-ferentcommunicationarchitectureconfigurationsforthedesign.Asonemightexpect,somearchitecturesarebettersuitedthanotherstomeetefficiencyrequire-mentssuchasagivenframerate.Inparticular,whenconnectingallcomponentstoasharedbuswithfixed-priorityscheduling(here,theOPB),theoverallvideoprocessingperformancehighlydependsonthepriorityallocation.Weutilizedtheabilityofourcoverageanalysistocountthenumberofexecu-tionsforthevariousprocessesinthemodelinordertoidentifythelocationofcommunicationbottlenecksindesignconfigurationswithpoorframerates.Table6.1presentssomeresultsoftheexperiments. 6MeasuringtheQualityofaSystemCTestbenchbyUsingCode85Table6.1Videoprocessorexecutiontraces#ex#exFPSFPSConfigvideodetect.videodetect.CommentBusonlymodel150050024.9824.98AscendingpriorityBusonlymodel245187222.5543.60HigherdetectionpriorityMixedbus/pipelinemodel150050024.9824.98LowerpipelinepriorityMixedbus/pipelinemodel250099924.9849.90HigherpipelinepriorityThecolumn“#exvideo”showsthetotalnumberofvideoframessuccessfullysentfromthevideoinputcomponent(mpegdecoder)tothevideooutputcompo-nent(displaycontroller).Thecolumn“#exdetect.”showsthetotalnumberofvideoframesprocessedbytheregiondetection.Fromthesenumberstheoverallframerateshavebeencalculated(columns“FPSvideo”and“FPSdetect.”).Row1androw2showtheframerateswegotwithabus-onlymodel.Whileinrow1,thebusaccessprioritieswereassignedinascendingorderaccordingtothesequenceofvideoprocessingstagesinthemodel,inrow2weassignedahigherprioritytotheregiondetectioncomponentsthantothevideodisplaydatapath.Asexpected,theframespersecondprocessedforregiondetectiongoesup,butasanunintentionalsideeffectduetohigherbusworkload,thenumberofvideoframesdis-playedperseconddropsdown.Rows3and4showtheresultsweachievedwithamixedbus/pipelinemodelasdepictedinFig.6.9.Here,wecouldconsiderablyincreasethevideodisplayframeratebyjustswappingthebusaccessprioritiesoftwocompo-nents.Withthissetup,~25framespersecondfullresolutionlivevideodisplayisachievedwhiletheregiondetectionrunsatthehighrateof~50framespersecond.6.5ConclusionsInthispaper,wehavepresentedanapproachtomeasurethequalityofatestbenchforaSystemCdesign.Theapproachisbasedondedicatedcodecoveragetech-niquesusingaSystemCfront-end.Thus,areliablefeedbackforuntestedpartsofthedesignispresentedtotheuser.ThisdataincludesexactsourcecodeinformationincombinationwithSystemCspecificinformation,likeprocesscontextandmod-ulehierarchy.Insummary,ourapproachhelpstocreateahighqualitytestbench.TheexperimentsshowedthatourapproachissuitableforbothRTLandTLMdesigns.Moreover,theTLMexamplerevealedthatouranalysismethodologyalsocansupportdesignspaceexploration.References1.B.Beizer.SoftwareTestingTechniques.Wiley,NewYork,1990.2.L.CaiandD.Gajski.Transactionlevelmodeling:anoverview.InCODES+ISSS’03,pp.19–24,2003. 86D.Großeetal.3.R.Drechsler,G.Fey,C.Genz,andD.Große.SyCE:AnintegratedenvironmentforsystemdesigninSystemC.InIEEEInternationalWorkshoponRapidSystemPrototyping,pp.258–260,2005.4.EmViD:EmbeddedVideoDetection.http://www.greensocs.com/GreenBench/EmViD.5.G.Fey,D.Große,T.Cassens,C.Genz,T.Warode,andR.Drechsler.ParSyC:AnefficientSystemCparser.InWorkshoponSynthesisAndSystemIntegrationofMixedInformationtechnologies(SASIMI),pp.148–154,2004.6.R.S.French,M.S.Lam,J.R.Levitt,andK.Olukotun.Ageneralmethodforcompilingevent-drivensimulations.InDesignAutomationConference,pp.151–156,1995.7.http://gcc.gnu.org/onlinedocs/gcc/Gcov.html.8.C.GenzandR.Drechsler.SystemexplorationofSystemCdesigns.InIEEEAnnualSymposiumonVLSI,pp.335–340,2006.9.D.Große,U.Kühne,andR.Drechsler.Hw/swcoverificationofembeddedsystemsusingboundedmodelchecking.InGreatLakesSymp.VLSI,pp.43–48,2006.10.W.Klingauf.SystematictransactionlevelmodelingofembeddedsystemswithSystemC.InDesign,AutomationandTestinEurope,pp.566–567,2005.11.W.Klingauf,R.Günzel,O.Bringmann,P.Parfuntseu,andM.Burton.Greenbus:Agenericinterconnectfabricfortransactionlevelmodelling.InDesignAutomationConference,pp.905–910,2006.12.S.Microelectronics.TAC:TransactionAccurateCommunication.http://www.greensocs.com/TACPackage,2005.13.OpenSystemCInitiative,http://www.systemc.org.SystemC2.1LanguageReferenceManual,2005.14.T.Parr.LanguageTranslationusingPCCTSandC++:AReferenceGuide.AutomataPublishing,SanJose,CA,1997.15.SystemCVerificationWorkingGroup,http://www.systemc.org.SystemCVerificationStandardSpecificationVersion1.0e.16.S.TasiranandK.Keutzer.Coveragemetricsforfunctionalvalidationofhardwaredesigns.InIEEEDesignandTestofComputers,18(4),pp.36–45,2001.17.J.Yuan,C.Pixley,andA.Aziz.Constraint-basedVerification.Springer,NewYork,2006. Chapter7SystemC-BasedSimulationoftheMICASArchitectureDragosTruscan1,KimSandström2,JohanLilius1,andIvanPorres1AbstractWepresentourapproachinusingSystemCforsimulatingacustomconfigurablearchitecture,MICAS.However,therearecertainaspectsofthearchitecture,likeconfigurationspecificinformationorprogramminginterface,whichcannotbedirectlyrepresentedusingSystemCconcepts.Thus,wedefineaC++-basedspecificationlanguageforMICASthatallowsustospecifyadditionalpropertiesofthearchitectureatsimulationlevelandfurthermore,tocombinethesepropertieswiththeSystemCexecutablespecification.KeywordsSystem-on-Chip(SoC),ServiceOrientedArchitecture(SOA),SystemCsimulation,executablespecification7.1IntroductionDuetotheincreasingcomplexityofsystemspecificationssimulationhasbecomeanecessarytoolforsystemdesigners.Simulationenablestheevaluationofsystemspecificationsagainstrequirements,atearlystagesofthedevelopment,beforepro-ceedingtohardwareimplementation.Theapproacheliminatescostsandshortensthedesignlifecycleofnewproducts.AccordingtoMoretti[1],mostoftheinte-gratedcircuitsdevelopedtodayrequireatleastonereturntoearlyphasesofthedevelopment,duetoerrors.Inrecentyears,SystemC[3]hasbecomeoneofthemostpopularlanguagesforsystem-levelmodelingandsimulation.SystemCisanextensionofC++,inwhichthehardwarecomponents(i.e.,modules)ofthearchitecturearespecifiedasC++classes.Agivenarchitecturalconfigurationisrepresented,atsimulationlevel,as1ÅboAkademiUniversity,Joukahaisenkatu35,FIN20500,Turku,FinlandEmail:{Dragos.Truscan,Johan.Lilius,Ivan.Porres}@abo.fi2NokiaResearchCenter,P.O.Box407,FIN00045NokiaGroup,Finland;Email:Kim.G.Sandstrom@nokia.comE.Villar(ed.)EmbeddedSystemsSpecificationandDesignLanguages,87©SpringerScience+BusinessMediaB.V.2008 88D.Truscanetal.moduleinstancesinterconnectedatportlevel.SystemCadvocatesreuseatcodeandcomponentlevel,allowingthereuseofthedevelopedcomponentsfromonedesigntoanother.Theapproachfacilitatestheuseofcomponentlibrariesforrapidcreationofnewdesigns.Inourwork,wehaveemployedSystemCtoprovideexecutablespecificationsofaconfigurablearchitecture,namelyMICAS[4].MICASisconfigurablenotonlybecausedifferenthardwareconfigurationscanbebuiltbyaddingnewcomponents,butalsobecausetheprogramminginterfaceofagivenconfigurationcanbecustom-ized,atdesigntime,tofacilitatetheapplicationmappingonthearchitecture.TheMICASdesignflowusesacomponentlibraryfromwhichSystemCspecificationsofMICASresourcescanbeinstantiatedatsimulationtime.However,therearecer-tainaspectsofMICASthatcannotbedirectlymodeledinSystemC.Forinstance,uponinstantiationdifferentmodulesaddedtoagivenMICASconfigurationhavetobeadornedwithconfigurationspecificinformation,likeaddressspaces,IRQnum-bers,etc.Suchinformationisnottypicallystoredinacomponentlibraryinordertoincreasethereusabilityofcomponentspecifications.Similarly,theprogramminginterfacethatisdesignedforaspecificconfigurationcannotbestoredinthecompo-nentlibrary,butratherhastobegeneratedforeachconfigurationinpart.InordertointegrateconfigurationspecificinformationwiththeSystemCexe-cutablespecificationofagivenconfiguration,wedefineaC++-basedspecificationlanguageforMICAS.Thislanguageenablesustoexpressadditionalpropertiesofthearchitectureinanexecutableform,easytointegratewithintheMICASsimula-tionframework.Weproceed,inSection7.2,withageneraloverviewoftheMICASarchitectureandofitsdesignprocess.Then,weintroduce,inSection7.3,aC++-basedspecifi-cationlanguagefortheMICASarchitecture.InSection7.4weshowhowthislan-guageisusedtodescribeMICASconfigurationsandhowtheresultingspecificationisintegratedwiththeSystemCsimulationframeworkofMICAS.WealsodiscussthecustomizationsappliedtotheMICASSimulationlibrarysuchthatthesimula-tionmodelofagivenconfigurationcanbeautomaticallygenerated.Weconcludewithfinalremarks.7.2TheMICASArchitectureMicrocodeArchitectureForaSystemOnaChip(SoC)(MICAS)[4]isanovelconceptdevelopedatNokiaResearchCenter,Helsinki,Finland,whichproposesbothaSoCarchitectureforsequentialdatastreamingprocessingsystems(e.g.,multimediaapplications,personalvideorecorders,mediastreamingapplications,etc.)andamethodforcontrollingthehardwareacceleratorsofsucharchitectures.SeveralgoalsarepursuedinMICAS:●Separationofthedata-andcontrol-flowsofthearchitecture,byusingdedicatedhardwareunits(HWprocesses)toassistdataprocessingtasksandcontrollerstodrivetheactivityoftheseunits. 7SystemC-BasedSimulationoftheMICASArchitecture89●Decentralizationofthecontrolcommunicationfromthe“mainprocessor”ofthesystem,typicallyrunningareal-timeoperatingsystem(RTOS),andthedistri-butionofthiscommunicationtodedicatedcontrollers,whichonlycontrol“local”resources.●Theuseofmicrocode(i.e.,softwarerunningoncontrollers)tocontrolthefunc-tionalityoftheHWprocessesandofthedatastreamingbetweenthem.Themicrocodeprovidesahardwareabstractionlayer(HAL)ofthearchitecture,whichallowsonetocreatedatastreamsbetweenHWprocessesandtoinvokethefunctionalityofagivenHWprocessusingastandardinterface.7.2.1HardwareArchitectureAnoverviewoftheMICASarchitectureisgiveninFig.7.1.AMICASconfigura-tioncomprisesseveraldomains.Adomainrepresentsacollectionofhardwareprocessingelementssituatedonthesamephysicalsiliconchipandcontrolledbythesamecontroller.Domainsprovidefastprocessingspeedfordedicatedtasks.Theyareinterconnectedbyoff-chipexternalnetworksusingforinstance,serial,BluetoothorWLANtechnology.Domain1Domain2(master)(slave)controllermodulemoduleclusterbussocketnetworksocketbusclusterRTOScontrollerbridgemodulemodulebusclustermodulemodulemoduleDomain4Domain3(slave)controller(master/slave)socketmodulemodulenetworkclustersocketsocketbusclustermodulebuscontrollerFig.7.1GenericviewoftheMICASarchitecture 90D.Truscanetal.Theorganizationofdomainsishierarchical,followingamaster-slaverelationship.Typically,onedomainofagivenMICASconfigurationisconnectedtoageneralpurposeprocessorrunninganRTOS,likeSymbian[2].Suchadomainiscalledmas-terdomain.Domainsconnectedtoamasterdomainareregardedasslavedomains.EachMICASdomainmaycontainseveralprogrammablehardwarecomponents,HWprocesses,whichimplementdedicatedtasksinhardware.HWprocessesareuniversallyinterconnectedviabusesandmaybegroupedintoclusters.TheremaybethreetypesofHWprocessesinsideaMICASdomain:bridges,socketsandmodules.Busesbelongingtodifferentclustersmaybeconnectedtoeachotherthroughbridges.Socketsmediateandtransformtheon-chipcommunicationintooff-chipcommunica-tion,whereasmodulesimplementdedicatedprocessingtasksoverstreamsofdata.7.2.2ProgrammingInterfaceTheMICASprogramminginterfacedefinesasetofservicesthatcanbeusedtoinvokecomplexfunctionalityofagivenMICASconfiguration.Theservicesaredefinedperdomainandareimplementedasaconsistentcombinationof(data)streamsbetweenHWprocesses.Domaincontrollersserveasacontrolinterfacetoanyexternalentity(i.e.,MICASdomainorRTOS).Anyrequestforaservicefromtheexternalenvironmentishandledbythecontroller,whichimplementsthestreamsofagivenservicebydispatchingthecorrespondingmicrocommandstotheappropri-ateHWprocesses.TheconceptofsubserviceofaserviceisusedinMICAStodepictaservicefromaremotedomainthatisusedbyaserviceinagivendomain.7.2.3TheMICASDesignProcessAnoverviewoftheMICASdesignprocessisgiveninFig.7.2.StartingfromtheApplicationRequirementsoneidentifiestheservices(i.e.,ServiceList)thatagivenMICASconfigurationhastoprovide.Theseservicesrepresenttheprogram-minginterfaceofthatparticularconfiguration.IntheServiceSpecificationphase,eachserviceisspecifiedintermsofdatastreams.Inturn,eachstreamisimplementedasacombinationofmicrocommandsusedtoprogramthecorrespondingHWprocesses.Basedonthemicrocommandsrequiredtoimplementthestreams,HWprocessesareaddedtothedomainunderdesignintheHwConfigurationphase.Threeartifactsareproducedafterthecompletionofthepreviousphases:●ServiceDescription–specificationoftheservicesofagivenconfiguration,andtheirimplementationintermsofstreamsandmicrocommands;●StructuralConfiguration–thehardwarecomponentsoftheconfigurationandtheirinterconnections;●FunctionalConfiguration–configurationspecificproperties(addressspaces,IRQs,etc.)oftheselectedhardwarecomponents. 7SystemC-BasedSimulationoftheMICASArchitecture91ApplicationArchitectureSimulationRequirementsSpecificationLibraryMICASServiceIdentificationServiceHardwareServiceListSpecificationConfigurationApplicationImplementationHWconfigurationApplicationServiceFunctionalStructuralCodeDescriptionConfig.Config.SimulationFig.7.2MICASdesignprocessAllthesethreeartifactsserveasinputtotheSimulationphasealongwiththeexecutablespecificationsoftheselectedhardwarecomponents.However,outoftheseartifacts,onlytheStructuralConfigurationofthearchitecturecanbespecifiedusingSystemC,morespecificallyviathemain.cppfile.Adifferentapproachhastobeemployedfortheremainingtwoartifactsinordertospecifytheminanexecutableform,easytointegratewiththesimulationenvironment.ToaddressthisissuewedefineaC++-basedspecificationlanguagefortheMICASarchitecture.7.3AC++-BasedSpecificationLanguageforMICASTheMICASC++-basedspecificationlanguagemodelsMICASresourcesusingtypedefinitions.Astructdatatypeisusedtodefinetheseresources,whilethefieldsofeachstructtypeareusedtorepresenttheirproperties.TheapproachallowstheuseofMICASresourcesaspropertiesofotherMICASresources.7.3.1SpecifyingtheFunctionalConfigurationAtthehighestlevel,aMICASconfigurationiscomposedofseveraldomains.Thus,aDomaindatatypeisdefinedasfollows: 92D.Truscanetal.structDomain{std::stringname;unsignedintdomain_id;Bus*busList[10];intb_no;Process*processList[10];intm_no;structProcess*master_domain_socket;structProcess*master_domain_ctrl_socket;structProcess*slave_domain_socket;structProcess*slave_domain_ctrl_socket;unsignedintDPRAM_int;unsignedintint_ctrl_reg_addr;};Anameandanumericdomain_idareusedtoidentifythedomainduringthesimu-lation.Thedomaincontainsanumber(m_no)ofprocessesstoredintheprocess-Listarray,eachofthembeingcharacterizedinturnbyspecificinformation.Inaddition,anumber(b_no)ofbusesarepresentineachdomain,andtheyaresimilarlystoredusingabusListarray.Theexternalconnectionsofthedomainaremodeleddirectlybythesocketspresentinthatdomain,specifyingwhetherthesesocketsareconnectedtoamasterortoaslavedomain.Thesocketdescriptionmaybeseenasa“routingtable”fortheinter-domaincommunication.InourcurrentMICASimplemen-tation,wehaveassumedthatadomainmayhaveatmosttwosocketscommunicatingwithitsmasterorslavedomainsrespectively,butamoregeneralapproachmaybefollowed.Werecallthatdomainshaveahierarchicalrelationshiptoeachother,beingpossibleforeachdomaintohaveamasterdomainand,atthesametime,beingitselfmastertoanother(slave)domain.Twosetsofpointersaremodelingthisinformation.Themaster_domain_socketandthemaster_domain_ctrl_socketareusedtoindicatetothecontrollerthesocketthroughwhichthedataandrespectively,thecontrolcommunicationwiththemasterdomainhastobedirected.Similarly,apairslave_domain_socket–slave_domain_ctrl_socketindicatestothecontrollerthesocketsthroughwhichthedataandthecontrolcommunication,respec-tively,withtheslavedomainhastobeforwarded.Anullpointerinoneofthesefieldsindicatesthatnomasterandrespectively,noslavedomainareconnectedtothedomaininquestion.TheprocessorrunningtheRTOSisconnectedtotheMICASmasterdomainthroughaDPRAMmoduleusinganinterrupt-basedmechanism.Wemodelitasaseparateentry(DPRAM_int),notonlybecausethisisahigh-priorityinter-rupt,butalsotoallowspecifyingexplicitlyifanRTOSisconnectedtoadomain.Anon-validvalueassignedtothisfieldindicatesthatnoRTOSiscon-nectedtothedomaininquestion.Finally,eachcontrollerhasaninterruptcontroller,throughwhichitcommunicatesviaacontrolbus.WhenaninterruptisraisedbyanyoftheHWprocessesinthedomain,thecorrespondinginterruptnumberispassedtothecontrollerviaacontrolregister,whoseaddressismodeledbytheint_ctrl_reg_addrfield. 7SystemC-BasedSimulationoftheMICASArchitecture93EachHWprocessincludedintheprocessListofagivendomainischar-acterizedbyitsownsetofproperties,asshowninthefollowingtypedefinition:structProcess{std::stringname;enummicas_process_typetype;unsignedintctrl_reg_addr;unsignedintmaster_reg_addr;unsignedintslave_reg_addr;unsignedintirq;unsignedintslave_data_buffer;unsignedintmaster_data_buffer;};Thenameisusedduringthesimulationfordebuggingpurposes,whereasatypepropertyspecifieswhethertheHWprocessisamodule,abridgeorasocket,basedonthedefinitionofthemicas_process_typeenumeration,whichweomithere.Basedonitsplacementrelativetotheotherelementsinadomain,aHWproc-essischaracterizedbyothertypesofinformation,likeaddressspacesusedforcommunicationpurposes.HWprocessesarecontrolledbythecontrollerviaacon-trolbus,towhichtheHWprocessisconnectedbyacontrolregister.TobeabletouniquelyidentifyeachHWprocessonthebus,eachcontrolregisterisassignedauniqueidentifier,thecontrol_register_address.WhenthecontrollerissuesacommandtoagivenHWprocess,infactitwritesthecommandidentifiertotheaddressofthecontrolregister.ThecommunicationonthedatabusbetweendifferentHWprocessesishandledinasimilarfashion.EachHWprocessisconnectedtothebusthroughamasterorslaveinterface,andinaddition,ithasanuniqueidentifierwithrespecttothatbus.Thus,twosuchidentifiersaredefinedmaster_reg_addrandslave_reg_addr,respectively.ThecommunicationbetweenHWprocessesandthecontrollerisdoneviaaninterrupt-basedmechanism.ThedomaincontrollerusesaninterruptcontrollerforreceivinginterruptsignalsfromHWprocesses.Eachmodulehasauniqueidentifier(i.e.,irq)correspondingtotheinterruptsignaltowhichitisassigned.SimilarlytoHWprocesses,busesarestoredinabusList,containingelementswiththefollowingstructure:structBus{std::stringname;unsignedintmaxCap;unsignedintavCap;};Besidethename,thetotalcapacityofthebus(maxCap)andtheavailablecapacityatagivenmoment(avCap)areincludedasproperties.Onedecisionthatwetookwastogroupallthegeneratedinformationinasinglefile,ratherthancreateseparatefilesforeachdomaindescription.Therefore,at 94D.Truscanetal.simulationtime,thecontrollersofdifferentdomainswillsharethisinformationfromthesamefile.Wedonotconsiderthistobeanimpediment,sincethegener-atedinformationisreadonly,andthus,itdoesnotposetheproblemofarbitratingtheaccesstoit.Assuch,allthedomaindescriptionsincludedinagivenMICASconfigurationaregroupedinadomainListarray.Domain*DomainList[];7.3.2SpecifyingServiceDescriptionAservicerepresentsanatomicpieceoffunctionalityprovidedbyagivenMICASdomain.Eachdomainprovidesitsownservicelist(i.e.,service-Table),inwhichanumber(s_no)ofservicesarestored.structDomain{Service*serviceList[10]unsignedints_no;};TheServicetypeischaracterizedbyaname,alistofCompositeStreams(i.e.,consistentcombinationsofstreams),apointertoasubservicefromaremotedomain,andanallocatedflagtobeusedatrun-timeforkeepingtrackiftheserviceisenabledatagivenmomentintime.ThedefinitionoftheServiceisshownbelow.structService{std::stringname;structSubservice*subservice;CompositeStream*compositeStreams[10];unsignedintallocated;};Inturn,theSubserviceischaracterizedbytheidentifier(remote_domain_id)oftheremotedomainfromwhichitcanbeaccessedandtheserviceidentifier(remote_service_id)inthatremotedomain.Inaddition,pointerstothelocalcontrolsockets(local_ctrl_socket)areprovidedtoindicatetothecontrollerwhereto“route”thecommandsforusingagivensub-service,andfromortowhatsocket(local_socket)itcanaccessorsendthedataprovidedbytheservice.TheSubservicedefinitionisgiveninthefollowing.structSubservice{unsignedintremote_domain_id;unsignedintremote_service_id;Process*local_socket;Process*local_ctrl_socket;}; 7SystemC-BasedSimulationoftheMICASArchitecture95Aserviceissupportedbyoneormanycompositestreamsdepictingthedata-flowperspectiveofthatservice.Inturn,eachcompositestreamisimplementedbyanumber(b_no)ofbasicstreams,includedinthebasicStreamsarray.structCompositeStream{std::stringname;structBasicStream*basicStreams[10];intb_no;};Abasicstream(i.e.,adata-flowbetweentwoHWprocesses)providesanintrinsicperspectiveontheassociatedcontrol-flowneededtosetuptheseHWprocesses.Thus,thereisaneedforthoroughlycharacterizingthepropertiesofeachbasicstream.Assuch,abasicstreamisspecifiedbyaname,acategoryandacapacity.Inaddition,eachstreamtransfersdataoveraphysicalbus,betweenasourceHWprocess(src_process)andadestinationHWprocess(dst_process).Thelatterarerepresentedaspointerstothecorrespondingelements.Fromacontrolperspective,abasicstreamisequivalenttooneormanyHWprocesscommandsthattriggerthedatatransfersoverthebus.Thesecommandsaregath-eredinthemicrocommandsarrayandexecutedeverytimethebasicstreamistriggered.structBasicStream{std::stringname;enumcategorycat;unsignedintCapacity;structBus*bus;//pointertothebus//transportingthestreamstructProcess*src_process;structProcess*dst_process;Microcommand*microcommands[10];unsignedintm_no;};TheMicrocommandischaracterizedbyanameandanimplementation(impl).Inturn,theimplementationconsistsofacommandidentifier(command),whichisanumericvaluetobewrittenbythecontrollertothecontrolregister(master_address)ofthemasterHWprocess.Themicrocommandwillalsospecifytheaddress(slave_address)oftheslaveHWprocesstowhichthemasterprocessistocommunicateoverthebus.structMicrocommand{std::stringname;structimpl{unsignedintcommand;Module*slave_address;Module*master_address;}impl;}; 96D.Truscanetal.WementionthatthesetypedefinitionsandtheirdatastructuresareindependentofthespecificconfigurationsthatcanbecreatedinMICAS.TheyareintendedonlytoprovideacommonframeworktospecifytheMICASarchitectureinC++.ThesetypedefinitionsmayberegardedasatextuallanguageforspecifyingMICAScon-figurationsatsimulationlevel.7.4GeneratingtheSimulationModelAgraphicalspecificationlanguage[5]isusedtocreateMICASconfigurationsandtodesigntheservicesprovidedbyagivenconfiguration.Forinstance,Fig.7.3presentsthehardwareconfigurationofanAudiodomain,whileFig.7.4depictsthestreamdefinitionofanencodeAudioserviceprovidedbythisdomain.FromthegraphicalspecificationsofMICASconfigurations,thesimulationcodeisgeneratedautomaticallyusingtheC++-basedspecificationlanguageofMICAS.See[5]formoredetails.MCU3microcontrollerInterruptcontrollerSFRBridgeinterrupt_controllersfr_bridgeInterruptSFRregisterinterrupt_SFR_register2SFRRegister_SoundRecorderSoundRecordermodule_SFR_registersoundRecorderBus1busSFRRegister_AudioEncoderAudioEncoder3module_SFR_registerencoderSFRRegister_Socket3Socket3module_SFR_registersocketSlave1socket_control_sfr_reg0socket_control_SFR_registerFig.7.3MICASdomainmodelexample 7SystemC-BasedSimulationoftheMICASArchitecture97SoundRecorderS12:wavAudioEncoderS13:mp3Socket3SoundRecorderEncoderSocketFig.7.4StreamsoftheencodeAudioservice7.4.1SpecifyingFunctionalConfigurationandServiceDescriptionThegeneratedcodehastwoparts,declarationandinitialization,similartoaC++program.Inthedeclarationpart,theMICAScomponentsofagivenconfigurationareinstantiatedusingtheC++datatypesdefinedpreviously.ThefollowingcoderepresentsthedeclarationofthedomainshowninFig.7.3.DomainAudio;ModuleAudio_Socket3;ModuleAudio_socket_control_sfr_reg;ModuleAudio_AudioEncoder;BasicStreamAudio_S11;Microcommandmc_S11_Audio_record_sound_wav;Microcommandmc_S11_Audio_transmit_data_to_domain;BasicStreamAudio_S13;Microcommandmc_S13_Audio_encode_wav_2_mp3;Microcommandmc_S13_Audio_transmit_data_to_domain;CompositeStreamAudio_encodedAudio;ModuleAudio_SoundRecorder;BusAudio_Bus1;BasicStreamAudio_S12;Microcommandmc_S12_Audio_record_sound_wav;CompositeStreamAudio_unencodedAudio;ServiceAudio_encodeAudio;ServiceAudio_plainAudio;Intheinitializationpart,thepropertiesofeachinstantiatedcomponentareinitial-izedwithdataextractedfromtheMICASmodels.Duetothelargesizeofthegen-eratedcode,weonlyshowthepropertiesoftheSocket3process,oftheserviceencodeAudio,andoftheS13basicstream.Audio_Socket3.name=“Socket3”;Audio_Socket3.master_ctrl_reg_addr=10;Audio_Socket3.slave_reg_addr=1;Audio_Socket3.slave_data_buffer=32; 98D.Truscanetal.Audio_Socket3.master_data_buffer=32;Audio_Socket3.irq=2;Audio_Socket3.type=SOCKET;……Audio_encodedAudio.name=“encodedAudio”;Audio_encodedAudio.basicStreams[0]=&Audio_S12;Audio_encodedAudio.basicStreams[1]=&Audio_S13;Audio_encodedAudio.b_no=2;……Audio_S13.name=“S13”;Audio_S13.bus=&Audio_Bus1;Audio_S13.src_module=&Audio_AudioEncoder;Audio_S13.dst_module=&Audio_Socket3;Audio_S13.Capacity=100;Audio_S13.cat=MP3;Audio_S13.microcommands[0]=&mc_S13_Audio_encode_wav_2_mp3;Audio_S13.microcommands[1]=&mc_S13_Audio_transmit_data_to_domain;Audio_S13.m_no=2;7.4.2SpecifyingtheStructuralConfigurationAspreviouslymentioned,thestructuralperspectiveofagivenMICASconfigura-tionismodeledatsimulation-levelusingtheSystemClanguage.TheMICASSimulationlibraryisusedforprovidingready-builtSystemCspecificationsofMICASresources.Followingthisapproach,onlythetop-levelconfigurationfileoftheSystemCmodelhastobegeneratedinordertoobtainthehardwaresimulationmodelofagivenMICASconfiguration.Inordertointegrate,atrun-time,thestructuralandfunctionalinformationoftheconfiguration,theSystemCmodulespecificationsstoredinthelibraryhavebeencus-tomizedtoalsotakeintoaccount,atinitializationtime,thefunctionalconfigurationandtheservicedescriptionofagivenMICASconfiguration.7.4.2.1ProvidingReusableModuleSpecificationsSystemCpromotesreuseofmodulespecificationsallowingtheinstantiationofthesamemoduleforimplementing(simulating)severalhardwarecomponentsinthesameconfiguration.However,eachmoduleinstancehastobemade“aware”ofitsconfigurationsettingsintermsofassignedaddressspaces,IRQnumbers,parame-ters,etc.Thisinformationhastobepassedtoinstancesatinstantiationtime,orfol-lowingtheSystemCterminology,atelaborationtime. 7SystemC-BasedSimulationoftheMICASArchitecture99Usingtheinformationprovidedbythefunctionalconfigurationandbytheserv-icedescription,respectively,weconfigure,atelaborationtime,SystemCmoduleinstanceswithspecificinformation.TheapproachenablesthereuseofthesameSystemCmodulespecificationinseveralarchitecturalconfigurations.Forinstance,iftwoMICASmodulesVideoEncoderandAudioEncoderareusedinaconfigura-tion,eachofthemaspartofadifferentMICASdomain,agenericSystemCencodermodulecanbeusedtosimulatebothcomponents.Thus,theencoderhastobeinstantiatedonceforeachofthetwoMICASmodules,andthefunctionalinformationspecifictoeachMICASmodulehastobepassedtoitscorrespondinginstance.AcoupleofcustomizationshavebeenappliedtothecomponentsoftheMICASSimulationlibrary.Firstly,wehavedefinedamechanismthatenablesustopasstheconfigurationpropertiestomoduleinstancesatelaborationtime.Secondly,theSystemCprocessesimplementingthemodulebehaviorhavebeencustomizedtotakethefunc-tionalconfigurationandtheservicedescriptionintoaccountduringsimulation.Passinginformationtomoduleinstances.Asmentionedpreviously,eachSystemCmodulespecificationisbasicallyaC++class.Assuch,besidetheSystemCspecificconstructs,onecandefineadditionalpropertiesofthatclass,likeattributesandmethods.Intheprevioussection,wehavedeclaredseveralC++datatypes(e.g.,Domain,Process,Bus,etc.),eachofthemspecifyingthefunctionalpropertiesofaspe-cifictypeofMICAShardwareresource.WeintegrateeachsuchdatatypewiththecorrespondingSystemCmodulebydeclaringamymoduleattributeofthemoduleclass.Forinstance,classesspecifyingMICASprocessescontainaProcessmymoduleattribute,whereasclassesspecifyingbusmoduleshaveaBusmymoduleattribute.Anexampleisgiveninthefollowing:SC_MODULE(socketMaster){SC_CTOR(socketMaster){……}public:Processmymodule;};Duringtheelaborationphase,whenmodulesareinstantiatedinthemain.cppfile,theinformationispassedtoagivenmoduleinstanceinthefollowingway:socketMasterSocket1(“Master_Socket1”);Socket1.mymodule=*this_domain->moduleList[Socket1_id];WehavefollowedasimilarapproachincaseofthemodulesimplementingMICAScontrollers,withthedifferencethattheentirefunctionalconfigurationofadomainispassedtothecontroller(MCU1.mymodule=*this_domain;)asanattribute.WehaveemployedthisapproachsincethedomaincontrollermanagestheresourcesoftheentireMICASdomainandtherefore,itrequiresaccesstotheprop-ertiesofalldomainresources. 100D.Truscanetal.Customizingmodulebehavior.HavingconfigurationinformationpassedtoSystemCmodulesalsorequiresthecustomizationoftheSystemCprocessesthataremodelingthebehaviorofeachmodule,suchthattheytakeintoaccountthefieldsofthemymoduledatastructure.Forinstance,asocketMastermoduleusestwomethods(transfer_over_socket()andtransfer_to_slave())tospecifyitsinternalproc-esses,asshownbelow:voidtransfer_to_slave();voidtransfer_over_socket();SC_CTOR(socketMaster){SC_METHOD(transfer_over_socket);sensitive_pos(Clk);SC_CTHREAD(transfer_to_slave,Clk.pos());}Thetransfer_over_socket()methodmanagesthedatatransferfromthesocketovertheexternalsocketnetwork,whilethetransfer_to_slave()methodhandlesdatatransfersonthelocalbus.Eachprocesshasacorrespondingimplementation,situatedinthe.cppfileofthemodulespecification.Forthesakeofexample,anexcerptofthecodeimple-mentingthetransfer_to_slave()processisshownbelow.ThepresentedcodereadsthecontrolregisteraddressofaMICAScomponent(mymodule.master_ctrl_reg_addr)andwritesittotheM_MDataportofthesocket-Masterinstance.voidsocketMaster::transfer_to_slave(){….M_MData.write(mymodule.master_ctrl_reg_addr);….}Therefore,usingthefunctionalpropertiesofthemoduleasvariables,insteadofhavingthemhardcodedintheprocessspecification,enablesustoreusethesameprocessinagenericmanner.7.4.3TheSystemCTop-LevelFileBasedonthepreviouscustomizationsoftheMICASSimulationlibrary,theproc-essofgeneratingtheSystemCtop-levelfileforagivenconfigurationisfullyauto-mated.TheSystemCcodecorrespondingtotheMICASdomainpresentedinFig.7.3isshownbelow://main.cpp#include“microcontroller.h”#include“interrupt_SFR_register.h”#include“AHB_bus.h”#include“bus.h”#include“soundRecorder.h” 7SystemC-BasedSimulationoftheMICASArchitecture101#include“socketSlave.h”#include“encoder.h”#include“inverter.h”#include“interrupt_controller.h”#include“sfr_bridge.h”#include“module_SFR_register.h”#include“socket_control_SFR_register.h”#include“config1.h”namespaceMicasSystem{namespaceAudio{microcontrollerMCU3(“Audio_MCU3”);socket_control_SFR_registersocket_control_sfr_reg(“Audio_socket_control_sfr_reg”);socketSlaveSocket3(“Audio_Socket3”);interrupt_controllerInterrupt_controller(“Audio_Interrupt_controller”);encoderAudioEncoder(“Audio_AudioEncoder”);soundRecorderSoundRecorder(“Audio_SoundRecorder”);sfr_bridgeSFR_Bridge(“Audio_SFR_Bridge”);module_SFR_registerSFR_Register_Socket3(“Audio_SFR_Register_Socket3”);module_SFR_registerSFR_Register_SoundRecorder(“Audio_SFR_Register_SoundRecorder”);busBus1(“Audio_Bus1”);module_SFR_registerSFR_Register_AudioEncoder(“Audio_SFR_Register_AudioEncoder”);interrupt_SFR_registerInterrupt_SFR_register(“Audio_Interrupt_SFR_register”);}//Audionamespaceend}//MicasSystemnamespaceendintsc_main(intargc,char*argv[]){sc_clockTestClk(“TestClock”,10,SC_NS,0.5);initialize();{usingnamespaceMicasSystem::Audio;MCU3.Clk(TestClk);socket_control_sfr_reg.Clk(TestClk);Socket3.Clk(TestClk);Interrupt_controller.Clk(TestClk);AudioEncoder.Clk(TestClk);SoundRecorder.Clk(TestClk);SFR_Bridge.Clk(TestClk);SFR_Register_Socket3.Clk(TestClk);SFR_Register_SoundRecorder.Clk(TestClk); 102D.Truscanetal.Bus1.Clk(TestClk);SFR_Register_AudioEncoder.Clk(TestClk);Interrupt_SFR_register.Clk(TestClk);Domain*this_domain=domain_list[Audio_id];MCU3.mydomain=*this_domain;socket_control_sfr_reg.socket_ctrl_register_addr=this_domain->moduleList[socket_control_sfr_reg_id]->master_ctrl_reg_addr;Socket3.mymodule=*this_domain->moduleList[Socket3_id];SFR_Register_Socket3.module_sfr_register_addr=this_domain->moduleList[Socket3_id]->master_ctrl_reg_addr;AudioEncoder.mymodule=*this_domain->moduleList[AudioEncoder_id];SFR_Register_AudioEncoder.module_sfr_register_addr=this_domain->moduleList[AudioEncoder_id]->master_ctrl_reg_addr;SoundRecorder.mymodule=*this_domain->moduleList[SoundRecorder_id];SFR_Register_SoundRecorder.module_sfr_register_addr=this_domain->moduleList[SoundRecorder_id]->master_ctrl_reg_addr;Interrupt_SFR_register.int_ctrl_SFR_register_addr=this_domain->int_ctrl_reg_addr;//connectports……}{//connectdomains……}//endELABORATIONPHASEintn=600000000;if(argc>1)std::stringstream(argv[1],std::stringstream::in)>>n;sc_start(n);//STARTSIMULATIONreturn0;}//sc_mainend7.5ConclusionsWehavepresentedaC++-basedspecificationlanguagefortheMICASarchitecturethatisusedtointegrate,atsimulationtime,theconfigurationrelatedpropertieswiththeSystemC-basedspecificationoftheMICAShardware.Theapproachfavorstheuseofsimulationlibrariesandenhancessupportforautomation. 7SystemC-BasedSimulationoftheMICASArchitecture103Wehaveshownhowthedefinedlanguagecanbeusedtomodelvariouscharac-teristicsoftheMICASconfigurationsandhowitcanbeintegratedwiththeSystemCspecificationofagivenconfiguration.Inaddition,wehavediscussedthecustomiza-tionsappliedtothecomponentsoftheMICASSimulationlibrary,suchthatthesimulationmodelofagivenMICASconfigurationcanbeautomaticallygenerated.Wementionthatalthoughtheprocessofupgradingthelibraryrequiredsomeaddi-tionaleffort,thebenefitoftheapproachistwofold:(a)itenablesfordifferentinstancesofthesamemodulespecificationnotonlytobeinstantiatedinseveralarchitecturalsettings,butalsotoreusethesamemoduleforimplementingdifferentMICAScom-ponents;(b)itfacilitatestheautomatedgenerationofthesimulationmodel.References1.G.Moretti.Thesearchfortheperfectlanguage.EDN,Feb.2004.Onlineathttp://www.edn.com/article/CA376625.html.Lastchecked10/12/2007.2.SymbianOS.Athttp://www.symbian.com.3.OpenSystemCInitiative.SystemCSpecification.Athttp://www.systemc.org.4.K.Sandström.MicrocodeArchitectureForASystemOnAChip(SoC).NokiaCorporationPatentNC37341,872.0167.P1(US)(FilingDate:07.10.2003),Oct.2002.5.D.Truscan.ModelDrivenDevelopmentofProgrammableArchitectures.Ph.D.thesis,ÅboAkademiUniversity,March2007. Chapter8HeterogeneousSpecificationwithHetSCandSystemC-AMS:WideningtheSupportofMoCsinSystemCF.Herrera1,E.Villar1,C.Grimm2,M.Damm2,andJ.Haase2AbstractThischapterprovidesafirstgeneralapproachtothecooperationofSystemC-AMSandHetSC(HeterogeneousSystemC)heterogeneousspecificationmethodologies.TheirjointusageenablesthedevelopmentofSystemCspecifica-tionssupportingawiderangeofModelsofComputation(MoCs).Thisisbecomingmoreandmorenecessaryforbuildingcompletespecificationsofembeddedsys-tems,whichareincreasinglyheterogeneous(theyincludethesoftwarecontrolpart,digitalhardwareaccelerators,theanalogfront-end,etc.).Thischapteridentifiesthesyntacticalandsemanticalissuesinvolvedinthespecificationswhichincludefacilitiesfromboth,SystemC-AMSandHetSCmethodologies.Thiswork,whichisanextensionofthepaperpresentedinFDL’07[7],considerstheavailabilityandsuitabilityoftheMoCinterfacefacilitiesprovidedbybothmethodologies,espe-ciallythoseofSystemC-AMS,whichwillbeproposedforfuturestandardization.Somepracticalaspects,suchasthecurrentsetofMoCscoveredbythemethodologiesandthecompatibilityontheinstallationoftheirassociatedlibrariesarealsocov-eredbythischapter.AcompleteillustrativeexampleisusedtoshowHetSCandSystemC-AMScooperation.KeywordsHeterogeneity,ModelsofComputation,System-LevelDesign,SystemC.8.1IntroductionSupportforheterogeneityhasbecomeanimportantfeatureforspecificationmethodologiesthataimtocopewiththecurrentcomplexityofembeddedsystems.Inthiscontext,heterogeneityistheabilityofthespecificationmethodologytoenablethebuildingofmodelswithpartsspecifiedunderdifferentMoCs[1].1UniversityofCantabria,Spain2TechnicalUniversityofVienna,AustriaE.Villar(ed.)EmbeddedSystemsSpecificationandDesignLanguages,107©SpringerScience+BusinessMediaB.V.2008 108F.Herreraetal.Eachdesigndomainadoptsaspecificationmethodologywhichusuallycorre-spondstoaspecificmodelofcomputation(MoC).OneofthemostcharacteristicpointsassociatedwiththeMoCisthehandlingoftime.Forinstance,analogmodels(ContinuousTime(CT)models[2]handlestrict-timeinformation,thatis,specifi-cationeventshaveanassociatedtimetagrepresentingphysicaltimeandfixingstrictorderrelationshipsamongthem.Incontrast,concurrentsoftwaremodelsoftenneglectsuchdetailinthetimedomainandconsideronlypartialorderrela-tionshipsamongtheeventsassociatedtothecode.Thedevelopmentofasystem-levelheterogeneousspecificationmethodologyis,toagreatextent,aunificationwork.Someworksdevelopedinterfacesbetweendifferentlanguages,i.e.,toconnecthardwaredescriptionlanguages(HDLs)withhigh-levelprogramminglanguages[3].Thisenabledcertaindecouplingbetweendifferentdesignteams,whichcanfixtheconnectionpointsandworkseparately.However,asystem-levelspecificationmethodologyhastoenablethegeneration,understanding,editionandsimulationofthespecificationofthewholesystem.Thisisaunificationworkwhichinvolvesfindingcommonpointsforthespecificationandsimulationmethodologieshandledbythedifferentdesigncommunities.Anefforttodevelopacommonspecificationandsimulationframeworkwasdone.RelevantexamplesareMetropolis[4]andPtolemyII[5].TheseframeworksenablespecificationunderdifferentMoCs,approachingtheseparationofcomputa-tionandcommunicationindifferentways.Bothprovidesupportforgraphicalspecification,whileJavaadoptstheroleofunderlyingimplementationlanguage.Uptonow,thefocusofthisunifyingworkhastendedtobethelanguageitself.ThelackofaunifiedsystemspecificationlanguagehasbeenidentifiedasoneofthemainobstaclesbedevillingSoCdesigners[6].Acommonspecificationlan-guageisamajoraidingeneratingaspecificationmethodologywhichaimstocom-bineandachievecoherenceamongtraditionallydifferentandseparateddesignapproaches.SystemChasstartedtoplayaroleasunifyingsystem-levellanguageforembeddedsystemdesign.BecominganIEEEstandardisasymptomofitsacceptanceandofastatedsyntaxandunambiguoussemanticforthelanguagecon-structswhichareusedbySystemC-basedmethodologies.Inthiscontext,severalproposalshaveappearedforbuildingheterogeneousspecifi-cationsinSystemC.Thischaptershowshowtwoofthem,HetSCandSystemC-AMScanbejointlyusedtoenablemodelsbasedontheSystemClanguageandcomprisingawidespectrumofMoCs.Thisworkisbasedon[7],whichisimprovedandextendedhere.Afterthisintroduction,Section8.2reviewspreviousworkonheterogeneousspecificationinSystemC.ThemainfocusisontheHetSCandSystemC-AMSspeci-ficationmethodologies.Section8.3dealswithgeneralissuesabouttheinteroperabilityofthesemethodologies.First,somepracticalissuesconcerningtheinstallationandthescopeofthelibrariesarediscussed.Then,howtheSystemC-AMSandHetSCcon-structsaremixedinthesamespecificationisexplained.ReviewingandunderstandinghowtheexistingfacilitiesprovidedbythetwomethodologiesforMoCconnectioncanbeusedandcombinedserveslatertoproposeimprovedconnections.Section8.4,pro-videsanillustrativeexampleofthepreviousconcepts.Lastsectionendswiththemainconclusionsandadvancesfurtherstepsoftheresearchonthistopic. 8HeterogeneousSpecificationwithHetSCandSystemC-AMS1098.2HeterogeneousSpecificationinSystemCAlthoughtheSystemCcorelanguagesupportshardwarespecification(RTLandBehavioural)andagenericDiscreteEvent(DE)modelling,thereisasetofMoCswhicharenotsufficientlysupportedbythecorelanguage.Suchsupportmustincludenewspecificationfacilities,MoCrulecheckers,reporttools,etc.Severalworkshaveattemptedtocoversuchdeficiencies.Inthefollowingsubsectionstheseworksareoverviewed.Mostofthesemethodologiesaresupportedbyanassociatedlibrary;however,theyextendSystemCindifferentways.8.2.1SystemC-AMSSystemC-AMS[8]isaspecificationmethodologydevelopedbytheOSCISystemC-AMSworkinggroupwhichprovidessupportforanalogandmixed-signalspecification.ThisinvolvessupportingtheSynchronousDataflow(SDF),discrete-time(DT)andcontinuoustime(CT)MoCs.AmongtheCTMoCs,itispossibletospecifylinearbehavioralmodelsbymeansoftransferfunctions(TF).Currently,twoviewsaresupportedforTFs:thenumerator-denominator(ND)viewandthezero-pole(ZP)view.Inaddition,thespecificationoflinearelectricalnetworks(LEN),whichenableacircuitleveldescription,isalsosupported.SystemC-AMSisextensiblebyothermodelsofcomputationthroughasynchro-nizationlayer.SolversfortheMoCssupportedarelayeredoverthesynchronizationlayer.ThedesignofthesynchronizationlayerofSystemC-AMSandtheMoCsprovidedareorientedtoasystem-levelmodellingwheresimulationspeedisamoreimportantfactorthanaveryfinesimulationaccuracy.Thesynchronizationlayersupportsdirectedcommunicationandonlyasimplesyn-chronization;onuserspecifiedeventsorinfixedtimesteps.Inthisway,thesimulationoflinearnetworkswithSystemC-AMScanbeordersofmagnitudesfasterthanthemoregeneralnumericalintegrationfornon-linearnetworks[9].Fromthespecificationpointofview,SystemC-AMSoffersanewsetoffacilities,suchasnewkindsofmod-ules(SCA_SDF_MODULE),ports(sca_sdf_in,sca_sdf_out,etc.),channels(sca_sdf_signal),andotherMoCspecificfacilities,suchasthesca_elec_node,sca_elec_port,etc.LinearbehaviouralmodelsareembeddedinSDFmodules,whileLENsareenclosedinSystemCmodules.SystemC-AMSprovidesconverterportsandfacilitiestoenabledifferentMoCstocommunicate(i.e.DEwithSDF,SDFwithLEN,etc).8.2.2HetSCHetSC[10]isamethodologyforenablingheterogeneousspecificationsofcomplexembeddedsystemsinSystemC.MoCssupportedincludeuntimedMoCs,suchasKahnProcessNetworks(KPN),itsboundedfifoversion(BKPN),Communicating 110F.Herreraetal.SequentialProcesses(CSP)andSynchronousDataflow(SDF).SynchronousMoCs,suchasSynchronousReactive(SR)andClockedSynchronous(CS)andthetimedMoCsalreadysupportedinSystemCarealsoincluded.HetSCaimsatacompletesystem-levelHW/SWcodesignflow.Indeed,themethodologyhasbeencheckedintermsofsystem-levelprofilingandsoftwaregeneration[11].TheHetSCmethodologydefinesasetofspecificationrulesandcodingguide-linesforeachspecificMoC,whichmakesthedesignertaskmoresystematic.ThesupportofsomespecificMoCrequiresnewspecificationfacilitiesprovidingthespecificsemanticcontentandabstractionlevelrequiredbythecorrespondingMoCs.TheHetSClibrary,associatedwiththeHetSCmethodology,providesthissetoffacilitiestocoverthedeficienciesoftheSystemCcorelanguageforhetero-geneousspecification.Inaddition,somefacilitiesoftheHetSClibraryhelptodetectandlocateMoCruleviolationsandassistthedebuggingofconcurrentspeci-fications.OneofthemaincontributionsofHetSCisitsefficientsupportofabstractMoCs(untimedandsynchronous).Thisisbecausetheyaredirectlysupportedovertheunderlyingdiscreteevent(DE)strict-timesimulationkernelofSystemC.NewabstractMoCsdonotrequireadditionalsolverssincethenewMoCsemanticisembeddedintheimplementationofthenewspecificationfacilities(usuallychan-nels)relatedtotheabstractMoC.WhenthenewMoCcanbeabstractedfromtheDEstrict-timeMoC,then,itispossibletofindamappingofinternaleventsofthenewspecificationfacility,i.e.,achannel,overthestrict-timeaxisoftheDEbaseMoC.ThismakesitfeasibletowritetheimplementationofsuchachannelbyusingSystemCprimitives,suchasSystemCevents,whichcontrolwhenthingshappenwithinthechanneland,therefore,intheprocessesrelatedbythechannel.8.2.3SystemC-HSystemC-H[12]isamethodologythatproposesageneralextensionoftheSystemCkernelforthesupportofdifferentMoCs.ThismethodologyproposestheextensionoftheSystemCkernelbyincludingasolverforeachMoC.ThecurrentscopeoftheSystemC-HlibrarycoverstheSDFandCSPuntimedMoCs.Forinstance,SystemC-HprovidesasolverforstaticschedulingofSDFgraphswhichenablesschedulabilityanalysisandprovidesa75%speed-uprespecttoDE[12].However,thisextensionisnotalwaysworthwhile.Indeed,thespeed-upforsomeabstractMoCscanbenegligible[13].Inaddi-tion,theeffectsofAmdahllawcanmakesimulationspeed-upsvanish.Forinstance,in[12]thespeed-upofamixedDE-SDFexampledecreasesto13%.ThissuggeststhatprovidingaspecificsolverforeachMoCcanbenotalwaysworthy.Incaseslikethese,itcanbemoreefficienttoletseveralMoCstosharethesamesimulationkernel.ThisistheapproachofHetSC,wheresimilarspeed-upstothoseof[12]werereportedforthedynamicapproachtoSDFforlarge-grainSDFspecifications[14].Anotherproblemofthisapproachisthatthewaytheextensionisproposedrequiresmodifyingthestandardkernelofthelibrary.Incontrast,SystemC-AMSandHetSCmethodologicallibrariesrelyontheSystemCstandardlibrary,whichremainsuntouched. 8HeterogeneousSpecificationwithHetSCandSystemC-AMS1118.2.4SysteMoCSysteMoC[15]focusesonprovidingamethodologywiththeabilitytoextractandanalyzetheMoCemployedintheSystemCdesign.Thisisunderstoodtobeapre-requisitefortherestofthedesignactivities.Inordertoachievethis,theSysteMoClibraryprovidessupportforabasicMoCcalledFunstate.SpecificationswrittenunderthisMoCexpresstheircommunicationbehaviourunderthefinitestatemachine(FSM)MoC.ThisenablestheautomaticextractionandanalysisoftheMoCemployed,onlybyanalyzingcommunicationFSMstogetherwiththetopol-ogyofthespecification.8.3HetSC/SystemC-AMSInteroperability8.3.1InstallationandScopeFigure8.1describestheinstallationrequirementsoftheSystemCuser.ApartfromtheSystemCcorelibrary,theSystemC-AMSandHetSClibrarieshavetobeinstalledontopoftheSystemCcorelibrary.Thereisflexibilitywithrespecttothedevelopmentplatform(i.e.,Linux,UnixandWindows-Cygwinaresupported).ThereisnocompatibilityproblemintheinstallationofHetSCandSystemC-AMSlibraries.Inthiswork,theHetSClibraryisextendedwithsomespecificfacilitiesforenablinganeasierconnectionofHetSCandSystemC-AMSparts.TheseHetSCfacilitiesusesomeSystemC-AMSfacilitiesthroughforwarddeclara-tions.ThispreventsobliginganinstallationorderbetweenHetSCandSystemC-AMSlibraries,makingtheinstallationprocedureeasier.Oncesuchaninstallationhasbeendone,thedevelopmentsystemisreadyforcompilingandexecutingSystemCspecificationswrittenunderawiderangeofMoCs.TheuseronlyhastoincludetheSystemC-AMSandHetSClibrariesinthesourcecodeoftheheteroge-neousspecification.SystemC-AMSHetSC#includeLibraryLibrary#include“systemc.h”intsc_main(..){…OSCISystemC}LibraryC++CompilerFig.8.1SystemC-AMSandHetSClibrariesareinstalledovertheSystemClibrary 112F.Herreraetal.analoguntimedsynchronousNDZPStaticDynamicPNSRLENBehavioralSDFSDFKPNCSLNsolverCSPRTLBeh.SynchronizationLayerSystemCDEstrict−timeSimulationKernelFig.8.2MoCsspectrumprovidedbythecooperationofSystemC-AMSandHetSCFigure8.2showsthesupportedMoCs.ThecooperationofSystemC-AMSandHetSCprovidesacomplementaryMoCsupport.WhileSystemC-AMSprovidessupportforanalogMoCsandstaticsynchronousdataflow,untimedandsynchro-nousMoCsaresupportedbyHetSCandSystemCcorefacilities.ThisisalsoanefficientconfigurationforthesupportofawidespectrumofMoCs.ThereasonisthatspecificsolversareprovidedonlyforasetofMoCswherethesimulationspeedupissignificant.ThissetcorrespondstoanalogMoCs,wherethesimulationspeedupscanbeofordersofmagnitude.Bearinginmindthelimitedspeed-upsreportedin[10,12,13],untimedandsynchronousMoCscanbesatisfac-torilysupporteddirectlyovertheSystemCkernel.TheexceptionwouldbefinegrainSDFspecifications,wherethespeedupofastaticSDFcomparedtoadynamicSDFcouldbesignificant.SpecificationswithoutCTpartsbutwithsyn-chronoushardware(RTLorbehavioural)couldalsojustifyacycle-accuratesimula-tor.However,thestudyoftheseexceptionsisnotinthescopeofthiswork.8.3.2SyntacticalandSemanticalIssuesTherearesomebasicissuestoconsiderinageneraldiscussionoftheconnectionbetweenHetSCandSystemC-AMS.Intermsoftheresultingstructure,twopartscanbedistinguishedinthespecification.OnecorrespondstotheAMSpart,whiletheothercorrespondstotheHetSCpart.Fromthesyntacticalpointofview,theSystemC-AMSpartwillbeidentifiedbySCA_SDF_MODULEsand/orSCAhierarchicalmodules.Thispartpresentsahier-archicalheterogeneitywheretheunderlyingMoCisthestaticsynchronousdata-flow(SDF)MoC.TheHetSCpartischaracterized,ingeneral,byanamorphousheterogeneity.ThismeansthattheHetSCspecificationpermitsmixingMoCfacili-tiesinaflathierarchy.Nevertheless,theHetSCspecifierwilloftenmakeuseofmodulehierarchyforseparatingpartsofthesystemunderdifferentMoCs.Thus,inmanycases,modulepartitionwillcorrespondwithMoCboundaries.Fromthesemanticalpointofview,thereisabasicconsideration.WhileHetSCdirectlyreliesontheDEstrict-timesimulationkernel,SystemC-AMSreliesonasynchronizationlayer,whichprovidessupportforthesolvers.InSystemC-AMS,CTdescriptionsarealwaysembeddedindataflowclusters[8].Thatis,themost 8HeterogeneousSpecificationwithHetSCandSystemC-AMS113importantsolveristheSDFonewhich,fromthepointofviewoftimesemantics,isthebasisfortheanalogMoCs.ThetimeaxisinSystemC-AMSisactuallyslicedbyeachSDFclusterinstrict-timedelayscalledclusterperiods(T),whichclusterdependsonthesampleperiod(T)andratesoftheclusterSDFgraph.Thus,withrespecttothepremisesof[14],theSDFapproachofSystemC-AMSisnotanuntimedSDF.Internally,modulesoftheclustercanbeviewedasastrict-timetimedapproachtotheSDFMoC(denotedasT-SDFhere),whichenablesastaticexecu-tionoftheAMSprocessesateachclusterperiod.Moreimportantforthepurposeofthiswork,fromanexternalpointofview,theclustercanbeconceivedasatimed-clockedsynchronous(CS)blockwhichtriggersateachclusterperiod.Thus,theclusterperiodmustbetakenintoaccounttosynchronizetheDEpartwiththeSystemC-AMSpart.SinceeveryMoCsupportedbyHetSCisabstractedovertheDEstrict-timesim-ulationkernelandeverySystemC-AMSMoCisclusteredintheT-SDFMoC,theproblemisreducedtoprovidingaSystemC/SystemC-AMSconnection,whichisbasicallyaDE/T-SDFconnection.InSystemC-AMS,thisconnectionisdonebymeansofSystemCsignals(sc_signalchannels)andasetofSystemC-AMScon-nectionfacilities(sca_scsdf_in,sca_scsdf_out,sca_sc2v,sca_sc2r,etc.).Eachoftheseconnectionfacilitiesarebasedonthesamplingand/orupdateofaSystemCsignalateachclustertime.Therefore,animmediateconclusionisthattheseele-mentscanbedirectlyemployedtocombineHetSCandSystemC-AMS.Suchdirectusageofthesc_signalandtheDE/SystemC-AMSconnectionfacili-tiesisimmediateinsomeHetSC/SystemC-AMSconnections.OnthelefthandsideofFig.8.3,aHetSCpartunderasynchronousreactiveMoC(SRMoC)isrepre-sented.BothinFigs.8.3and8.5thegraphicalrepresentationusedinHetSCmeth-odologyisemployed.Thereisasimplereactivechaincomposedofageneratorprocess(GP)whichtriggersareactiveprocess(RP).ThisRPisalsoaborderproc-ess(BP),sinceitwritestoaSystemCsignalchannel(sc_signal),whichiscon-nectedtoaSystemC-AMSpart.ItsconnectionwiththeSystemC-AMSpartbymeansofasignalchannelissyntacticallyandsemanticallycompatiblewiththeSRMoCrules.Theserulesand,specifically,perfectsynchrony,arerespectedsincethewriteaccesstotheSystemCsignalisnon-blocking.Thisenablesthereactivechaintobecomputedconsumingoneormoresimulationdeltacycles,butwithoutrequir-ingaSystemCtimeadvance.Thisisthewayinwhichperfectsynchronyisimple-mentedinHetSC.BPsca_scsdf_inSCA_SDF_MODULEuc_SRsc_signalLENsca_sc2rnetworkGPRPFig.8.3ConnectionofHetSCandSystemC-AMSpartsbymeansofaborderprocess 114F.Herreraetal.S1S2S3HetSCSRslotsC1C2C3SystemC-AMSSDFClusterTimesTclusterTclusterSystemCtimestampFig.8.4StricttimeinformationintheHetSC/SystemC-AMSconnectionFromtheSystemC-AMSpart,theconnectioniscoherenttoo.IntheconnectiontoaSCA_SDF_MODULE,thevalueofthesc_signalisreadateachclustertime.Thisvaluecanbereadasmanytimesasnecessary,astheconsumptionrateofthesca_scsdf_inportdetermines.Anotherpossibilityistheconnectiontoalinearelectricalnetwork(LENMoCofSystemC-AMS)bymeansofaconverterfacility,forinstance,asca_sc2rinFig.8.3.Thisfacilityenablestheupdateofitsassociatedresistancevaluewheneverthesc_signalchanneliswritten.Then,thisupdatedresistancevalueisemployedbytheLENsolverinthefollowingclustertimestosolvethedifferentialequationcorrespondingtotheelectricalnetworktheconverterfacilitybelongsto.ThetimestampinformationoftheHetSCSRslotisirrelevanttotheeffectoftheHetSCSRMoCitself(theonlynecessaryconditionisthateachslothastohappenatdifferenttimestamps).However,itisimportanttotheeffectofthe(HetSC)SRMoC/(SystemC-AMS)LENMoCconnection,sinceittellswhenthedifferentialequationsystemisupdated,beforeorafteragivenclustertime.Forinstance,inFig.8.4,thetimestampsoftheSystemC-AMSclustercomputationsarerepresentedasblackdots.Theirtimestampsareequallyspaced.ThetimestampsoftheSRtimeslotsarerepresentedaswhitedots.Asmentioned,thereisstillconsistencyintheSRpartifslottimestampsarenotequallyseparated.However,actualtimestampsofSRslotsaffecttherelationshipoftheSRpartwiththetimedSystemC-AMSpart.Forexample,thefirsttwoclustercomputations,C1andC2,usethesignalvalueupdatedintheslotS1,whiletheclustercomputationC3usesthesignalvalueupdatedintheslotS3.IftheS2slotsmovestoatimestampbeforeC2,then,althoughthisisnorelevanttotheeffectsoftheSRpart,itaffectstheSystemC-AMSpart,sinceC2takesthevalueupdatedinS2.ThesetofMoCsabstractedfromtheDEMoCandsupportedbyHetSCisrichenoughtoconsiderspecificconnectionswhichcannotbedirectlyhandledbyonlyaSystemCsignalplusSystemC-AMSconnectionfacility.Forinstance,theconnec-tionofaKPNMoCwithaLENMoCinvolvesfifochannelsemanticsononesideandelectricalnodesontheotherside.Itwouldbeconvenienttocountonsomeconnectionfacilitywhichenablessuchdirectconnection,withouttheexplicitinter-mediationoftheSystemCsignal(sc_signal).Inordertogetsuchadirectconnection,bothinsyntacticalandsemanticalterms,theSystemCsignal-SystemC-AMSconnectionfacilitycanbeconvenientlycom-plementedandwrappedbyoneofthebasicconceptsemployedinHetSCfortheconnectionofMoCs,theborderprocess.Externally,theconnectionfacilitycantake 8HeterogeneousSpecificationwithHetSCandSystemC-AMS115theshapeofaHetSCborderchannel(BC).Figure8.5showsaborderchannel(uc_inf_fifo_sca_sdf),whichenablesadirectconnectionbetweenaKPNMoCandaT-SDFMoC.Itisbuiltasahierarchicalchannelwhichontheonehandexportsthewriteinterfaceofanuc_inf_fifochannel,whileontheotherhandoffersaT-SDFport(sca_sdf_out)port.Internally,itusesaborderprocesswhichconsumesfifotokens,whosevaluesareusedtoupdatetheinternalSystemCsignal.Thesignalisconnectedtoaconverterport(sca_scsdf_in)ofaninnerSystemC-AMSmodule.Inaddition,BCsprovideascalablewaytoconstructthesedirectconnectionssinceitdoesnotrequiretheSystemC-AMSkerneltobechanged.BCsprovidesasemanticalsolutionfortheuntimed/timedconnectionwhichariseswhenuntimedMoCsofHetSCareconnectedtoSystemC-AMSMoCs.Inthe(HetSC)SR-(SystemC-AMS)T-SDFexamplethesolutionwasbasedonsampling(read)andupdating(write)signalsandconsideringtherelationshipoftheactualtimestampsofHetSCSRslotsandtheclusterperiodoftheSystemC-AMSpart.TheconnectionofSystemC-AMSwithuntimedHetSCMoCsismorecomplexbecauseofthedifferencesintermsorcommunicationsemantics.HetSCuntimedMoCshandleadifferentbehaviourintermsofthedestructiveandnon-destructivesemanticsofthewriteandreadaccesses.Forinstance,aKPNpart,expectsthatwritingtoa(fifo)channelprovokestheaccumulationoftokenswithinthechannelincasetheycannotbeimmediatelytransferred,thustheyareneverlost.Thisisanon-destructivewritesemantic.Italsoexpectstoconsumeinsteadofpeekingorsamplingthedatapresentinthechannel,thatis,adestructiveread.Thiscommunicationsemantic,typicalfromuntimedMoCshastobecoherentlyconnectedwiththeT-SDFpart,whichwritesandreadsatafixedpace(determinedbytheclusterperiodandportrates)withanon-accu-mulative(destructive)writeandsampling(non-destructive)readsemantic.Then,somekindofadaptationhastobeintroducedtoconvertconsumptioninsampling(andviceversa)andproductioninwriting(andviceversa).Actually,thistypeofadaptationisnotcomprisedbyanyoftheSystemC-AMSconnectionfacilities.Suchadaptationcanbeexplicitlywritten,i.e.asaHetSCborderprocess.TheBCenablesthepackagingofsuchadaptationinaspecificationprimitive.Forinstance,intheuc_inf_fifo_sca_sdfisaBC.InthisBC,whentoconsumefifotokensisdefinedbymeansofasamplingperiod,which,ingeneral,canbedifferentfromtheclusterperiod.TheBCcanalsoraiseanerroriftheinternalfifogetsemptywhenanewsamplingisgiven.uc_inf_fifo_sca_sdfsca_scsdf_inSDA_SDFuc_inf_fifosc_signal_MODULEsca_sdf_outcons_TFig.8.5Structureofauc_inf_fifo_sca_sdfchannel 116F.Herreraetal.8.4ExampleInordertodemonstratethepreviousgeneralconcepts,anexamplehasbeendeveloped.Thisexampleisavailablein[16].Itconsistsofasoundboard,whichisshowninFig.8.6.Thesystemhasanaudioinputandanaudiooutput.Theaudioinputundergoesthreestagefiltering.Thefirstfilterisanoisefiltertoremoveanysignalcomponentover22kHz.Thesecondoneisa10-channelequalizer.Thelastoneisanintegrator,which,atthesametime,controlsthegeneralvolumeandfilterstheDCcomponentoftheaudiooutput.Thesystemhasotherinputs,aswellastheaudioinput.Adialenablesselectionoftheequalizerchannel,whileanotherdialtunesthegainoftheselectedchannelindBs(ina[-10dB,10dB]range).Astatedisplayshowsthecurrentstateoftheequalization,whileaneditiondisplayshowsthecurrentlyselectedchannelandthecurrentlyeditedequalizationprofile.Thisprofileisnotappliedtillthesetbuttonispressed.Then,thestatedisplaychangestoreflectthisequalizationprofile.Ifthecancelbuttonispressedinstead,thentheeditiondisplayandtheeditionequalizationprofilereturntotheinitialstate(0dBforeverychannels).Anotherdialcontrolsthegeneralgainofthesystem(alsoina[-10dB,10dB]range).Itdoesnotdependonthesetbutton.Thatis,itschangeimmediatelyupdatesthesystemgain.Figure8.7depictshowthishasbeensolvedusingHetSCandSystemC-AMStogether.ThesystemisenclosedinaSystemCmodule(soundboard).ThistopmodulecontainsanotherSystemCmodule(panel_control),whichcontainsthe+10dBEQ.STATEDISPLAYAINAOUT0dBGENVOLMODE−10dBHz32641252505001K2K4K8K16K+10dBCANCELSETCHVOLCHSELECT0dB−10dBCHEQ.EDITIONDISPLAY**Fig.8.6Soundboardsystem 8HeterogeneousSpecificationwithHetSCandSystemC-AMS117testbenchCSPsoundboarduserSReditionsoundboard_displaycontrol_panelstate_displayKPNRch_ctrlRgen_ctrl(T-SDF)s_insinsrcnoise_filterequalizer_arrayintegrator(LN-TF)(LEN)HetSCSystemC-AMS(ANALOG)Fig.8.7SystemC-AMS-HetSCspecificationHetSCpartofthesystemandusestheHetSClibraryspecificationfacilities.ThesoundboardmodulealsocontainsthreemoduleswhichuseSystemC-AMSfacili-ties.Inthiscase,thetestbenchmodel(testbenchmodule)iscomposedoffourmoduleswhichonlyuseHetSCfacilities.Inanotherversion,partofthetestbench(theaudioinput)wasspecifiedusingSystemC-AMSspecificationfacilities).Inthissense,severalcombinationswerepossibleleadingtothesameresult.InFig.8.7,thecorrespondencewiththeMoCsemployedisdepictedwithdashedlines.Inthetestbenchmodule,twoprocesses(left_handandright_hand)modelthehandlingofdialsandbuttonsofthesoundboard.Thetwoprocessesaresynchro-nizedthrougharendezvouschannel,toensurethelefthandeditstheequalizerpro-filebeforetherighthandpushesthesetbuttonandraisesthegeneralvolume.Becauseofthis,thispartisaCSPnetwork.Inaddition,eachoftheprocessesisanautonomousprocessgeneratingaSRreactivechain.Dialturnandbuttonpressaremodelledaswritestouc_SRchannels.Thereactivechainwhichcontrolsthegen-eralvolumeispureinthatitiscomposedonlyofgeneratorandreactiveSRproc-esses.Thereactiveprocessconvertsthedialevents(turningleftorright),whichmeanplus1dBorminus1dB,consideringtheboundsofthe[-10dB,10dB]range,inacontrolSystemCsignalwhichaffectsthevalueofaresistorcomposingtheintegratormodule.Asimilarthinghappenswiththechannelequalizationcontrol.However,herethereisnotapurereactivechain,sincethetworeactiveprocessesareborderprocesses,astheyalsowritetoinfinitefifoHetSCchannels(uc_inf_fifo),properoftheKPNMoC.Forinstance,oneisusedtopassthenewequalizationprofiletothestatedisplaywhenthesetbuttonispressed. 118F.Herreraetal.Intheanalogpart,thenoisefilterismodelledthroughaSystemC-AMSSDFmod-ule(noise_filter).Thismodulehasaninputport,toreadthes_inexternalsignalwhichprovidestheaudiosamples.ItisdesignedasasecondorderButterworthlowpassfilterwithacutfrequencyof22kHz,whichismodelledundertheLN-TFMoCofSystemC-AMS,usingtheNDview.Theothertwoblocksaremodelledatacircuitlevel,undertheLENMoC.Theequalizer_arraymoduleenclosesanarrayoftenequalizercells.Eachofthemisanactivebandpassfiltercentredatthechannelfrequency.Thisfilterisdescribedasacircuitwiththreeresistors,twocapacitorsandamodelofoperationalamplifier(OA)whichconsidersthegain,theinputandoutputresistance.Eachequal-izercellisinstantiatedtakingthecapacitorvaluesastheparameterforcentringeachfilteratthechannelfrequency(32Hzforchannel0,64Hzforchannel1andsoontill16kHzforchannel9).Theoutputofeachequalizercellisconnectedtoaresistorinstanceoftypesca_sc2r,controlledbyoneofthesignalsoftheRch_ctrlsignalarray.Theseresistorsareconnectedtothesameelectricaloutputnode,wherethecontribu-tionofeachequalizercellisadded.Thisnodeisusedasinputtotheintegratormodule.Thismoduleisalsodescribedasacircuitwhichalsoinstantiatesthepreviouslymen-tionedOAmodel,acapacitor,andaresistorcontrolledbytheRgen_ctrlsignal,tocontrolthegainoftheintegratorand,thus,ofthewholesystem.Inboth,theHetSCandSystemC-AMSparts,elementsareemployedtoconnectMoCs.Forinstance,BPsconnectKPNandSRMoCsintheHetSCpart,andasca_sdf2vinstanceconnectsthenoisefiltertotheequalizerarray.InFig.8.7,theconnectionsbetweentheHetSCandtheSystemC-AMSparthavebeenhighlightedwiththickerarrows.Specifically,theaudioinputsamplesaretransferredtothesoundboardmodulethroughaninstanceoftheuc_inf_fifo_sca_sdfchannelintro-ducedintheprevioussection.Thisborderchannelenablesadirectconnectionbetweentheuntimedpart,whichgeneratesthesamples,andtheSystemC-AMSinputconverterportofthenoisefilter.TheconnectionoftheSRreactivechainstotheLENpartofthemodelisplacedbetweenthelowerpartofthecontrol_panelmoduleandtheequalizer_arrayandintegratoranalogmodules.Forinstance,thereactiveprocesstriggeredbytheturneventsofthegeneralvolumedialisindeedaborderprocesswhichwritestheRgen_ctrlSystemCsignal.Asimilarthinghappenswiththenonpurereactivechain,whichdrivesanarrayoftensignals(eachoneforitscorrespondingequalizerchannel).EachofthesesignalscontrolsthevalueofaSystemC-AMSsca_sc2rprimitive.Atimedomainsimulationandtwofrequencyanalyseshavebeenperformed.Thetimedomainsimulationisdumpedtodataandwaveformfiles.Thefirstfrequencyanalysisisdoneinthemiddleofthetimedomainsimulation.Atthistime,thesound-boardresponsecorrespondstothatoftheinitialstate(0dBgainforeverychannelandforthegeneralvolume).Thesecondfrequencyanalysisisdoneattheendofthetimedomainsimulation,onceamanualconfigurationhasbeenperformedandthesetbuttonpressed.Additionalresultsofthesimulationaretwodatafiles,withthefrequencyresponseoftheequalizer(thus,theequalizationprofile)atdifferentpointsofthesimulationtime.Theresulthasbeenpost-processedwithOctavespecificationexecution,justtoreflectthechangeontheequalizationprofile(Fig.8.8).Otherout-putsofthesystemaretwologfileswhichreflecttheactivityofthedisplays. 8HeterogeneousSpecificationwithHetSCandSystemC-AMS119dBInitialandEditedfrequencyresponse.20initialedited0−20−40−60−80−100−1201101001000100001000001e+06HzFig.8.8InitialandeditedfrequencyspectrumTable8.1HostconfigurationswheretheexamplehasbeencompiledandexecutedOSGCCSystemCSystemC-AMSHetSCLinux2.6.3/32bits3.3.22.1v10.15RC1/RC21.2Linux2.6.3/32bits4.0.02.2.00.15RC41.2Linux2.6.3.2/64bits4.1.22.2.00.15RC41.2Thisspecificationtookaround2,500SystemCcodelinesincludingtestbenchmodulesandaround30man-hours(ignoringlearningtime).Thesimulationtimewaslessthan53sinanIntelPIV2.8GHz,Linux2.6.3developmentplatform.Thisillustrateshowfastthesystem-levelspecificationandanalysisofsuchheterogene-oussystemcanbedoneusingHetSCandSystemC-AMS.Theexamplehasbeencheckedforthreeconfigurationsofdevelopmentplatforms,reflectedinTable8.1.8.5ConclusionsandFutureWorkThisworkaddresseshowtheHetSCandSystemC-AMSspecificationmethodolo-giescanbeusedtogether.Withtheircooperation,awiderangeofMoCs,fromuntimedtoanalogones,areefficientlycovered.Thisisakeyfeatureinenablingtheearlysystem-levelspecificationofembeddedsystems.Theinstallationandcompat-ibilityoftheHetSCandSystemC-AMSlibrarieshasbeenchecked.Furthermore, 120F.Herreraetal.thesyntacticalandsemanticalissuesrelatedtotheconnectionhavebeendiscussed.SystemC-AMSisbasedonatimedSDFMoC,whereAMSclusterscanbeconcep-tuallyseenastimed-clockedsynchronousblocksfromtheDEpart.SystemC-AMSprovidesfacilitiesforthisAMS/DEconnectionwhicharebasedonthesamplingandupdateoftheSystemCsignal.SinceHetSCMoCsareabstractedfromtheunderlyingDEstrict-timeMoC,theconnectionofanyHetSCMoCwithanySystem-AMSMoCcanbereducedtoaSystemCDE/SystemC-AMSconnection.Thus,SystemC-AMSfacilitiesfortheDE/AMSconnectioncanbeused.Moreover,theHetSCborderchannelcanbeconvenientlyusedtoprovidedirectconnectionsamongspecificuntimedandsynchronous(HetSC)MoCsandanalog(SystemC-AMS)MoCs,hidingtheintermediationofDEsignalsintheconnectionofMoCsthatdonotemploysuchspecificationprimitivesandencapsulatingthedetectionoferrorsituationswhichconsidertheclusterperiod,thetimeconditionsofHetSCpart,etc.Theimmediateevolutionofthisworkcanbefound[17],whereconverterchannelsareintroduced.Thesechannelsincorporateconceptsofpolymorphicsig-nals[18],releasingfromanymanualengagementinthesystemrefinement.Aswellasadaptationsonthetimeandcommunicationdomain,converterchannelsalsointroduceadaptationsatthedatatypedomain.Finally,thisworkimplicitlystatestheneedforaformalenvironmentinordertoobtainacommonunderstandingoftheinteroperationofthiskindofmethodologies.AcknowledgmentsWorksupportedbytheFP6-2005-IST-5Europeanproject.References1.E.A.LeeandA.Sangiovanni-Vincentelli.AFrameworkforComparingModelsofComputation.IEEETransactionsonComputer-AidedDesignofIntegratedCircuitsandSystems,17(12),December1998.2.A.Jantsch.ModellingEmbeddedSystemsandSoCs.MorganKaufmann,SanFrancisco,CA,June2003.MorganKaufmannPublishersAnimprintofElsevierScience340PineStreet,SixthFloorSanFrancisco,California94104-3205www.mkp.com3R.Gupta.HDL/CInterfaceExploration.Tech.Report,ICSDpt.,UniversityofCalifornia,California,2002.4.A.Davareetal.ANext-GenerationDesignFrameworkforPlatform-BasedDesign.InDVCon2007,SanJose,CA,USA,February2007.5.C.Brooksetal.PtolemyII:HeterogeneousConcurrentModelingandDesigninJava.Tech.Report,UniversityofCalifornia,Berkeley,CA,July2005.6.L.Geppert.ElectronicDesignAutomation.IEEESpectrum,37(1),January2000.7.F.Herrera,E.Villar,C.Grimm,M.DammandJ.Haase.AGeneralApproachtotheInteroperabilityofHetSCandSystemC-AMS.InProceedingsoftheForumofDesignLanguages2007.FDL’07,Barcelona,Spain,2007.8.A.Vachoux,C.Grimm,andK.Einwich.TowardsAnalogandMixed-SignalSoCDesignwithSystemC-AMS.InIEEEDELTA’04,Perth,Australia,2004.9.A.Herrholzetal.ANDRES–AnalysisandDesignofRuntimeReconfigurableHeterogeneousSystems.InProceedingsofDATE’07,Nice,France,April2007. 8HeterogeneousSpecificationwithHetSCandSystemC-AMS12110.F.HerreraandE.Villar.AFrameworkforEmbeddedSystemSpecificationUnderDifferentModelsofComputationinSystemC.InProceedingsofDAC’06,SanFrancisco,CA,July2006.11.H.Posadas,F.Herrera,V.Fernandez,P.Sanchez,andE.Villar.SingleSourceDesignEnvironmentforEmbeddedSystemsBasedonSystemC.TransactionsonDesignAutomationofElectronicEmbeddedSystems,9(4):293–312,December2004.12.H.D.PatelandS.K.Shukla.SystemCKernelExtensionsforHeterogeneousSystemModeling:AFrameworkforMulti-MoCModeling.Springer,July2004.13.H.D.Patel,D.Mathaikutty,andS.K.Shukla.ImplementingMulti-MocExtensionsforSystemC:AddingCSPandFSMKernelsforHeterogeneousModelling.Tech.Report,FERMAT,VirginiaTech.,June2004.14.E.A.LeeandD.G.Messerschmitt.StaticSchedulingofSynchronousDataFlowProgramsforDigitalSignalProcessing.IEEETrans.onComputers,C-36(1):24–35,1987.15.J.Falk,C.Haubelt,andJ.Teich.EfficientRepresentationandSimulationofModelBasedDesignsinSystemC.InProceedingsofFDL’06,Darmstad,Germany,September2006.16.http://www.teisa.unican.es/HetSC/downloads.html17.J.Haase,M.Damm,C.Grimm,F.Herrera,E.Villar.UsingConverterChannelswithinaTop-DownDesignFlowinSystemC.The15thAustrianWorkhoponMicroelectronics,Graz,Austria,October,2007.18.R.Schroll,C.Grimm,andWaldschmidtK.VerfeinerungvonMixed-SignalSystemenMitPolymorphenSignalen.InAnalog’05.VDE-Verlag,Berlin,Germany,2005. Chapter9AnExtensiontoVHDL-AMSforAMSSystemswithPartialDifferentialEquationsLeranWang,ChenxuZhao,andTomJ.KazmierskiAbstractThispaperproposesVHDL-AMSsyntaxextensionsthatenabledescrip-tionsofAMSsystemswithpartialdifferentialequations.WenamedtheextendedlanguageVHDL-AMSP.AnimportantspecificneedforsuchextensionsarisesfromthewellknownMEMSmodellingdifficultieswherecomplexdigitalandanalogueelectronicsinterfaceswithdistributedmechanicalsystems.ThenewsyntaxallowsdescriptionsofnewVHDL-AMSobjects,suchaspartialquantities,spatialcoordinatesandboundaryconditions.Pendingthedevelopmentofanewstandard,asuitablepre-processorhasbeendevelopedtoconvertVHDL-AMSPintotheexistingVHDL-AMS1076.1standardautomatically.Thepre-processorallowsdevelopmentofmodelswithpartialdifferentialequationsusingcurrentlyavailablesimulators.Asanexample,aVHDL-AMSPdescriptionforthesensingelementofaMEMSaccelerometerispresented,convertedtoVHDL-AMS1076.1andsimulatedinSystemVision.KeywordsHardwaredescriptionlanguage,VHDL-AMS,mixed-technologymodel-ling,partialdifferentialequations,MEMS9.1IntroductionVHDL-AMSisahardwaredescriptionlanguagedesignedtosupportmodellingatvariousabstractionlevelsinmixed,electricalandnon-electricalphysicaldomainsaswellasmixed,digitalandanaloguecomponents[1].ThesefeaturesmakeitstraightforwardforVHDL-AMStobeusedasthemodellinglanguageinMEMSdesign.SinceMEMSsystemsarecombinationsofsubsystemsfromboththeelec-tricalandmechanicaldomains,thefieldofMEMSdesignisinterdisciplinaryinnature.SeveralVHDL-AMSbasedMEMSmodelshavealreadybeenreportedinliterature,suchasayawratesensor[2]andavibrationsensorarray[3].SchoolofElectronicsandComputerScience,UniversityofSouthampton,UKEmail:{lw04r,cz05r,tjk}@ecs.soton.ac.ukE.Villar(ed.)EmbeddedSystemsSpecificationandDesignLanguages,123©SpringerScience+BusinessMediaB.V.2008 124L.Wangetal.AlthoughVHDL-AMSisaverypowerfulandflexiblemixedphysicaldomainmodellingtool,itfacesachallengeinMEMSrelatedapplications.ThecurrentVHDL-AMS(IEEE1076.1)canonlydescribethecontinuouspartsofasystembyusingdifferentialandalgebraicequations(DAEs).Supportforpartialdifferentialequations(PDEs)wasintentionallyleftoutinthedevelopmentofVHDL-AMSstandardduetothecomplexity[4].Thislimitsaccuratemodellingofsystemblocksthatincludedistributedphysicaleffects[5].However,simulationofsingle-domaincharacteristicsofmicrodevicesisusuallyperformedbysolvingPDEswithgeometry-relatedboundaryconditions[6].SuchblocksarecurrentlymodelledinVHDL-AMSmainlybyreduced-ordermodels(ROMs)[2,3].BecauseofthesizeofaMEMSdevice,distributedeffectsarenotnegligibleandmayevenplayvitalroles,forwhichreduced-orderMEMSmodelsareoftennotaccurateenough.ThusanimplementationofPDEsinVHDL-AMSisindemand.SuggestionshavebeenmadetoextendotherAMS-HDLs,suchasModelica[7]andVerilog-AMS[8],toaddPDEsupport.SomeattemptshavealreadybeenmadetoimplementPDEswithintheexistinglimitsofVHDL-AMS.Atransmissionlineexample[5]andasystemwithelectro-thermalcoupling[9]aremodelledusingVHDL-AMS1076.1.Thewayistodiscretizetheequationswithrespecttospatialvariablesandleavethetimederiva-tivestobehandledbyVHDL-AMS[5].Theproblemwiththisapproachisthatthediscretizationisdonemanually.Whensomemodificationsaremadetothesystem,aseriesofequationshavetoberewrittenwhichmakesthemodellingveryinefficient.NewlanguageextensionsforPDEsupporthavealsobeenraised[5,9]butcurrentlynosimulatorcanhandlethenewoperators.TheworkpresentedinthispaperimplementsPDEsinVHDL-AMSinsuchawaythatpendingthedevelopmentofacorrespondingstandard,PDEscanbewrit-tendirectlybutnonewsimulatorsareneeded.Necessarylanguageconstructshavebeenadoptedfrompreviouswork[5,9]andsomeimprovementshavebeenmade.Atranslationpre-processorhasbeendevelopedtoconverttheextendedlanguage(VHDL-AMSP)intoVHDL-AMS1076.1automaticallysothatmodelswithPDEscanbesimulatedusingcurrentlyavailablesimulators.UsingthisnewmethodVHDL-AMSmodelsthatdescribesystemswithdistributedphysicaleffectscannowbebuiltandsimulatedmoreefficiently.Theproposedmethodologyisexpectedtohaveparticularadvantagesinmixedmechanical-electricalsystemswithtightcontrolfeedbackloops,ofwhichtheMEMSblockisanintegralpart.Forexample,theworkpresentedinarecentpaper[10]intendstodevelopnewandinnovativecontrolandinterfacesystems,technologiesandcircuitsforMEMSphysicalsensors.Theprimarymethodologyisbasedontheincorporationofmicro-mechanicalsensingelements(e.g.foraccelerometersandgyroscopes)inhigh-orderΣ∆modulator(SDM)loops.Theloopfilterconsistsofmechanicalandelectronicintegrators;theformerisconstitutedbythemicromachinedsensingelementwhichis,toafirstorderapproximation,asecondordertransferfunc-tion.Thetoolscurrentlyusedforsimulatingsuchacomplexandhighlycoupledsystemareprimarilysystemleveltools,suchasMatlab/Simulink.Thelumpedparametermodelofthesensingelementcapturesonlythefirstmechanicalmode. 9AnExtensiontoVHDL-AMSforAMSSystems125However,whendesigninghigher-orderelectro-mechanicalSDMloops,higherordermechanicalmodesmaywellbeofconsiderablesignificanceforthestabilityandperformanceofthecontrolloop.Consequently,havingadistributedmechani-calmodelusingpartialdifferentialequationswouldbeasignificantbreakthroughforthedesignofsuchdevices.Todemonstratetheefficiencyofourapproach,thesensingelementofsuchaMEMSaccelerometerinSDMloophasbeenmodelledinVHDL-AMSP,translatedtoVHDL-AMS1076.1andsimulated.Simulationresultsshowthathigh-orderbehaviourofthecantileverbeamhasbeencaptured,whichisnotpossibleinconventionalmethodologies.9.2VHDL-AMSExtensionsforPDESupportTheextensionsoutlinedbelowsupportequationsthatmaycontainhigh-orderpartialderivativesdescribingsystemsinamultidimensionalspace.9.2.1PartialQuantityWiththekeywordpartial,apartialquantityisdefinedasaphysicalvariablewhichhasacontinuousvaluenotonlyoveraperiodoftimebutalsooverahypercubeinamultidimensionalspace.Itisdeclaredas:partialquantityq:real;ThecorrespondingBNF(Backus-NaurForm)notationis:partial_quantity_declaration::=partialquantityidentifier_list:subtype_indication;Partialquantitiesmayactasinterfacesbetweenentitiesaswellasappearinarchi-tecturebodies.9.2.2SpatialCoordinateWiththekeywordcoordinate,spatialcoordinateisdeclaredoverwhichapartialquantityisdistributed.Multiplecoordinatedeclarationswillformahypercubeinspace.Thedeclarationcandefinearangeinspaceandthediscretizationstepsize. 126L.Wangetal.Therangeisobligatoryasitdefinesthehypercube,butthestepsizeisoptional.Itisuptothedesignertodecidewhethertousedefaultstepsizeortogiveafixedvalue.Thefollowingisanexampleofaspatialcoordinatedeclaration:coordinatex:realrange0.0to10.0step0.1;TwonewgrammarproductionshavebeenaddedtothelanguageBNF:coordinate_declaration::=coordinateidentifier_list:subtype_indication;step_size::=stepsimple_expressionTheexistingrangeconstructisextendedbythenewstepconstructionas:range::=range_attribute_name[step_size]|simple_expressiondirectionsimple_expression[step_size]9.2.3PartialDerivativesAssuggestedinthepapersbyNikitinetal.[5,9],anewlanguageattributenameisintroducedas′dot(x).Ifqisapartialquantityandxisacoordinate,q′dot(x)representsthederivativeofqwithrespecttox.Unliketheexamplegiveninthepaper[9]whereahigh-orderderivativeisrepresentedbymultipleticks,e.g.q″dot(x)forthesecondorder,VHDL-AMSPusesthesamenotationasVHDL-AMS,namelyq′dot(x)′dot(x).ThiskindofrepresentationisinthespiritoftheexistingVHDL-AMS1076.1standardandq′dot(x)asawholeisstillapartialquantity.Apartialquantitycanalsohaveaderivativewithrespecttotime,usingtheattribute′dot,soitemslikeq′dot(x)′dotarevalid.Multidimensionalderivativesaresupported,suchasq′dot(x)′dot(y)wherexandyaretwocoordinates.SincethereisnopredefinedattributenameandattributedesignatorinVHDL-AMS,thisextensiondoesnotaffectthelanguageBNF.9.2.4SimultaneousStatementwithPartialDerivativesAsimpleexampleis:q′dot(x)==A*q′dot; 9AnExtensiontoVHDL-AMSforAMSSystems127∂q∂qwhichrepresents=A.∂x∂tPartialdifferentialequationscanalsoappearinsimultaneousiforcasestate-ments.High-orderderivativesorderivativesofmorethanonespatialcoordinatecanalsobedescribedinasimultaneousstatement.9.2.5BoundaryConditionsAboundaryconditionisdefinedasaspecialsimultaneousstatementasshownbelow.Theexpressionafterthekeywordatspecifiesthespatialboundarywheretheconditionsshouldapply.Conditionsarewrittenintheformofsimultaneousstate-ments.Anexampleis:boundaryxat0.0isbeginq==0.0;q′dot(x)==0.0;endBOUNDARY;ThecorrespondingproductioninthelanguageBNFis:simultaneous_boundary_statement::=[boundary_label:]boundarycoordinate_nameatsimple_expressionisbeginsimultaneous_statement{simultaneous_statement}endboundary[boundary_label];9.3TranslationtoVHDL-AMS1076.1Wehavedevelopedatranslationpre-processortoautomaticallyconvertVHDL-AMSPmodelsintoVHDL-AMS1076.1.Thepre-processorcanbeusedasatenta-tivemeasuretoimplementPDEsinVHDL-AMSpendingthedevelopmentofanappropriatestandard.Thetranslationpre-processorusesamodifiedversionofaVHDL-AMSparser[11]wherethemodificationsincorporatethenewsyntaxintotheparserandallowsyntaxanalysisbyrecursivescanningoftheparsetree.Duringthescanning,newlanguageconstructscanbeidentifiedandreplacedbynecessaryVHDL-AMS1076.1constructs.Howthenewconstructsareconvertedintoexistingconstructsisdemonstratedbelow,usingtheexamplesfromSection9.2. 128L.Wangetal.Inthedeclarationpartofthemodel,apartialquantityisconvertedintoaquantityvectorbythesamename.Thevectorsizeisdeterminedbythecoordinate’srangeandstep,i.e.range/step.Thecoordinatewon’tappearintheoutputfilebutadiffer-entialcoefficient(dxintheexample)willbedeclaredasaconstant,whichhasthevalueofthestepsize.Thedeclarationpartwillthereforecontain:quantityq:real_vector(0to100);constantdx:real:=0.1Inthearchitecturepart,aPDEwillbereplacedbyaseriesofDAEs.Finitediffer-enceapproach[12]isusedasthediscretizationmethod.Notethatthediscretizationonlyappliestothemiddlepartofahypercubespacewhiletheborderswillbedescribedbyboundaryconditions.ThePDEinSection9.2.4willbediscretizedas:(q(2)-q(1))/dx==A*q(1)′dot;(q(3)-q(2))/dx==A*q(2)′dot;(q(4)-q(3))/dx==A*q(3)′dot;…TheboundarystatementsinSection9.2.5aretranslatedintosimplesimultaneousstatements:q(0)==0.0;(q(1)-q(0))/dx==0.0;TheseDAEsaresolvablebyaVHDL-AMS1076.1simulator.9.4MEMSAccelerometerinaSDControlLoopFigure9.1showstheblockdiagramofaMEMSaccelerometerinfifth-orderSDMcontrolloop[10].Likemostconventionalmodellingapproaches,themicro-mechanicalsensingelementismodelledasasecond-orderspringdampingsystem:Mzt

()++=Czt
()Kzt()Ft()(9.1)whereMistheproofmass,CandKareeffectivedampingandspringfactorrespec-tively,z(t)istherelativedisplacementandF(t)isthefeedbackforce.ThefrequencyresponseofthelumpedmodelisshowninFig.9.2. 9AnExtensiontoVHDL-AMSforAMSSystems129Fig.9.1MEMSaccelerometerinSDMloopFig.9.2FrequencyresponseofthelumpedmodelTheproof-massdisplacementisconvertedtoelectronicsignalbydifferentialcapacitivepositionsensing.Theelectronicsignalisthenpassedthroughathird-orderlow-passfilter,whichisimplementedwithdistributedfeedbackstructure.Thefilteredsignalisdigitizedbya1-bitquantizerandtheoutputisthedigitalsignal.TheelectrostaticfeedbackforceisgeneratedbyaDAC.SuchaSDMcontrolloophastheadvantagesofincreaseddynamicrange,linearityandband-width[10]thusithasattractedgreatresearchinterests.Inactualsituation,thesensingelementconsistsofaMEMScantileverbeamlocatedbetweentwoplateelectrodes(Fig.9.3).Insteadofmovingasalumpedmass,thecantileverbeamitselfvibratesandhashigherfrequencymodes.Ithas 130L.Wangetal.Fig.9.3MEMScantileverbeamasthesensingelementbeenprovedthathigher-orderresonantfrequenciescanaffecttheperformanceofanSDMloop[13].However,asshowninFig.9.2,suchbehaviourcannotbecapturedbytheconventionallumpedmodel.9.5VHDL-AMSPModeloftheSensingElement9.5.1ModelDescriptionFigure9.3showsthesensingelementofanaccelerometerinSDMcontrolloops.Thefeedbackforceisactingonthebaseofthecantilever(non-collocateddynamics)[13]andthecantileverbeamisonlydeformedbydistributedelectrostaticforce.Thegoverningequationofthismodelis:452yxt(,)yxt(,)yxt(,)EI++=crSFxt(,)(9.2)44De2xxttwherey(x,t)istherelativedisplacementatpositionxandtimet,EistheYoung’smodulus,Iisthemomentofinertia,cisthedampingfactor,risthematerial’sDdensity,SisthecrosssectionalareaandF(x,t)istheelectrostaticforce.eTheboundaryconditionsattheclampedendandthefreeendareshowninEqs.9.3and9.4respectively[14],ytzt(,)0=()yt(,)0(9.3)q==0x 9AnExtensiontoVHDL-AMSforAMSSystems1312yLt(,)ME=−I=02x(9.4)3yLt(,)QE=−I=03xwhereq,MandQdenotetheslopeangle,thebendingmomentandtheshearforcerespectively,Listhelengthofthebeam.Theinitialconditionissimply:y(x,0)=0(9.5)TheelectrostaticforceF(x,t)isgivenby:e221⎡VV⎤00Fe(,)xt=eA⎢2−2⎥(9.6)2((dyx−,t))((dyx+,t))⎣00⎦whereeisthepermittivityofthegap,Aistheareaoftheelectrode,disthespacing0betweenthebeamandtheelectrodeandVistheamplitudeoftheappliedAC0voltage.Thedistributedcapacitancebetweenthecantileverandtheelectrodeisgivenby:eeAAC=,C=(9.7)ss12dyx−(,)tdyx+(,)t00Theoutputvoltagecanbecalculatedas:CC−ss12V()t=Vsin(wt)(9.8)out0CC+ss12Forsmalldisplacementcases,itcanbeassumedthaty2<0.0);quantityFE:realvector(0to5):=(others=>0.0);quantityzacrossF0throughPROOF_MASStoTRANS-LATIONAL_REF;beginM*z’DOT’DOT+D*z’DOT+K*z==F0;–-movementofproofmassFE(0)==0.5*ep0*A*(1.0/((d0-y(0))**2)-1.0/((d0+y(0))**2)); 134L.Wangetal.–-electrostaticforceforclampedendFE(1)==0.5*ep0*A*(1.0/((d0-y(1))**2)-1.0/((d0+y(1))**2));–-electrostaticforceforsection1FE(2)==0.5*ep0*A*(1.0/((d0-y(2))**2)-1.0/((d0+y(2))**2));–-electrostaticforceforsection2FE(3)==0.5*ep0*A*(1.0/((d0-y(3))**2)-1.0/((d0+y(3))**2));–-electrostaticforceforsection3FE(4)==0.5*ep0*A*(1.0/((d0-y(4))**2)-1.0/((d0+y(4))**2));–-electrostaticforceforsection4FE(5)==0.5*ep0*A*(1.0/((d0-y(5))**2)-1.0/((d0+y(5))**2));–-electrostaticforceforsection5y(0)==z;–-dynamicsofclampedendE*I*(y(3)-4.0*y(2)+6.0*y(1)-3.0*y(0))/dx**4+ROU*S*y(1)’DOT’DOT+C*(y(3)’DOT-4.0*y(2)’DOT+6.0*y(1)’DOT-3.0*y(0)’DOT)/dx**4==FE(1);–-dynamicsofsection1E*I*(y(4)-4.0*y(3)+6.0*y(2)-4.0*y(1)+y(0))/dx**4+ROU*S*y(2)’DOT’DOT+C*(y(4)’DOT-4.0*y(3)’DOT+6.0*y(2)’DOT-4.0*y(1)’DOT+y(0)’DOT)/dx**4==FE(2);–-dynamicsofsection2E*I*(y(5)-4.0*y(4)+6.0*y(3)-4.0*y(2)+y(1))/dx**4+ROU*S*y(3)’DOT’DOT+C*(y(5)’DOT-4.0*y(4)’DOT+6.0*y(3)’DOT-4.0*y(2)’DOT+y(1)’DOT)/dx**4==FE(3);–-dynamicsofsection3E*I*(-2.0*y(5)+5.0*y(4)-4.0*y(3)+y(2))/dx**4+ROU*S*y(4)’DOT’DOT+C*(-2.0*y(5)’DOT+5.0*y(4)’DOT-4.0*y(3)’DOT+y(2)’DOT)/dx**4==FE(4);–-dynamicsofsection4E*I*(y(5)-2.0*y(4)+y(3))/dx**4+ROU*S*y(5)’DOT’DOT+C*(y(5)’DOT-2.0*y(4)’DOT+y(3)’DOT)/dx**4==FE(5);–-dynamicsofsection5endarchitectureBCR; 9AnExtensiontoVHDL-AMSforAMSSystems135Fig.9.4Frequencyresponseofthedistributedbeammodel9.5.4SimulationResultsTheVHDL-AMS1076.1descriptiongeneratedbythetranslationpre-processorhasbeensimulatedbySystemVisionfromMentorGraphics[15]andsimulationresultsshowingthefrequencyresponseofaveragebeampositionarepresentedinFig.9.4.Itisclearthathigher-orderresonantmodeshavebeencaptured.9.6ConclusionThispaperproposesextensionstoefficientlyimplementgeneralpartialdifferentialequationsinVHDL-AMS.ThecurrentversionofVHDL-AMS(IEEE1076.1)canonlysupportordinaryderivativeswithrespecttotimeandfacesdifficultieswhenappliedtothemodellingofdistributedsystems.IntheproposedVHDL-AMSPlanguage,newconstructsareintroducedtodescribePDEsinadirectform.Atrans-lationpre-processorhasbeendevelopedtoconvertVHDL-AMSPmodelsintoVHDL-AMS1076.1automatically,suchthatmodelswithPDEscanbesimulatedusingcurrentlyavailablesimulators.TheaddedPDEsupportenhancestheability 136L.Wangetal.ofVHDL-AMStomodelMEMSsystemswheredistributedbehaviourisessential.TheefficiencyofthisnewapproachhasbeeninvestigatedbyVHDL-AMSPbasedmodellingandsimulationofthesensingelementofaMEMSaccelerometerinhigh-orderSDMloop.SimulationresultsshowthatVHDL-AMSPmodelcoulddescribethedistributedbehaviourofasystemwhichisnotpossibleincurrentVHDL-AMS1076.1language.References1.ChristenEandBakalarK(1999)VHDL-AMS–ahardwaredescriptionlanguageforanalogandmixedsignalapplications.CircuitsandSystemsII:AnalogandDigitalSignalProcessing,IEEETransactionson,46(10):1263–12722.MahneT,KehrK,FrankeA,HauerJ,andSchmidtB(2005)Creatingvirtualprototypesofcomplexmicro-electro-mechanicaltransducersusingreducedordermodellingmethodsandVHDL-AMS.InForumonSpecificationandDesignLanguages,Proceedings,pages27–303.SchlegelM,BenniniF,MehnerJE,HerrmannG,MullerD,andDotzelW(2005)AnalyzingandsimulationofMEMSinVHDL-AMSbasedonreduced-orderFEmodels.SensorsJournal,IEEE,5(5):1019–10264.ShiC-JandVachouxA(1995)VHDL-AMSdesignobjectivesandrationale.CurrentIssuesinElectronicModeling,KluwerAcademicPublishers,2:1–305.NikitinPV,ShiCR,andWanB(2003)ModelingpartialdifferentialequationsinVHDL-AMS.InSystems-on-ChipConference,2003.Proceedings.IEEEInternational,pages345–3486.BushyagerN,TentzerisMM,GatewoodL,andDeNataleJ(2001)AnoveladaptiveapproachtomodelingMEMStunablecapacitorsusingMRTDandFDTDtechniques.InMicrowaveSymposiumDigest,2001IEEEMTT-SInternational,volume3,pages2003–20067.SaldamliL,FritzsonP,andBachmannB(2002)ExtendingModelicaforpartialdifferentialequations.In2ndInternationalModelicaConference,proceedings,pages307–3148.ProposedVerilog-Alanguageextensionsforcompactmodeling(2004)http://www.eda.org/verilogams/htmlpages/compact.html9.NikitinPV,NormarkE,andShiC-JR(2003)DistributedelectrothermalmodelinginVHDL-AMS.InBehavioralModelingandSimulation,2003.BMAS2003.Proceedingsofthe2003InternationalWorkshopon,pages128–13310.DongY,KraftM,GollaschC,andRedman-WhiteW(2005)Ahigh-performanceaccelerometerwithafifth-ordersigma-deltamodulator.JournalofMicromechanicsandMicroengineering,15:1–811.SouthamptonVHDL-AMSValidationSuite(2007)http://www.syssim.ecs.soton.ac.uk/12.EvansG,BlackledgeJ,andYardleyP(1999)Numericalmethodsforpartialdifferentialequa-tions.Springer,London13.SeegerJI,XuesongJ,KraftM,andBoserBE(2000)SensefingerdynamicsinaSDforcefeed-backgyroscope.InTech.DigestofSolidStateSensorandActuatorWorkshop,pages296–29914.LiuY,LiewKM,HonYC,andZhangX(2005)Numericalsimulationandanalysisofanelectroac-tuatedbeamusingaradialbasisfunction.SmartMaterialsandStructures,14(6):1163–117115.MentorGraphicsCorporation(2004)SystemVisionUser’sManual.Version3.2,Release2004.3 Chapter10Mixed-LevelModelingUsingConfigurableMOSTransistorModelsJürgenWeber1,AndreasLemke1,AndreasLehmler1,MarioAnton1,andSorinA.Huss2AbstractThiscontributionpresentsanapproachtomixed-levelmodelingusingconfigurableMOStransistormodelsaspartofabehavioralmodel.AlleffectsofthecompleteMOStransistormodelcanbespecificallyenabledordisabledintheconfigurablemodel.Byactivatingonlytheeffectsrequiredforthebehavioralmodel,simulationtimescanbereducedsignificantlywithverylittleeffort.ThenewmethodisdemonstratedbypartitioningtheMOSlevel-1transistormodelaccordingtoeffectsandimplementingaconfigurableMOSlevel-1transistormodelinVerilog-A.Severalexamplesofusewillshowthereductioninsimulationtime.TheproposedapproachcanbeusedwithanytypeoftransistormodelandiseasilyintegratedincircuitsimulatorssuchasSPICE.Keywordsmixed-levelmodeling,Verilog-A,behavioralmodel,configurable,MOStransistor,virtualtest10.1IntroductionThegenerationofbehavioralmodels[1]isbecomingmoreandmoresignificantinthedevelopmentofintegratedcircuits.Inmodernmixed-signalsystemdesignflows,atop-downdesignmethodologyfollowedbybottom-upverification[6,3]isused.Inthebottom-upmethod,thespecifictransistorlevelcomponentsoftheentiredesignwillberealizedfirst,afterthatthecomponentswillbeconnectedtolargerunits,andfinallyverifiedbysimulation.Inintegratedcircuitdesign,behavioralmodelsareneededindifferentapplications.Sincenounifiedmodelingstrategiesthatcoverallapplicationranges(executablespecifications,top-downandbottom-upmethodology,customermodelsandvirtualtests[7,5])havebeenestablishedyet,custom-designedsolutionswiththelargestcoverageofthedifferentrequirementsmustbeused.Thecomponentbasedmixed-levelmodelingapproach[8]isanefficient1AtmelGermanyGmbH,Heilbronn2IntegratedCircuitsandSystems,DepartmentofComputerScience,TUDarmstadtE.Villar(ed.)EmbeddedSystemsSpecificationandDesignLanguages,137©SpringerScience+BusinessMediaB.V.2008 138J.Weberetal.modelingmethod.Itappliestheconceptofmixed-levelsimulationsalsoatthecomponentlevel.Thusitispossibletodescribethecircuitbehavioratrequiredpointswiththehighestprecisionbutwiththeadditionaladvantageofsubstantiallydecreasingthesimulationtime,withspecificsimplifications.Intransistormodels,whichareusedinthismethod,propertieswhichareredundantforbehavioralmodelsareincluded.ThesearerealizedwithBSIM,EKV,orotherhigherSPICEorSPECTRElevelmodels,whichusedifferentregionsofoperationthataredescribedusingequationswithinthemodel.Forexample,invirtualteststhefulldescriptionoftheprimitivesisnotnecessaryinmostcases.Inthisarticle,amethodwillbeintroducedwhichdescribeshowtransistormodelscanbepartitionedandcharacteristicscanbeactivatedordeactivatedwiththegoalofreducingthenumberofequationsused,thusachievingbetterperformance.Furthermore,MOSFET-HDLmodelswhichcanbeuniversallyimplementedinamultitudeofmodellingapplications,forexampleinthedevelopmentprocess(top-downmethodology)orinthevirtualtest,canbegenerated.Todemonstratethismethod,aboostconverter,whichisrealizedwithmixed-levelmodelling,isused.Inpracticalapplications,low-levelMOSFETmodelsarerarelyused.InthemajorityofcasesBSIMorEKVareestablishedhere.Thedem-onstrator,whichisintroducedinthisarticle,isbasedonEKVmodels.Becauseofitscomplexity,level-1modelsareusedtodemonstratethenewmethodinstead.ThisMOSFETbehaviouralmodelisrealizedinVerilog-AandthensimulatedusingCADENCESPECTRE.Thebasicsofalevel-1modelaredefinedSection10.2.InSection10.3,therealisationoftheMOSFETbehavioralmodelsinVerilog-Aisintroduced,withademonstrationofthismethodinSection10.4.10.2MOSFETLevel-1ModelIntheMOSFETlevel-1modelthreeregionsofoperationaredefinedaccordingtothevoltagedifferencesbetweenthegate,source,anddrainterminals.TheseregionsarelistedinTable10.1.Ifthegate-sourcevoltageVislessthanthethresholdvoltageV,noconduct-GSthingchannelcanexist.Inthatcasethetransistorisinthecut-offregion,whereforthedraincurrentI
0holdsindependentofthedrain-sourcevoltageV.IfVDDSGSexceedsthethresholdvoltageV,achannelisformedandcurrentcanflow.ThethresultingcurrentIisapproximatelyproportionaltoV(forsmallV).Thus,thisDDSDSregioniscalledthelinearregion.IfVisincreasedbeyondV=V–V,theDSDS,satDSthchannelispinchedoffatthedrainsideandIrisesonlyslowly.ThetransistorisinDthesaturationregion.Assuminganidealchargedistributioninthechannel,thedraincurrentcanbeapproximatedusingSah’sModel[2].Table10.1RegionsofoperationintheMOSFETlevel-1modelCut-offregionVvtho))region=2;elseregion=3;10.3.3CalculationoftheDrainCurrentInthebehavioralmodel,fourmethodsofcalculatingthedraincurrent(cf.Table10.2)areavailable.Themostsimplevariant(var=0)assumesthatthetransistoroperatesinthelinearregiononly.ThedraincurrentiscalculatedasI
β*((V-DGSV)*V).ThiscorrespondstoavoltagecontrolledresistorwiththDS1Kn∗ωRDS=,b=(10.4)b∗()VVGS−thLAnothervariant(var=1)isthecalculationbasedontheassumptionofanidealchargedistributioninthechannel(Sah’sModel).Channellengthmodulationistakenintoaccountwithvar=2andcalculatedaccordingtoEq.10.1(Shichman-Hodgemodel). 142J.Weberetal.Thiseffectiscontrolledbytheparameterλ.Thefinalvariant(var=3)addstheshortchanneleffectasgiveninEq.10.3.ThefollowingsourcecodeshowstheimplementationofthevariantsofthedraincurrentcalculationinVerilog-A:if(var==0)begincase(region)1:id=‘ids;2:id=beta*(vgs-vtho)*vds;3:id=beta*(vgs-vtho)*vds;default:id=‘ids;endcaseendif(var==1)begincase(region)1:id=‘ids;2:id=beta*((vgs-vtho)-(vds/2))*vds;3:id=(beta/2)*(pow((vgs-vtho),2));default:id=‘ids;endcaseendif(var==2)beginearly_effect=1+lambda*vds;case(region)1:id=‘ids;2:id=beta*((vgs-vtho-(vds/2))*vds*early_effect;3:id=(beta/2)*(pow((vgs-vtho),2))*early_effect;default:id=‘ids;endcaseendif(var==3)begincase(region)1:id=‘ids;2:id=beta*((vgs-vtho)-(vds/2))*vds*(1+lambda*((1/(2e5*Leff))+1)*vds);3:id=(beta/2)*(pow((vgs-vtho),2))*(1+lambda*((1/(2e5*Leff))+1)*vds);default:id=‘ids;endcaseend10.3.4DrainCurrentAssignmentIftheseriesresistancescomponentofthemodelisused,thedraincurrentisassignedtotheinternalnodesDiandSi.OtherwiseitisassignedtotheexternalnodesDandS. 10Mixed-LevelModelingUsingConfigurableMOS143‘ifdefres_nodalI(Di,Si)<+id;‘elseI(D,S)<+id;‘endif10.3.5SeriesResistancesTheseriesresistancesconnecttheexternalnodestotheinternalnodes.ThemodelusestheeffectiveresistancesofthedrainRandthesourceR.TheresistancesofDSthebulkandthegatearenottakenintoaccount.‘ifdefres_nodalV(S,Si)<+I(S,Si)*RS;V(D,Di)<+I(D,Di)*RD;‘endif10.3.6GateCapacitancesGatecapacitancesarecalculatedinthethreeregionsofoperationdependingonCoxandtheterminalvoltagesasdescribedin[2].Overlapcapacitancesareincludedaswell.Switchingthecapacitancesbetweentheregionsofoperationcancausecon-vergencedifficultyinthesimulation.Thisproblemissolvedusingthetransitionstatementthatprovidessmoothswitchingbutalsoincreasesthecomputationaleffort.‘ifdefcap_gateif(region==1)begincgsk=0;cgdk=0;cgbk=cox;endif(region==2)begincgsk=((2*cox)/3)*(1-pow(((vgs-vtho-vds)/(2*(vgs-vtho)-vds)),2));cgdk=((2*cox)/3)*(1-pow(((vgs-vtho)/(2*(vgs-vtho)-vds)),2));cgbk=0;endif(region==3)begincgsk=(2*cox)/3;cgdk=0;cgbk=0;endqgs=(transition(cgsk)+‘cgso*W)*vgs;qgd=(transition(cgdk)+‘cgdo*W)*vgd;qgb=(transition(cgbk)+‘cgbo*L)*vgb;‘ifdefres_nodal 144J.Weberetal.I(Gi,Di)<+ddt(qgd);I(Gi,Si)<+ddt(qgs);I(Gi,Bi)<+ddt(qgb);‘elseI(G,D)<+ddt(qgd);I(G,S)<+ddt(qgs);I(G,B)<+ddt(qgb);‘endif‘endif10.3.7JunctionCapacitancesJunctioncapacitancesarisefromthepnjunctionsattheinterfacesfromsourceanddraintosubstrate.Thesecapacitancesarevoltagedependent,cf.[2].‘ifdefcap_subfbp=‘FC*‘mj;if(vbd<=fbp)cbd=‘cj*‘Abd*(1-(vbd*1/‘PB));elsecbd=((‘cj*‘Abd)/pow((1-‘FC),1+‘mj))*(1-(1+‘mj)*‘FC+‘mj*vbd/‘PB);if(vbs<=fbp)cbs=‘cj*‘Abs*(1-(vbs*1/‘PB));elsecbs=((‘cj*‘Abs)/pow((1-‘FC),1+‘mj))*(1-(1+‘mj)*‘FC+‘mj*vbs/‘PB);‘ifdefres_nodalI(Bi,Si)<+ddt(cbs*vbs);I(Bi,Di)<+ddt(cbs*vbs);‘elseI(B,S)<+ddt(cbs*vbs);I(B,D)<+ddt(cbs*vbs);‘endif‘endif10.3.8SubstrateDiodesSubstratediodesarelocatedbetweentheinternalnodesofbulkanddrainandsource,respectively.Byusing$vt,thetemperaturevoltagecalculatedbythesimu-latorisaccessed.Thereversesaturationcurrent‘isisusedforbothIandI.S,SS,D‘ifdefdio_subibd=‘is*(limexp(vbd/$vt)-1.0);ibs=‘is*(limexp(vbs/$vt)-1.0); 10Mixed-LevelModelingUsingConfigurableMOS145‘ifdefres_nodalI(Bi,Di)<+ibd;I(Bi,Si)<+ibs;‘elseI(B,D)<+ibd;I(B,S)<+ibs;‘endif‘endif10.3.9BodyEffectThethresholdvoltageismainlydependentonthebulk-sourcevoltage(bodyeffect).Asamodelparameterthezero-biasthresholdvoltagevt0ispassed.‘ifdefthresholdvtho=vt0+(gamma*((sqrt(abs(phi-vbs)))-(sqrt(phi))));‘elsevtho=vt0;‘endif10.3.10StaticMOSFETModelUsingInstanceParametersInthestaticMOSFETmodelusinginstanceparameters,theif-elsestatementisusedinsteadofpreprocessorstatements.Theindividualfunctionsofthemodelareenabledanddisabledbyinstanceparameterssothateachtransistorinstanceisconfiguredindi-vidually.Thisisanadvantageofthismethodasopposedtopreprocessorstatements.Asadisadvantage,thecomputationaleffortincreasesslightlyinthesimulation.parameterintegerres_nodal=0;if(res_nodal==1)-Withseriesresistanceselse-Noseriesresistancesend10.3.11DynamicMOSFETModelInsomeapplicationssuchasthevirtualtest,severaltestsaregroupedandmustbesimulatedinonesimulationrun.Thus,aMOSFETmodelisrequiredthatcanbereconfigureddynamicallyduringruntime.Thisisimplementedbyreplacingtheparametersofthestaticmodelwithvariables. 146J.Weberetal.integerres_nodal;if(res_nodal==1)-Withseriesresistanceselse-NoseriesresistancesendThesevariablescanbeswitchedindividuallyforeachinstancebythetestbench.Thefollowingsourcecodeshowsanexampleofatestbenchthatactivatestheseriesresistancesofaninstanceafter10,000unitsoftime.I_top.I_inv.I_NMOS1.res_nodal=0;#10000I_top.I_inv.I_NMOS1.res_nodal=1;endCurrently,AMS-DesignerandSpectredonotsupportanalogstatementsinVerilog-Athatusevariablesinsideofifclauses.Therefore,thesestatements,e.g.tocalcu-latecurrentsofcapacitancesusingddtorcurrentsofdiodesusinglimexp,havetobekeptoutsideofifclauses.Thus,themaximumpossiblereductioninsimulationtimecannotbeachievedwiththedynamicmodels.Forthatreason,inthefollowingsectionthestaticmodelusinginstanceparametersisused.10.4ResultsInthissection,theuseofconfigurableMOSFETbehavioralmodelswithinmixed-levelmodelingisdemonstratedonaboostconverterandtheresultsarediscussed.10.4.1DCBehaviourwithaConfigurableMOSFETModelFigure10.2showsthesimulatedoutputcharacteristicoftheNMOSwithvariedsettingsfortheconfigurableMOSFETbehavioralmodel.Thecapacitances(gateandjunctioncapacitances)donotinfluencetheDCbehaviour.Thesameappliestothesubstrateeffect,becausebulkandsourceareconnectedtogether.10.4.2ImplementationoftheConfigurableMOSFETModelThefollowingaspectshavetobeconsideredduringtheconfigurationoftheconfig-urableMOSFETbehavioralmodel: 10Mixed-LevelModelingUsingConfigurableMOS147NMOSDC−CharacteristicHDL−ModelMOS−Modelvar=3MOS−Modelvar=01.25MOS−Modelvar=2MOS−Modelvar=11.0completeMOS−Modelwithvar=2.700Id(mA)MOS−ModelwithRsandRdandvar=2.500.250.001.02.03.04.0vdrain()Fig.10.2MOSFETcharacteristicofvariedsettingsforthevariableMOSFETHDLmodelMN2var=2cap_sub=1cap_gate=1dio_sub=1res_nodal=1threshold=1Fig.10.3ConfigurationofthebehaviouralmodelatthesymbolApplicationofthecircuit(testbench),operationpointofthecircuitandthetran-sistor,respectively,simulationtype(DC,transient,etc.),requiredaccuracyofthesimulation,purposeofthesimulation(virtualtest,developmentphase,systemsim-ulation,etc.).Tochoosethecorrectsettings,circuitryknowledgeisnecessary.Thesettingsaremadedirectlyatthetransistorsymbolintheschematiceditor,asshowninFig.10.3.Thefollowingexamplesshowtheproceedingforvarioussimulationtasks.10.4.3BoostConverterInthefollowingexample,aboostconverterisintroduced.ThecircuitwastakenfromanantennadriverICforpassive-entry-gosystems.Thistypeofcircuitpresentsaproblemforsystemsimulationsbecauseofitscomplexityitrequiresa 148J.Weberetal.VBOUTVCCover-occurrentdetec-tionclkgateporControl-enLogicdriverVNFig.10.4Blockdiagramsimplifiedmodellotofprocessingandthus,substantiallyincreasesthesimulationtime.Thebehavioraldescriptionoftheconverterwasgeneratedfortwodifferentabstractionlevels:firstly,asimplifiedmodelcreatedbyapplyingmeet-in-the-middledesignmethod-ology[4]and,secondly,acomplexHDLmodelcreatedusingbottom-upstrategies.Bothbehavioralmodelsincludeadriverstage,whichisimplementedattransistorlevelwithconfigurableMOSFETHDLmodels.InFig.10.4,ablockdiagramofthesimplifiedHDLmodeloftheboostconverterisshown.Asimplifiedmodelforthegatecontroloftheoutputdriverwithanovercurrentdetection,avoltagedivider,controllogicandthedrivingstageareimplementedinthisblockdiagram.Conversely,inthecomplexHDLmodelallsub-blocksofthetransistorcircuitareincluded.Thisincludes,forexample,theerroramplifier,thecompensationstage,therampgenerator,theovercurrentdetection,thevoltagedivider,thecontrollogic,andthedriverstages.TheblockdiagramisshowninFig.10.5.Thistypeofmodelisoptimalforthedevelopmentoftransistormodels,sincethecompletecontrolloopismappedinthemodel.Analysisofstabilityandcompensa-tionofthecontrolloop,respectively,arenowpossible.Thedriverstageconsistsoffourbuffers,whichareusedforthegatecontrolofthefouroutputtransistorsandasensortransistor,whichisresponsiblefortheovercurrentdetection(seeFig.10.6).TheperformancebenefitandthemodeldifferenceoftheHDLmodelsincomparisontotheoriginaltransistorcircuitareshowninTable10.4.Heretherun-up,ascanbeseeninthesimulationresultsinFig.10.7,wastested.InthedrivingstagesallfunctionsofthevariableMOSFETHDLmodelswereenabledduringsimulation.ThemodeldifferencewascalculatedusingtheEuclideandistance.Withinthecircuitdesign,thecomplexbehavioralmodelwasusedwhichallowstheuser,forexample,tooptimize/stabilizethecompensationsofthecircuit.WithsuitablesettingsoftheMOSFETHDLmodelfunctions,onlyalimitedperformancebenefitisachieved.Thisisbecausethesimulationactivitiesoccurmostlyinthecontrolloopinsteadofthedrivingstage. 10Mixed-LevelModelingUsingConfigurableMOS149OUTVBcompensationVCCover-currentdetec-tionerroramp.overcurrentrampControl-LogicdrivercomparatorclkporenovervoltageVBGdividerVNFig.10.5BlockdiagramcomplexmodelOUTVCCMP2MP1HV4MN2MN1MP6MP5HV3MN6MN5ENbufMP4MP3HV2SENSMN4MN3MP8MP7HV5INHV1MN8MN7VNFig.10.6Blockdiagramboostdriver 150J.Weberetal.Table10.4PerformanceandaccuracyoftheboostconvertermodelsModellevelPerformanceDifferenceComplexmodel92×7.2%181×13.4%Simplifiedmodelcomplexmodelsimplifiedmodeloriginal35.0simplifiedmodel30.0simplifiedmodel25.0V(V)originaloriginal20.0complexmodelcomplexmodelcomplexmodel15.0100.0200.0300.0400.0time(us)Fig.10.7Simulationresultsboostconverter(simplified,complex,original)Table10.5ResultsofthecomplexboostconvertermodelswithsuitablesettingsoftheMOSFET-HDLmodelfunctionModellevelPerformanceDifferenceComplexmodel123×9.4%Thecomponentsofthecontrolloop,suchastheerroramplifier,arepartlydescribedwithLaplacefunctionsinVerilog-A.Table10.5showstheresultsincomparisontotheoriginaltransistorcircuit.Duringasystemsimulationandatestsimulation,respectively,thesimplebehavioralmodelswhichincludetheprimaryfunctionslikecurrentandvoltageswitch-offaswellasalldigitalcontrolfunctionstoswitchonandoffthestageareoftenused.Inthefollowingexample,asimulationtaskchecksthecurrentswitch-offoftheconverter.Heretheconvertermustberegu-latedfirsttothesteady-statevoltageandthenthethresholdofthecurrentswitch-offcanbedeterminedbyallowingtheloadcurrenttoriseslowly.Here,asopposedtothecomplexbehavioralmodels,ahigherperformanceben-efitisachievedsincemostofthesimulationactivitiesoccurinthedriverstage(seeTable10.6) 10Mixed-LevelModelingUsingConfigurableMOS151Table10.6MOSFET-HDLmodelsconfigurationsVarianteM×1,3,5,7M×2,4,6,8HV1,2,3,4,5var112res_nodalNoNoYescap_gateNoNoYescap_subNoNoYesdio_subNoNoYesthresholdNoNoYes10.5ConclusionsInthisarticle,amethodwasdiscusseddetailinghowtopartitionMOSFETmodels.Italsodemonstratedhowtoactivateordeactivatetheircharacteristics,withthegoalofachievinganimprovedperformance.ThismethodwasdemonstratedusingMOSFETbehavioralmodelswhichwereimplementedonthebasisoflevel-1MOSFETcalculations.Additionally,themodelshavetoofferselectableoptionssuchasshortchanneleffectorsimplificationswhichallowuseofthetransistorasavoltage-controlledresistor.Themodelcharacteristics,whichcanbeactivatedordeactivated,weredescribedindividuallyinthesourcecode.ThemodelwascreatedusingVerilog-AandsimulatedwithSPECTRE(CADENCE).Threedifferentsce-narios,andtheprosandconsfoundforeach,wereusedtodemonstratethecorrectselectionoftheMOSFETmodelcharacteristics.Inconclusion,theconfigurableMOSFETHDLmodelswereappliedinasimulationexample.Forthisexample,thesimulationtimeandthemodelerrorrateweredeterminedusingvarioussimulationtasks.Animprovedsimulationtimebyafactorof719andanerrorrateof16.1%wasachieved.Adisadvantagewasdetectedwithconvergenceproblemsappearingseveraltimes.However,thisproblemwascorrectedbychoosingsuitablesimulatorsettings.Itisawellknownfactthatusingoriginalsimulatortransistors(e.g.EKV,BSIM)isfasterthanadoptingthemostcomplexstageofexpansionforMOSFETHDLmodels.Tocounteractthis,CADENCEimplementedaC-CompilerforVerilog-Ainitslatestsimulatorversion.However,itisseenthatimprovedsimulationtimeoccursusingtheoptimalMOSFETHDLmodelsrathertheoriginalEKVtransis-tors.Toachieveimprovedperformanceitisdesiredtoincludethemodels,whicharedescribedinthisarticle,inthesimulator.Inthisarticle,aMOSHDLmodelbasedonthelevel-1modelwasrealized,butthisjustservestodemonstratethemethod.ItwouldmakesensetousesuchamethodinallMOSFETmodeltypes.Circuitryknowledgeisrequiredofthemodelertobeabletodeterminetheoptimalsettingsneededforthemodelcharacteristics.AcknowledgmentsThisworkhasbeencarriedoutwithintheBMBFproject“Verificationofanalogcircuits”(VeronA). 152J.Weberetal.References1.AbidiAA(2001)BehavioralModelingofAnalogandMixedSignalIC’sv.IEEEInternationalConference,06–09May2001,Pages443–4502.ChenW(1999)TheVLSIHandbook.CRCPressLLC,BocaRaton,FL,December19993.EnrightD,MackRJ,MassaraRE(2003)Mixed-Levelhierarchicalanaloguemodelling.Circuits,DevicesandSystems;IEEProceedings,Volume150;February2003,Pages78–844.EschermannB,DaiWM,KuhES,PedramM(1988)HierarchicalPlacementforMacromodels:AMeet-In-The-MiddleApproach.IEEEInternationalConference,07–10November1988,Pages460–4635.MieglerM,WolzW(1996)DevelopmentofTestProgramsinaVirtualTestEnvironment.IEEE,VLSITestSymposium,Pages99–1026.SommerR,Rugen-HerzigIetal.(2002)FromSystemSpecificationtoLayout:SeamlessTopdownDesignMethodsforAnalogandMixed-SignalApplications.DATE02,Paris,March4–8,ISBN0-7695-1471-57.WeberJ,AntonM,HussSA(2003)VerhaltensmodellierungvonEin-undAusgangsstufenfürdenVirtuellenTestvonMixed-SignalAutomotiveSchaltkreisen.Analog2003,Heilbronn,10–12September,Pages91–968.WeberJ,AntonM,HussSA(2005)EffizienteMixed-LevelModellierungintegrierterMixed-SignalAutomotiveSchaltkreise.Analog2005,Hannover,16–18March,Pages217–2229.AccelleraVerilogAnalogMixed-SignalGroup(2004)Verilog-AMSLanguageReferenceManual.Version2.2,November2004. Chapter11ModelingAADLDataCommunicationswithUMLMARTECharlesAndré,FrédéricMallet,andRobertdeSimoneAbstractTheemergingOMGUMLProfileforModelingandAnalysisofReal-TimeEmbeddedsystems(MARTE)aims,amongstotherthings,atprovidingareferentialTimeModelsubprofilewheresemanticissuescanbeexplicitlyandformallydescribed.Asafull-sizeexercisewedealherewiththemodelingofimme-diateanddelayeddatacommunicationsinAADL.ItactuallyreflectsanimportantissueinRT/Emodelsemantics:apropagationofimmediatecommunicationsmayresultinacombinatorialloop,withill-definedbehavior;introductionofdelaysmayintroduceraces,whichhavetobecontrolled.WedescribeheretheabilitiesoftheMARTEtimemodelinthisrespect.KeywordsMARTE,UML,AADL,TimedMoCC11.1IntroductionThemodelingphaseinReal-TimeEmbeddeddesignisincreasinglyrequiredtosupportvarioustypesoftiminganalysispriortofinalcodeproductionandtesting.AADL[7]andMARTE[5]aretwosuchmodelingformalisms,inpartsimilarintheirobjectives.Theybothprovideindependentdescriptionsofthefunctionalapplicationsandtheexecutionplatforms,andthepossibleallocationoftheformerontothelatter.Theyalsosupportthedescriptionofboththestructuralorganizationofsystems,andtosomeextentoftheirdynamicbehaviors.OurbeliefhereisthatAADLreliesonanumberofassumptionsthatmakethedefinitionofdynamicbehaviorsvisiblysimple,butlargelyimplicitandinformal–withtheriskofambiguityormisdesign,whichvariousanalysistoolsthentrytospotandidentify.Conversely,MARTEexplicitTimemodelwithpowerfullogicaltimeI3S,UniversitédeNice-SophiaAntipolis,CNRS,F-06903SophiaAntipolis,Inria,F-06902Email:{candre,fmallet,rs}@sophia.inria.frE.Villar(ed.)EmbeddedSystemsSpecificationandDesignLanguages,155©SpringerScience+BusinessMediaB.V.2008 156C.Andréetal.constraintsallowsprecisespecificationoftheschedulingaspectsofapplicationelements.MultiformlogicaltimesupportedbyMARTE,isinspiredfromthetheoryoftagsystems[1].Timerelationsandconstraintsbetweenvarious“clocks”canbestatedsoastorepresentthetimeactivationsofconcurrenttasks.ClockconstraintscanthusbeviewedinawaysimilartotheObjectConstraintLanguage[6],asprovidingfancyparticularconstructionsofTimedModelsofComputationsandCommunications(MoCC).TheseMoCCaretobedefinedbyamodelarchitectandshouldbetranspar-entlyusedbytheend-userofthemodelingframework.Synchronous,time-triggeredorpurelyasynchronousformalismsaresimple–andextreme–examplesofthat.Inthispaper,weuseMARTEtomakeexplicitpartoftheMoCCunderlyingAADL.AADLapplicationscomprisethreads,oftenofperiodicnature–withdis-tinctperiods–connectedthrougheventordataports.Ascanbeseenhere,thesamemodelprovidesstructuralinformation–thethreadconnections–togetherwithacrudeabstractionofbehaviorsusuallyneededforschedulabilityanalysis–therelativespeedsofthreads.AADLthreadmodelingthusrequirestheconjunctoftwoMARTEmodels–onebehavioralandonestructural–withtherelevantlogicalclocksdefiningtherelativeorderingofdispatcheventsforthethreadsaccordingtothedesiredsemantics.Datacommunicationscanbeimmediateordelayed.Delayedcommunicationsareneededinparticulartobreakdowncyclepropagationofdata.Theyimplicitlyimposeapartialorderonhowvariousthreads–andtheircontainingprocesses–canbeexecuted/simulatedinasimultaneousstep.Theissuesofpriorityinversioninvolvedherearedealtwithin[4].Whentheflowcontainsdata-port,thecommunicationessentiallyamountstosampledproduction/consumptionofadatavaluesharedbetweentwotasks.Operationsareperformedatthepaceofthe–oftenperiodic–tasks,andtheschemeisevent-less.Inparticular,datacanbewrittenorreadseveraltimesifevertherela-tivespeedsofthetasksdemandit.SuchacommunicationpatternisnotreadilypresentinUML–andthusMARTE.ModelingAADLdata-portcommunicationsinMARTEistheprimegoalofthispaper.Theoperationalsemanticsismadeexplicit,andthevariousprotocols–immediate/delayed–canbeconstructedinaformalway.Thehopeisthatsuchconstructioncanthenallow,byanalytictechniques,topreventnon-determinismandpathologicalpriorityinversionstooccur,inawaythatispre-dictedandguaranteedratherthanmonitoredbynon-exhaustivemodelsimulations.11.2Background11.2.1TimeinMARTEThemetamodelfortimeandtime-relatedconceptsisdescribedinthe“Timemode-ling”chapteroftheUMLprofileforMARTE,availableattheOMGsite.Thetimechapterisbrieflydescribedinanotherpaper[2]. 11ModelingAADLDataCommunicationswithUMLMARTE157InMARTE,Timecanbephysical,andconsideredascontinuousordiscretized,butitcanalsobelogical,andrelatedtouser-definedclocks.Timemayevenbemultiform,allowingdifferenttimestoprogressinanon-uniformfashion,andpos-siblyindependentlytoany(direct)referencetophysicaltime.Thetimestructureisdefinedbyasetofclocksandrelationsontheseclocks.Hereclockisnotadeviceusedtomeasuretheprogressofphysicaltime.Itisratheramathematicalobjectlendingitselftoformalprocessing.Aclockthatreferstophysicaltimeiscalledachronometricclock.AdistinguishedchronometricclockcalledidealClkisprovidedintheMARTEtimelibrary.Thisclockrepresentsthe“ideal”physicaltimeused,forinstance,inphysicalandmechanicslaws.Atthedesignlevelmostoftheclocksarelogicalones.Themathematicalmodelforaclockisa5-tuple(I,
,D,l,u)whereIisasetofinstants,
isanorderrelationonI,Disasetoflabels,l:I→Disalabelingfunc-tion,uisasymbol,standingforaunit.Forachronometricclock,theunitcanbetheSItimeunits(second)oroneofitsderivedunits(ms,µs…).Theusualunitforlogicalclocksistick,butclockCycle,executionStepmaybechosenaswell.Sinceinstantsofaclockarefullyordered,(I,≺)isanorderedset.Clockareaprioriindependent.Theybecomedependentwhentheirinstantsarelinkedbyinstantrelationsimposingeithercoincidencebetweeninstants(coinci-dencerelation≡)orprecedence(precedencerelation
).Clockrelationsareaconvenientwaytoimposemany–ofteninfinitelymany–instantrelations.ExamplesofclockrelationsaregiveninSection11.3.2.ATimeStructureisa4-tuple(C,R,D,l)whereCisasetofclocks,Risarelationon∪(I×I),Disasetoflabels,l:I→Disalabelingfunction.a,b∈C,aπbabCIisthesetoftheinstantsofatimestructure.IisnotsimplytheunionofthesetsCCofinstantsofalltheclocks;itisthequotientofthissetbythecoincidencerelationinducedbythetimestructurerelationsrepresentedbyR.Atimestructurespecifiesaposet(I,
).CCDuringadesignweintroduceseveral(logical)clocksthatareprogressivelyconstrained.Thiscausesstrengtheningoftheorderingrelationoftheapplicationtimestructure.11.2.2AADLInter-ThreadCommunicationsAsademonstrationoftheexpressivenessofMARTE,wetakeasanexampletheinter-threaddatacommunicationsemanticsofAADL.InAADL,thecommunicationscanbeimmediate(Fig.11.1a)ordelayed(Fig.11.1b).Thethreadsareconcurrentschedulableunitsofsequentialexecu-tions.Severalpropertiescanbeassignedtothreads;theoneofconcernhereisthedispatchprotocol.Weactuallyconsideronlyperiodicthreads,associatedwithaperiodandadeadline,specifiedaschronometrictimeexpressions(e.g.,period=50msorfrequency=20Hz).Bydefault,whenthedeadlineisnotspecifieditequalstheperiod. 158C.Andréetal.fdfdt1t1Legendread_dataread_dataThreadComponentproperty(e.g.,frequency,ffsubprogram...)t2ct2ccontrolcontrolimmediateconnectionaImmediatebDelayeddelayedconnectionFig.11.1AADLinter-threaddatacommunication11.3TheExplicitModelingofAADLCommunicationAspects11.3.1ApplicationandClockRefinementAfirstdifferencewithAADListhatMARTEdifferentiatesthealgorithmfromtheunderlyingstructure.Thealgorithmisrepresentedasanactivitydiagram(Fig.11.2,left-mostpart).Thestructureismodeledasacompositestructurediagram(Fig.11.2,right-mostpart).Eachparthasitsowncausalityconstraints.MARTErefinementmechanism,anditsassociatedclockconstraints,allowsformakingexplicitrelationsamongsttheclocksofbothparts.InMARTE,activationconditionsofallapplicationmodelelementsarerepresentedbyclocksidentifiedwiththeappropriatestereotypes,forinstanceTimedProcessing.Asastartingpoint,weconsidertheclocksofeachelementasindependent,andthenthecontext(dependenciesandrefinement)constrainstheseclocks.Finally,atiminganalysistoolmayresolvetheconstraintstodeterminea(familyof)possibleschedule.Westrivetoavoidover-specificationandkeepthemodelasgenericaspossible,addingonlyrequiredconstraints.Fromthealgorithmicpointofview,theactionsread_dataandcontrolareCallBehaviorActionthatexecuteagivenbehaviorrepetitivelyaccordingtotheiractivationcondition(clocks^dand^crespectively).11.3.2IntroducingClockConstraintsFromthestructuralpointofview,thethreadst1andt2arealsoassociatedwithclocks(^t1and^t2respectively).Thesepurelylogicalclocksrepresentthedispatchesofthethreads.InAADL,theperiodofathreadisexpressedasachronometrictimeexpressionandtherefore,atsomepoint,weneedtoestablishrelationsbetweentheseclocksandchronometricclocks.ThisaspectisaddressedinSection11.3.5,butweneedtosetupsomecausalityrelationsfirst. 11ModelingAADLDataCommunicationswithUMLMARTE159Fig.11.2Application/executionplatforminMARTEDecidingthatagivenbehavior(e.g.,read_data)isexecutedbyaperiodicthread(e.g.,t1)impliesthateachthreaddispatch(modeledbyclock^t1)causesandthereforeprecedesanewexecutionofsubprogramread_data,andthatthisexecutionmustcompletebeforethedeadline(thenextdispatchbydefault).InMARTE,wedifferentiateatomicbehaviors,forwhichtheexecutiontimeiscon-siderednegligibleascomparedtotheperiod,fromnon-atomicones.Ifweconsiderthebehaviorsasatomic,theassociationofabehaviorwithathreadissimplyexpressedwiththeconstraintgivenbyEq.11.1.Notethatthisconstraintisnotsymmetricalsincet1maycaused,butnottheconverse.^t1alternatesWith^d(11.1)Iftheexecutiontimeisnotnegligible,eachactioncanberepresentedbytwoevents,thestart(e.g.,dsford,csforc)andthefinish(e.g.,dfford,cfforc),andaduration.Inthiscase,weneedthreeconstraintstoexpressthatthebehaviorread_dataisrepetitivelyexecutedonthreadt1(Eqs.11.2–11.4).^t1alternatesWith^ds(11.2)^t1alternatesWith^df(11.3)^dsisFasterThan^df(11.4)Thefirsttwoconstraintsexpressthatthebehaviorstartsandfinishesbetweentwoconsecutivedispatchesofthreadt1.Thelastconstraint,whichreadsclock^dsis 160C.Andréetal.fasterthanclock^df,specifiesthattheactionread_datastartsbeforeitfinishes;itissufficienttoimposethatitfinisheswithinthesamecycleofexecution.Thenextconstraintcomesfromthecommunicationitself.WeuseaUMLdatastoretomeanthattheactionread_datacanoverwritetheexistingvalue(intheobjectnode)withoutgeneratinganewtokenandthisverysamevaluecanbereadseveraltimesbytheactioncontrol(nondepletingread).InUML,theremustbeatleastonewritingbeforeanyreading(Eq.11.5).^d[1]precedes^c[1](11.5)Let^wrbethe(logical)clockforsignificantwritingsinthedatastore.Therecouldbeseveralconsecutivewritingsinthedatastorebeforeonereading.Inthatcase,onlythelastoneisconsideredsignificant.Let^rdbethecorresponding(logical)clockforsignificantreadingsfromthedatastore.Whenthesamevalueisreadseveraltimes,onlythefirstreadingisconsideredtobesignificant.Furthermore,AADLassumesthatcommunicatingthreadsmusthavecommondispatches.Asimplewaytoachievethatisifallthreadsstarttheirexecutionatthesametime(theyareinphase).TheAADLstandardconsidersthreecases:synchronousthreadswiththesameperiod,oversampling(theperiodofcontrolisevenlydividedbytheperiodofread_data),undersampling(theperiodofread_dataisevenlydividedbytheperiodofcontrol).Letq1andq2benaturalnumberssuchthatf/f=q1/q2.Theydcrepresenttherelativeperiodsofread_dataandcontrol.Section11.3.6discusseshowtocomputeq1andq2inthegeneralcase.Whenthethreadsaresynchronous(Eq.11.6),q1=q2=1.Whenoversampling(Eq.11.7),q1=1andq2>1.Whenundersampling(Eq.11.8),q1>1andq2=1.max(q1,q2)iscalledthehyper-period.InEq.11.7(resp.Eq.11.8),thebinaryword[3]followingthekeywordfilteredByexpressesthateachinstantof^t1(resp.^t2)issynchronouswitheveryq2th(resp.q1th)instantof^t2(resp.^t1).^t1≡^t2(11.6)^t1≡^t2filteredBy(1.0q2-1)(11.7)^t2≡^t1filteredBy(1.0q1-1)(11.8)Selectingthesignificantwritingsandreadingsconsistsinchoosingoneeveryq1thinstantof^d(Eq.11.9)andoneeveryq2thinstantof^c(Eq.11.10).Additionally,Eq.11.11statesthateachsignificantwritingmustprecedeitsrelatedsignificantreading.^wrisPeriodicOn^dperiodq1(11.9)^rdisPeriodicOn^cperiodq2(11.10)^wralternatesWith^rd(11.11) 11ModelingAADLDataCommunicationswithUMLMARTE161WerestrictourcomparisontothethreecasesconsideredbytheAADLstandard.However,inSubsection11.3.6weelaborateonthegeneralcase.Wehavedefinedallgeneralconstraints.Inparticular,notethatcontrarytoEqs.11.7–11.10donotspecifywhichinstantischosenasasignificantwritingorreading.Theactualinstantdependsonthesemanticsofthecommunication.Thefollowingtwosubsectionsstudythethreedifferentcases(synchronous,oversampling,under-sampling)withbothanimmediateandadelayedcommunication,eachsubsectiongivesstrongerconstraintscompatiblewithEqs.11.9–11.11.11.3.3ImmediateCommunicationAnimmediatecommunicationmeansthattheresultofthesendingthread(hereread_data)isimmediatelyavailabletothereceivingthread(herecontrol).Whenthreadsaresynchronous(Fig.11.3a),thisisdenotedby^wr≡^dand^rd≡^c,ormorepreciselyby^wr≡^dfand^rd≡^cs.Incaseofoversampling(Fig.11.3b),theresultoftheactionread_datamustbewrittenintheobjectnodeearlyenoughsothatthefirst(foreachq2-longhyper-cycle)executionoftheactioncontrolcanuseit.Thisisdenotedby^wr≡^dand^rd≡^cfilteredBy(1.0q2-1).ThelatterconstraintisstrongerthanEq.11.10,itimpliesit.Incaseofundersampling(Fig.11.3c),AADLspecifiesthattheexecutionofthefirst(foreachq1-longhyper-cycle)executionoftheactionread_datamustcompletebeforetheexecutionoftheactioncontrol.Thisisstatedby^rd≡^cand^wr≡^dfil-teredBy(1.0q1-1).wr(sample)read_datacontrolrd(sample)asynchronousboversamplingcundersampling(q1=q2=1)(q1=1,q2=3)(q1=3,q2=1)Fig.11.3Immediatecommunications11.3.4DelayedCommunicationAdelayedcommunicationmeanstheresultofthesendingthreadismadeavailableonlyatitsnextdispatchwhilethereceivingthreadonlyreadsafteritsowndispatch 162C.Andréetal.andultimatelywhenthedataisrequired.Thedispatchesofthesendingandthereceivingthreadsarenotnecessarilyallsynchronous,eveniftheremustsynchro-nizeatsomepoint.Whenthethreadaresynchronous(Fig.11.4a),theconstraintisdenotedbyEqs.11.12,11.13.Notethatδ4offersthepossibilitytodelaytheactualexecutionofread_data.Thethreadt1caneitherbeidleorbeexecutinganotheractionbeforestartingtoexecuteread_data.Eq.11.12statesthat(∃d4∈)("k∈*)(^wr[k]≡^t1[d4+k]).(∃d4∈))(^wr≡^t1filteredBy0d4(1))(11.12)^rd≡^c(11.13)Foroversampling(Fig.11.4b),theresultisavailableforthefirstexecutionoftheactioncontrolofthenextq2-longhyper-cycle.Thisleaveslotsoffreedomtoscheduletheactionread_dataanywherewithinthecurrenthyper-cycle.WekeeptherelationEq.11.12whileEq.11.13isreplacedbyEq.11.14.^rd≡^cfilteredBy(1.0q2-1)(11.14)Forundersampling(Fig.11.4c),theresultofthelastexecution(foreachq1-longhyper-cycle)oftheactionread_dataisavailablefortheactioncontrolatthenexthyper-cycle.ThisisdenotedbycombiningEq.11.15withEq.11.13.(∃d4∈)(^wr≡^t1filteredBy0d4(1.0q1-1))(11.15)Notethattherelationsarenotfullysymmetrical.ThisisduetotheAADLseman-ticsthatchangestheruledependingonthekindofcommunication.Uptohere,wehaveonlydefinedlogicalconstraints.Insomecases,thesecon-straintsarestrongenoughtogetatotalorder,andthusapossibleschedule,onallinstantsbelongingtothedefinedclocks.Forinstance,inthedelayedsynchronouscase,wheneverthefirstexecutionofread_dataoccurs,thefirstsignificantwritingoccursattheverynextdispatch.However,insomeothercases,weneedadditionalwrread_datacontrolrdasynchronousboversamplingcundersampling(q1=q2=1)(q1=1,q2=3)(q1=3,q2=1)Fig.11.4Delayedcommunications 11ModelingAADLDataCommunicationswithUMLMARTE163strongerconstraintstogetaschedule.TheseconstraintsreflectadditionalchoicesthataremainlyimplicitintheAADLsemantics.Dependingonthesechoiceswegetdifferentdeterministicschedules.Thesecasesarestudiedinthenextsection.11.3.5GettingaScheduleFigure11.3showsthatforimmediatecommunications,theconstraintsgivendefineatotalorderbetweeninstantsof^dand^cinboththesynchronousandtheover-samplingcases.Combiningourconstraintswegetthesameresultanalytically.Onequestionremainswhetherornotbothexecutions(read_dataandcontrol)canbeperformedwithintheperiodofthreadt2.Ifnot,thereisnopossibleschedule,otherwise,thescheduleisgivenbyFig.11.5,assumingboththreadsareexecutedonthesameprocess.Fordelayedcommunications,additionalconstraintsarerequiredtogetadeter-ministicschedule.Severalcriteriacanbeconsidered,forinstance,thesizeofthebufferusedforthecommunication,orapplyingawell-knownschedulingpolicy,likeEarliestDeadlineFirst(EDF).Anapparenteasywaytoforceatotalorderistoprojectthelogicalclocksontochronometricclocks.Logicalclocksonlygiveanorderamongstinstants(some-timespartial),whilechronometricclocksgiveanabsolutepositionintime.TheuseofchronometricclocksisimpliedinAADLbecauseoftheunitsusedtodescribeeitherthefrequency(Hz)ortheperiod(s).InMARTE,wecreatemodelsofchronometricclocksbydiscretizingidealClk(Section11.2.1).Forinstance,wecreatethreechronometricclocksc,candcofrespective1001030frequency100,10and30Hz(Eqs.11.16–11.18).Notethatthesearerelations,whencethedefinitionofthe30Hz-clockfromc.10Fig.11.5Scheduleswithimmediatecommunications 164C.Andréetal.Now,wereplacethethreeequations(Eqs.11.6–11.8)bythethreefollowingconstraints.^t1≡^t2≡c(synchronous),^t1≡cand^t2≡c(oversam-101030pling),^t1≡cand^t2≡c(undersampling).Theonlyadditionalinformation3010wehavehereisthedistance(expressedinseconds)betweentwoconsecutivedis-patches.Thisinformationisusefulforcomparingthedurationofexecutionswiththeperiodofthethreads;howeveritdoesnotchangeinanywaythecausalityrela-tionsexpressed.c≡idealClkdiscretizedBy0.01(11.16)100c≡cfilteredBy(1.09)(11.17)10100c≡cfilteredBy(1.02)(11.18)1030Fortheimmediateundersampling,wecaninferfromthespecifiedconstraintsthat,foreachhyper-cycle,thefirstexecutionofread_datamustcompletebeforetheexecutionofcontrol.However,wecannotdecidewhentoexecutecontrolrelativelytootherexecutionsofread_data.Weneedanothercriterion.Forinstance,wechoosetominimizetheactualsizeofthebufferusedforthecommunication.Togetthisbufferassmallaspossible(size=1),wehavetoschedulecontrolbeforethesecondexecutionofread_data.WerewetoscheduleaccordingtoanEDFpolicywewouldgetanotherschedule,seeFig.11.5.Foradelayedcommunication,wejusthavepartialordersandweneedadditionalcriteria.Forsynchronousthreads,theuseofanEDFpolicyisofnohelp.However,reducingthesizeofthecommunicationbuffergivesaschedule(top-mostpartofFig.11.6).Foroversampling,bothcriteriaarecompatibleandwegetthesecondscheduleonFig.11.6.Forundersampling,wegettwodifferentschedulesdependingonwhetherweapplyanEDFpolicyorweattempttoreducethebuffersize.Fig.11.6Scheduleswithdelayedcommunications 11ModelingAADLDataCommunicationswithUMLMARTE16511.3.6GeneralizationWecangeneralizetheconstraintstogetonlytwosetsofconstraints,onefortheimmediatecommunicationandoneforthedelayedcommunication.InthissectionwedonotrestricttothethreespecialcasesaddressedintheAADLstandard.Thisgeneralizationdoesnotassumethatthefrequenciesofthethreadsarenaturalnumbers;itjustassumesthattheyarerationalnumbers.ItalsoassumesthatinthenotationofourbinarywordsY.x0=Y,foranybinarywordYandanybitx.Letfd=n/dandf=n/df/f=(n*d)/(n*d)withn,n,d,drrccc,dcrccrrcrc∈*.Letr=n*dandr=n*d.Wechooseq1andq2suchasq1=r/1rc2cr1gcd(r,r)andq=r/gcd(r,r).Note,thatwestillhavef/f=q1/q2122212dcandthattheconstraintsgivenbyEqs.11.14and11.15aregeneral.However,Eqs.11.6–11.8arereplacedbyasingleone,Eq.11.19.^t1filteredBy(1.0q1−1)≡^t2filteredBy(1.0q2−1)(11.19)Again,theseconstraintsarepurelylogical.Inthegeneralcase,theseconstraintsarenotstrongenoughtoidentifydeterministicallythesignificantwritingsandreadings.Ifwetakeforinstance,thecasewhereq1=2andq2=5(Fig.11.7).IfweapplytheAADLsemantics,wecanonlysaythat,withinanhyper-cycle(ofperiodlcm(q1,q2)),thefirstexecutionofread_dataproducesthesampleforthefirstcontrol,butwecannotknowwhatsampleisusedbyotherexecutionsofcontrol.Inparticular,thereisnorelationbetweent1[2*n+1]andt2[5*n+2].Togetadeterministicbehavior,weneedtogivemoreconstraints.Forinstancewecanprojectourclocktochronometricclocksandwemodelasanexamplethecasewheref=10Hzandf=25Hz.Weproceedbyusingtheclockcdefineddc100inEq.11.16andweaddtwonewconstraints(Eq.11.20-11.21).wr(sample)t1[2*n]t1[2*n+1]read_datacontrolt2[5*n]t2[5*n+1]t2[5*n+2]t2[5*n+3]t2[5*n+4]rd(sample)general(q1=2,q2=5),immediateFig.11.7Immediatecommunicationsandpurelylogicalclocks(q1=2,q2=5) 166C.Andréetal.wr(sample)0s0.1s0.2sread_datacontrol0s0.04s0.08s0.12s0.16s0.2srd(sample)Fig.11.8Immediatecommunicationsandchronometricclocks(q1=2,q2=5)^t1≡c(11.20)10^t2≡cfilteredBy(1.03)(11.21)100Withsuchconstraints,wegetatotalorder(Fig.11.8)andthentherearetwopossi-blecases.Thefirstcaseappearswhenduration(read_data)+duration(control)≥0.02s.Then,weexactlygettheresultpresentedinFig.11.8,where,withinahyper-cycle,thethirdexecutionofcontrolusesthesamplecom-putedbythefirstexecutionofread_dataandthefourthexecutionofcontrolusesthesamplecomputedbythesecondexecutionofread_data.Inthesecondcase,ifduration(read_data)+duration(control)<0.02s,thethirdexecutionofcontrolshouldusethesamplecomputedbythesecondexecutionofread_data.However,notethatsuchsystemsthatverymuchdependontheexactdurationoftasksarenotveryrobust.Ifwenowtakealookatthesituationwithadelayedcommunication(Fig.11.9),thereareseveralpossibleinterpretationsofageneralizedAADLsemantics.Thesimplestinterpretationisthatthedataismadeavailable(writtenintheobjectnode)atthefirstdispatch(ofthesendingthread)followingtheexecutionofthebehaviorthathasproducedit(read_data).Andthedataisreadatthefirstdispatchofthereceivingthreadfollowingthewriting(seeFig.11.10).Asecondinterpretation(seeFig.11.11)couldbethatthedataisreadatthefirstdispatchofthereceivingthreadfollowingtheactualproductionofthedata(notwaitingforthefollowingdispatchofthesendingthread).Thisinterpretationleadstomakethesecondsignificantreadingsynchronouswiththethirdinstantofcontrol(foreachhyper-cycle)insteadofthefourthasinFig.11.10.Thesecasesarestudiedindetailin[2].Notethesetwointerpretationscanallbevalidanddeterministic.Itisjustamatterofmakingexplicitthesemantics.Thefirstinterpretationisverysimpletoimplementandthesecondonerequiresbeingabletocontrolverytightlythecommunicationtimes. 11ModelingAADLDataCommunicationswithUMLMARTE167Fig.11.9Logicalclocks(q1=2,q2=5)Fig.11.10Firstinterpretationwithdelayedcommunications(q1=2,q2=5)Fig.11.11Secondinterpretationwithdelayedcommunications(q1=2,q2=5)AUMLobjectnodehastwointerestingattributes:ithasanupperbound,possiblyunlimited,anditcanorderevents,bydefaultaccordingtoaFIFOpolicy.Thus,thereisnoreasontoassumethatthethreadsareinphase,thesendingthreadwrites(andpossiblyoverwrites)tokensintheobjectnode,whilethereceivingthreadreadsthemwhenrequired.Ourdefinitionofthesignificantwritingsandreadings 168C.Andréetal.helpsdefiningwhenthetokenisthesame–thecontentmustbeoverwritten–andwhenthetokenisdifferent,whichimpliesthatanewtokenmustbecreated.Actually,theoccurrenceof^wrshouldcreateanewtoken.11.4ConclusionWehavebrieflyintroducedtheTimemodelofMARTEandwehaveillustrateditsuseonanexampletakenfromAADL.WethinkthatourclockconstraintlanguagecouldbeusedtomakeformalthesemanticsofUML-likegraphicalrepresentationsthatisoftenpartiallyimplicit.Inthislanguage,weborrowedsomenotationsonbinarywordsfromtheN-synchronousapproachbutinourcasewedonotlimitour-selvestosynchronousrelations.WehaveimplementedaconstraintparserthathasbeenmadeavailablewiththeXMIoftheTimesubprofileontheOMGwebsite.ThisparsercanbeusedtoparseconstraintsextractedfromUMLmodels.Someanalytictoolsshouldreducetheconstraintsorcomputenewonesandputthembackinthemodels.Fornow,alltheseformalcomputationsaremanualbutweintendtotrans-formourconstraintsintolanguagesamenabletoclockcomputations(timeautomataorsynchronouslanguageslikeSignalorEsterel).Ultimately,ourconstraintlan-guagecouldbeusedtodriveaUMLsimulator,inaconstructiveway,accordingtothemodeltimesemanticsratherthananuntimedevent-drivensemantics.References1.LeeE.A.,Sangiovanni-VincentelliA.L.(1998):Aframeworkforcomparingmodelsofcom-putation.IEEETransactionsonComputer-AidedDesignofIntegratedCircuitsandSystems,17(12):1217–1229.2.AndréC.,MalletF.,deSimoneR.(2007):ModelingTime(s).SpringerLNCS4735:559–573.3.CohenA.,DurantonM.,EisenbeisC.,PagettiC.,PlateauF.,PouzetM.(2006):N-synchronousKahnNetworks:ARelaxedModelofSynchronyforReal-timeSystems.ConferenceRecordoftheACMSymposiumonPrinciplesofProgrammingLanguages,pp.180–193.4.FeilerP.H.,GluchD.P.,HudakJ.J.,LewisB.A.(2004):EmbeddedSystemArchitectureAnalysisUsingSAEAADL.CarnegieMellonUniversity,TechnicalNoteCMU/SEI-2004-TN-005,June2004.http://www.sei.cmu.edu/pub/documents/04.reports/pdf/04tn005.pdf.5.OMG:UMLprofileforModelingandAnalysisofReal-TimeandEmbeddedsystems(MARTE),beta1,August2007,Documentptc/07-08-04.http://www.omg.org/docs/ptc/07-08-04.pdf6.OMG:ObjectConstraintLanguage(OCL),OMGAvailableSpecification,Version2,May2006,Documentformal/06-05-01.http://www.omg.org/docs/formal/06-05-01.pdf7.SAE:ArchitectureAnalysisandDesignLanguage(AADL).June2006,DocumentAS5506/1.http://www.sae.org/technical/standards/AS5506/1. Chapter12SoftwareReal-TimeResourceModelingFrédéricThomas1,SébastienGérard1,JérômeDelatour2,andFrançoisTerrier1AbstractSettinguptrulyflexibledesignprocessesbecomesanimportantchal-lengetofacewiththeincreasingcomplexity,theshortertimetomarketconstraintsandtheconstantevolutionofReal-TimeEmbedded(RTE)softwarerequirements.Onepromisedsolutionisthemodeldrivendevelopment(MDD)basedontheprinci-pleofseparatingtheapplicationdescriptionfromitsplatformspecificimplementa-tion.Nowadays,thisisoftendonethroughdedicatedmodeltransformationswhichimplicitlyrepresenttheplatformmodel.Specifictransformationshaveshowntheirlimitsassoonaswewanttooptimizetheimplementation.Inthiscontext,agoodcompromisecouldbetomakeexplicitaplatformmodel.Thisisoneofthechal-lengesaddressedbytheObjectManagementGroup(OMG)throughthedefinitionofthestandardprofileforModelingandAnalysisofReal-TimeandEmbeddedsys-tems(MARTE).Inparticular,thecapabilitiestomodelsoftwarereal-timeembeddedresourceswillallowdescribingexplicitlytheRTEsoftwaremultitaskingplatformcharacteristics.Itwilleasetheirintegrationinaflexibledesignprocess(bothtopro-duceimplementationandtoperformaccurateschedulingofperformanceanalysis).KeywordsPlatformmodeling,MARTE,UMLprofile,softwaremodeling,multitasking12.1IntroductionReal-timeembedded(RTE)applicationdesignmethodologiesareclassifiedundertwoheadings:sequential-baseddesign(alsocalledloopdesign)andmultitasking-baseddesign.Thefirstcategorycallsfordesigningapplicationsasasetofordered1CEALIST,Boîte94,GifsurYvette91191,FranceEmail:{frederic.thomas,sebastien.gerard,francois.terrier}@cea.fr2ESEOTRAME,49000Angers,FranceEmail:jerome.delatour@eseo.frE.Villar(ed.)EmbeddedSystemsSpecificationandDesignLanguages,169©SpringerScience+BusinessMediaB.V.2008 170F.Thomasetal.sequentialactions,whereasthesecondcategoryaimsatdesigningapplicationsasasetofunitsthatexecuteconcurrentlyandinteract(i.e.communicateandsynchro-nize)viaspecificmechanismssuchassemaphoresandmessages.Ourworkfallsunderthesecondheading.Mostmultitasking-basedapproachesrelyonaspecificmultitaskingexecutionplatform,calledareal-timeoperatingsystem(RTOS).Thislatterrunsontopofahardwareplatformandofferstodesignersthewell-suitedconstructsneededtosupportbothfeatures,concurrency(e.g.task,threadandproc-ess)andinteractions(e.g.mailbox,sharedmemoryandsemaphore).Likethesoftware/systemengineers,real-timeembeddedsystem(RTES)engi-neersarefacedwiththechallengeofdevelopingmoreandmorecomplexsystems,achievinghigherqualityatalowercost,andinashortertime.Withinthiscontext,reusability,maintainabilityandportabilitybecomemajorissuesinRTESdesignprocesses.TheusageofRTOSplatformswasaninitial,“architectural”responsetotheseproblemsbyenablingthedevelopmentofapplicationsindependentlyoftheirhardwarecomputingplatforms.TheRTESdesigncommunityhasmadeeffortsforstandardizingapplicationprogramminginterfaces(APIs)ofRTOS,asforexamplePOSIXStd1003.1[1],OSEK/VDX-OS[2]andARINC-653[3].Usageofsuchstandardsfordesigningmultitasking-basedapplicationshasfosteredreuseofappli-cationsindifferentsoftwarecontexts.Nevertheless,theycannotanswerallportabil-ityproblems.PlatformisagreatconcernforRTEsystemdesignerssincetheirperformancesarepasseddirectlyontotheapplications.Aunique,standardanduni-versalimplementationisthusadream.FewRTOSAPIsareactuallyconformanttoagivenstandard.Moreover,standardAPIsprovideintentionaldegreesoffreedomfortheimplementation.Hence,systematic,standaloneandsyntaxtransformations(e.g.codegeneration)basedonstandardAPIsfailtodealwithengineerneeds.Forsomeyears,theITcommunityhasproposedanewdevelopmentapproachsaidtobemodel-driven.Thisinitiativeplacesthemodelparadigmandtheuseofmodeltransformationsatthecenterofthedevelopmentprocess.Onepromisedsolutionistoseparatetheapplicationdescriptionfromitsplatformspecificimple-mentation.ThemostmatureformulationofthisvisionatpresentistheModel-DrivenArchitecture(MDA)approach[4].ThislatterispromotedbytheObjectManagementGroup(OMG).MDAinvolvesaY-chartdesignprocessinwhichaplatform-independentmodel(PIM)ofthesoftwareistransformedintoaplatformspecificmodel(PSM);givenaplatformdescriptionmodel(PDM).Allthesemod-elsaredescribedintheUnifiedModellingLanguage(UML)[5].WeproposetoinvestigatetheMDAapproachtodesignRTEsystems.Thus,wewanttomodelRTEmultitaskingexecutionplatformwithUML.Duetoitsgeneralpurpose,UMLlackscertainkeynativeartifactsfordescribingconcreteandpreciseRTEmultitaskingconceptssuchastask,semaphore,andmail-box.ThislackhasbeenfullbyanewOMGstandarddedicatedtomodelingandanalysisofreal-timeandembeddedsystems,MARTE[6].Inthatcontext,thispaperpresentstheSoftwareResourceModel(SRM)UMLprofilededicatedtocharacterizeRTEmultitaskingexecutionplatform.AfteraquicktouraroundrelatedworkforsoftwareexecutionplatformmodelingwithUML,weshowhowtoachievethisgoalthankstoMARTEandhowitcan 12SoftwareReal-TimeResourceModeling171helpapplicationdesigninamodel-drivenstyle.Finally,wewillgivesomeconclu-sionsandwillelaborateonsomepossiblefuturework.12.2RelatedWorkMuchworkhasalreadybeendoneonplatformmodeling.Thissectionisthereforedividedintotwosub-sections:onededicatedtorelatedresearchoncharacterizingexecutionplatformsandtheothertomodelsuchplatformswithUML.12.2.1CharacterizingRTESoftwarePlatformsTheMDAguide[4]providesthefollowinggenericdefinitionoftheplatformcon-cept:“Aplatformisasetofsubsystemsandtechnologiesthatprovideacoherentsetoffunctionalitiesthroughinterfacesandspecifiedusagepatterns,whichanyapplicationsupportedbythatplatformcanusewithoutconcernforthedetailsofhowthefunctionalityprovidedbytheplatformisimplemented”.Althoughthisisaverybroadandhigh-leveldefinitionwhichleavesalargescopeforinterpreta-tion,itdoesmakeclearthattheMDAguideconsidersaplatformasasupportfortheexecutionofsoftwareapplications.Thiscorrelatewellwiththeindustrialintui-tivedefinitionof“platform”whichreferstomachinesorsystemssuchasframe-works,middleware,virtualmachinesandRTOS,whicharebuilttosupportanexecutionprocess.AccordingtoB.Selicin[7],this“enablingexecution”conceptconsistsofpro-vidingresources(i.e.,mechanisms)andservices(i.e.,functionalities)tobeusedbyoneormoresoftwareapplications.Resourcesarestructuralentitiesofferingserv-icesthatmaybequalifiedbynon-functionalproperties(e.g.,latency,worstcaseexecutionandpoolsize).Thesepropertiesreflecttheofferedexecutioncharacteris-ticsandtheplatformperformances.A.Sangiovanni-Vincentelliemphasizesin[8]thatresourcesandservicesareprovidedbyapplicationprogramminginterfaces(APIs).AnAPIshouldprovideacompleteandaccuratedescriptionoftheplatform,sothatanyapplicationthatisconsistentwiththisinterfaceisguaranteedtobeprocessableviathatplatform.Hence,theAPImaybeconsideredasarepresentationofthis“enablingexecution”concept.Wecanthussummarizepreviousdiscussionontocharacterizingexecutionplat-formsasfollows:anexecutionplatformis“anabstractionlayerinthedesignflowwhichinterfacesthroughitsAPIasetofresources(i.e.,typesandinstances)com-posedofasetofservicesandasetofusagepatterns,eitherwithotherplatformresourcesorwithotherclientsystemscalledapplications”.ThelanguageusedtomodelsuchexecutionplatformsmustthereforeallowmodelingofspecificRTEtypes,alongwithpredefinedinstancesandusagepatterns. 172F.Thomasetal.12.2.2ExecutionPlatformModelingwithUMLUML2.0[5]isnowwidelyusedforsoftwaredevelopmentandisemergingasapossiblesolutionforenhancingRTEsystemdevelopment[9].UMLprovideslin-guisticconceptstodescribetypes(i.e.,resources),instancespecifications(i.e.,resourceinstances),andbehavioralfeatures(i.e.,services).Moreover,UMLpro-videsmeanstodescribeusagepatternsas“collaborations”and“collaborationuses”withincompositediagrams.Sinceexplicitplatformmodelscanhaveanarbitrarilycomplexstructure,wecanalsouseUML2.0’scompositestructurestobreakdownacomplexdesignintosmallerparts.Insuchaview,theconceptsofconnectorandportmaybeusefultodescribethebindingofapplicationswithplatforms[7].Finally,state-machineandactivitydiagramsmaybeassociatedwithencapsulatedclassifierstodefinetheirbehaviours.UMLnativeconceptsneverthelessneedtobeextendedtocoverthesemanticsofRTEconcepts.Forthatprecisepurpose,UMLprovidesalightweightextensionmechanismcalledprofile(seeSection12.18of[5]).AUMLprofileconsistsof“stereotypes”and“constraints”.Stereotypesmayhavepropertiescalled“tags”andareusedtodefineextensionstoexistingUMLlanguageconstructs(metaclasses).Theylikewiseenableuseofplatform/domain-specificterminologyandnotation.ConstraintsareusedtorestrictortospecifytheusageofthestereotypeswithinthecontextofaUMLmodel.WhentheyarewritteninObjectConstraintLanguage(OCL)[5],constraintscanbecheckedautomaticallyonUMLmodelsapplyingaprofile.Theythenprovidesupportforcheckingstaticsemanticrules.AlargenumberofUMLextensionsforreal-timeandembeddeddesignshavealreadybeenproposed.In[10],theUMLProfileforSchedulability,PerformanceandTime(SPT),standardizedbytheOMG,proposesmainlyconceptsfortwokindsofanalysis:RMA-basedschedulabilityanalysis,andperformanceanalysisbasedonlay-eredqueuingtheory.Forplatformmodeling,SPTprovidesonlyhigh-levelconcepts.ThislackhasbeenoneoftheOMGmotivationsforanewRTEprofile,MARTE.In[11],P.Kukkalaproposesamodel-drivenmethodologybasedonbothUMLandaspecificprofiletodescribeapplicationsandplatforms.Thismethodologydoesnotonlyallowthedescriptionofplatformstructuresbutalsothebindingofapplicationswithplatforms.Theproposedprofiledoesnot,however,takeintoaccounttheoperatingsystemasaplatform.In[12],R.ChenproposesaUMLprofileforspecificationofembeddedsystemplatforms.Thisprofileprovidesdomain-specificclassifiersandrelationshipstosup-plementtheSPTapproach.However,itdoesnotincludemeanstodescribeplatformservices,andessentiallyenablestoannotateresources.Suchanapproachmaynotallowautomatingcompletelythebindingoftheapplicationwiththeplatform.In[7],B.SelicdescribesastraightforwardbutrelativelygeneralUMLprofileforplatformmodelinganddeploymentofrelationshipsbetweenplatformsandapplications.Althoughthismodelenablesasystematicapproachtofactorcrucialplatformcharacteristics,theproposedprofiledoesnotprovidespecificconceptstomodelRTEexecutionresourcessuchastasksandsemaphores. 12SoftwareReal-TimeResourceModeling173RelatedworkhasresultedinUMLextensionsthatmakenotationandsemanticsmoresuitableforhighlyabstractreal-timeconceptmodelingwithUML.But,allthisworkdoesnotprovideenoughdetailedartifactstodescribebothresourcesandserv-icesprovidedbysoftwareexecutionplatforms.Acompleteexplicitmodelwillfacili-tateandautomatebindingofanapplicationwithitsRTOSexecutionplatform.WehaveconsequentlyproposedanewUML2.0profileforthatpurpose,theUMLprofileforSoftwareResourceModeling(SRM).ThislatterispartoftheMARTEstandard.TheMARTEspecificationconsistsofthreemainpackagesdescribedinfigure12.1.ThefirstpackagedefinesthefoundationalconceptsofMARTE.Itprovidesbasicmodelconstructsfornon-functionalproperties,timeandtime-relatedcon-cepts,allocationmechanismsandgenericresources,includingconcurrentresources.Thesefoundationalconceptsarethenrefinedinbothotherpackagestorespectivelycomplywithmodellingandanalyzingconcernsofreal-timeembeddedsystems.Thesecondpackageprovidesagenericbasisfordifferentquantitativeanalysissub-domains.ThisGenericQuantitativeAnalysisModelingpackageisfurthergeneralizedintotwopackages:oneforschedulabilityanalysis,topredictwhetherasetofsoftwaretasksmeetsitstimingconstraints;andanotherforperformanceanalysis,todetermineifasystemwithnon-deterministicbehaviourcanprovideadequateperformance.Thethird,“Real-TimeEmbeddedDesignmodelling”packageprovidessupportformodellinghigh-levelmodelconstructstodepictreal-timeembeddedfeaturesofapplications,butalsoforenablingthedescriptionofdetailedsoftwareandhardwareexecutionplatforms.TheSRMprofiledealswiththesoftwareexecutionpart.FoundationsNFPs«import»Time(Non-FunctionalProperties)«import»«import»GCM(GeneralComponentModel)AllocGRM«import»(Allocation)«import»(GenericResourcemodeling)«import»«import»RTEanalysismodelRTEdesignmodelGQAMRTeMocc(GenericQuantitativeAnalysis)(Real-TimeModelofcomputation&«import»«import»Communication)SAMPAM(Schedulability(PerformanceHRMSRMAnalysisAnalysis(HwResource(SwResourceModeling)Modeling)Modeling)Modeling)Fig.12.1OverviewoftheUMLMARTEprofile 174F.Thomasetal.12.3SoftwareResourceModelingTherearecurrentlynoformalwaysfordesigningUMLprofiles.Wehavedesignedourprofileintwostages.Thefirststageaimsatdefiningallconceptsrequiredtocoveraspecificdomain.Theoutputofthisstageiscalledthe“domainmodel”oftheprofile.Itisconsideredasaspecificationofthedomain-specificlanguage.ThesecondstagethenconsistsindesigningthepreviouslanguagespecificationintermsofUMLextensions,i.e.,definingUMLstereotypes,theirpropertiesandadditionalconstraints.Thus,thatsectionisorganizedasfollows:thefirstsubsectionisanoutlineoftheSRMdomainview,thesecondisanoverviewoftheSRMUMLpro-fileandthelasttwopresentsomeSRMProfileusageexamples.12.3.1OutlineoftheSRMDomainViewTheSRMprofileisbasedonthe“resource-service”modelingpatternproposedforplatformmodellingin[7]and[10].Thatpatternallowsdescribingresourceswhichownpropertiesandprovideservices.Somepropertiesandservicesplayroles.Suchrolesaremodelledasresourcesattributes.Figure12.2illustratesthatpatternonasoftwareresource.Asoftwareresourceownssomeattributes.Amongthoseattributessomeareusedtoidentifytheresource.Thosearereferencedbythe“iden-tifierElements”meta-property.Asoftwareresourceprovidesalsoservices.Somemaybeusedeithertocreateortodeletetheresource.Thosearerespectivelyrefer-encedeitherbythe“createServices”orbythe“deleteServices”meta-properties.ThewholedomainmodelhasbeenbuiltonthebasisofadetailedanalysisofmainRTOSAPIstandards[1–3],andcertainindustrialstandards(e.g.[13,14]).AnoverviewofdomainresourcesisshowninTables12.1–12.3.Real-timeembeddedsoftwareconceptsmaybeclassifiedaccordingtofollowingconcerns:●Concurrentexecution(i.e.,parallelexecution)contextssuchasaninterruptandatask●Interactionsbetweenconcurrentcontextsforeithercommunicationorsynchro-nizationpurposes(e.g.,mailboxandsemaphoremechanisms)Resource1.*providedServices0..*ownedPropertiescreateServicesidentifierElements0..*ResourcePropertySwResourceResourceService0..*deleteServices0..*Fig.12.2Anexampleofthe“resource-service”modelingpattern 12SoftwareReal-TimeResourceModeling175Table12.1ConcurrencyresourcesResourceSemanticsSchedulableResourceEncapsulatedsequencesofactionswhichexecuteconcurrently.MemoryPartitionVirtualaddressspace.InterruptResourceAcomputingcontexttoexecuteuser-deliveredroutines(i.e.,entrypoint)connectedtoasynchronoussignals.AlarmAnexecutingcontextforauserroutine,whichmustbeconnectedtoatimer.Table12.2InteractionresourcesResourceSemanticsMessageComResourceCommunicationresourceusedtoexchangemessages.SharedDataResourceResourceusedtosharethesameareaofmemoryamongconcurrentresources.NotificationResourceResourcesupportingcontrolflowbynotifyingtheoccurrencesofconditionstoawaitingconcurrentresources.MutualExclusionResourceResourcethatsynchronizesaccesstosharedvariables.Table12.3BrokeringresourcesResourceSemanticsMemoryBrokerResourcethatmanagesmemoryallocation,memoryprotectionandmemoryaccess.SchedulerResourcethatorchestratestheexecutionofmultipleschedulableresources.DeviceBrokerResourcethatenablesinterfacingofhardwareperipheraldeviceswiththesoftwareexecutionsupport.●Hardwareandsoftwareresourcebrokeringconcepts,suchasdriverormemorymanagement12.3.2SRMProfileOverviewFigure12.3providesonoverviewoftheprofilearchitectureresultingfromthedesignofthepreviousSRMdomainviewintermsofUMLextensions.TheSRMprofileprovidesabroadrangeofmodelingcapabilitiescoveringallRTOSconcernsandwithalow-levelofdetailstoenablegenerativeapproacheswheremodelsareusedtogeneratepartsoftheapplication.Duetospacelimitationsofthispaper,itisoutofthescopeofthepapertodescribeinverydetailstheSRMprofile.Bothnextsectionsarethereforerespectivelydedicatedtoanoverviewofitstypicalmodelingcapabilitiesanditsmainexpectedusecases. 176F.Thomasetal.«profile»SRM«profile»«import»«import»SW_ResourceCore«import»«profile»«profile»«profile»SW_ConcurrencySW_BrokeringSW_InteractionFig.12.3SRMprofileoverview«SchedulableResource»deadlineElements=Task::DeadlineyieldService=Task::yield()«SchedulableResource»TaskDeadline:Integer+yield()Fig.12.4Exampleofclassextension«interface»«SchedulableResource»TaskServiceyieldService=TaskService::yield()«SchedulableResource»Task+yield()Fig.12.5Exampleofcomponentextension12.3.3ModelingExamplesSRMconceptsmainlyextendtheClassifiermetaclassofUML(Fig.12.7showsatypicalextension).AnyUML“Classifier”submetaclasscanthusbeextendedbythesestereotypes(e.g.,“Class”,“Interface”,“Component”and“AssociationClass”).Figures12.4and12.5illustratetheusageof“Class”and“Component”extensions.Figure12.6illustratestheuseofan“AssociationClass”todescribeinteractionsamongconcurrentresources.Sincethe“InteractionResource”stereotypeextendstheUMLClassifiermetaclass,anUML“AssocationClass”maybestereotypedasany“InteractionResource”substereotype(e.g.,“NotificationResource”,“MessageComResource”,and“MutualExclusionResource”).Inthisexample,theexecutionsupportprovidesconcurrencyresources(“Alarm”and“Task”)tocomputeinstructions. 12SoftwareReal-TimeResourceModeling177«NotificationResource»Eventtask0..1«Alarm»«SchedulableResource»AlarmTaskFig.12.6Exampleofanassociationclass«profile»SRM«metaclass»UML::kernel::Classes::Classifier«stereotype»SchedulableResouce+priorityElements:TypedElement[0..*]+stackSizeElements:TypedElement[0..*]+activateService:Operation[0..*]+createService:Operation[0..*]«apply»VxWorksPlatform«SchedulableResource»VxWorksTask«SchedulableResource»+stackSize:Integer;priorityElements=[priority,initPriority]+priority:Integer;stacksizeElements=[stackSize]createService=[taskSpawn]+taskSpawn(initPriority:Integer)activateService=[taskSpawn,taskActivate]+taskActivate()Fig.12.7ExamplesoftaggedvaluesTheseresourcesaredescribedasUMLclassesandrespectivelystereotypedas“Alarm”and“SchedulableRessource”.Inthisexample,an“Alarm”resourcemayinteractwitha“SchedulableResource”bymeanofaneventmechanismstereo-typed“NotificationResource”.SincepredefinedinstancesareassociatedwithoneormoreclassifiersintheUMLmetamodel,platformprovidersmustfirstdefinetheirclassifiers.Theseclas-sifiersshouldbestereotyped.ThismeansthatanextensionoftheUML“InstanceSpecification”metaclassisnotmandatory. 178F.Thomasetal.Stereotypetagsallowuserstospecifyresourcefeaturetaxonomies.ForexampleinFig.12.4,the“Deadline”propertyisreferencedbythe“DeadlineElements”stereotypepropertytoclarifyitstaxonomy.Itshowsexplicitlyinthemodelthatoneoftheattributesofthisclassplaystheroleofadeadline.Thisistheattributenamed“Deadline”.Suchamodelingapproachallowstoolstodistinguishpropertiesandtopermitautomaticmodeltransformations(e.g.,codegeneration).Notethattherearenoconstraintsonthetaggedvalueowner.InthesecondpartofFig.12.5,the“TaskService”interfaceownsa“yield”operation.Thisoperationistaggedasa“yieldServices”viathe“SchedulableResource”stereotype.Butthisstereotypeisnotappliedtotheinterface,whichmeansthat,withinthecontextofa“task”,theservicetocalltoreleasethecomputingresourceisthe“yield”operationofthe“TaskService”interface.Notealsothatbothmultipletaggedvaluesforthesametagandmultipletagsforthesamefeatureareallowed.Withthisapproach,theusercanformallyexpressmultiplesemanticsforthesamefeaturethroughmultipletags.Figure12.6describesa“taskSpawn()”serviceasbothtaskcreatingandtaskactivatingservices.Inthesameway,toactivateatask,theusercaneithercallthe“taskSpawn()”serviceorthe“taskActivate()”service.Thisalsoallowsuserstoexpressthesamesemanticsformultiplefeaturesthroughuseofthesametag(see“priorityElements”inFig.12.7).12.3.4MainSRMUseCasesFigure12.8showsthemainusecasesinwhichtheSRMprofileislikelytobeinvolved.Potentialkeyusersofthisdescriptioninclude“softwaredesigners”engagedindefiningreal-timesystemsoftwarearchitectures,“platformproviders”whodevelopandsellreal-timeoperatingsystems,and“methodologyproviders”whospecifyprocesseswhereplatformmodellingisimportant(e.g.,anMDAY-chart).SRMUMLProfileDescribeplatform«include»modellibraryExecutionPlatformBindapplicationmodelwithProviderplatformmodel«include»«extend»Describemultitasking«extend»SoftwaremodelDesignerModeltransformation«extend»MethodologyProviderCodegenerationFig.12.8TypicalSRMusecasesdiagram 12SoftwareReal-TimeResourceModeling179Figure12.9depictsaspecificexampleofaroboticapplicationbuilttorunontheOSEK/VDX-OSRTOS[2].Thisdesignisabasicrobotmotioncontroller.Itistypi-caloftheprocessesinvolvedinRTESdesign.Theexampleusedheredoesnotrefertoaspecificmethodology,butisintendedtoillustratethepreviouslydescribedSRMusecases.Inourexample,thesoftwaredesignerdescribesthelogical“RobotController”model.ThismodeldoesnotusetheSRMprofileinordertobeindependentofthetargetplatform.Platformindependencereferstothefactthatagivendesigncanbeportedwithoutchange,fromoneplatformtoanother.TheSRMprofileisnormallyusedtodescribetheplatformmodellibrary,asisusuallydonebytheplatformprovider.Theplatformmodellibraryincludesresourcesandresourceinstancesprovidedbytheexecutionplatform.Forinstance,theplatformproviderindicatesthatthe“OSEK/VDX”RTOSprovidesaspecific,structuredtypenamed“BasicTask”.AUMLclassisusedtoshowthattheplatformproviderstereotypesthatclassasa“SchedulableResource”toindicatethatthis“BasicTask”conceptownsthesemanticsofaconcurrentexecutionresourceman-agedbyaspecificscheduler.Theplatformprovideralsospecifiesthattheintegerattributenamed“priority”istheprioritypropertyofthatschedulableresource.Finally,theapplicationmaybeboundwiththeexecutionplatformtoproduceamultitaskingmodel.Todothat,theapplicationdesignmayimportthepreviousdefinedplatformmodellibrarytoinstantiatepredefinedtypesandusepredefinedinstances.BindingisdescribedviaaUML2.0dependencystereotypedwithaspe-cificstereotype.Inthecaseofaschedulableresource,thestereotype“entryPoint”«model»«Profile»RobotControllerSRM«modelLibrary»RobotDriver«apply»MotionControllerOSEK/VDXdriver«schedulableResource»setSpeed()trajectoryControl()0..1priorityElements=[priority]getSpeed()odometry()getSonar()«SchedulableResource»BasicTaskc1:MotionControllerpriority:Integer«import»«import»«instanceOf»«model»«entryPoint»SpecificOSEKVDXApplicationisReentrant=trueroutine=trajectoryControlt1:BasicTaskpriority=10«entryPoint»Fig.12.9AnOSEK/VDX-OSdesign 180F.Thomasetal.isusedtospecifythatthe“trajectoryControl”operationbodyisthecodewhichhastobeexecutedinthecontextofthatschedulableresource.Basedonthisdescription,themethodologyprovidercandefinetoolstoauto-maticallygeneratetheOSEK/VDXconfigurationfiledescribedinOILlanguage[15].ForeachUML“InstanceSpecification”whoseclassifierisstereotyped“SchedulableResource”,anOILTaskdeclarationblockcanbegenerated.Asthepriorityisexplicitlyreferenced,toolsareabletogivethetaskpriorityvalue.Figure12.10isanexampleofthepossiblegeneratedcode.Moreover,asoftwaredesignermaywishtoreuseandportapartofanapplica-tiondescriptiontorunontopofanewRTOS.Figure12.11illustratessuchausecasewithanARINC-653RTOS[3].Inthisexample,methodologyprovidertoolsmusttransformeachUML“InstanceSpecification”oftheOSEK/VDX“BasicTask”intoaUML“InstanceSpecification”ofanARINC-653process.Thetransformation01.OILVERSION=“2.5”:“RobotController”;02.…03.CPUcpu{04.TASKt1_trajectoryControl{05.PRIORITY=10;06.};07.}08.…Fig.12.10ExtractfromanOSEK/VDXconfigurationfile«Profile»SRM«model»RobotController«modelLibrary»«apply»Arinc-653RobotDriverMotionControllerdriver«schedulableResource»priorityElements=[prio]setSpeed()trajectoryControl()0..1getSpeed()odometry()«SchedulableResource»getSonar()«MemoryPartition»processProcessPartition0..1prio:Integerc1:MotionController«instanceOf»«import»«import»«instanceOf»«entryPoint»«model»isReentrant=trueSpecificArincApplicationroutine=trajectoryControlt1:Processp1:Partitionprio=10«entryPoint»Fig.12.11AnARINC-653design 12SoftwareReal-TimeResourceModeling181patternisgeneric,sincebothentitiesaredescribedwiththesame“SchedulableResource”stereotype.Themethodologyprovidercanthuswriteagenerictransformationruletoportanapplicationfromoneplatformtoanother:EachUML“InstanceSpecification”whoseclassifierisstereotyped“SchedulableResource”inthesourceRTOSmustbetransformedintoaUML“InstanceSpecification”whoseclassifierisstereotyped“SchedulableResource”inthetargetRTOS.Sucharulecanbeeasilywritteninanylanguageformodeltrans-formationasforexampleATL[16].Taggedattributesandtaggedoperationscanbetransformedinthesameway.12.4ConclusionandFutureWorkInthispaper,wehaveproposedameansformodelingsoftwareexecutionplatformswithUML.Thisisdonewithinthescopeofprovidingmodel-drivenprocessesthataffordreusability,portabilityandmaintainabilityofRTEapplications.WehavefocusedonanapplicationbuiltonanRTOS.Wehavethussoughttoprovidemod-elingartifactsformodelingexistingstandardizedRTOSAPIs,inordertobeabletoautomaticallyproducecodeforinterfacingtheapplicationwiththeseAPIs.Inthispaper,wefirstlydefinedtheplatformconceptandinvestigatedthestateoftheartrelatedtoUML-basedplatformmodeling.ThisrevealedthatUMLwaslackingincertainmeansfordescribingefficientlyandpreciselythesoftwareexecu-tionplatforms.Wethereforeconcludedthatmoreconcreteconceptswererequiredtoenableautomaticmodeltransformations(e.g.,throughcodegeneration).Forthisreason,wehaveproposedwithinMARTEaUMLprofile,calledSoftwareResourceModeling(SRM).Thisprofileprovidesbothfinedetailsandabroadrangeofmod-elingcapabilities.Italsoprovidesartifactsthatcanbeusedtowritegenericmodeltransformations.SuchtransformationscanbeusedtogeneratecodeandassistforportingRTEapplicationstoseveralmultitaskingplatforms.ThemainadvantageofusingtheSRMprofileisthatthisisnotanewRTEAPIbutinsteadastandardframeworkformodelingexistingexecutionplatformAPIs.WhiletheexecutionplatformsdiscussedinthispaperworkaremainlyRTOS,theSRMprofilecanalsobeusedtodescribeAPIsofotherexecutionplatformssuchasRTEframeworksorvirtualmachines.TheSRMprofileispartofthenewUMLprofileforModelingandAnalysisofReal-TimeEmbeddedsystems(MARTE)adoptedbytheOMGconsortium.Thus,theSRMprofileisastandardizedframeworkfordescribingRTEexecutionplatforms.FutureresearchwilldealwiththetransformationsusingtheSRMprofile.Effortswillthusfocusonusagepatterndescriptionandbehaviormodelingforthepurposeofobtaininganaccuratedescriptionoftheexecutionplatform.AcknowledgmentsTheauthorsdothankJ.P.BabauforitsvaluablecontributiontotheSRMprofile. 182F.Thomasetal.References1.TheOpenGroupBaseSpecifications,PortableOperatingSystemInterface(POSIX),ANSI/IEEEStd1003.1,20042.TheOSEK/VDXGroup,OSEK/VDXOSspecification,Version2.2.3,http://portal.osek-vdx.org/files/pdf/specs/os223.pdf,20053.TheAirlineselectronicengineeringcommittee,AvionicsApplicationSoftwareStandardInterface,ARINCSpecification653–1,Aeronauticalradio,Inc.,Annapolis,MD,October20034.TheObjectManagementGroup,MDAguideversion1.1,http://www.omg.org/mda/,June20035.TheObjectManagementGroup,UML2.1.1OCL2ndrevisedsubmission,2007,OMGdocu-ment:ad/2007-02-036.TheObjectManagementGroup,UMLProfileforModelingandAnalysisofReal-TimeandEmbeddedsystems(MARTE),RFP2005,OMGdocument:realtime/05-02-067.B.Selic(2005),OnSoftwarePlatforms,TheirModelingwithUML2,andPlatform-IndependentDesign,EighthIEEEInternationalSymposiumonObject-OrientedReal-TimeDistributedComputing(ISORC’05),IEEEComputerSociety,Washington,DC,pp.15–218.A.Sangiovanni-Vincentelli,G.Martin(2001),Platform-baseddesignandsoftwaredesignmethodologyforembeddedsystems,Design&TestofComputers,Volume18,Number6,November–December,IEEEComputerSociety,LosAlamitos,CA,USA,pp.23–339.Y.Tanguy,S.Gérard,A.Radermacher,F.Terrier(2006),ModelDrivenEngineeringforRealTimeEmbeddedSystems,In3rdEuropeanCongressEmbeddedRealTimeSoftware(ERTS),Toulouse,France10.TheObjectManagementGroup,UMLProfileforSchedulability,Performance,andTime,Version1.1,2005.OMGdocument:formal/05-01-0211.P.Kukkala,J.Riihimâki,M.Hämäläinen,K.Kronlöf(2005),UML2.0ProfileforEmbeddedSystemDesign,AutomationandTestinEuropeConference(DATE2005),pp.710–71512.R.Chen,M.Sgroi,L.Lavagno,GrantMartin,A.Sangiovanni-Vincentelli,J.Rabaey(2003),UMLandPlatform-basedDesign,UMLforReal:DesignofEmbeddedReal-TimeSystems,Kluwer,Norwell,MA,USA,pp.107–12613.VxWorks5.5DocumentationPage,http://www.windriver.com14.RTAI3.1DocumentationPage,http://www.rtai.org/15.TheOSEK/VDXGroup,OILspecificationVersion2.5,http://portal.osek-vdx.org/files/pdf/specs/oil25.pdf,200416.F.JouaultandI.Kurtev(2005),TransformingModelswithATL,ProceedingsoftheModelTransformationsinPracticeWorkshopatMoDELS2005,MontegoBay,Jamaica Chapter13ModelTransformationsfromaDataParallelFormalismTowardsSynchronousLanguagesHuafengYu1,AbdoulayeGamatié2,EricRutten3,andJean-LucDekeyser4AbstractTheincreasingcomplexityofembeddedsystemdesignscallsforhighlevelspecificationformalismsandforautomatedtransformationstowardslowerleveldescriptions.Inthispaper,ametamodelandatransformationchainaredefinedfromahigh-levelmodelingframework,Gaspard,fordata-parallelsystemstowardsaformalismofsynchronousequations.Theseequationsaretranslatedinsynchronousdata-flowlanguages,suchasLustre,whichprovidedesignerswithformaltechniquesandtoolsforvalidation.Inordertobenefitfromthemeth-odologicaladvantagesofre-usabilityandplatform-independence,aModel-DrivenEngineeringapproachisapplied.KeywordsMDE,modeltransformation,Gaspard,synchronouslanguages,embeddedsystem13.1ContextandMotivation13.1.1MDEandData-ParallelApplicationsData-parallelapplications,suchasmobilemultimediaprocessing,high-definitionTVandradar/sonarsignalprocessing,playanincreasinglyimportantroleinembed-dedsystems.Theseapplicationsgenerallyconcerncomputationsonmultidimen-sionaldatastructures.Buttheseapplicationsbecomemoreandmorecomplex.Asaresult,theirdesignandvalidationturnouttobedramaticallycomplicated.Furthermore,theproductivityproblemisagreatconstraintforthedevelopmentoftheseapplications.Moreefficientmodelinganddesignmethodsarehighlyneeded.1INRIAFutursLille-LIFL,FranceEmail:huafeng.yu@inria.fr2LIFL-CNRS(UMR8022),FranceEmail:abdoulaye.gamatie@lifl.fr3INRIARhône-Alpes,FranceEmail:eric.rutten@inrialpes.fr4LIFL-USTL(UMR8022),FranceEmail:jean-luc.dekeyser@lifl.frE.Villar(ed.)EmbeddedSystemsSpecificationandDesignLanguages,183©SpringerScience+BusinessMediaB.V.2008 184H.Yuetal.Nowadays,amongintensiveresearchactivitiestoaddresssuchproblems,Model-DrivenEngineering(Mde)[17]basedmethodscanbementioned.Well-definedmodelingspecificationsleadtorapiddesignaswellasconciseandcleardocumentation,andtheirautomatedtransformationsenabletogeneratePlatform-SpecificModels(Psm)andevenexecutablecodeconveniently.There-usabilityandmodularityoftheirmodels,IntellectualProperties(IPs)andthehierarchicalmode-lingmaketheproductionoftheseapplicationsmoreefficientandrapid.13.1.2TheGASPARDMethodologyforData-ParallelComputingGaspard[15]isaMdebaseddevelopmentenvironmentandmethodologyfordata-parallelapplications.Itproposesconcepts,whichfeaturehighleveldataparallel-ism,dataflowandcontrolflowmixing,hierarchicalandrepetitiveapplicationandarchitecturemodeling,etc.Theinherentdata-parallelformalismofGaspardisadoptedbyMarte(ModelingandAnalysisofReal-TimeandEmbeddedsystems)[16],whichisanOmg(ObjectManagementGroup)standardforthemodelingandanalysisofreal-timeembeddedsystems.Gaspardconcernssoftware/hardwareco-modelingandmodeltransformations.Moreprecisely,itenablestomodelsoftwareapplications,hardwarearchitectures,theirassociationandIPdeploymentthroughapredefinedmetamodelinauniquemodelingenvironment.Thismodelingstaysatahighabstractionlevelandisplatformindependent.GaspardenablesaswelltransformationsfromthesemodelstoPsmmodels.GaspardmetamodelispartiallybasedontheconceptoftheY-chart(seeFig.13.1and[15]).Modelsforapplicationandhardwarearchitecturearedefinedseparately.Then,applicationmodelscanbemappedonarchitecturemodels.TheobtainedmodelsareassociatedwithsoftwareorhardwareIPsduringthedeployment.Allthesemodelsareplatform-independent,andingeneraltheyarenotassociatedwithparticulartechnologies,buttheycanstillbeassociatedwithanexecution,simula-tion,validationorsynthesistechnology.Modeltransformationsareperformedfromdeployedmodelstospecificlanguages(synchronouslanguagesandothers,whicharenotdetailedhereandareshadowedintheFig.13.1,suchasFortran,SystemCandVhdl).ThesecharacteristicsofGaspardhelptoreducethesystemdesigncomplexity.Inthefollowing,webrieflypresentmainfeaturesofthehigh-levelmetamodelofGaspard.●Applicationfocusesonthedescriptionofdatadependenciesbetweentheappli-cationcomponents.Thesecomponentsanddependenciescompletelydescribethefunctionalbehaviourwithpotentialdata-parallelism.●Architecturespecifiesthehardwarearchitectureatahighabstractionlevel.Itenablestodimensionhardwareresourcesinthesamewayasinapplication.●Associationallowsonetoexpresshowtheapplicationisprojectedonthehardwarearchitecturewiththeconsiderationoftaskanddataparallelism. 13TransformationofDataParalleltoSynchronousPrograms185Fig.13.1Y-chartaccordingtoGaspard●Deployment(representedbytheboxtaggedas“Deployed”inFig.13.1)enablestochoseaspecifictargetplatformforcodegenerationfromGaspardmodels.ThisisachievedbyimportingIPs.13.1.3Motivation:ConnectingGASPARDtoValidationToolsTheGaspardmethodology,dedicatedtothedata-parallelapplicationdesign,adoptsatop-downapproach,whichgoesfromthehighabstractionleveltolowimplementationlevels.Moreover,thecorrectnessofthedesignandimplementationishighlyrequiredaswell.However,GaspardUmlmodelsarelimitedbyformalsemantics,whichisnecessaryfortheformalvalidationofthesystemdesign.Henceamapfromthesemodelsonformalmethodsisneeded.Synchronouslanguagesarewellknownfortheirformalaspectsandtheirrichnessintermsoftoolsforvalidation,verificationandautomaticcodegeneration.Therefore,theconnectionofthesetwotechnologiesisencouragedbecauseitofferstheopportunitytobenefitfromthecapabilityofGaspardinthespecificationofdata-parallelismandalsofromthepowerofformalaspectsofsynchronouslanguages.ThispaperpresentshowMDEtransformationscontributetobridgethesedifferentabstractionlevelsfromGaspard 186H.Yuetal.tosynchronouslanguages(Lustre[9]isconsideredhereforillustration).Furthermore,theautomatedtransformationreducespotentialerroroccurrencescausedbythemanualtranslation.Previousworks([1,5])haveexploitedthesim-ulationofGaspardspecificationsinPtolemyIIandalsotheirprojectionsintoKahnprocessnetworkforthedistributedexecution,buttheywerenotimple-mentedwiththeMdeapproachanddidnotaimattheformalvalidationandverification.13.2DataParallelismandSynchronousApproach13.2.1Data-ParallelApplicationDesign:GASPARDThispaperonlyaddressessoftwareapplicationmodelinganditsdeployment.BasicapplicationmodelsofGaspard[3]canbesummarizedbythefollowinggrammar:Task::=(r1)Interface::=(r2)Port::=(r3)Body::=Taskh|Taskr|Taske(r4)Taske::=(r5)Taskr::=<{Tiler},(r,Task),{Tiler}>(r6)Tiler::=(r7)Taskh::=<{Task},{(Task,array,Task)}>(r8)AllGaspardtasksshareafewcommonfeatures(rule(r1)):aninterface(rule(r2)where{}denotesaset)thatspecifiesinput/outputports(typedbyinoroutinrule(r2)anddefinedinrule(r3))fromwhicheachtaskrespectivelyreceivesandpro-ducesmultidimensionalarrays;andabody(rule(r4)),whichdependsonthetypeoftaskasfollows:●Elementarytask(rule(r5)).Thebodycorrespondstoanatomiccomputationblock.Typically,itconsistsofafunctionoranIP.●Repetitivetask(rule(r6)).Itexpressesthedata-parallelisminatask.Theinstancesoftheassociatedrepeatedtaskareassumedtobeindependentandschedulablefollowinganyorder,eveninparallel.Theattributer(intherule(r6))denotestherepetitionspace,whichindicatesthenumberofrepetitions.Itisdefineditselfasamultidimensionalarraywithashape.Eachdimensionofthisrepetitionspacecanbeseenasaparallelloopandtheshapeoftherepetitionspacegivestheboundsoftheloopindicesofthenestedparallelloops[3].Inaddition,eachtaskinstanceconsumesandproducessub-arrayswiththesameshape.Thesesub-arraysarereferredtoaspatterns.Thewaypatternsareconstructedisdefinedviatilers(rule(r7)),whichareassociatedwitheacharray.Atilerextracts(resp.stores)patterns 13TransformationofDataParalleltoSynchronousPrograms187from(resp.in)anarraybasedoncertaininformationitcontains:F:afittingmatrix(howarrayelementsfillpatterns);o:theoriginofthereferencepattern;andP:apavingmatrix(howpatternscoverarrays).●Hierarchicaltask(rule(r8)).Itisrepresentedbyahierarchicalacyclicgraphinwhicheachnodeconsistsofatask,andedgesarelabeledbyarraysexchangedbetweentasknodes.Anapplicationisahierarchicaltaskinwhichthetop-levelofthehierarchyiscom-posedofasingletask,whichplaysasimilarroleto“main”inaCprogram.TheGaspardapplicationmetamodelisdefinedaccordingtotheabovebasicconcepts.ThewholesoftwareapplicationismodeledasanApplicationModel,inwhichApplicationComponentsmodelhierarchicaltasks(seedetailedexamplesin[18]).InstancesofotherApplicationComponent,calledApplicationComponentInstance,canbecomposedinit.TheseinstanceshavePortInstances.ConnectorsareusedtoconnectPortInstancesand/orPorts.Internalstructures,suchasElementary,CompoundandRepetitive,aredefinedinanApplicationComponentaccordingtoitsinsidecomponentinstances.●ElementarypointsoutthattheApplicationComponentisanelementarytask,whichisablackboxinGaspard.●RepetitiveindicatesthattheApplicationComponentisarepetitivetask.TheConnectorswhichconnectApplicationComponent’sportsandPortInstancesofitsinternalinstanceareTilers.●Compoundcorrespondstoahierarchicaltaskandexpressestaskparallelism.AlltheComponentInstancesinsidethiscomponentruninparallel.13.2.2TheSynchronousApproachThesynchronousapproach[2]proposesformalconceptsthatfavorthetrusteddesignofembeddedsystems.Itsbasicassumptionisthatcomputationandcommunicationareinstantaneous,referredtoassynchronyhypothesis.Therearedifferentsynchronouslanguages,whichhavestrongmathematicalfoundations,suchasLustre,LucidsynchroneandSignal.Theselanguagesarewell-adaptedfordata-flow-orientedapplications.Alltheselanguagesareassociatedwithtool-setsthathavebeensuccess-fullyusedinseveralcriticaldomains(e.g.avionics,automotive,nuclearpowerplants).Inthispaper,Lustreistakenastheexample(seeasegmentofLustrecodeinFig.13.2)fortheintroductionofsomebasicconceptsinsynchronouslanguages.AnodeisabasicfunctionalityunitinLustre.Eachnodegivesthesameresultswiththesameinputsthankstoitsdeterminism.Nodeshavemodulardeclarationsthatenabletheirreuse.Eachnodehasaninterface(inputatline(l1)andoutputat(l2)),localdefinition(l3),andequations(line(l5)and(l6)).VariablesarecalledsignalsinLustre.Equationsaresignalassignments.Furthermoreonlyuniqueassignmentsareallowedforsignals.Intheseequations,therearepossiblynodeinvocations(l5)thataredeclaredoutsidethisnode.Obviously,inLustre, 188H.Yuetal.nodenode_name(A1:intˆ4)(l1)returns(A3:intˆ4);(l2)varA2:intˆ4;(l3)let(l4)A2=a_function(A1);(l5)A3=A1+A2;(l6)tel(l7)Fig.13.2AnexampleofLustrecodemodularityandhierarchyareinbuilt.Thecompositionoftheseequations,denotedby“;”,meanstheirparallelexecutionw.r.t.data-dependencies.Thenodehasthesamemeaningindependentoftheequationorder.13.3ASynchronousEquationalMetamodelThemetamodelproposedhereaimsatthreesynchronousdata-flowlanguagesatthesametime.Theselanguageshaveconsiderablecommonaspects,whichenabletheircodegenerationwiththehelpofonlyonemetamodel.Inaddition,becauseoftheobviousdifferencesbetweenGaspardandsynchronouslanguages,anintermediatemodelisnecessarytobridgethegapbetweenthemaswell.Asynchronousmodelisthereforeproposed,whichfollowsthesynchronousmodelingofdata-intensiveapplications[8].Itaimstobegenericenoughtotargetthesynchronousdata-flowlanguagesmentionedearlierandtobeadequatetoexpressdata-parallelapplica-tions.So,itisnotintendedtohaveexactlythesameexpressivityastheselanguages.ButthisisnotthecaseoftheSignalmetametamodel[4],whichisspecificallydedicatedtotheSignallanguage.Thismetamodelcompletelydefinesallprogram-mingconceptsinSignal.IthasbeenspecifiedintheGenericModelingEnvironment(Gme),developedatVanderbiltUniversity.13.3.1SignalIntheproposedmetamodel,allinput,outputorlocalvariablesarecalledSignals(seeFig.13.3).EachSignalisassociatedwithaSignalDeclaration,whichdeclaresthenameandtypeoftheSignal.ItisassociatedwithatleastoneSignalUsage.ThelatterrepresentsoneoperationonSignal.IftheSignalisanarray,aSignalUsagecanbeanoperationonapatternofthisarray.Hence,ifthearrayhasseveralpatterns,theSignalisassociatedtothesamenumberofSignalUsagecorrespondingly.EachoftheseSignalUsageshasanIndexValueSet,whichisasetofIndexValueoftheassociatedSignal.ASignalUsageisassociatedwithatleastoneArgumentofequations,whichindicatestheirinputs/outputs. 13TransformationofDataParalleltoSynchronousPrograms189<>NodeVariables+owner+owner0..*0..*+signals+signalUsage<>1<>Signal+signal1SignalUsage1+signal+signalUsage+signalUsage1+declaration<>0..*0..1<>Argument+arguments+indexValueSetSignalDeclaration<>IndexValueSet+owner<><>SignalInterDecSignalLocalDec1..*{ordered}+inputs+outputs+parameters+locals+indexValues0..*0..*0..*1..*{ordered}{ordered}{ordered}{ordered}<>IndexValue+value:int[*]{ordered,nonunique}+interface+interface+interface+owner<><>InterfaceLocalDeclarationsFig.13.3Extractofthesynchronousmetamodel:Signal13.3.2EquationEquations(Fig.13.4)indicatetherelationsbetweentheirinputsandoutputs,whicharecalledArgumentshere.AnEquationhasanEquationRightPartandatmostoneEquationLeftPart.ThelatterhasArgumentsasEquationoutputs.EquationRightPartiseitheranArrayAssignmentoranInvocation.ArrayAssignmenthasArgumentsandindicatesthattheEquationisanarrayassignment.InvocationisacalltoanotherNode(seethefollowingsubsectionNode).InanInvocation,Function-Identifierindicatesthecalledfunction.13.3.3NodeSynchronousfunctionalitiesaremodeledasNodes(seeFig.13.4).ANodehasnomorethanoneInterface,LocalDeclaration,NodeVariables,anEquationSystemandsomeImplementationsandCodeFiles.NodeVariablesisthecontainerofSignalsandSignalUsages.Eachinput/outputSignalisassociatedwithaSignalDeclaration,whichbelongstotheInterface,whilelocalSignals’SignalDeclarationsbelongto 190H.Yuetal.<>Module+name:String+owner+owner+owner0..*1..*10..*+localNodes+nodes+mainInstance+implementations<><>NodeImplementation+name:String0..1+owner+owner+owner+owner+node+implementation0..11+interface+equationSystem1..*<><>+portImplementationInterfaceEquationSystem<>+owner0..1PortImplementation+nodeVariables<>0..11..*NodeVariables0..*0..*+localDefinitions+equations+implementingFiles+codeFiles<><><><>LoacalDeclarationsEquationFunctionIdentifierCodeFile+owner+owner<>0..1+left1+rightImplementationLanguage<><>LustreEquationLeftPartEquationRightPartSignal+equationLeftPartLucidSynchrone<><>ArrayAssignmentInvocation+arrayAssignment+invocation+invocation{ordered}1..*1..*0..*{ordered}1+arguments+arguments+arguments+invocatedFunction<><>ArgumentFunctionldentifierFig.13.4Extractofthesynchronousmetamodel:Node,EquationLocalDeclaration.EquationSystemisthenodebodythatfulfillsthefunctionalitythroughacompositionofatleastonesynchronousEquation.AllNodesaregroupedinaModule,whichrepresentsthewholeapplication.Itcon-tainsoneNodeasthemainNodeoftheapplication.EachNodeiseitherdefinedintheModuleorlinkedtoanexternalfunctionthroughIPdeployment. 13TransformationofDataParalleltoSynchronousPrograms19113.3.4RemarksNodesthatarenotdefinedintheModuleshouldbedeployed.Theequiva-lentsofthesenodesareGaspardelementarytasks.AnImplementationassociatedwithaNodecontainstheinformationoftheexternalfunction.ParametersofexternalfunctionarerepresentedbyPortImplementations.TheirordersaredefinedintheImplementationsothatparametersarepassedcorrectlytotheapplication.AnImplementationisassociatedwithatleastoneCodeFile,whichrepresentstheimplementationoftheexternalfunction.Synchronousmodels,whichconformtothismetamodel,actasintermediatemodelsbetweendata-parallelapplicationsanddata-flowlanguages.Theirparallelcompositionspreservetheparallelism,andtheirmodularityandre-usabilityensurehierarchicalcompositionsoforiginalGaspardmodels.Thismodelingisalsogenericenoughsothatitwillnotsufferfromthecomplexityandparticularityoftargetlanguages.Moreoveritenablespotentialimprovements,forinstance,theintegrationofapplicationcontrolinspiredby[13].13.4ModelTransformationsOnlyGaspardmodelswiththeinfinitedimensionatthehighesthierarchycanbetransformedintosynchronousmodels.Theinfinitedimensionistranslatedbyalogicaltimeinthereactivestyleofsynchronouslanguages.Soinsynchronousmodels,therearenomoreinfinitedimensions.Themultidimensionalarraysaretranslatedintoarray-typesignals.ParallelisminGaspardcanbeeasilymodeledinsynchronousmodelswiththehelpofthecompositionoperatordefinedinsynchro-nouslanguages.TransformationsofGaspardmodelsintosynchronousspecifications(typically,Lustreprograms)consistoftwosteps:firstly,atransformationofGaspardmod-elsintosynchronousmodels;andthen,thegenerationofsynchronouscodefromsynchronousmodelsobtainedfromthefirststep.13.4.1FromGASPARDModelstoSynchronousModelsSomebasictransformationsarefirstgiven.ComponentsandCompon-entInstancesaretransformedintoNodesandEquationsrespectively.Ports,PortInstancesandDefaultLinkconnectorsinaComponentaretransformedintoSignals,whereasTilerconnectorsaretransformedintoEquationsaswellasNodes. 192H.Yuetal.13.4.1.1TransformationRulesAlltherulescanberepresentedthroughatreestructure(seeFig.13.5).Theuniqueinitial(root)ruleisGModel2SModel.IttransformsawholedeployedGaspardapplicationintoasynchronousmodule.Thisrulethencallsitssub-rules:GTiler2SNode,GApplication2SNode,GACI2SNode,etc.GApplication2SNodehasalsothreesub-rules:GRepetitive2SEquationSystem,GCompound2SEquationSystemandGElementary2SEquationSystem.NotethatnotallrulesaregivenintheFig.13.5duetolackofspace(see[18]fordetails).Inthefollowing,onlyrulespresentedintheFig.13.5aredescribed.Amongthem,GTiler2SNodeandGRepetitive2SEquationSystemarealittlemoredetailed.Theotherrulesareconstructedinthesameway.●GTiler2SNode(seeFig.13.6inwhicheachelementisnumbered).ItisaruleforthetransformationoftilerconnectorsintosynchronousinputoroutputtilerNodes.AninputtilerNodeistakenasanexamplefortheconstructionofasynchronousnode.Firstofall,theNode(numbered1)iscreatedandisassoci-atedwithitsModule.ThePortandPortInstanceconnectedbythistilerarethentransformedintoinputandoutputSignalsrespectively.OnePortcorrespondstooneinputsignal,andonePortInstancecorrespondstosev-eraloutputsignals,whosequantity,n,iscalculatedfromtherepetitionspacedefinedinitsconnectedComponentInstance.TheinputsignalisassociatedwithnSignalUsages(4)andanoutputsignalisassociatedwithaSignalUsage(8).Interface(2)isthencreatedandassociatedwithSignalDeclarations(3,9)thatareassociatedwithsignals.NotethattherearenoLocalDeclarationsinthisnode.Next,anEquationSystemcon-tainsnEquations(5).IneachEquation,theEquationLeftParthasanArgument(6)whichisassociatedwithaSignalUsageofaninputsignal.EquationRightPartisdirectlyanArrayAssignment.ItsArgument(7)isassociatedwithaSignalUsage(8)ofacorrespondingoutput.Fig.13.5Hierarchyofthetransformationrules 13TransformationofDataParalleltoSynchronousPrograms193Tiler1Node225467895467893546789546789Fig.13.6Transformationofthetiler●GApplication2SNode.IttransformsapplicationcomponentsintoNodes.However,alltheelementsintheseNodesaregeneratedbyitsthreesub-rules,whichtransforminternalstructuresintheComponentintoanEquationSystem.●GACI2SNode.IttransformstheuniquemainApplicationComponentInstancesintoasynchronousNode.Itisthemaininstanceoftheapplication.●GRepetitive2SEquationSystem.(Fig.13.7)Inthisrule,anEquationSystemisfirstcreated.AndthenthreetypesofEquationarecreated:inputtilerEquations,repeatedtaskEquationandoutputtilerEquations.Tilerconnectorsaretransformedintoinput/outputtilerEquations,whichareinvo-cationstoNodesgeneratedbyGTiler2SNode,andtheinternalComponentInstanceistransformedintorepeatedtaskEquation.Arele-vantrepeatedtaskNodeisthencreated,inwhichnequationsinvokethetasknodecorrespondingtothecomponentthatdeclarestheinternalcomponentinstance.NotethathierarchicalcompositioninGaspardmodelsispreservedinsynchronousmodelsbynodeinvocations.●GCompound2SEquationSystem.EachinternalComponentInstanceistrans-formedintoanequation.ConnectorsbetweentheseComponentInstancesaretransformedintolocalSignals.●GElementary2SEquationSystem.NoEquationiscreatedbecauseitsownerNodeisimplementedexternallyandDeploymentmodelsareusedtoimportitsexternaldeclarations.HoweveranInterfaceiscreatedaccordingtothecomponent’sports. 194H.Yuetal.RepetitivetaskTilerTaskTilerNodeNodeNodeNode.........Fig.13.7Transformationoftherepetitivetask13.4.1.2ImplementationoftheTransformationChainGaspardmodelsarespecifiedinthegraphicalenvironmentMagicDraw,andareexportedasEclipseModelingFramework(Emf)[6]models.Emfisamodelingframeworkandcodegenerationfacility.Inthefollowingtransformationphase,thesemodelsaretransformedintoEmfGaspardmodels.Thesetwoprevioustrans-formationswillnotbedetailedhere.ThenEmfGaspardmodelsaretransformedintoEmfsynchronousequationalmodels,whicharefinallyusedtogeneratesyn-chronouslanguagecode(e.g.Lustrecode).AnautomatedmodeltransformationchainisthendefinedthroughtheconcatenationofthesetransformationsfromMagicDrawUmlmodelstodata-flowlanguages(Fig.13.8).Thesetransformationswereimplementedwiththehelpofspecifications,stand-ardsandtransformationlanguages.Someofthemarebrieflypresentedinthispaper.MofQvt[14]istheOmgstandardonmodelqueryandtransformation,whichisrespectedintransformationspresentedhere.Severalothertransformationlanguagesandtools,suchasAtl[10]andKermeta[12]alreadyexist.Atlisamodeltransformationlanguage(amixedstyleofdeclarativeandimperativecon-structions)designedw.r.t.Qvt.Kermetaisametaprogrammingenvironmentbasedonanobject-orientedDomainSpecificLanguage.Butthesetwolanguageslackofextensioncapabilityespeciallywhensomeexternalfunctionsareneededtobeintegratedintothetransformation.Emft(EclipseModelingFrameworkTechnology)projectwasinitiatedtodevelopnewtechnologiesthatextendorcom-plementEmf.ItsquerycomponentofferscapabilitiestospecifyandexecutequeriesagainstEMFmodelelementsandtheircontents.TheMoMoTEtool(MOdeltoMOdelTransformationEngine),whichisbasedontheEmftQueryandisinte-gratedintoGaspard,isaJavaframeworkthatallowstoperformmodeltomodeltransformations.ItiscomposedofanApiandanengine.Ittakesinputmodelsthatconformtosomemetamodelsandproducesoutputmodelsthatconformtoothermetamodels.AtransformationbyMoMoTEiscomposedofrulesthatmaycallsub-rules.TheserulesareintegratedintoanEclipseplugin.Ingeneral,oneplugincorrespondstoonetransformation.Duringmodeltransformations,thesepluginsareautomaticallyinvokedonebyone. 13TransformationofDataParalleltoSynchronousPrograms195MagicDrawEclipseEMFSynchronousSynchronousUMLmodelUMLmodelGaspardmodelLustreequationalmodelModelTransformationCodegenerationCodeFig.13.8Thedetailedtransformationchain13.4.2SynchronousCodeGenerationfromModelsTheimplementedcodegenerationfromsynchronousmodelsistemplatebased.EmfJet[7]andMoCodEareusedtobuildcodegenerators(threegeneratorsforthreedata-flowlanguages).Jetisatemplatebasedcodegenerationtool.UserdefinedtemplatesinJetareusedtogenerateJavaimplementationclasses.Then,thelattercanbecalledtogeneratetargetcode.MoCodE(MOdelstoCODeEngine),whichworkswithJet,isalsoatoolintegratedintoGaspard.ItconsistsofanApiwithanenginethatenablestoperformmodeltotexttransformation.Ittakesasetofmodelsasinputs,andthenitsenginerecursivelytakesoutelementsfrominputmodelsandexecutesacorrespondingJavaimplementationclassonthem.TheseJavaclassesfinallygeneratetargetcode.13.5AnApplicationExampleExamplesofmatrixprocessing,whichaveragesthepatternsfrominputs,areintui-tive,buttheyaretypicaltoshowthetransformationandtheapplicationdomain.OneoftheexamplesimplementedisillustratedinFig.13.9,whichtakesaflowof(4,4)-array,andproducesaflowof(2,2)-array.Foreachstepintheflow,theaver-agecomputingblockhasfourrepetitions,eachofwhichtakesa(2,2)-sub-arraysfromtheinputarray,thencarriesoutthecomputing,andproducesa(1,1)-sub-array.Finallyallofthe(1,1)-arraysfromthefourrepetitionsthenconstructtheoutput(2,2)-arrayoftheapplication.ThedeploymentofthematrixaverageIP(TASK)isillustratedinFig.13.10.ThisdeploymentindicateswheretofindtheLustrecodethatimplementsthisIP.ThephysicalLustrecodeisrepresentedbytheCodeFile,anditisassociatedtotheelementarytaskbythecomponentAbstractSoftwareImplementation,whichiscomposedofatleastoneSoftwareImplementations.Thismeansoneelementarytaskmayhaveseveraldifferentimplementations(indifferentlanguagesorthroughdifferentalgorithms).TheSoftwareImplementationcontainsthedeploymentinformation,forexample,theelementaryfunctionname, 196H.Yuetal.<>MatrixAverage<><>[(2,2)][(4,4)]t:TASK[(2,2)]<>[(2,2)][(1,1)]<>{fitting=“((1,0),(0,1))”,{fitting=“((1,0),(0,1))”,origin=“(0,0)”,origin=“(0,0)”,paving=“((1,0),(0,1))”}paving=“((2,0),(0,2))”}Fig.13.9Anexampleofmatrixaveragecomputation<><>TASKi1:Integer[(2,2)]o1:Integer[(1,1)]<><><><>asiTask<>siTaski1{functionName=“TASK1”,o1language=Lustre}<><>cfTask{filePath=“./eclipse/runtimeConfiguration/demo/exLustre/”}Fig.13.10ThedeploymentofthematrixaverageIPthelanguageofitsimplementation.Otherdeploymentinformation,suchasports,etc.,canbefoundthroughthereferences(portImplementedBy,imple-mentedBy)betweenAbstractSoftwareImplementationandElementaryComponent.Thetransformationchainandthegeneratedcodeisillustratedinthevideolocatedin[11].Theextractofthegeneratedcodecanalsobefoundin[18]. 13TransformationofDataParalleltoSynchronousPrograms19713.6ConclusionsandPerspectivesInthispaper,weproposedasynchronousmetamodelandpresentedmodeltransfor-mationsfromdata-intensiveapplicationsspecifiedinGaspardintosynchronouslanguages,particularlytheLustrelanguage,throughaMdeapproach.Thecodeinjavaandrulesoftheimplementedtransformationsaddsuptoabout5,000linesinEclipse.Someillustrativeexamplesofthetransformationhavebeenimplemented.Duetospaceproblem,onlyoneisshowedinthispaper.Othermorecomplicatedexam-plescanbefoundin[18].Simulationandvalidationissuesarealsoaddressedwiththegeneratedcode.Functionalsimulationandverificationofdeadlockabsenceontheoriginaldesignhavebeencarriedout.Whereasthesynchronizabilityanalysisrequirestheintroduc-tionofclocksinGaspard.Oneofthefutureworkconcernstheintegrationofcon-trol(inspiredby[13])inGaspardmodelsandtheirtransformationintosynchronouslanguagesforautomaticverification.Moreanalysisdetailscanbefoundin[8,18].Finally,thewayalltheseanalysisresultscanbeexploitedbyGaspardusersisachallengingperspectivefromapracticalpointofview.References1.Amar,A.,Boulet,P.,Dumont,P.:ProjectionoftheArray-OLspecificationlanguageontothekahnprocessnetworkcomputationmodel.In:ProceedingsoftheInternationalSymposiumonParallelArchitectures,Algorithms,andNetworks,LasVegas,NV(2005)2.Benveniste,A.,Caspi,P.,Edwards,S.,Halbwachs,N.,LeGuernic,P.,deSimone,R.:Thesynchronouslanguagestwelveyearslater.In:ProceedingsoftheIEEE91(1),64–83(2003)3.Boulet,P.:Array-OLrevisited,multidimensionalintensivesignalprocessingspecification.ResearchReportRR-6113,INRIA,http://hal.inria.fr/inria-00128840/en/(2007)4.Brunette,C.,Talpin,J.-P.,Besnard,L.,Gauthier,T.:Modelingmulti-clockeddata-flowpro-gramsusingthegenericmodelingenvironment.In:SynchronousLanguages,Applications,andProgramming.Elsevier,ViennaAustria,(2006)5.Dumont,P.,Boulet,P.:Anothermultidimensionalsynchronousdataflow:SimulatingArray-OlinPtolemyII.Tech.Rep.5516,INRIA,www.inria.fr/rrrt/rr-5516.html(2005)6.Eclipse:EclipseModelingFramework.http://www.eclipse.org/emf7.Eclipse:EMFTJET.http://www.eclipse.org/emft/projects/jet8.Gamatié,A.,Rutten,E.,Yu,H.,Boulet,P.,Dekeyser,J.L.:Synchronousmodelingofdatainten-siveapplications.ResearchRep.5876,INRIA.http://hal.inria.fr/inria-00001216/en(2006)9.Halbwachs,N.,Caspi,P.,Raymond,P.,Pilaud,D.:ThesynchronousdataflowprogramminglanguageLustre.In:ProceedingsoftheIEEE79(9)(1991)10.INRIAAtlasProject:Atl.http://www.sciences.univ-nantes.fr/lina/atl/11.INRIADaRTProject:Presentationsanddemonstrations:Gaspard2towardsLustre.http://www2.lifl.fr/west/DaRTShortPresentations12.INRIATriskellProject:Kermeta.http://www.kermeta.org/13.Labbani,O.,Dekeyser,J.L.,Boulet,P.,Rutten,E.:AdvancesinDesignandSpecificationLanguagesforSoCs,SelectedcontributionsfromFDL’06,chap.UML2ProfileforModelingControlledDataParallelApplications.Springer,TUDarmstadt,Germany(2007) 198H.Yuetal.14.ObjectManagementGroup(OMG):MOFQuery/Views/Transformations(QVT).http://www.omg.org/cgibin/doc?ptc/2005-11-01(2005)15.INRIADaRTProject:Gaspard.http://www.lifl.fr/west/gaspard/16.Rioux,L.,Saunier,T.,Gerard,S.,Radermacher,A.,deSimone,R.,Gautier,T.,Sorel,Y.,Forget,J.,Dekeyser,J.L.,Cuccuru,A.,Dumoulin,C.,André,C.:MARTE:Anewprofilerfpforthemodelingandanalysisofreal-timeembeddedsystems.In:UML-SoC’05,DAC2005WorkshopUmlforSoCDesign.Anaheim,CA(2005)17.Schmidt,D.C.:Model-drivenengineering.IEEEComputer39(2)(2006)18.Yu,H.,Gamatié,A.,Rutten,E.,Dekeyser,J.L.:Modeltransformationsfromadataparallelformalismtowardssynchronouslanguages.ResearchReport6291,INRIA.http://hal.inria.fr/inria-00172302/en/(2007) Chapter14UMLandSystemC–AComparisonandMappingRulesforAutomaticCodeGenerationPerAnderssonandMartinHöstAbstractTodayembeddedsystemdevelopmentisacomplextask.Toaidtheengi-neersnewmethodologiesandlanguagesareemerging.Duringthedevelopmentthesystemismodeledusingdifferenttoolsandlanguages.Transformationsbetweenthemodelsaretraditionallydonemanually.Weinvestigatetheautomationofthisproc-ess,specificallywearelookingatautomaticUMLtoSystemCtransformation.InthispaperwecompareUMLandSystemC,focusingoncommunicationmodeling.WealsopresentmappingrulesforautomaticSystemCcodegenerationfromUML.ThemappinghasbeenimplementedinourUMLtoSystemCcodegenerator.Keywordscodegeneration,UML,systemC14.1IntroductionTodaythereisaneverendingdemandfornewfunctionalitytobeincludedinembeddedsystemssuchasmobilephones.Thisleadstoincreaseddesigncomplex-ity.Toovercometheincreasedsystemcomplexitynewdesignmethodologies,suchasmodeldrivenarchitecture,havebeenintroduced.Inparallelwiththis,newlan-guages,i.e.SystemC[2,3],forsystemlevelmodelingandsimulationhavealsoemerged.Combiningnewmethodologiesandnewlanguagesisapromisingapproachtomanagetheincreasingsystemcomplexity.ThisisthefocusoftheMARTES(Model-BasedApproachforReal-TimeEmbeddedSystemsdevelop-ment)project.1IntheprojectweinvestigatehowUMLandSystemCcanbeusedtogetherwhentheideasofModelDrivenArchitectureareapplied.OneofthetasksoftheprojectistoinvestigatehowtransformationsfromUMLtoSystemCcanbeLundUniversity,P.O.Box118,SE-22100Lund,SwedenEmail:Per.Andersson@cs.lth.seandMartin.Host@cs.lth.se1www.MARTES-ITEA.orgE.Villar(ed.)EmbeddedSystemsSpecificationandDesignLanguages,199©SpringerScience+BusinessMediaB.V.2008 200P.Andersson,M.Höstautomatedandsupportedbytools.Duringthisresearchwearedevelopingaproto-typetool,whichmanagetheUMLtoSystemCtransformationsandcodegenera-tion,asanadd-intotheTelelogicTAUUML2modelingtool.2ThispartoftheMARTESprojectiscarriedoutinclosecooperationbetweenLundUniversityandTelelogic.Inthisresearchthereareanumberofdecisionsthatneedstobetakenrelatedtothedetailedrequirementsonthedevelopedtool.Itiscrucialtotaketherightdecisionsconcerningwhatfunctionalitytoincludeinthetool.Thisisachievedbydevelopingthetooliteratively.Differentversionsaredevelopedaftereachother,andeveryversionisevaluatedinordertodecidewhatadditionalfunctionalitytoincludeinthenextversion.Evaluationsareaveryimportantpartofthedevelop-mentofthetool.TheevaluationsarebeingcarriedouttogetherwithotherpartnersintheMARTESproject,inthecontextofcasestudiesinindustrialprojects.InthispaperwepresenttheworkandresultsfromdevelopingthefirstversionofourUMLtoSystemCcodegenerator.WestartwithasummaryofrelatedworkinSection14.2.WecomparetheconstructsandsemanticsofUMLandSystemCinSection14.3.BasedonthiscomparisonwehavedevelopedasetofmappingruleswhicharedetailedandmotivatedinSection14.4.OurimplementationofthemappingrulesispresentedinSection14.5andpracticalexperiencecanbefoundinSection14.6.FinallythepaperisconcludedinSection14.7.14.2RelatedWorkEarlierpublicationsonUMLtoSystemCmapping[4,7]suggestthat,toalargeextent,thereisaonetoonerelationbetweenconceptsinthetwolanguages.ForexampleaUMLclassismappedtoaSystemCmodule.Thisisnotalwaysdesira-ble,sometimesUMLclassesareusedfordataencapsulationandinthesecasestheyshouldremainasclassesintheSystemCmodel.OnlyUMLclasseswithports,and/orwitharchitectureshouldbemappedtoSystemCmodules.Riccobeneetal.[7]addressthisbyexposingallSystemCdetailsintheUMLmodelthroughaSystemCprofile.TheirapproachistouseUMLasanimplementa-tionlanguageforSystemC.InadditiontomakingallstandardSystemCtypesavail-ableattheUMLleveltheyalsoextendactionsinstatemachinestohandleSC_THREADandSC_METHODsynchronization.Withtheirapproach,theengi-neersmusttagtheirUMLmodelbyaddingrelationstotheintendedSystemCele-ments.Thisissimilartothelastpartinourdesignprocess.InourdesignprocessengineersstartwithanabstractUMLmodel,whichisrefinedinthreesteps.ThisisfurtherexplainedinSection14.5.Onedifferencecomparedtotheirworkisthatweintendtoautomatemostofthispartinourprocess,minimizingthedesigneffort.AnotherproblemwithbringingtoomanyoftheSystemCdetailsintotheUMLmodelisthesemanticdifferencesbetweenthelanguages,asdiscussedinSection2www.telelogic.com 14UMLandSystemC20114.3.Thiswillleadtoproblemsduringco-simulationofpureUMLmodelswithmodelsapplyingtheSystemCprofile.Itwillalsobeproblematictogeneratecodefordifferenttargets,i.e.hardwareandsoftware.Asfarasweknownoonehaspub-lishedasemanticcomparisonofthesetwolanguages.14.3LanguageComparisonInthissectionwecomparetheUMLandSystemClanguages.ThecomparisonisbasedonUML2[1,6]andSystemC2.2[2,3].ThepurposeofthecomparisonistofindandmotivatemappingrulesforautomaticSystemCcodegenerationfromUML.Thefocusisonconceptswhichareequivalentinbothlanguagesaswellasconceptsandconstraintswhichareonlypresentinoneofthetwolanguages.WhenwerefertoconceptswhicharesimilarinbothlanguagesweusethenotationUMLname/SystemCname,forexampleclass/module.Alsowerefertoaclasswhichinheritsfromsc_moduleasaSystemCmoduleandanyclassinheritingfromsc_interfaceasaSystemCinterface.14.4CompositionUMLandSystemCaresimilarfromastructuralpointofview.Bothlanguageshavetheconceptsofpackage/namespacewhichcanbeusedtogroupmostotherlan-guageconstructs.Inrealmodelspackages/namespacesaremainlyusedtogroupdeclarationsofclasses/modules.Apackage/namespacecannotbeinstantiated.Anyinstantiationsdoneinapackage/namespacewillresultinoneinstanceinthesys-tem,withlimitedvisibilitytothepackage/namespace.InthispaperwefocusthediscussionaroundthesmallsystemshowninFigs.14.1and14.2.GameIPingPing<>IPingp1signalPing(Integervalue)IPongIPongPong<>p2IPongsignalPong(Integervalue)IPingFig.14.1StructureinaUMLdesign 202P.Andersson,M.HöstFig.14.2CommunicationinaUMLdesignping:Pingpong:Pongp1p2WewilllatershowtheSystemCcodegeneratedfromit.Inthissystemthepack-ageGameencapsulatesthedeclarationsoftheclassesPingandPongaswellastheinterfacesIPingandIPong.ASystemCmoduleisverysimilartoaUMLclass.InfactaSystemCmoduleisdefinedasaC++classwithsomepredefinedmethodsandattributes.ThusaSystemCmodulecanhaveattributesandmethodsandalsoitcaninheritfromoneormoreclassesand/ormodules.ThereareafewpropertieswhichcanbeassignedtoaUMLclasswhichcannotbeexpressedintheSystemClanguage.Onesuchisabstract,butthiscanbeemulatedbymakingoneofthemethodsintheclassabstract.WebelievetheminorlimitationsofaSystemCmod-ulearenegligibleinpracticaluse,sowetreatUMLclassesasequivalenttoSystemCmodules.BothUMLclassesandSystemCmodulescancontainrefer-encestootherobjectsmakingitispossibletocommunicatebetweenclassesbymethodcalls.Thisishowevernottheintendedmeanstomodelcommunicationinneitherlanguage.Insteadcommunicationshouldpassthroughportsconnectedusingconnectors/channels.Aportispartofanclass/moduleanddefinesitscom-municationinterface.InUMLaporthasarequiredandarealizedinterfaceindicat-ingwhichsignalsitwillsendandreceive.BoththerequiredandrealizedinterfacecanbecomposedofalistofUMLinterfaces.Sometoolsalsoallowsignallists.InSystemCasc_portmusthaveexactlyoneSystemCinterface.Theinterfacedetailswhichmethodsthemodulewillcallontheconnectedchannel.ASystemCportcorrespondstotherequiredinterfaceofaUMLport.TheequivalentoftheUMLrealizedinterfaceisaSystemCsc_export.ASystemCsc_exportispartofamoduleandhasexactlyoneinterface,whichdetailsthecallsthemodulewillimplement.14.5CommunicationThewaycommunicationiscommonlymodeledisquitedifferentinUMLandSystemC.InUMLcommunicationismodeledusingsignals,asynchronousmessagesthatcancarrydata.Thesignalsaresentthroughtheportsofaclass.Thedestinationofasignalisdeterminedbytheconnectorsofthemodel.InFig.14.2,anysignalsentfromtheobjectpingwillbeforwardedtotheobjectpong.Atthereceivingobjectthesignalisstoredinaqueue,fromwhereitlaterwillbeconsumedbythebehaviorofthisclass.AUMLconnectoronlyprovidesroutinginformationforsignals,itdoesnotmodelthecommunicationmechanism,i.e.anetworkorabus.Ifthisistobeincludedinthemodelitmustbedoneusingclasses.NotealsothataUMLconnectorsareprimarilyarelationbetweentwoobjectsandnotbetweenclasses.AUMLportcanhaveseveralconnectors,andaconnectorconnectsexactlytwoports.SystemCchannelsareacentralpartofcommunicationmodelinginSystemC.Theyimplementthebehaviorofthecommunicationmechanism,asfollows.During 14UMLandSystemC203initializationeachportisconnectedtoachannel.Atthistimetheportsavesarefer-encetothechannel.Laterduringsimulationtheportswillbetransparent,forward-inganyoperationtothechannel(thisisdonebyoverridingthe–>operation).Thisdesignimpliessomeconstraints;aportmayonlyconnecttoachannelwhichimple-mentitsinterface,andalsoaportcanonlyconnecttoonechannel.Bydefaultthereisnolimittohowmanyportsthatcanconnecttoachannel,butitispossibleforachanneltolimitthenumberofportsconnectingtoit.Sinceamessagesendingisrealizedasamethodcallinachannel,itisnotpossiblefortwomodulestocom-municatewithoutanintermediatechannel.AlsoSystemCdoesnotallowportstobeusedtomakemethodsinamoduleavailabletoothermodules.Forthispurposesc_exportwasaddedtothelanguage.Usingsc_exportamodulecanencapsulateachannelandexportitsinterfacetoothermodules.Thismakesitpossibleforasc_portinonemoduletoconnecttoasc_exportinanothermodulewithoutcreatinganyintermediatechannel.14.6MappingRulesConsideringthedifferenceincommunicationmodelingitisclearthattheredoesnotexistatrivial,onetoonemappingfromUMLtoSystemC.SomeUMLcon-structsarehoweversosimilartoSystemCthatwesuggestthattheyshouldbereplacedwiththecorrespondingSystemCconstructduringthemappingprocess.Table14.1listssomeoftheseconstructs.WebaseourSystemCcodegeneratortoalargeextentonTelelogic’sC++codegenerator[8].ThisispossiblesinceSystemCisalibraryandasimulationengineimplementedontopofC++.Theimplementa-tionofourcodegeneratorisexplainedfurtherinSection14.5.InthissectionwefocusonthemappingrulesthatareuniqueforSystemCandreferto[8]fordetailsregardingmappingofthepartsoftheUMLlanguagenotcoveredhere.TheasynchronouscommunicationofUMLsignalsimpliesthattheremustexistamessagequeuesomewhereinthecommunication.InUMLthisislocatedinthereceivingclass.WhencomparingtothepredefinedchannelsinSystemC,sc_fifocomesclosest.However,therearesomelimitationswhichmakeitlesssuitable.First,inaUMLstatemachineitispossibletowaitforoneofseveralsignals,i.e.severaltransitions,withdifferenttriggers,fromthesamestate.Whenthestatemachineisinsuchstate,thetriggeringsignalsmightarriveondifferentports.Thisleadstotheneedtodoblockingreadsonseveralfifoqueuesatthesametime.Table14.1MappingrulesforequivalentconceptsUMLSystemCPackageNamespaceActiveclasssc_moduleClasswithportssc_moduleOtherclassesC++class 204P.Andersson,M.HöstThisisnotpossible.InSystemCitispossibletowaitforoneofseveraleventstooccur,butwhenthecalltowaitreturnsitisnotpossibletodeterminewhicheventthatactuallyoccurred.TheconceptofeventsinSystemCissimilartothewait()andnotify()synchronizationmechanismfoundin,forexample,Java.Thesecondprob-lemwithsc_fifoisitslimitationtoconnectonlyonesenderandonereceiver.ThisisthesameconstraintasaUMLconnector.TheproblemisthatseveralUMLcon-nectorscanconnecttothesameport,butaSystemCportcanonlyconnecttoonechannel.AUMLconnectordoesnotprovideanymessagequeue;insteaditcon-nectsthesendingportwiththequeueinsidethereceivingclass.ThishasthesamesemanticasconnectingaSystemCporttoachannel,assumingthatthechannelwillprovideamessagequeue.TheobservationthataUMLconnectorhasthesamesemanticasconnectingaSystemCporttoachannelisonemotivationforourmapping.WemapaUMLcon-nectortocodewhichconnectsthesendingmodulesportwiththechannelcontain-ingthemessagequeueofthereceivingmodule.Forthistowork,weneedachannelwhichimplementsamessagequeueandallowsmultipleconnectingsenders.Also,tosolvethefirstproblemwithsc_fifo,thisqueueshouldbesharedamongallportsofthereceivingmodule.ThereisnoSystemCchannelwhichmeetstheseneeds,sowegenerateoneforeachgeneratedSystemCmodule.Thechannelwillhandleallincomingsignalstothemodule.ThestructureofageneratedSystemCmoduleisshowninFig.14.3.Themoduleiscomposedofoneormorethreads,onechannel,andoneormoreportsand/orexports.Whenamessagearrivesatasc_export,amethodinthechannelwillbeinvokedandthemessagewillbestoredinthechannelsmessagequeue.Thethreadsinthemodulewilllaterconsumethemessageusingthechannelsblockingread()method.Thethreadscanalsosendmessagesthroughasc_port.Amessagesentthroughasc_portwillarriveatasc_exportofanothermodule.Table14.2liststheUMLsourcesfordifferentSystemCconstructs.Howwegener-atethecomponentsoftheSystemCmodulewillbedetailedbelow.ForeachrealisedinterfaceoftheUMLclasswegenerateonesc_exportandconnectittothemodulessc_modulesc_portSC_THREAD...sc_portread()sc_channelsc_export...messagequeuesc_exportFig.14.3ThestructureofageneratedSystemCmodule 14UMLandSystemC205Table14.2ThetablelistsSystemCpartsandtheUMLconstructstheyarecreatedfromSystemCpartUMLsourcesc_portPort,requiredinterfacesc_exportPort,realizedinterfacesc_channelInterface,signalsc_interfaceInterface,signalconstructorofsc_modulePort,channel,statemachine.AttributeinitializationhavemoresourcesSC_THREADStatemachine1Pingping("Ping");2Pongpong("Pong");3ping.p1_port(pong.p2_export);Fig.14.4Codegeneratedfrom4pong.p2_port(ping.p1_export);Fig.14.2channel.Thechannelimplementsallrealizedinterfaceswithonemethodforeachsignal.Themethodstorestheparametersofthesignalinthechannelsmessagequeue.ThisqueueisimplementedusingaC++std::deque.Thechannelalsoprovidesanblockingread,usedbythemodulesthreads,i.e.themethodsgeneratedfromthestatemachineoftheactiveUMLclass.Toclarify,letuslookatanexample.TheUMLdiagraminFig.14.2willgeneratetheSystemCcodeshowninFig.14.4.Inthefirsttwolinesthemoduleinstancesarecreated.Linesthreeandfourconnecttheportsandexportsofthegeneratedmoduleinstances.LinesthreeandfouraregeneratedfromtheUMLconnector.Commonlylineoneandtwowillbeattributesinamoduleandlinethreeandfourwillbepartofthatmodulesconstructor.NextwewillexaminetheSystemCdeclarationofmodulePing,showninFig.14.5.ThisoriginatesfromtheUMLviewin.TheUMLportp1ismappedtoasc_portandasc_exportatline3–4.TheinterfacesIPingandIPongaregeneratedfromtheUMLinterfaces.Thismappingisdetailedbelow.Lines6–16containthedeclarationoftheSystemCchannel,whichcontainsthemessagequeueofthePingmodule.Thechannelisinstantiatedatline17.ThemethodPingatline15origi-natesfromtheUMLsignalPingandispartoftheIPinginterfaceinheritedatline8.Theimplementationisonlines21–26.Atline30,intheconstructorofPing,p1_exportisboundtothechannelinstancePing_channel.WiththegeneratedcodeFigs.14.4and14.5,themoduleinstancepongcansendaPingsignalcarryingthevaluethree,usingthesyntaxp2_port->Ping(3).14.7InterfacesandSignalsThemappingofUMLclasses,portsandchannelsdetailedaboveisnotenoughtogeneratecodewhichcompile.TheSystemCinterfacesanddatastructuresforstor-ingsignalsinthemessagequeuearemissing.ThesearegeneratedfromtheUML 206P.Andersson,M.Höst1SC_MODULE(Ping){2public:3sc_exportp1_export;4sc_portp1_port;5/*---channel---*/6classChannel_class:7publicsc_channel,8publicIPing{9private:10std::dequequeue;11sc_evente;12public:13Channel_class(sc_module_namename);14UML_signal*read(;)15voidPing(intvalue);16;}17Channel_classPing_channel;18/*---statemachinebehavior---*/19voidPing_thread(;)20;}21voidPing::Channel_class::Ping(int22value){23ueue.push_bqack(new24Ping_signal(value);)25e.notify(;)26}27Ping(sc_module_namename):28sc_module(name),29Ping_channel(Ping_channel""{)30p1_export(Ping_channel);31SC_HAS_PROCESSPing)(;32SC_THREADPing_thread)(;33}Fig.14.5CodegeneratedfromFig.14.1A,BA,CM2M3ppM1Fig.14.6UMLclasseswithpA,B,Cinterfacelistsinterfacesandsignal.ForeachUMLinterfaceaSystemCinterfacewillbegener-ated.ThegeneratedinterfacewillcontainonemethodforeachsignalintheUMLinterface.Themethodwillhavethesameparametersastheoriginalsignal.Inaddi-tiontothemethodeachsignalwillalsogenerateaclasswithoneattributeforeachsignalparameter.ThecodegeneratedfromtheUMLinterfaceIPinginFig.14.1isshowninFig.14.6. 14UMLandSystemC2071classIPing:publicsc_interface{2public:3virtualvoidPing(intvalue)=0;4classPing_signal:publicUML_signal{5public:6intvalue;7inlinePing_signal(intvalue):8value(value)}{9;}10;}Fig.14.7CodegeneratedfromFig.14.1InSystemCaportandexportcanonlyhaveoneinterfaceandforaporttocon-necttoanexport/channelitsinterfacemustbeimplementedbythechannel.NowlookatFig.14.7.UMLportM1::phasthreerealisedinterfacesA,B,C.PortsM2::pandM3::phaverequiredinterfacesA,BandA,C.PortM1::pwillbemappedtoanSystemnCexportwhileM2::pandM3::pwillgenerateSystemCports.Thegeneratedexportandportsneedoneinterfaceeach,herenamedif1,if2,andif3.AtrivialattemptwouldbeforthegeneratedinterfacestoinheritdirectlyfromfromA,BandC,i.e.classif1:A,B,C{},classif2:A,B{},andclassif3:A,C{}.Nowneitherif2norif3isasubtypeofif1andtheportscannotconnecttotheexport.Aworkingsolutionisforif1toinheritformif2andif3.Butnow,duetothedoubleinheritance,if1willcontaintwoinstancesofA.Also,withthismappinganexportsinterfacewillchangeasportsconnecttoitmakingitunpracticaltogeneratecodeforpartsofasystem,ortodistributeIP-coresinbinaryform,sincetheyneedtoberecompiledwhenused.TosolvethiswesuggestthatoneUMLportshouldbemappedtoseveralSystemCports,oneforeachinterfaceitrequires.Thelistofrealizedinterfacescanstillbemappedtooneexportwithoneinterface,i.e.classif1:A,B,C{}.WiththismappingM2willhavetwoports,oneforinterfaceAandoneforB.Bothcancon-necttoM1::p.ThissolvestheproblemsmentionedabovewhilepreservingthetypehierarchyamonginterfacesintheUMLmodel.14.8MappingProcessDuringinitialsystemmodeling,apureUMLmodelisused.ThoughitispossibletodefineasetofmappingrulesfromapureUMLmodeldirectlyintoSytemsCcode,itwouldgivetheengineerlittleinfluenceonthemappingandmostlikelyalesssatisfactoryresult.Insteadwedividethemappingintothreesteps,asdepictedinFig.14.8.llmodelsareavailableandeditable.Thismakesitpossiblefortheengineertohavefullcontrolovertherelevantdetailsforthesystemunderdevelopmentandhavethetoolmanageallremainingdetails. 208P.Andersson,M.HöstFig.14.8OurthreestepcodegenerationUML,pureUML,SystemCprofileUML,SystemCexplicitSystemCStep1,verticalrefinementtransformation:InthisstepaninitialUMLdescrip-tionisrefinedtoaUMLdescription,whichfollowsaUMLprofileforSystemC.Thisstepwill,atleastpartly,becarriedoutmanually.Tominimizethedesigneffortitshouldnotberequiredtotagthewholemodel.ThismeansthatasetofdefaultvaluesfortheSystemCspecificattributesoftheUMLprofile,mustbedefined.Thedefaultvalueswillinmostcasesprovideasatisfactorymappinginthefollowingtransformationsteps.Step2,verticalrefinementtransformation:InthisstepthemodelistransformedintoanewUMLdescriptionthatonlyincludesUMLconstructswithdirectrepresen-tationsinSystemC,i.e.classes,attributes,inheritance,etc.Otherconstructssuchasstatemachinesaretranslatedtothetargetlanguage.Duringthisstepwetransformeachstatemachinetoaclasswithmethodsthatimplementthebehaviorofthestatesandtransitions.Inthefirstversionofthetool,theresultingmodelwillbeaun-timedfunctionalmodel.ThemappingrulesforUMLclasses,ports,channels,signalsandinterfacesaregiveninSection14.4.AcompletelistofUMLconstructswhichareremovedduringthistransformationisbeyondthescopeofthispaper.InadditiontoremovingUMLonlyconcepts,wealsomakeallrelationsinthemodelexplicit.WhenaclassismadeactiveinUMLitimpliesthattheclasswillhaveitsownthreadofexecution.InSystemCthisisrealizedusingSC_THREADorSC_METHODwhichimpliesthattheclassisaninstanceoftheSystemCclasssc_module.Duringthistransformationallsuchimplicitrelationsaremadeexplicit.Forexample,weaddageneralizationrelationtotheSystemCclasssc_modulefromallactiveUMLclasses.Inthefirstversionofthetooltheresultingmodelisaun-timedfunctionalmodel.Step3,horizontaltransformation:InthissteptheUMLmodelresultingfromstep2istransformedintoacorrespondingSystemCcode.ThistransformationisaonetoonecorrespondencebetweentheUMLmodeltotheresultingSystemCcode,i.e.thisisa“prettyprint”oftheUMLmodel.ThisstepisimplementedusingtheexistingC++codegeneratorfromTelelogicandthusreuseitssupportforscoperules,header-fileinclusionandmakefilegenerationwithoutanymodifications.IfthegeneratedcodeistobereadbyhumansitisdesirabletousethecommonSystemCmacroswhenapplicable.Thisrequiresaslightcustomizationofthesyn-taxofthegeneratedcode.Wedothisusinganagent,amechanismwhichmakesitpossibleforthirdpartyexecutablestointeractwiththeC++CodegeneratorinTelelogicTauG2.OuragentgeneratesSystemClikemoduledeclarations,insteadofaC++classdeclarations,SC_MODULE(MyModule){…}insteadofclassMyModule:publicsc_module{…}. 14UMLandSystemC20914.9ExperimentalValidationThemappingrulesandcodegeneratorpresentedinthispaperhavebeenusebyVTTtoextendtheirworkload-basedperformancesimulation[5].TheautomaticmappingfromUMLtoSystemCmakesitpossibletopartiallyreuseexistingUMLapplicationmodels,removingtheneedforseparateworkloadmodels.VTTsexpe-rienceisthatourSystemCcodegeneratorisusefulinpracticeandsimplifiestheengineersworkintheirmodelbaseddesignflow,see[5].14.10ConclusionsCombiningnewmethodologiesandnewlanguagesisapromisingapproachtoover-cometheincreasedcomplexityoftoday’sembeddedsystems.ThisisthedrivingforceintheMARTESproject.InthispaperwecompareUMLandSystemC.Thecomparisonrevealsthatthecommunicationismodeledquitedifferentinthetwolanguages.BasedonourobservationswepresentmappingrulesforautomaticSystemCcodegenerationfromaUMLmodel.Wealsopresentourtransformationtechnique,composedoftwoverticalandonehorizontaltransformations.Usingourtransformationtechniqueitispossibletoreuselargepartsofacodegeneratorforothertargetlanguagessimilartothetargetlanguagesofthecodegenerator,i.e.theimplementationofourSystemCcodegeneratorusesalargepartofTelelogic’sC++codegenerator.References1.Eriksson,H.,Penker,M.,Lyons,B.,Fado,D.:UML2Toolkit.OMGPress,Indianapolis,IN(2004)2.Grötker,T.,Liao,S.,Marin,G.,Swan,S.:SystemDesignWithSystemC.Kluwer,Norwell,MA(2002)3.IEEE:IEEEStandardSystemCLanguageReferenceManual.IEEEStandard1666–2005(2006)4.Nguyen,K.D.,Sun,Z.,Thiagarajan,P.S.,Wong,W.:SystemdrivenSoCDesignViaExecutableUMLtoSystemC.Real-TimeSystemsSymposium(2004)5.Kreku,J.,Hoppari,M.,Tiensyrjä,K.,Andersson,P.:SystemCWorkloadModelGenerationfromUMLforPerformanceSimulation.ProceedingsofForumonspecificationandDesignLanguages(FDL)(2007)6.Piltone,D.,Pitman,N.:UML2.0InaNutshell.O’ReillyMediainc.,1005GravensteinHighwayNorth,Sebastopol,CA95472(2004)7.Riccobene,E.,Scandurra,P.,RostiA.Bocchio,S.:ASoCDesignMethodologyInvolvingaUML2.0ProfileforSystemC.DesignAutomationandTestEurope(DATE)(2005)8.Telelogic,POBox4128,Kungsgatan6,SE-20312Malmö,Sweden:C++ApplicationGeneratorReference Chapter15AnEnhancedSystemCUMLProfileforModelingatTransaction-LevelS.Bocchio1,E.Riccobene2,A.Rosti1,andP.Scandurra2AbstractThischapterdescribesaUML2profilefortheSystemClanguage,whichtakesintoaccountthelanguageimprovementsasspecifiedintheIEEE1666SystemCStandardandeffectivelyprovidedintheSystemC2.2simulatorasfoundationforTransaction-LevelModeling(TLM).Theprofileisasetofmod-elingconstructswhichliftboththestructuralandbehavioralfeaturesofSystemCtoUMLlevel.Itispartofamodel-drivenHW-SWco-designmethodologybasedontheUML2,aSystemCUMLprofilefortheHWside,andamulti-threadedCUMLprofilefortheSWside,whichallowsmodelingofthesystemathigherlevelsofabstraction(fromafunctionalexecutableleveltoRegisterTransferLevel)andsupportsautomaticcode-generation/back-annotationfrom/toUMLmodels.KeywordsEmbeddedsystems,system-leveldesign,SystemC,UML,UMLprofiles15.1IntroductionToincreasethedesignproductivityandtackletheevergrowingsystemcomplexity,theElectronicDesignAutomation(EDA)communitiesarepushingashiftindesignentrylevelfortheEmbeddedSystems(ES)andSystemsonChip(SoC)develop-ment.Newmoreabstractdesignmethodologiesandlanguages–farbeyondthecapabilitiesofexistingHWdescriptionlanguages,likeVHDLandVerilog,operat-ingatthelowRegister-Transfer-level(RTL)–areneededinordertohandleadesigntaskwhichshouldallowtheconvergenceofbothHWandSWfacets,aswellasbetterreuseandintegrationofpre-designedcomponents(theIntellectualProperties).1STMicroelectronicsR&I,AgrateBrianza,Italy;Email:{sara.bocchio,alberto.rosti}@st.com2UniversityofMilan–DTI,Crema,Italy;Email:{riccobene,scandurra}@dti.unimi.itE.Villar(ed.)EmbeddedSystemsSpecificationandDesignLanguages,211©SpringerScience+BusinessMediaB.V.2008 212S.Bocchioetal.Recently,theUnifiedModelingLanguage(UML)[15]anditsextensionmecha-nismisreceivingsignificantinterestinthehardwarecommunity,sinceitallowsUMLcustomizationtowardsthedefinitionofafamilyoflanguagestargetedtospecificapplicationdomains(telecommunications,aerospace,realtimecomputing,automotive,System-on-Chip,etc.)andlevelsofabstraction.ThisisconfirmedbyseveralstandardizationactivitiescontrolledbytheOMG,suchas:theSchedulability,Performance,andTimingAnalysis(SPT)profile[17];therecentUMLforSoCForum(USoC)[18]inJapanfoundedbyFujitsu,IBM/Rational,andCATStodefineasetofUMLextensionstobeusedforSoCdesign;theSysMLproposal[24]whichextendsUMLtowardstheSystemsEngineeringdomain,andtheMARTE(ModelingandAnalysisofReal-TimeEmbeddedsystems)initiative[16].Alongthesameresearchline,wecanmentiontherecentmodel-drivenHW-SWco-designmethodologyin[2,5].AccordingtotheemergingModelDrivenEngineering(MDE)approach,anewdesignflowisproposedforESdevelopment.ItisbasedontheUML2.0tobeusedinaplatform-independentmannertoprovideafirsthigh-levelfunctionalspecificationofthewholesystem,aSystemCUMLprofiletobeusedfortheHWdescriptionatseveralabstractionlevelsontopoftheRTLlevel,andamulti-threadedCUMLprofiletospecifytheSWapplication.Moreover,tofosterthismethodologyinasystematicwayandcombinealltheinvolvednotationstogetherinaseamlessmanner,in[6]adesignprocess,calledUPES(UnifiedProcessforEmbeddedSystems),isdefinedbyextendingthecon-ventionalUnifiedProcess(UP)ofUML,togetherwiththeUPESsub-process,calledUpSoC,forrefiningtheHWplatformmodel.Furthermore,aHW/SWco-designenvironment[4]wasdevelopedontopoftheUMLvisualmodelingEnterpriseArchitect(EA)tool[9],toassistthedesigneracrosstherefinementstepsintheUMLmodelingactivityregardingtheHWpart,fromahigh-levelfunctionalmodelofthesystemdowntotheRTLlevel,andsupportsforwardandreverseengi-neeringofC/C++/SystemCcode.TheSystemCUMLprofile[6,25]isthekeypointofthismodel-drivenco-designmethodologyforES.Itisaconsistentsetofmodelingconstructswhichliftboththestructuralandbehavioralfeatures(includingprocesses,eventsandtimefeatures)ofSystemCtoUMLlevel,whileprovidingunificationintheoverallUMLmodelingactivity.ThislaststartsfromthedefinitionofanabstractUMLmodel(orPIM–platformindependentmodel)describingthegeneralfunctionalityofthesys-tem,andcontinueswithsubsequentrefinementsofthePIM(orofportionsofit)intoplatformspecificmodels(orPSMs)throughasequenceofmodeltransforma-tions.FortheHWcomponents,thissequenceofPSMsgoesfromahighlevelfunctionalun-timed/timedmodelofthesystemdowntoatransaction-levelmodel,toabehavioralmodel,toabus-cycleaccurate(BCA)model,toafinalRTLmodelforthesynthesisofanend-productintegratedintoachip.TheUMLprofileforSystemCallowsusingUMLatPSMlevel,providesunificationbetweenPIMandPSMs,andallowsautomaticencodingofPSMsintofinalSystemCcode.ThechoiceofSystemCasimplementationlanguageisintentional,andmainlyduetothefactthatSystemCisbecomingoneofthemostimportantsystem-levellanguagesforSoCdesign.In2006,SystemCreceivedamajorrevision(2.2)and 15AnEnhancedSystemCUMLProfileforModelingatTransaction-Level213becameIEEEStandard[5].Thislastrevisionincludesnewstructural(sc_exportandsc_event_queue)andbehavioral(dynamicprocesses,fork/joinsynchroni-zation,etc.)featuresrequiredformodelingattransaction-levelaccordingtotheOSCI[19]standardTLM1.0API.ToaligntheSystemCprofilewiththestandardIEEE[25]andsupportrefine-menttowardsimplementationinSystemC2.2accordingtotheOSCITLMstand-ard,theSystemCUMLprofiledescribedin[1]hastobereviewed.Inthischapter,wepresentaUML2profilefortheSystemC2.2release.Itextendstheprofilein[6,25]withthenewimprovementsspecifiedintheIEEE1666SystemCStandard.ThestructuralfeaturesoftheSystemCUMLprofilein[1]havebeenextendedincludingthenewfeaturesofportsconnectionandeventqueuehandling,whileforthebehav-ioralpart,weextendtheSystemCProcessStateMachines(anextensionoftheUMLstatemachineformalismintroducedaspartoftheSystemCprofiletomodelthereactiveandconcurrencybehaviorofSystemCprocesses)withthenewenhancementsinSystemC2.2fordynamicprocesses,i.e.processescreatedatrun-timeaschildrenprocessesofrunningprocesses.ThislastextensionrequiredtofixsomeUMLstatemachinessemanticvariationpointstocapturetheoperationalsemanticsofthedynamicSystemCprocesses.ThisnewprofileallowsformodelingatTransaction-Level(TLM)ofabstractionwiththeOSCITLM1.0library.Moreover,accordingtothereviewedversionoftheprofile,thecodegeneratoroftheHW-SWco-designenvironmentin[4]hasbeenupdatedtoguaranteestraight-forwardgenerationofefficientSystemC2.2codefromdiagrammaticalUMLmod-elsdevelopedbyusingtheSystemCprofile.Theremainderofthischapterisorganizedasfollows.Section15.2sketchessomefundamentalsoftheSystemC2.2languageassumingthereaderfamiliarwiththeSystemClanguage.Section15.3introducesbasicconceptsunderlyingtheSystemCUMLprofilealongwiththeenhancedstructuralandbehavioralfeaturesoftheprofile.Section15.4describesthecodegenerationfacilityfordiagrammati-calmodelsdevelopedusingtheSystemCUMLprofile,whileSection15.5presentssomecasestudies.RelatedworkandconclusionsaregiveninSections15.6and15.7,respectively.15.2SystemCBackgroundTheSystemClanguageisanopenstandardthatisimposingasthereferencelan-guageinESL(ElectronicSystemLevel)design;itiscontrolledbytheOSCIgroup[19]madeofdifferentcompaniesintheEDAarea.SystemCisdefinedintermsofaC++classlibraryformodelingintermsofC++programs,andprovidesanevent-basedanddiscrete-timedsimulationkernel.SystemCprovidesconstructsformodelingthesystemstructure(sc_moduleandsc_channel),thecommunication(sc_port,sc_interface,sc_event),theconcurrentbehaviorthroughprocesses(sc_methodandsc_threadprocesses)andasetofdatatypesforhardwaredata. 214S.Bocchioetal.In2006,SystemCreceivedamajorrevision(2.2)andbecameIEEEStandard[25].Thislastrevisionincludesnewstructuralfeatures(sc_exportandsc_event_queue)andbehavioralfeatures(dynamicprocesses,fork/joinsynchroni-zation,etc.)requiredformodelingattransaction-leveltowardshardware-softwareimplementationaccordingtotheOSCITLMstandard.SystemChasbeeninvolvedintoseveralSoCdesignflowsatindustriallevel,exceeding,foritsexpressivity,thecapabilitiesoftraditionalHardwareDescriptionLanguages(HDLs).Itpermitstodesignatsystemlevelsupportingdifferentabstractionlevels(un-timed/timedfunctional,TLM,behavioral,BCA,andRTL),thusallowingdesignrefinementinauniquemodelingenvironment.15.3TheSystemCUMLProfileAUMLprofileistobeintendedasadialectoftheUMLforaparticularplatformorapplicationdomain.TheUMLprofilesmechanismisastandardwayofcustomizingtheUMLbyaddingasetofstereotypes,tagsandconstraints.StereotypesdefinehowthesyntaxandthesemanticsofanexistingmetaclassoftheUMLmetamodelareextendedforaspecificdomainterminologyorpurpose.Tagvaluesareuser-definedpropertiesofastereotypetoaddfurtherattributestotheextendedmetaclass.ConstraintsareexpressedasformulasintheObjectConstraintLanguage(OCL)andservetoaddstaticsemanticrestrictionstotheextendedUMLmodelingelement.Fordefiningprofiles,UML2isendowedwithastandardgraphicalnotationwhichiseasilysupportedbyUMLvisualmodelingtools.Aprofileisdenotedasapackagewiththekeyword«profile».Withintheprofilepackage,aclassoftheUMLmetamodelthatisextendedbyastereotypeislabeledasaconventionalclasswiththekeyword«metaclass».Astereotypeisdenotedasaclasswiththekey-word«stereotype».Theextensionrelationshipbetweenastereotypeandametaclassisdepictedbyanarrowwithasolidblacktrianglepointingtowardthemetaclassbox.WhenappliedtoanelementinaUMLmodel,astereotypeisshownasakeywordconsistinginthenameofthestereotypewithinapairofguillemets,nearthesymboloftheUMLelementorwithaspecialicondefinedforit(ifany)inplaceoftheconventionalsymbolfortheelement.AUML2profileforSystemC2.0alreadyexists[1].Inthenexttwosections,anextensionofthisprofileispresented(weassumethereaderfamiliarwithSystemC2.0)inalightweightmannerbydescribingsomenewstructuralfeatures(sc_exportandsc_event_queue)andbehavioralfeatures(dynamicprocessesandfork/joinsynchronization)capturingthesemanticsasspecifiedintheIEEE1666SystemCstandardandimplementedintheSystemC2.2executionengine[5].ThisextensionisdictatedbythenecessitytoaligntheprofiledefinitionwiththestandardIEEE[5]inordertoincludethenewSystemCconstructsformodelingsystems,communication,hardwareandsoftwareatthetransaction-level,andsup-portingrefinementtowardshardware-softwareimplementationaccordingtotheOSCITLMstandard. 15AnEnhancedSystemCUMLProfileforModelingatTransaction-Level21515.3.1EnhancedStructuralFeaturesInSystemC2.2,aport(sc_port)maybeboundtoachanneleitherdirectly,orindirectlybybeingboundtoanotherport(accordingtoaparent-to-childmodulerelationship)ortoasc_exportport(export,inbrief).Figure15.1showsthesc_portandsc_exportstereotypes.Notethat,afurthertagpolicy(anelementoftheenumerationtypesc_port_policy)hasbeenaddedtothesc_portstere-otype;itisusedtodeterminetherulesforbindingmulti-portsandtherulesforunboundports,asspecifiedinthenewSystemCversion.Anexportdefinesasetofservices(asidentifiedbytheinterfacetypeoftheexport)thatareprovidedbythemoduleexposingtheexport.Providinganinterfacethroughanexportisanalternativetoamodulewhichsimplyimplementstheinter-face.Theuseofexplicitexportsexposedbyamoduleinstanceallowsasinglemoduletoprovidemultipleinterfacesinastructuredmanner:theunderlyinginter-facesareimplementedsomewherewithinthemodule,e.g.byachildchannelinstance.Thesc_exportstereotypemapsthenotionofSystemCexportportdirectlytothenotionofUMLport,plussomeconstraints.Anexportportcanhaveexactlyoneprovidedinterface–thetypeoftheexport–andnorequiredinterfaces.Anexportcanonlybeboundtoachannelderivedfromthetypeoftheexportortoanotherexport(providedthatthisexportitselfisdirectlyorindirectlyboundtoachannel)withatypederivedfromthetypeoftheexport.Similarlytothesc_portnotation,anexportportisshownasasmallsquaresymbolwiththeportnameandthekey-word«sc_export»nearby.Alternatively,anexportcanalsobeshownasasmalltriangleiconwiththeportname.Inbothcases,theprovidedinterfaceisshownbyacircleorball,labeledwiththenameoftheinterface,attachedbyasolidlinetotheexportport.Inthenewprofiledefinition,thesemanticsofconnectorssc_connectorandsc_relay_connectorhasbeenextendedinordertorepresentthreenewpos-siblebindings:port-to-export,export-to-channel,andexport-to-export.Tobeprecise,thesc_connectorstereotype,originallyprovidedasextensionoftheUMLconnectortoexplicitlybindaporttoachannel(port-to-channel),nowcanbeusedtodirectlybindaporttoanexportprovidedthattheexportexposestheinterfaceFig.15.1sc_exportandsc_portstereotypes 216S.Bocchioetal.requiredbytheport.Similarly,asc_relay_connector,originallydefinedtorepresenttheparent-to-childportbinding,nowisalsousedtobindanexporttoachannel,andalsotobindanexporttoanotherexport.Bothconnectorsarebinary,i.e.aconnectorspecifiesalinkthatenablescommunicationbetweentwoinstancesonly.AllconnectivityrulesareprovidedintermsofOCLconstraintsdefinedovertheinvolvedclassesoftheUMLmetamodel.Figure15.2showsanexampleofapplicationofthesestereotypesinaUMLclassdiagramtomodelthehierarchicalstructureofaTopmodulemadeoftwosub-modules,CallerandMiddle,con-nectedviaaport-to-exportbinding.Figure15.3showsthesc_event_queuestereotypedefinitiontogetherwiththeoneforthesc_eventstereotype.TheyrepresentSystemCeventsintermsofspecialUMLsignalswhosenotificationgeneratessignalevents(instancesofthe«sc_module»«sc_module»pi_fBottomCallerxp«sc_port»ch:Chan«sc_relay_connector»i_f«sc_export»«sc_module»Middlei_fxpxp«sc_relay_connector»b:Bottom«sc_export»«sc_export»«sc_module»Topc:Callerp«sc_port»«sc_connector»m:Middlexp«sc_export»Fig.15.2Exampleofstructuralmodelingwithsc_esport 15AnEnhancedSystemCUMLProfileforModelingatTransaction-Level217‹‹metaclass››Signal(fromCommunications)basesignal1basesignal1‹‹stereotype››SC_event‹‹stereotype››SC_event_queueFig.15.3sc_event_queuestereotypeclassSignalEventintheUMLmetamodel)tobeputintheinputpooloftheprocessestobeactivated/resumed.Inparticular,thesc_event_queuestereo-typedenotesastructuredsignal,namely,aneventqueuewhichcanhavemultiplenotificationspending.Foraneventqueueonlydelta-cycledelayedandtimednoti-ficationsareallowed.Asc_event_queuecannotbeusedinmostcontextsrequiringasc_eventbutcanbeusedtodefinethestaticsensitivityofprocesses.Themechanismusedtoqueueeventnotificationsshallbeimplementation-defined,withtheprovisothataneventqueuemustprovideasingledefaulteventthatisnotifiedonceforeverynotifyactionfortheeventqueue.Effectiveuser-namedsignalinstancesaredeclaredwiththestereotypekeyword«sc_event»withintheattributecompartmentofamodule’sclassorachannel’sclass.Thelabelforatriggeronastatemachinetransitiondenotingasc_eventsignalmayexplicitlyindicatesthenameofthespecificsc_eventinstancewhosenotificationcausesthetriggeringofthetransition.Thesamenotationisusedforasc_event_queuestructuredsignal.15.3.2EnhancedBehavioralFeaturesProcessesarethebasicmechanisminSystemCforrepresentingconcurrentbehavior.Twokindsofprocessesareavailable:methodsandthreads.Clockedthreadsareaspecializationofthreads.Eachkindofprocesshasaslightdifferentbehavior,butbasicallyallprocesses:runconcurrently,aresequential,andareactivated(iftermi-natedorsimplysuspended)onthebaseoftheirownsensitivity,whichconsistsofaninitiallistofzero,oneormoreevents–thestaticsensitivityofaprocess–andcandynamicallychangeatruntimerealizingthesocalleddynamicsensitivitymechanism.TheSystemCUMLprofiledefinestwoprocessesstereotype«sc_method»and«sc_thread»(see[1]fordetails);bothextendtheOperationandtheStateMachineUMLmetaclasses.Thisdoubleextensionallowsustoassociateanoperationtoitsbehaviorspecifiedintermsofa(method)statemachine.Specialstateandactionstereotypesareaddedtosupportthebehavioralfeaturesmentioned 218S.Bocchioetal.above.ThesestereotypesandtheirassociatedOCLconstraintsleadtoavariationoftheUMLstatemachineformalism:theSystemCProcessStateMachines.Thisformalismallowsmodelingthecontrolflowandthereactivebehaviorofprocesses(methodsandthreads)withinmodules,dealingwithconcurrency,synchronizationandtimingaspects.Aprocessstatemachinecancontainthedefinitionoflocalvariables.Twoparticularstates(initialandfinal)areusedtomodelstartandterminationoftheprocessbehavior.Thebehaviorismodeledbystates,transitions,andactions.StatescancontainsimpleactionsoractivitywhichmustobeythesyntacticrulesandtakethesemanticsoftheC++/SystemClanguage(theactionorsurfacelanguage).ThesemanticsofbasicC/C++controlstructures,likeifconditions,whileloops,etc.,iscapturedintermsofstereotypedchoicepseudostates(seeforexamplethewhileloopinFig.15.4).TheexampleinFig.15.4alsoshowsastatic_wait-stereotypedstate.ItcapturestheSystemCsemanticofawait()statementwithnoarguments.«dont_initialize»RUNNINGdo/load=true;din=0;[else]«white»[true]«static_wait»[dout=_maxcount−1][else]«if»do/load=false;do/load=true;din=0;«endif»Fig.15.4Exampleofthreadprocessstatemachine 15AnEnhancedSystemCUMLProfileforModelingatTransaction-Level219Ingeneral,tomodelthedynamicsensitivitymechanismofathreadprocesstwopossiblewait-stereotypedstatesareavailable(seeFig.15.5):thefirstoneisawaitonthestaticsensitivitylist,thesecondisawaitonadynamicsensitivitylistcharacter-izedbyaneventconditione*.Figure15.6showshowawait(e*)callismodeledinUMLforallpossibleformsoftheevente*:asingletimedevent,asinglesignalevent,asingleeventwithtimeout,anAND-listofsignalevents,an‹‹static_wait››‹‹wait››WAITONSTATICWAITONDYNAMICSENSITIVITYLISTSENSITIVITYLISTe*Fig.15.5StaticanddynamicwaitFig.15.6Dynamicsensitivityofathreadprocess 220S.Bocchioetal.OR-listofsignalevents,AND-listofsignaleventswithtimeout,andOR-listofsignaleventswithtimeout.Similarconstructshavebeendefinedtomodelthedynamicsensitivitymechanismofamethodprocess.WechoosetousethestatemachineswithrespecttootherUMLbehavioraldia-grams(liketheactivitydiagrams)becausethiskindofdiagramprovidesabehavio-ralpatternappropriateformodelingthereactiveandhierarchicalbehaviorofSystemCprocesses,whichcanbeactivatedbytriggeringexternalsynchronizationevents.Moreover,accordingtotheOMGspecification[15],statemachinesaresequentialasfarastheirinternalbehaviorisconcerned,butanystatemachineisconcurrentwithrespecttotheotherstatemachinesofthesystem.Indeed,UMLstatemachinescanbeusedformodelingsimplefunctionsthatexecuteunderthecontrolofprocesses,anditisalsopossibletorepresenttheSystemCsynchroniza-tionmechanismforsuspending/resumingaprocessintermsofstereotypedstatesandevents.WeextendheretheSystemCprocessstatemachinesbyaddingspecializedsubmachinestatesandorthogonalregionswithinastatemachinetomodelthenotionofprocesshierarchyexpressedinSystemCintermsofdynamicprocesses.Adynamicprocessisaprocesscreatedatrun-timeduringexecution,aschildproc-essofamethodprocessorathreadprocess,oraclockedthreadprocess.Adynamicprocesscaninturncreateotherprocessesdynamically.TheSystemC2.2releasesupportsthenotionofdynamicprocessbyintroducingtheconceptofspawnedprocess,i.e.aprocess(achildprocess)createdbyanotherprocess(theparentproc-ess)byinvokingthepredefinedfunctionsc_spawn.IntheSystemcUMLprofile,thedynamiccreationofsuchaprocess–adynamicspawnedprocess-isdenotedinthestatemachinediagramassociatedtotheparentprocessbymeansofasubma-chinestate1labeledwiththestereotype«sc_spawn»(seeFig.15.7forthestereotypedefinition).Thestatemachinereferencedbythesubmachinestatespecifiesthefunctionalityofthatdynamicprocess.Afterthecreationofaspawnedprocess,theparentprocessandthenewchildprocessproceedinparallel,unlessaspecificsynchronizationschemaisexplicitlyprovidedbythedesignerbymeansofnotificationofevents.Thisnaturalasynchro-nismisreflectedatUMLlevelinthestatemachinediagramoftheparentprocessbytheuseoforthogonalregions.Tobeprecise,aprocessstatemachinewhichdynamicallycreatesprocessesisrepresentedbyastatemachinewithtwoormoreregions(seeFig.15.8).Oneregioncontainsthebehaviorspecificationoftheparentprocess,whiletheotherscontainexactlyone«sc_spawn»submachinestateeach.Theoverallprocesscreation(i.e.theinvocationoftheSystemCsc_spawnfunction)isdenotedbyaforkvertexintheparentregionwithtwooutgoingtransi-tions:oneenteringinthe«sc_spawn»submachinestateofthechildprocess,andoneenteringinsomestateoftheparentregiontocontinuethespecificationoftheparentprocessbehavioraftertheprocesscreation.Therefore,thesubmachinestate1InUML,asubmachinestatespecifiestheinsertionofthespecificationofasubmachinestatemachine.Thestatemachinethatcontainsthesubmachinestateisthecontainer. 15AnEnhancedSystemCUMLProfileforModelingatTransaction-Level221«metaclass»State(fromBehaviorStateMachines)0..1baseState«stereotype»sc_spawnsensitive:Stringdont_initialize:Boolean=falsespawn_method:Boolean=falseFig.15.7sc_spawnstereotypesm«thread»my_thread«sc_spawn»child_p1:chils_p1SMdodoinitsomething[true]«while»[else]«sc_spawn»child_p2:chils_p2SMFig.15.8Athreadprocessspawningdynamicallytwoprocesseswithinaninfiniteloop(andthereforeitsreferenceprocessstatemachine)isexclusivelyenteredviaaforkvertexdepartingfromtheparentregion,andcanbeexitedeitherasaresultofreachingitsfinalstate(normalcase)orviaajoinvertexintheparentregion(inthecaseofafork/joinschema,seethelastparagraphbelow).Noentry/exitpointscanbedefinedfora«sc_spawn»submachinestate.Aspecialcaseofsynchronismforthreadprocessesiswhentheparentprocesswantstowaitfortheterminationofachildprocess,forexample,togetanyreturn 222S.Bocchioetal.valuesfromthechildprocessexecutionandthenresumesandcontinuesitsownexecution.Inthiscase,theparentprocesshastowaitfortheterminated_eventoftheunderlyingchildprocessinstancethatisautomaticallynotifiedwhenthechildprocessterminates.Thesc_spawn’staggedvaluesareusedtospecifysomespawnoptionswhichdeterminecertainpropertiesofthespawnedprocessinstance.Inparticular,asforthreadandmethodprocesses,thesensitiveanddont_initialize(false,bydefault)tagsareusedtodeclarethestaticsensitivitylist(ifany)andtheinitializa-tionstatusofthespawnprocess,respectively.Thebooleantagspawn_methodbeingsettotrueindicatesthatthespawnedprocessisamethodprocess,andthere-foretheassociatedprocessstatemachineshallbeamethodstatemachine.Bydefault,thistagissettofalse,i.e.bydefaultaspawnedprocessisathreadprocess.Itisnotpossibletospawnadynamicclockedthreadprocess.Aspawnedprocess,incontrasttoordinaryprocesses,allowsthepassingofargu-mentsandareturnvaluetoandfromit.UML2supportstheconceptofparameter-izedbehaviorforallthekindsofbehaviorinUML(activities,statemachines,etc.);thismeansthatwhenaprocessstatemachineisinvokedasbehaviorofaspawnedprocess,itsparameters(ifany)arecreatedandappropriatelyinitialized(bythecallerprocess)accordingtotheirdirectioninandinout.Whenthestatemachineofthespawnedcompletesitsexecution,avalueorsetofvaluesisreturnedcorre-spondingtoeachparameterwithdirectionout,inout,orreturn.SystemC2.2introducesalsothemacrosSC_FORKandSC_JOINtobeusedinpairswithinathreadprocesstoencloseasetofcallstothefunctionsc_spawn.Theparentthreadcontrolleavesthefork-joinconstructwhenallthespawnedproc-essesareterminated;thismeansthatduringtheexecutionofthespawnedprocessestheparentprocessisnotrunning.WeusetheUMLfork/joinpseudo-statestomodelthesemacros,asshowninFig.15.9:apairoffork/joinfortwospawnedprocesses;«scthread»smmy_thread«sc_spawn»process_2:process_2SM«sc_spawn»process_1:process_1SM......Fig.15.9sc_forkandsc_join 15AnEnhancedSystemCUMLProfileforModelingatTransaction-Level223boththefork/joinbarsarewithintheregionoftheparent(thread)process.Afterterminationofthetwospawnedprocesses,theparentthreadcontinuestoexecute.15.4GeneratingSystemCCodefromModelPatternsWedevelopedaprototypetoolbasedontheEA[9]UMLvisualmodelingtoolasfront-endforconsolidatedlowerlevelco-designtools(see[4]).Thistoolconsistsoftwomajorparts:adevelopmentkit(DK)withdesignanddevelopmentcompo-nents,andaruntimeenvironment(RE)representedbytheSystemCexecutionengine.TheDKconsistsofaUML2modelersupportingtheUMLprofileforSystemCandaUMLprofileformulti-threadC,andtranslatorsforforward/reverseengineeringto/fromC/C++/SystemC.WefurtherextendedtheSystemCcodegeneratorbyincludingnewcodegenera-tionrulesfortheenhancedstructuralandbehavioralfeaturesoftheprofile.ThetaskofthegeneratoristoinspecttheelementsintheUMLmodelviatheirconnectionsandcreatethecorrespondingmodulesstructuresandprocessesbehaviorinSystemC.Inparticular,fromtheprocessstatemachines,thegeneratorfollowsandcombinesspecificmodelpatterns.Theresultisacompleteworkingcode,withouttheneedforpost-generationcodemodificationsoradditions.15.5CaseStudiesWehavedevelopedseveraldifferentcasestudies,sometakenfromtheSystemCdistributionliketheSimpleBusdesign,andsomeofindustrialinterest.TheSimpleBuscasestudyisawell-knowntransaction-levelexample,designedtoperformalsocycle-accuratesimulation.Itismadeofabout1,200linesofcodethatimplementahighperformance,abstractbusmodel.WemodeledtheSimpleBussysteminaforwardengineeringflowinordertotestthecodegenerator.TheUMLdescriptionusingourSystemCprofileconsistsofabout15diagramsamongclassdiagramsandprocessstatemachines.Totesttheexpressivepoweroftheprofileinrepresentingavarietyofarchitec-turalandbehavioralaspects,wemodeledtheOnChipCommunicationNetwork(OCCN)API[13],aparameterizedandconfigurableSystemClibraryofabout14,000linesofcode.TheOCCNdesignhasbeenimportedautomaticallyfromtheC++/SystemCcodeintotheEA-basedmodelerbythereverseengineeringfacility,thenrefinedusingthemodelingconstructsoftheSystemCUMLprofile.Wehaveusedthisexampletotestthereverseengineeringflow.In[3],wepresentanexamplerelatedtoasystemcomposedofaVLIWproces-sordevelopedinST,calledLX,withsomededicatedhardwareforan802.11bphysicallayertransmitterandreceiverdescribedatinstructionlevel.TheUMLmodelofthisapplicationisafunctionlibraryencapsulatedinaUMLclasswhich 224S.Bocchioetal.provides,throughports,theI/OinterfaceoftheSWlayertotheHWsystem.ThisclassisthentranslatedtoC/C++codeandtheresultingcodeisexecutedbytheLXISSwrappedinSystemCforHW/SWco-simulationatcycleaccuratelevel.TheUMLwrapperoftheLXISSismodeledwiththeSystemCUMLprofile,inordertogenerateaSystemCwrapperfortheISSandtoallowaHW/SWco-simulationattransactionorcycle-accuratelevel.15.6RelatedWorkThepossibilitytouseUML1.xforsystemdesignstartedin1999[11,12].Thegeneralopinion,atthattime,wasthatUMLwasnotmatureenoughasasystemdesignlanguage.NeverthelesssignificantindustrialexperiencesandresearchdevelopmentsonhowtouseUMLwithinasystemdesignprocessstarted,tryingtosolvethelimitationsofthelanguage.AsparttheOMGprofileinitiativesmentionedintheintroduction,weherereferencesomerelevantworksforUMLmodelingandcodegenerationintheareaofembeddedsystemsandSoCdesign.YAML[23]isonethefirsttoolbasedonUMLwhichprovidesaskeleton-basedgenerationofSystemCcode.In[10]anextensionofUML1.xispresentedtodesignembeddedreal-timeapplications.UMLisconceivedasaspecificationlan-guagethatallowsdescribingdifferentfacetsofthesystem.Theproposedapproachreliesontheconceptofplatformbaseddesign.ThefundamentalideaistoadaptUMLforthedesignofembeddedsoftware,providingapropernotationandanassociatedsemanticstouseUMLdiagramsformodelingdifferentfacetsofthesystem.ThemethodologyspecifiesasetofUMLdiagramstocapturethefunction-ality(usecases,class,statemachines,activityandsequencediagrams)andtorefineitbyaddingproperMOCs.However,nocodegenerationfacilityisprovided.AnotherapproachtotheunificationofUMLandSoCdesignistheHASoC(HardwareandSoftwareObjectsonChip)[8]methodologybasedontheUML-RTprofile[17,21].Thedesignprocessstartswithanuncommittedmodelandafteracommittedmodelisderivedbypartitioningthesystemintosoftwareandhardware,andthenmappedontoasystemplatform.FromthesemodelsaSystemCskeletoncodecanbealsogenerated,buttoprovideafinerdegreeofbehavioralvalidation,detailedC++codemustbeaddedbyhandtotheskeletoncode.AlltheworksmentionedabovecouldgreatlybenefitfromtheuseofnewconstructsavailableintheUML2.AModelDrivenArchitecture(MDA)[14]approachforSoCdesignispresentedin[7]inthespecificcontextofIntensiveSignalProcessing.TheapplicationandthearchitecturearespecifiedinUMLasseparateplatformindependentmodels;accordingtotheYchartdiagramconcept,itisthenpossibletoapplymodeltrans-formationsanddeployplatformspecificmodels,amongwhichSystemC.SysML[24]isaconservativeextensionofUML2foradomain-neutralrepre-sentation(i.e.aPIMmodelasinMDA[14])ofsystemengineeringapplications.Itcanbeinvolvedatthebeginningofthedesignprocess,inplaceoftheUML,for 15AnEnhancedSystemCUMLProfileforModelingatTransaction-Level225therequirements,analysis,andfunctionaldesignworkflows.SoitisinagreementwithourUMLprofileforSystemC,whichcanbethought(andeffectivelymade)acustomizationofSysMLratherthanUML.SimilarconsiderationsalsoapplytotheMARTEproposal[16].Thestandardizationproposal[18]byFujitsu,incollaborationwithIBMandNEC,hasevidentsimilaritieswithourSystemCUMLprofile,likethechoiceofSystemCasatargetimplementationlanguage.However,theirprofilesupportneitherconstructsformodelingbehaviornoratimemodel.Recently,asetofpapersdealagainwiththeissueofSystemCcodegenerationfromUMLdiagrams.In[22],forexample,theauthorsproposetheuseofUMLactivitydiagramstomodeldataflows.Thisapproachissimilartoouronewiththedifferenceofusingactivitiesdiagramsinsteadofstatemachinesformodelingthesystembehavior.CodegenerationissupportedfortheHandel-Clanguage.In[20],amappingfromSysMLtoSystemCisproposed.TheiraimistoobtainaSystemCcodethatresemblesthebehaviouroftheoriginalUMLmodel,whereasweextendtheUMLaccordinglytotheSystemCexecutionsemantics.15.7ConclusionsWeextendtheUML2profileforSystemC[1]inordertocapturetheadvancedfea-turesoftheSystemCIEEEStd[25]concerningportsconnection,eventqueuehan-dlingandconcurrentaspectsofdynamicandhierarchicalprocesses.ThemaintargetofthisUMLprofileistoprovideameansforSWandHWengineerstoimprovethecurrentindustrialSoCdesignflowjoiningthecapabilitiesofUMLandSystemCtooperateatsystem-level.ThisenhancedSystemCUMLprofileallowsmodelingatTLMleveland,specifically,atacertainnumberofTLMsub-lev-elsthroughtheOSCITLM1.0API,aswellasthenewTLM2.0proposal.Asfuturework,weareexploringthepossibilitytodefineaformalrefinementmethodol-ogywithpreciseabstraction/refinementpatternsformodelingattransaction-level,thusenablinguserstoefficientlydevelopSoCvirtualprototypesatUMLlevelbeforephysicalimplementationandmakingtheUML-basedenvironmenttheidealframeworkforhigh-levelsystemmodelingandvalidation.References1.BocchioS.,RiccobeneE.,RostiA.,ScandurraP.(2005)AUML2.0ProfileforSystemC.STMicroelectronicsTR,AST-AGR-2005-3.2.BocchioS.,RiccobeneE.,RostiA.,ScandurraP.(2005)ASoCDesignMethodologyBasedonaUML2.0ProfileforSystemC.In:ProceedingsofDesign,AutomationandTestinEurope(DATE’05).3.BocchioS.,RiccobeneE.,RostiA.,ScandurraP.(2005)ASoCDesignFlowBasedonUML2.0andSystemC.In:WorkshopUML-SoC’05atDAC’05.4.BocchioS.,RiccobeneE.,RostiA.,ScandurraP.(2006)AModel-drivenDesignEnvironmentforEmbeddedSystems.In:ProceedingsofDesignAutomationConference(DAC’06). 226S.Bocchioetal.5.BocchioS.,RiccobeneE.,RostiA.,ScandurraP.(2007).AModel-drivenCo-designFlowforEmbeddedSystems.In:AdvancesinDesignandSpecificationLanguagesforEmbeddedSystems(BestofFDL’06),Springer.Netherlands6.BocchioS.,RiccobeneE.,RostiA.,ScandurraP.(2007)DesigningaUnifiedProcessforEmbeddedSystems.In:ProceedingsofInternationalWorkshoponModel-BasedMethodologiesforPervasiveandEmbeddedSoftware(MOMPES’07).7.DumoulinC.P.,BouletM.P.,DekeiserJ.L.(2003)MDAforSoCEmbeddedSystemDesign,IntensiveSignalProcessingExperiment.In:ProceedingsofSIVOES-MDA’03.8.EdwardsM.D.,GreenP.(2003)UMLforHardwareandSoftwareObjectModeling.In:UMLforrealdesignofembeddedreal-timesystems,pages127–147.9.TheEnterpriseArchitectTool.www.sparxsystems.com.au.10.RongChen.etal.(2003)UMLandplatform-basedDesign.In:UMLforRealdesignofEmbeddedReal-TimeSystems,Kluwer,Norwell,MA,USA.11.MartinG.(1999).UMLandVCC.CadenceDesignSystems,Inc.,WhitePaper.12.MartinG.,LavagnoL.,GuerinJ.L.(2001)EmbeddedUML:AMergerofReal-timeUMLandCo-design.In:ProceedingsofCODES’01.13.TheOCCNProject:http://occn.sourceforge.net/.14.OMG,ModelDrivenArchitecture(MDA).http://www.omg.org/mda/.15.OMG.UML2.1.1SuperstructureSpecification.www.uml.org.16.OMG.UMLProfileforModelingandAnalysisofReal-timeandEmbeddedSystems(MARTE),ptc/07-08-04(Beta1).17.OMG.UMLprofileforSchedulability,Performance,andTime,formal/03-09-01.18.OMG.UMLProfileforSystemonaChip(SoC),formal/06-08-01,v1.0.119.TheOpenSystemCInitiative.www.systemc.org.20.RaslamW.,SamehA.(2007)MappingSysMLtoSystemC.In:ProceedingsoftheForumonSpecificationandDesignLanguages(FDL’07).21.SelicB.,RumbaughJ.(1998)UsingUMLforModellingComplexReal-TimeSystems.ObjecTimeLimited/RationalSoftwareWhitePaper.22.SchattkowskyT.,HausmannJ.H.,EngelsG.(2006)UsingUMLActivitiesforSystem-on-ChipDesignandSynthesis.In:Proc.oftheACM/IEEEInternationalConferenceonModel-drivenEngineeringLanguagesandSystems(MoDELS’06).Genova,Italy.23.SinhaV.etal.(2000)YAML:AToolforHardwareDesignVisualizationandCapture.In:Proc.ofthe13thInternationalSymposiumonSystemSynthesis,IEEEPress.Madrid,Spain.24.SysML.http://www.sysml.org/.25.SystemCLanguageReferenceManual.IEEEStd1666–2005,31March2006. Chapter16SC2StateChartstoSystemC:AutomaticExecutableModelsGenerationMarcelloMuraandMarcoPaolieriAbstractTherecentdevelopmentofembeddedsystemscallsforthenecessityofacompleteframeworkfordesignandsimulationofapplicationsthatspanthroughalllevelsofsystemdesign.Desirablecharacteristicsofsuchaframeworkarerapidityofuse,simplicityandreusability.Forthispurposewealreadyintroducedagenera-torthatconvertsspecificationswrittenwithasubsetofStateChartstobehavioralSystemC[16,17].Wepresentherethenewversionofourtool:mostofthelimita-tionsofthepreviousversionshavebeenovercome,theconsideredsubsetoftheStateChartsformalismhasbeenextendedandthetargethasbeenchangedfrombehavioraltoRegisterTransferLevel(RTL)SystemC.Amajorenhancementofthisnewversionisthepossibilityofobtainingvariousmoduleinstancesstartingfromasinglespecification,whichisvitalinsomecontexts(e.g.WirelessSensorsNetworkssimulation).ThesemanticschosenforourStateChartsdiagramsisclearlydescribed.Thegenerationofexecutablemodels,aswellasthekerneltemplateofthegeneratedcode,arediscussedindetail.16.1IntroductionThepossibilityofgeneratingcustomizedsimulatorstomodelarelevantsubsetofsystemsinaveryeffectivewaycouldopeninterestingscenariosinearlydesignphases(evenbeforeHardware/Softwarepartitioning[12]),especiallywhenintrin-siccomplexityrelatedtotheprojectsissuchthatpeoplewithdifferentexpertiseneedtocooperate.Infactwithinthiskindofframeworkitispossibletodesign,inaveryshorttime,virtualprototypesthatcanbeusedforrequirementsformalizationandvalidation.Moreoversystemsunderdevelopmentcouldbeextensivelytestedfromtheverybeginninguptoadvanceddesignstageswiththesametool,incre-mentallyintegratingthemodellevelofdefinition.Functionalandnon-functionalALaRI,FacultyofInformatics,UniversityofLugano,Switzerland;Email:muram@alari.chE.Villar(ed.)EmbeddedSystemsSpecificationandDesignLanguages,227©SpringerScience+BusinessMediaB.V.2008 228M.Mura,M.Paolieripropertiescanbeanalyzed,e.g.usingsuchkindofinstrumentsweanalyzedpowerconsumptionofanetworkingprotocolin[14,15]andofthecachememoryofamicroprocessorin[16].Inourworktheemphasisisonthemodel:ourmaincontributionisinfactamodel-basedgeneratorofsimulatorsthat–startingfromdynamicinformationaboutasystemexpressedwithaconvenientsubsetoftheStateChartsformalism–generateswellstructuredRTLSystemCcodeforsimulation.Theframeworkisorganizedinawaythatitispossibletoiterativelyrefinemodelsuptoapointthatthegeneratedcodeisveryneartothesynthesizablelevel.Duringthisprocessresultscanbecompared,allowingforaneasierdevelopmentprocess.InSection16.2relatedworkisdescribed.ThesemanticsoftheStateChartsdia-lectweusearepresentedinSection16.3andcomparedwiththemostimportantvariants.ThemethodologyforextractinginformationfromUMLdiagramsandusingittocreateSystemCmodelsisbrieflyoutlinedinSection16.4.Section16.5presentsamajorinnovationofourwork:thepossibilityofperformingmulti-instancesimulation.AsmallexampleshowingthemostnoticeablefeaturesofourframeworkaswellastheintroductionofashellconsoleisillustratedinSection16.6.ConclusionsandfurtherworkareoutlinedinSection16.7.16.2RelatedWorkInthepasttenyearstherehasbeenaconsistentresearcheffortonthissubject,lead-ingalsotocommercialsoftwareproducts.I-LogixStateMate[1]generatesexecut-ablemodelsstartingfromUMLdiagrams,MATLABStateflow[2],doesthesamestartingfromaconcurrentFSMformalismsimilartothatofStateCharts.In[4]thetranslationofStateChartsintoHierarchicalFiniteStateMachines(HFSMs)isexploredinordertobuildtestcasesforthecorrespondingVHDLrealization.StateChartsformalismisalsoveryappropriatefortheformalvalidationofmodels.Inparticular,automatictranslationintoPromela/SPIN,alanguageusedforauto-maticmodelchecking,waspresentedin[5,10,13];recentlyaninterestingapproachtothisproblemwasreportedin[9].Thepresentresearcheffortaimsatbuildingaframeworkforthegenerationofsimulators.Itdiffersfromthecommercialproducts([1,2])firstofallforthechoiceofSystemCasatargetlanguageforthegeneratedmodels[11]sothattheycanbeinsertedinalreadyexistingSystemCsimulationframeworks.Ithassimplersemanticsallowingforaneasiercustomization.Asaresultthesimulatorcodeisclearlystructuredandeasytounderstandandmanage.MoreoveritispossibletousethegeneratedmodelasanentrypointforsuccessiverefinementphasesleadingpossiblytoHWsynthesis.Theoutputcanbereducedtoaminimum,thereforesimulationsarequickerandthisgreatlyextendstherangeofapplicability(i.e.contextsinwhichsimulationsforlongperiodsoftimeareneces-sary).TheuseofSystemCisparticularlyindicatedformodelingpurposes,e.g.in[18]andin[20]SystemCcodeisgeneratedstartingfromUMLrepresentations,withthefinalpurposeofcreatingahardwaresynthesis.Differencesbetweenthese 16SC2StateChartstoSystemC:AutomaticExecutableModelsGeneration229worksandourgeneratorareevident.In[18]TransactionLevelModeling(TLM)SystemCcodeisgenerated;in[20]asimpleone-to-onebindingbetweenspecifica-tionsandgeneratedcodeisstudied.AsaresulttheexpressivenessofthemodelinglanguageisreducedandmodelsneedtobeconceivedinawaythatisveryneartoSystemCgeneratedcode.Westartedfromtheconceptsexplainedinourpreviouswork[16,17]butthetoolhasbeencompletelymodified.Thetemplateofthegener-atedcodeisverydifferent(frombehavioraltoRTLSystemC)andthishasaclearimpactontheperformanceofgeneratedcode.ThesubsetofStateChartssemanticsrepresentedisextendedwithinsertionofhierarchicalstates,historyandinterleveltransitions.Moreoverthepossibilityofgeneratingmultipleinteractinginstancesfromasinglemodelisprovided.Thisinnovativecontributionrepresentsamajorenhancementasitallowseasygenerationofexecutablemodelsforawiderangeofmulti-instancesdomain(e.g.networkingwherealotofindistinguishabledevicesmayoperate).16.3StatechartsSemanticsOverviewStateChartsareaformalismintroducedmorethantwentyyearsago[7]andrepresentaverypowerfulinstrumentforthedesignofsystems.TheyarederivedfromFSMswithsomeextensionssuchastheconceptofhierarchy,thepossibilityofmodelingconcurrency,ofbroadcastingcommunicationtoalltheconcurrentlyrunningmachinesandofaddingcodetocompletebehavioraldescriptionofstates.Inparticularcodemaybeinsertedsuchthatitisexecutedwhenatransitiontriggers(action),whenenteringastate(entry-activity),whileinastate(do-activity)orwhenexitingastate(exit-activity).SincetheirintroductiontherehavebeenmanyattemptstogivewelldefinedsemanticstoStateCharts.Themainissuewastodefinedeclarativesemantics(e.g.[19])–possiblyadenotationalonewithacompositionalapproach–correspondingtotheoperationalonethatwasfirstlyproposed.GiventhatStateChartsarenotanofficiallanguage,inashorttimealargenumberofvariantsweredeveloped.In[3]thepossibledifferentaspectswereanalyzedandasummaryofmorethan20differentsemanticsdevelopedfortheformalismwasgiven.Evenlatersomemoreapproachesweretaken,themostremarkableonebeingthesemanticsbehindStateMate[1]thatwasclearlyexposedin[6].WhendealingwithStateChartsitisthereforenecessarytoexplicitlyspecifythesemanticalchoicesthathavebeenadopted.Wedecidetofocusonclarityandonusabilityoftheformalism.Forthisreasononlyasubsetofthesemanticsdefinedin[6]hasbeenchosen.ThebasicideathathasbeenfollowedisthatofusingStateChartsinordertofacilitatethenotationofConcurrentFSMsandtomakeitmorereadable.ThereforeeveryoperationdefinedinStateChartshasitsimmediatecounterpartintermsofconcurrentstatemachines.Whilethisononesidereducestheexpressivityoftheformalism,ontheotherkeepsastrictcontactwithpossibleimplementationsandallowstousediagramscreatedforthesimulatorinlaterphaseofdevelopmentasareferencepointoreven–oncetheframeworkwillbecompleted 230M.Mura,M.Paolieri–forHWsynthesis.Withreferencetothepossibleoptionssummarizedin[3]wehavedecidednottousePerfectSynchronyHypothesis;thereforeeventshappeninginatimeinstantareaccountedforinthefollowingone.ThisinordertomaintainCausality,toavoidSelf-Triggering,InstantaneousStatesandconsequentlymulti-pleentranceorexitsto/fromstatesandinfinitesequenceoftransitionsinasingletimeinstant.ItiseasytonoticethatbecauseofthisdecisiontransitionshappeningsimultaneouslyareconstrainedtobeindifferentparallelcomponentsoftheStateCharts.Theeffectofatransitioncanalsobecontradictorytoitscausewithoutanyproblemasthetworefertotwodifferenttimeinstants.Thisapproach(inaccordancewith[6]andinoppositionto[19])isparticularlysuitedtotheHWcon-textasconfirmedbythefactthatasimilarapproachisfoundinHDLs(e.g.VHDL).AnothercentralpointisthatofInterlevelTransitionsandtheuseofHistory.Ononesidesemanticscomprisingtheseaspectstendtohaveproblemsintermsofcompositionality,becauseinformationregardinginternalstatesneedstobeexported.Ontheothersidetheyallowtomodelinanintuitivewaycomplexsys-temsreducingthenumberofstates.Thereforewehavedecidedtosupportthesecharacteristicsinourmodel,thedesignerisfreetousethemornotdependingonthekindofmodelandthelevelofthedesignprocedure.NegatedTriggersandingeneralLogicalCompositionofTriggersaresup-portedbyoursemantics,reversepolishnotationisused.WedonotuseanyimplicitStateReference:iftheentrance,presenceinastateandexitneedstobeusablebyotherpartsoftheStateCharts,expliciteventsshouldbeputrespectivelyinentry,doandexitactivities.Thischoiceallowsquickersimulationsasalotofredundanciesareremoved.DiscreteEventsareused,i.e.,eventsarevalidonlyintheinstanttheyappear;giventhatInstantaneousStatesarenotallowedinoursemantics,durationofeventsisnotanissue.Theonlypriorityschemewehaveisthatancestorstatestransitionshavepriorityoverdescendantstatesones;nonpreemptiveinterruptisusedtothisend.Transitionshappeninnulltime,timecanpassonlywithinstates.Atimerhasbeenusedwiththekeywordtimer(t)withtheobviousmeaningthataftertimetelapsedwhileinagivenstatethetransitionhav-ingthetimerasatriggerexecutes.Determinismofthemodelislefttothedesigner.Inourformalismitispossibletospecifynon-deterministicbehavior(e.g.twodifferenteventstriggeringtwodifferenttransitionshappeninthesameinstant).Whereasnon-determinismisconsideredbysomeoneofthemaindrawbacksoftheformalism,itallowsrepresentingseveralaspectsofcomplexsystems.Theincreaseincomplexity(possibleexponentialexplosionofstates)iswellcompensatedbytheextendedexpressiveness.AcentralaspectistheinjectionofexternalcodebymeansofActionsandActivities.Thismayinvolveaddingcomplexbehaviorandcomplexprocessingofvariables.Giventhatafullconcurrentenvironmentisprovided,racingconditiononvariablesmayappear.Blockingracingisnothard,butmaynotbethebestsolution,inparticularwhentheorderofexecutionoftheaccessestovariablesdoesnotinfluenceitsfinalvalue.Inoursemanticsdifferentaccessestothesamevariableinthesameinstantareputinsequence(inrandomorder).Thereisthepos-sibility–fordebuggingpurposes–ofdetectingracingconditions. 16SC2StateChartstoSystemC:AutomaticExecutableModelsGeneration23116.4GenerationofSimulatorsTheoverallframeworkhasbeendevelopedexploitingacompilerlikestructure:itcanbeseenascomposedofafront-endinchargeofextractingalltheusefulinfor-mationfromtheXMI–exportedfromthePoseidon1UMLsuite–andturningitintoanIntermediateRepresentation(IR),andaback-endpartwheretheIRistrans-formedintheSystemCcodeofthesimulator.ThiskindofapproachguaranteesthepossibilitytoeasilyadaptSC2todifferentXMIdialectsjustbymodifyingthefront-endorobtainingthesimulator’ssourcecodeinanotherprogramminglanguagejustchangingtheback-end.Whereasthecompiler-likestructurehasbeeninheritedfrom[17]boththeIRandthefinaltemplatearedeeplydifferentandrepresentinnovativecontributionsaswillbedetailedinthefollowingsections.16.4.1FrontEndandIntermediateRepresentationWedecidedtodefineIRthroughanXML-grammar,forthefollowingreasons:●ItiseasiertomaketransformationbetweendifferentXMLrepresentations.●Toolsforparsing,syntaxcheckingandtranslationofXMLareavailableandfree(e.g.weusedSaxon2).●XMLSchemaDefinition(XSD)makesitpossibletodefineawell-structuredXMLgrammarandtovalidateitagainstanyinputXMLfile.WhereasinourprevioustoolstheIRwasrepresentedinGrapheXchangeLanguage(GXL),wenowdecidedtoradicallychangeapproach.Takingintostrictconsidera-tionthefactthatnostandardXMLformatforStatechartsexistswedefinedourowngrammar–abletofullydescribetheStatechartsformalism–fittingthecompletesemantics.Moreoverweprovide–usingXMLSchema–debuggingfeatures,giv-ingthepossibilitytovalidateaStateChartsmodelbeforethecodegenerationproc-essstarts.AsafirststepwedefinedthegrammarintheBackus-NaurForm(BNF)asshowninFig.16.1.Grammardefinitionwasperformedtakingintoconsiderationthecompilationprocess.TheStateChartsdiagramsareseenascomposedbyalistofFSMsandadditionalinformation.Additionalinformationconsistsofthevaria-blesusedinsidetheFSMsandtheeventstriggered–thatmustbedeclaredbefore-hand.FSMsareconsideredasalistofstatesandalistoftransitions.Astatecanbeeitherasimplestate,aFSM–incaseofhierarchicalstates–oraparallelexecutionofmultiplestates.ItisapparentthatthesymbolinFig.16.1isines-sential,butithasbeeninsertedinordertoexportsomeredundantinformationandmaketheautomaticgenerationeasier.Simplestatesandtransitionsarefurther1http://www.gentleware.com2http://saxon.sourceforge.net/ 232M.Mura,M.Paolieri::=::=::=|::=var|var::=event|event::=::=|::=|::=||::=::=entry_actdo_actexit_act::=sourcedestinationtriggerguardsactionFig.16.1StateChartsBackusNaurFormgrammardecomposedintoatomiccomponentsasclearlyshown.Itispossibletouselogicalcombinationofevents–expressedinreversepolishnotation–astriggers.ThestructuredescribedabovehasbeendirectlydefinedintermsofXSDrules.HavinganXMLSchemaoftheIRitispossibletovalidatesyntacticalandgram-maticalcorrectnessofanyinstancethroughanalreadyexistingXMLSchemavali-dator(e.g.weusedSaxon).Thisisakeyfeature–andrepresentsanenhancementwithrespecttoourpreviousreleasesandavailablesolutions–asitallowsearlyidentificationofawideclassofmistakesbeforecompilationofSystemCcodespeedingupthedebuggingprocess.WhereasinpreviousversionsinformationwasonlygatheredfromStateChartsdiagramandvariableswereautomaticallyrecog-nized,inordertoenhancecapabilitiesofourmodelsweusealsoClassdiagrams.Theyserveforseparatingdifferentpartsofthemodelandgivethepossibilitytohavemoredetailsindeclarationofvariablesandevents.InformationfromClassDiagramsiscollectedintheelementoftheBNFgrammar.16.4.2BackEndandGeneratedCodeThepreviouslydescribedIRcontainsinformationforgenerationofallSystemCcode.TheprocesshappensthroughaseriesofExtensibleStylesheetLanguageTransformation(XSLT)[8]passesthatrepresentsthemostnaturalwaytotranslateanXMLformat.ThesimulatoriscodedatRTLlevel.InFig.16.2apieceofpseu-docodeillustratingthetemplateofeachisshown.Thereisaone-to-onemappingbetweenthenumberofinstancesinthegrammarinFig.16.1andthenumberofsuchSCMETHODsintheexecutablemodel.IncasetheStateChartshaveaflatstructure(i.e.withouthierarchy)thenumberofsisequaltothenumberofconcurrentmachines.Incasehierarchyisusedthereisonemoreforeachsubstate–i.e.simplestateormachine–inthemodel.ThisgreatlyreducesthenumberofSCMETHODsrunningconcurrentlyasonourfirstreleasethere Fig.16.2Pseudo-CodetemplateforeachintheStateCharts.timerblocks(1),eventsblocks(2),internalsignalstopropagateacrosssubstates(3)arethemainsectionsofcodedevotedtomanagementofstates.Theswitchesforselectingtheappropriateexitactivity(4),action(5)andentryactivity(6)correspondingtoatransitionarehighlightedinthebottompartwereasmanySCTHREADsasstates.Reductionincomplexityisevenmorerobustasin[16]wefoundthatitispossibletocreateabetterperformingsystemusingtwoSCMETHODsinsteadofeachSCTHREAD.TheSystemCmodelcodeisorganizedinSCMODULEs.EachSCMODULEcorrespondstoanIndependentConcurrentStateMachine(i.e.notformingan 234M.Mura,M.PaolieriANDSTATE).InputsandOutputs–i.e.variablesandevents–oftheseSCMODULEsareaccuratelydefined,reducingthereforethenumberofports(i.e.highsimulationefficiency).Thecodeissplitintotwoparts(AandBinFig.16.2),thefirstonedescribesbehaviorwhileinsideastate,theotherduringtransitions.Theoperationsinsidethestatesareexecutedattherisingedgeoftheclock.Ateveryclockcycleallthedoactivitiesareexecuted.Timerblocks–onepereachoutgoingtransitiontriggeredbyatimer(t)–andeventsblocks–onepereachoutgoingtran-sitiontriggeredbyanevent–arechecked.Ifconditionsforatransitionhold,theappropriatesignalistoggledanditcausesinthefollowingcycletheexecutionofthecodemanagingthetransition.Thiscodeisveryclear:agroupofswitchesevalu-atescurrentstate,transitioncodeandnextstateinordertoexecutetherightexitactivity–dependentoncurrentstate–,action–dependentontransitioncode–andentryactivity–dependentonnextstate.ThisensuresthattransitionshappeninnulltimeandalltherelatedcodeisexecutedinthesameinstantaccordingtoStateChartssemantics.HierarchyistreatedwiththeuseofmultipleFSMSCMETHODsinthesameSCMODULE.Thereisnotheoreticallimitationonthedepthofhierarchy.Anywayabuseofthispossibilitywillslowdownperformance(asthenumberofconcurrentSCMETHODsincreases).Theclockisusedbythefirstlevelofhierarchy,theneachotherlevelissensitivetoan“internalclock”triggeredbytheimmediatelylowerhierarchicallevel.Withthissolutionifastatehasmultiplehierarchylevels,allthelevelsareexecutedinconsecutivecyclesinthesametimeinstant.Thisisnotpossibleusingonlyoneclock.Restoringtheinitialstateonexitinghierarchicalmachinesisperformedonlyifnohistoryispresentotherwisethelastvalidstateiskeptforthenextentrance.Managementofeventsandvariablesiscomplicatedbythepresenceofhierar-chy.Eventhoughwefoundamechanismthatensuresnotimeinstantsarelostintakingexecutionacrossthehierarchicallevels,elapsingofcyclescancauseerrone-ousprocessingofevents.Fordealingwithsuchissuewedesignedagenericmodulethatneedstobeinstantiatedforeachevent.Eventsarerepresentedbyalogiconeonthecorrespondingsignal.Modulessampleontheclocknegativeedge–sothatelapsingofcyclesdoesnothaveanyimpact–theORofsignalsfromalltheFSMsthatcanfirethecorrespondingevent.ThissolutionhasapriceintermsofhighercomplexityaseveryinstantiatedmoduleformanagementofeventscostsonemoreSCMETHOD.Aslongasvariablesareconcernedthereistheproblemofmultiplewritingaccessestothesamevariable.Thereforeagenericmodule(workingasabusarbiter)isneces-sarytotakecareofupdatingthevariablevaluewheneveramodificationisrequired.Ifmoremodificationsarerequiredatthesameinstantonlyonecanbeperformed(nondeterministicallychosen).Giventhattheapplicationforourtoolsstartedfrompowerestimationofcomplexsystems–i.e.multiplestatescangiveacontributetopowerconsumptioninthesameinstant–thereisthepossi-bilityofusingadifferentkindofvariablethatcanacceptmultipleinputsinthesameclockcycle,resultinginthesumoftheinputs.Amodule(i.e.amultiinputadder)managestheseofvariables. 16SC2StateChartstoSystemC:AutomaticExecutableModelsGeneration23516.5Multi-instantiationWefoundthatanimportantrequirementthatwasnotmetbyourpreviousversions[16,17]andsimilarworks[18,20]isthepossibilityofcreatingmultipleinstancesstartingfromasinglemodel.Thissameexigenceholdsformanyenvironments(e.g.systemsfollowingtheclient-serverparadigm).Variablesandeventsshouldbedividedintotwogroups,thosethatareglobalandserveallthesimulatorandthosethatareonlyusedbytheinstancethatincludesthem.Thiswayitispossibletomaketheinstancesworkautonomouslyonetotheotherandinteractonlywhentheyshareaccesstoglobalfields.Asanexample–inthecontextofwirelesscom-munication–allthedeviceswakeupandlistenwhenabeaconeventistriggered,butincaseofasingledevicecommunicationtheeventthattriggersitschangeofstateshouldnottriggeranyotherdevice.Ourmodulartemplateallowsforeasygenerationofmultipleinstances.Infacttheissueisreducedtoaroutingproblem,asthepropersignalsmustberoutedtothepropermodules.Globalsignals(variables)areroutedeverywherethereforetheyareeasilyman-aged.Suchadivisionrequirestheusertoseparatethevariables/eventsinsidetheclasses.Thevariablesandtheeventsthataredeclaredpublichaveglobalscopeinthesimulator,whereasthoseprivateareonlyvisibleinsidetheparticularinstance.Ontheotherhandvariablesandeventsthataredeclaredpubliccanbeaccessedbyallthemachines.Inthecaseofwirelesscommunicationsystems–asanexample–thechannelandthesynchronizationsignalsarepublic,eventscausingaradiototransmitamessage(orvariablesthatindicatethelengthofthemessage)areobvi-ouslylocaltotheinstancethatgeneratesthem.ClassesarelinkedtoStateChartsrepresentingtheirbehavior,inthiswayitispossibletogroupmultipleinstancesfunctionalitiesjustrepresentingtheirbehavioronce.ThisisamajorenhancementasinourpreviousworksitwasnecessarytoreplicateStateChartstohavemoreinstances,andmoreoverthemanagementofeventsandvariablesofthesereplicaswascumbersome.WhengeneratingthesimulatoritispossibletogiveoneormoreUMLfilesasinput.Eachfilecontainsaclassdiagramwiththedeclarationofevents/variablesandthecorrespondingStateChartsdiagrams.Theframeworkcreatesaninstantiata-bleobjectperfileanditispossibletocreateasmanyinstancesofeachoneasneeded.Thevariables/eventsintheclassdiagramsarecheckedpername,publicvariables/eventsofdifferentfilesthathavethesamenameareallgroupedasasin-glevariable.Themainlimitationofthisschemeisthatforthemomentitisnotpossibletodefinerelationshipsbetweensingleinstanceswhenthesharingofvaria-blesisinvolved.Itispossible,e.g.,todefineapublicchannelvariablethatcanbeusedbyalltheinstances,butitisnotpossibletodecidethattwoparticularinstancesshareavariable,whereasfourothersshareanotherone.InordertoobtainsuchbehavioritisnecessarytocreateacomplexStateChartsthatthroughsomeguardconditioncandecideinwhichwaytooperate.Thisisofcoursenotoptimalasitcausesanoticeableincreaseinthenumberofeventsandvariables,andcomplicatesthedesignphase.Weareplanningtoimprovethisaspectinthefuture. 236M.Mura,M.Paolieri16.6ASimpleExampleItisalsousefultoillustrateanothernewfeatureofourtool:theconsoleshell.WhereasinpreviousversionsitwasnecessarytocreateStateMachinesontoptopasseventsandactonvariables,nowitispossibletodotheseoperationsfromtheconsoleline.Thisenhancesusabilityofthetoolsspeciallywhenmodelsarecreatedasinsertingvariousdebuggingpatternsismuchquicker(doesnotrequiremodifyingdiagrams,creatingthemodelandcompilingit).TheconsoleisaninterfacebetweentheuserandtheSystemCsimulationengine.Inordertoillustratealltheconceptsexplainedaboveweshowasimpleexample(seeFigs.16.3and16.4).Thescenarioisthatofpressureandtemperaturemonitors.Theenvironmentisrepresentedasaglobalmachine.Wejustintroducedanexemplarysimplemachinethatchangestem-peratureandpressureparametersfollowingasimplepattern.Monitorscanaccessthepressureandtemperaturevariablesandhavevisibilityovertheeventsfiredbytheglobalmachine,buttheyworkindependentlyonetotheother.Itispossibletoinstantiateasmanymonitorsasdesired.Thenumberofforthisexampleisthreefortheenvironment(global)andfiveforeachinstanceofthemonitors.Therefore3+5×#instancesSCMETHODsarenecessary.ItisnecessarytoaddoneSCMETHODperdistinctvariableandevent.EnterCommand:fireon_signal[1]10addedfiringeventon_signal[1]time10LISTCOMMANDINSERTEVT:on_signal[1]EnterCommand:firesample_evt[2]10addedfiringeventsample_evt[2]time10LISTCOMMANDINSERTEVT:sample_evt[2]EnterCommand:fireread_evt[1]11addedfiringeventread_evt[1]time11LISTCOMMANDINSERTEVT:read_evt[1]EnterCommand:go15........................................................................fsm:device[1]ENTRYstate:IDLEtime:10fsm:device[2]ENTRYstate:READINGtime:10........................................................................time:10THEPRESSUREIS10time:10THETEMPERATUREIS0........................................................................fsm:device[1]ENTRYstate:READINGtime:11........................................................................Fig.16.3Abriefexampleshowingtheuseoftheconsoleshellisshown.Meansoffiringevents(firecommand)forthevariousinstancesandrunningthesimulator(gocommand)areillustrated.Importantlineshavebeenextractedfromoutput 16SC2StateChartstoSystemC:AutomaticExecutableModelsGeneration237Fig.16.4StateChartsofanexample.Monitoringdevicescanbeinstantiated,whereastheenvi-ronmenthasglobalscopeItisverydifficulttogiveanaccurateperformancecomparisonbetweenthistoolandolderversions,astheyoperateindistinctway,andtheycandealwithadifferentsubsetoftheformalism.Usingflathierarchymachines(theonlyonesmanageablebyourpreviousversion)simplifiedeventsmanagementispossible,butclarityofthemodelsisunderpinned.Moreoverperformanceoftheresultingsimulatordependsalsoonthekindofmodel.Thereforewegivesomegeneralindicationsug-gestingthatthenewapproachisverybeneficialintermsofperformance.InFig.16.5reductioninnumberofconcurrentprocessesrunningisclearlyshown.AsfarasexecutiontimeisinvolvedtheweightofaSCMETHODisaboutonethirdthatofaSCTHREAD.16.7ConclusionsandFutureWorkInthispaperwediscussedthenewversionofourtool.AlotofinnovationshavebeenintroducedinthewholeprocessandasaresulttherepresentablesubsetofStateChartisgreatlyextended(e.g.hierarchicalstates,history,interleveltransi-tions).MoreoveranXMLgrammarforStateChartshasbeendesignedandusedasIntermediateRepresentationintheprocessofmodelgeneration.Resultingmodelsaremorepowerfulandnewinterestingfeatureshavebeeninsertedasthepossibilityofinstantiatingmultipleobjectsfromasinglemodelandthecreationofashellinternaltothemodelforimprovingitseasyofuse.FutureworkwillinvolverefinementoftemplateinordertomapittoaVHDLsynthesizablecode,optimizationtoimproveperformanceandimprovementofthe 238M.Mura,M.PaolieriFig.16.5Comparisoninthenumberofgeneratedconcurrentprocessesperstateinthemodel.Thelinehasbeendrawnconsideringmulti-instantiationinanaveragecasemechanismformultiinstantiation.Inparticularwewillworkonfindingamecha-nismforminimizingtheconcurrentSCMETHODsrunningincaseofStateChartswithhierarchyandonovercomingthelimitationinmodelinstantiation.AcknowledgementTheauthorswouldliketothankProfessorMarcEngelsforhispreciousadvices,hiskindsupportandhisvaluablefeedback. 16SC2StateChartstoSystemC:AutomaticExecutableModelsGeneration239References1.http://www.ilogix.com/sublevel.aspx?id=74.2.http://www.mathworks.com/products/stateflow/.3.M.VonDerBeek.AcomparisonofStateChartvariants.InFormalTechniquesinReal-TimeandFaulttolerantSystems,1994.4.F.Fummi,M.G.Sami,andF.Tartarini.UseofStatecharts-Relateddescriptiontoachievetest-abledesignofcontrolsubsystems.InProc.GLSVLSI,1997.5.S.Gnesi,D.Latella,andM.Massink.ModularsemanticsforaUMLstatechartdiagramsker-nelanditsextensiontomultichartsandbranchingtimemodel-checking.JournalofFormalAspectsofComputing,51,2002.6.D.HarelandA.Naamad.TheSTATEMATEsemanticsofStateCharts.ACMTransactionsonSoftwareEngineeringandMethodologies,1995.7.D.Harel.Statecharts:Avisualformulationforcomplexsystems.ScienceofComputerProgramming,1987.8.M.Kay.XSLT2.0Programmer’sReference(ProgrammertoProgrammer).WROX,3edition,Aug.2004.9.D.Latella,I.Majzik,andM.Massink.AutomaticverificationofabehaviouralsubsetofUMLstatechartdiagramsusingthespinmodel-checker.JournalofLogicandAlgebraicProgramming,11,1999.10.J.LiliusandI.P.Paltor.vUML:AtoolforverifyingUMLmodels.ase.11.GrantMartin.SystemCandthefutureofdesignlanguages:Opportunitiesforusersandresearch.InProc.SBCCI,2003.12.G.DeMicheliandR.K.Gupta.Hardware/Softwareco-design.InIEEEProceedings,Mar.1997.13.E.Mikk,Y.Lakhnech,M.Siegel,andG.J.Holzmann.Implementingstatechartsinpromela/spin.InProc.WIFT,1998.14.M.Mura.Ultra-lowpoweroptimizationsfortheieee802.15.4networkingprotocol.InProc.MASS,2007.15.M.Mura,M.Paolieri,F.Fabbri,L.Negri,andM.G.Sami.Powermodelingandpoweranaly-sisforIEEE802.15.4:aconcurrentstatemachineapproach.InProc.CCNC,2007.16.M.Mura,M.Paolieri,L.Negri,andM.G.Sami.StatechartstoSystemC:ahighlevelhardwaresimulationapproach.InProc.GLVLSI,2007.17.L.NegriandA.Chiarini.StateC:apowermodelingandsimulationflowforcommunicationprotocols.InProc.FDL,Sept.2005.18.K.D.Nguyen,Z.Sun,P.Thiagarajan,andW.Wong.Model-drivenSoCdesignviaexecutableUMLtoSystemC.InProc.RTSS.19.A.PnueliandM.Shalev.Whatisinastep:onthesemanticsofStateCharts.InProc.TACS,1991.20.ChenXi,LuJianHua,ZhouZuCheng,andShangYaoHui.ModelingSystemCdesigninUMLandautomaticcodegeneration.InProc.ASP-DAC,2005. Chapter17AsynchronousOn-LineMonitoringofLogicalandTemporalAssertionsK.Morin-Allory1,L.Fesquet1,B.Roustan2,andD.Borrione1AbstractPSLisastandardformallanguagetospecifylogicalandtemporalpropertiesundertheformofassertions.ThispaperpresentsthesynthesisofPSLassertionsintoasynchronoushardwaremonitorsthatcanbelinkedtothecircuitundermonitoring.ThecheckersynthesisisbasedonasystematicinterconnectionofasynchronousprimitivemonitorscorrespondingtoPSLoperators.Theasyn-chronousmonitorsareimplementedwithquasidelayinsensitivelogicwhichgivesreliableandrobustmonitorsinthecaseoftrulyasynchronousevents,temperatureorvoltagevariations.Thesemonitorsareapplicabletoawiderrangeofverificationtaskssuchasthecommunicationsamonggloballyasynchronousmodulesorinsafeorsecureapplications.KeywordsPSL,SVA,hardwaremonitors,asynchronouscircuits17.1ApplicationContextNewdesignparadigmsarerequiredforlargesystemsonachip,amongwhichthesystematicuseofsoftwareandhardware“platforms”,andrigorousspecification,verificationandtestmethods.Inthiscontext,theuseofdeclarativeassertions,tospecifytheexpectedfunctionalandtemporalpropertiesofmodulesand/ortheirenvironment,isrecognizedasavaluable,timesavingtechnique[12]thatcanbecarriedacrossdescriptionlevelsandserveawiderangeofusages.AssertionsareusefulforspecifyingconstraintsforcorrectIPutilization,theresultsdeliveredbyIPs,thecorrectexpecteddesignbehaviors,etc.AsaBooleanpropertyexpectedto1TIMALaboratory,46avenueF.Viallet,38031Grenoble,France;Email:{name.surname}@imag.fr2ENSERG/INPG,3parvisL.Néel,38016Grenoble,France;Email:roustanb@enserg.frE.Villar(ed.)EmbeddedSystemsSpecificationandDesignLanguages,243©SpringerScience+BusinessMediaB.V.2008 244K.Morin-Alloryetal.betrue,anassertioncanbeevaluatedbysimulation,emulationorformalverifica-tion.Anassertioncanalsobeseenasahighlevelfunctionalspecificationforacircuitprimarilyintendedforsnoopingoneventsovertime.Severalformalismshavebeendevelopedtoeasewritingtemporalandlogicalproperties,amongwhichSystemVerilogAssertionsandPSLareIEEEstandards[13,14].Synthesizinganassertedpropertyasamonitor,andinterconnectingthedesignandthemonitor,isacommontechniquetodesignvalidationandonlinecir-cuittestingthatpromisestobecomeincreasinglyusefulforlargeembeddedsystems.Theon-goingworkreportedinthispaperaimsatautomaticallygeneratingtrulyasynchronousandsynthesizablemonitorsfromPSLassertions,foronlinecheckingofcircuitsinnormaloperation.Moreover,themonitorscaneasilybesimulatedandemulatedonahardwareplatform.ThedesigndebuggingonaFPGAboardisalsoanobviousapplicationofourmethod,withtheadvantageofpermittingfullopera-tionspeed.Inthiscontext,manyapplicationsareforeseen.Someexamplesaregivenbelow:●MonitoringlargesystemsbuiltfromsynchronousIP’s:onedifficultyindebug-ging“globallyasynchronouslocallysynchronous”systemsisthecorrectnessofcommunications.Asynchronousmonitorsareneededtopinpointerroneoustransactionsbetweenmodulesthatbelongtodifferentclockdomains.●Monitoringinherentlyasynchronousevents,guaranteeingthatanappropriateresponseisgiven,irrespectiveoftheeventsdelay.●Safelymonitoringcircuitsinharshenvironmentsthankstotheintrinsicrobust-nessofasynchronouslogic.●Monitoringsecurechips,suchascryptoprocessors,inordertodetectside-channelattacksusingfaultinjections.17.2StateofArtFOCSfromIBM[1,6]was,toourknowledge,thefirsttooltoautomatethegenera-tionofregister-transferlevel(RTL)monitorsfromPSL,producingVHDLorVerilogcodethatcanbelinkedtothedesignathandforcheckingonaclockcyclebasis.Althoughprimarilyintendedforon-linesimulation,includingmixedsignalsimulationbyotherparties[2],monitorsproducedbyFOCSaresynthesizable,andcanbefedtoamodelchecker.Theprinciplesforbuildingsyntaxdirectedmonitorsforclocksynchronized“foundationlanguage”PSLexpression[7]andSERE’s[9,15]havebeendisclosedwithaparticularemphasisondebuggingfeature[8,15].Amoreformalautomatatheoreticconstructionofmonitors,theso-called“temporaltesters”,arealsobuiltinacompositionalway[17].Cimattietal.[10]proposeanothermodularencodingtoturnPSLpropertiesintonondeterministicBüchiautomata.OthertoolsarenowprovidedbythemainCADcompanies,thatinterface 17AsynchronousOn-LineMonitoringofLogicalandTemporalAssertions245severalverificationengines(simulation,emulation,formalverification);variouslibrariesofpredefinedcheckers(CheckerWare[3],OVL[4])aresupportedinaddi-tiontothestandardassertionlanguages.Tothebestofourknowledge,allsynthesizedcheckersareclocksynchronized.Checkersthatpretendcrossingmultipleclockdomains,e.g.[5],appeartobehard-wiredspecialpurposemodulesratherthangeneratedfromgeneralassertions.Yet,atsystemlevel,oneneedstowritepropertiesthataretriggeredbyasynchronousevents,suchasinterrupts,orthatcheckcommunicationprotocolsamonggloballyasynchro-nousmodules.TheearlypublishedsolutionsgeneratesoftwarecheckerslinkedtodesignmodelsinC++orinSystemC,thatareverifiedbysimulation[11].17.2.1AModularConstructionThemethodweproposeismodular.Westartedwiththemethodinitiallydevelopedin[7]forsynchronousdesigns.Wethuscreatedacompletelynewlibraryofprimi-tivedigitalasynchronouscomponentsforthebasicPSLtemporaloperators,andaninterconnectiontechniquebasedonhand-shakingprotocols.Thenoveltyofourapproachliesinthefactthattheadvancementoftimeisseenasasequenceofeventsonarbitrarysignalsinsteadofoccurrencesofasinglemasterclockticks.Signalchanges,ratherthanclockticks,arethusconsideredthepointsintimewhenPSLformulasaretobeevaluated.Thispaperisanextensionofanearlyarticle[16]withsomeexperimentalresults.17.2.2AsynchronousLogicBenefitsforMonitoringWhileinsynchronouscircuitsaclockgloballycontrolsactivity,asynchronouscir-cuitsactivityislocallycontrolledusingcommunicatingchannelsabletodetectthepresenceofdataattheirinputsandoutputs.Thisisconsistentwiththeso-calledhandshakingorrequest/acknowledgeprotocol.Onetransitiononarequestsignalactivatesanothermoduleconnectedtoit.Therefore,signalsmustbevalidatalltimes.Asynchronouscircuitsynthesismustbemorestrict,i.e.hazard-free.Inordertohaveveryreliablemonitors,wechoosetoimplementQuasi-DelayInsensitive(QDI)circuits[18].Indeed,thesecircuitsareveryrobusttoProcess,Temperatureand(strong)Voltagevariations.Moreover,theyoffernicepropertiessuchasmodu-larityorlow-powerconsumption.Incontrasttosynchronouscircuits,theQDIcircuitsynchronizationismadelocallywithtwoasynchronoussignals:arequestsignalandanacknowledgesignal.ThisisdonewithaMullergatewhichimplementsa“rendezvous”betweenthesetwosignals.WhenallinputsofaMullergate(Fig.17.1)areequal,theoutputtakestheinputvalue.Wheninputsaredifferent,theoutputholdsitspreviousvalue(seeTablebelow). 246K.Morin-Alloryetal.A0011B0101Z0Z−1Z−11Fig.17.1AMullergate17.3PropertySpecificationLanguageWebrieflyrecallhowpropertiesarewritten,tounderlinethesubtledifferencesbetweenthesynchronousandasynchronousinterpretationofPSLformulas.Apropertyisbuiltonthreetypesofbuildingblocks:theBooleanexpressions,thesequentialexpressions(SERE)thatdefinefinite-lengthregularpatterns(calledsequences)ofBooleanexpressionsandsubordinatepropertiesthatexpressrelationshipamongBooleanorSEREexpressions.VariousoperatorscalledFoundationLanguage(FL)operatorsexpresstemporalrelationships:until,always,before,…InthispaperwefocusontheFLoperators.Ourworkisbasedontheformalsemanticsoftheoperators,definedontraces,andgivenin[13].Tomakethispaperselfcontained,andunderstandable,webrieflygiveanintuitivedefinitiononasmallexample.ConsiderthefollowingpropertyP1.PSLpropertyP1isAlwaysA→next(BuntilC);PropertyP1meansthatforeachevaluationcyclesuchthat‘A’holds,atthefol-lowingevaluationcycleBmustremain‘1’untilCholds.ThePSLsemanticsaredefinedonatrace,andsomeevaluationcycle.Inasyn-chronousdesign,theevaluationcyclecanbeclockdriven(@clock’eventandclk=‘1’),butinanasynchronousdesign,theevaluationcyclemaybeeventdriven.Thus,forasametraceapropertycanholdorfail.ThetwowaveformsonFig.17.2illustratetwoevaluationsonasametraceforpropertyP1.Topwaveform:Atclockedge#2and#7,Aholds.Startingfromthenextevalu-ationcycle(#3and#8)BmustholduntilCis‘1’.ThepropertyisnotverifiedsinceBdoesnotholdat#8:thesecondevaluationfailsandthewholeassertionisnotverified.Bottomwaveform:Forthiswaveform,theevaluationcycleiseventdriven:eachtimethereisaneventononeofthesignalsinvolvedintheproperty,thepropertyis 17AsynchronousOn-LineMonitoringofLogicalandTemporalAssertions247ABC12345678910failABC123456789PendingFig.17.2AsynchronousandanasynchronousevaluationofP1evaluated.Atevent#7,Aisasserted,andonthenexteventBis‘1’andremains‘1’untiltheendofthetrace.SinceCis‘0’,thepropertyispending:anextensionofthetracemayleadtoanerrorornot.Theasynchronoussolutionweproposesupportsbothevaluationcycles.17.4MonitorGenerationThemonitorswebuildreflectthefoursatisfactionlevelsforaproperty:holdstrongly,hold,pendingandfail[13].Whenimplementedinhardware,themonitoroutputsdisplaythepropertysatisfactionlevel,andtheindicationthattheanswerisnolongerpendingmaybeusedasaninterrupttotriggerfurtheractions.AmonitorforapropertyPisbuiltasamodulethattakesasinputsthereset,thesynchronizationsignals(clock,hand-shake,etc.),asignalStartthattriggerstheevaluation,andthesignalsofthedesignunderverification(DUV)thatareoperandsofthetemporaloperatorsinP(seeFig.17.3).Thethreemonitoroutputshavethefollowingsignificance:●Checking:a1indicatesthatoutputValidiseffectiveatthenextsynchronizationtime;●Valid:providestheevaluationresult(1meansabsenceoferror,0meanserror);●Pending:a1indicatesthatthemonitorhasbeenstartedandthatthesatisfactionresultispending;thisissignificantforstrongoperators. 248K.Morin-Alloryetal.Fig.17.3InterfaceofamonitorResetGen_InitAlwaysImplyNextUntilack_start_alwaysack_starttmpack_checkoutresetack_startack_inack_startack_inack_startack_checkoutack_startCHECKINGalwaysack_inack_startack_incheckingstartcheckingstartstartstartcheckoutcheckingstartcheckingCheckingbcheckoutvalidack_bvalidvalidvalidValidack_aaack_aaack_aaack_aaack_bback_blackblacktmpack_atmpatmpack_blackblacktmpack_btmpbtmpackctmpctmp1SynchroASynchro1SynchroSynchroSynchroA,B,CA,B,CB,CBCFig.17.4PropertymonitorforP1Thesynthesismethodrelieson:●Alibraryofprimitivemonitors,oneforeachPSLoperatorofthe“foundationlanguage”.●Asystematicconnectionproceduretobuildcomplexmonitorsfromprimitiveones,basedonthePSLexpressionsyntaxtree.Operatorsthattakeoneortwointegerparameters,suchasnextornext_a,havecorrespondinggenericmonitorswiththesameparameters.Inadditionsomeoperatorshaveseveralvariants:weakorstrong,overlappingornonoverlapping(e.g.before),ineffectcorrespondingtoseveralprimitivemonitors.Allprimitivemonitorshave,maximally,theinterfaceshownonFig.17.3:theremaybe1or2operandinputs,theremaybeapendingoutputornot.Figure17.4illustratestheconstructionofthemonitorforproperty.Inthismonitor,wehavechosentoaddaneventdrivensynchronizationblock.Foreachprimitivemonitor,thisblocktakesasinputtheoperandoftheprimitivemonitorandallthesignalsinvolvedinthesub-formulaassynchronizationsignals:e.g.theoperator“next”takesnooperandasinput(connectedto‘1’),andB,CassynchronizationsignalssincetheyareinvolvedinthesubformulaofP1:next(BuntilC).Thissynchronizationblockcanbesubstitutedbyanysynchronizationblockevenbyaclockdrivensynchronizationblock. 17AsynchronousOn-LineMonitoringofLogicalandTemporalAssertions249Asanexampleoflibraryprimitives,theimplyoperatorispresented.ThepropertysemanticsarefirstexpressedasaPetriNet(seeFig.17.5).TheprimitivemonitoristhensynthesizedfromthisPetriNetdescriptionintoagatenetlistinclud-ingstandardlogicalgatesandMullergates.Thisapproachfitsnaturallywithasynchronouslogic,whereanarbitrarynumberofmodulescanbeassembledbymeansofthehandshakeprotocol,preservingdelayinsensitivity.Figure17.6showsthesub-circuits(identifiedwithdashedlines)correspondingtotheplacesinthePetrinet.ThethreeboxescontainaverysimplestructurewhichFig.17.5PetrinetoftheimplyoperatorrecognizedStartedACHECKINGSTARTC2CSBCSAC1CSBnack_csbACK_STARTACK_A_ACK_ACSBn_C3Aack_csblostFig.17.6Monitoroftheimplyoperator 250K.Morin-Alloryetal.implementsarendezvousbetweenastatesignal(similartoatokeninaPetriNet)andaconditionsignalallowingatransitionbetweentwostates.Thisisrealizedwitha3-inputMullergateandaninverter.Forinstance,the3-inputMullergate,locatedintheStartedbox,issetto1whenthecurrentstateisStarted.ThetransitiontostatesrecognizedandlostisconditionedbythevalueofsignalA.AssumethatalltheMullergateoutputsaresetto0,excepttheoutputofC1(themonitorisinstateStarted).AssumethatAis‘1’.AlltheinputsofC2are1(theacknowledgmentsignalofthefollowingstateisalso1)andtheoutputofgateC2goesup.Theacknowledgmentsignal,connectedtotheinvertedvalueoftheMullergateoutput,resetstheprecedingStartedstate.ThisisinterpretedasastatechangefromStartedtoRecognized.Last,themonitoroutputCheckingisdirectlycomputedwiththegateC2.17.5FPGAImplementation17.5.1ImplementationofAssertionMonitorsToimplementPSLassertionsinadigitalsystem,thedesignerfollowsthestandarddesignflow(HDLdescription,synthesis,placeandroute)asillustratedonFig.17.7.ThePSLassertionsareextractedfromthesystemspecification.OncethePSLassertionshavebeenextracted,themonitorsareautomaticallygeneratedbyourdedicatedplatformHORUS,resultinginanetlistofpropertymonitors.ThischeckernetlististhenmergedwiththeIPtobemonitoredusingHORUS.ThenextstepsfollowthestandarddesignflowandtargetFPGAsaswellasASICs.MonitorsimplementedinASICareprimarilydevotedtoon-linetestingofthecircuitinoperation.InFPGA,themonitorscanbeusedtodetectdesignerrorsatthehardwareorsoftwarelevel,theprimaryinterestbeingseveralordersofmagni-tudeintheverificationspeedcomparedtoasimulationexecution.17.5.2ABusSnoop-SystemforSoftwareVerificationTodemonstratethehardwareasynchronousmonitorprinciplesonarealsystem,anexperimentalplatform,basedonanAlteraFPGA(aStratix1s40),hasbeendesigned.TheimplementedarchitectureisdescribedinFig.17.7.TheNios-AvalonarchitectureisbasedonastandardAvalonbusandhasanUARTserialinterface,aNiosprocessorwithaRAMandabootROM.ThehardwaremonitorsareconnectedtothebusthroughasmallinterfaceinordertosnoopthedatatransactionsaboutwhichthePSLpropertiesarewritten.TheinterfacealsoallowstheNiosprocessortoscanthestate(Pending,Hold,Fail)ofthemonitors.Figure17.7displaysanexperimentwithoneasynchronousmonitor. 17AsynchronousOn-LineMonitoringofLogicalandTemporalAssertions251BehaviouralSimulationRTLSimulationHDLmodelPSLmonitorsSynthesisNetlistSimulationPlace&routeNetlistPrototypeEmulationASICassertCorrectnessEmbeddedpropertyresultFig.17.7DesignflowoftheHorusplatformAhostcomputerisusedtoloadthehardwareontheFPGA(withaJTAGlinknotrepresentedonFig.17.8).Then,thesoftwareisdownloadedthroughtheUARTlinkandexecutedontheNiosprocessor.EachmonitorsnoopsitsownsetofsignalsontheAvalonBus,andevaluatesaparticularproperty.Aftermonitorsarestarted,aslongasallhardwaremonitorsareinpendingstate,theNiosexecutesitsprogramnormally.WhenamonitordetectsaHoldorFailcondition,aninterruptisgeneratedandtheNiosprocessorexecutesanexceptionhandler.Theinterruptroutineperformsappropriateactionsfordebug,e.g.readthestateoftheimpliedmonitoranddisplayitonthehostcomputer.17.6ConclusionThisarticleaimstosynthesizeasynchronouscheckers,describedinanassertionlanguagesuchasPSLorSVA,notonlyfordebuggingduringsimulationoremula-tionbutalsoforASIConlinemonitoring.Themainadvantagesofasynchronouscheckersaretheirintrinsicrobustnesstoprocess,temperatureandvoltagevariations 252K.Morin-Alloryetal.Fig.17.8TheNiosarchitectureconnectedtooneasynchronousmonitorthankstotheQDIlogic.Intheseconditions,anabnormalbehaviorofthemonitoredcircuitcanbedetectedevenifitspowersupplyvoltageisnothighenoughtoensureacorrectfunctioning.Indeed,theasynchronousmonitorfunctionalcorrectnessiswarrantedinalargevoltagerange(typicallyfrom1.2to0.4Vfora130nmCMOSprocess).ThiscanbeusedformonitoringcriticalIPsinsafeorsecureapplications.Moreover,thedelayinsensitivityallowsareliableverificationoftransactionsbetweenmodulesthatbelongtodifferentclockdomains.Themonitorgenerationisbasedonasystematicinterconnectionofasynchronousprimitivemonitorscorre-spondingtoPSLoperatorsofthe“foundationlanguage”.ThisapproachhasbeensuccessfullyprototypedonstandardFPGAplatforms.FurtherworkswilladdressthemonitorgenerationofSEREs.References1.www.haifa.il.ibm.com/projects/verification/Formal_Methods-Home/index.html.2.www.dolphin.fr/medal/smash/flash/smash_flash.html.3.www.mentor.com/products/fv/abv/0-in/index.cfm.4.www.accellera.org/activities/ovl/.5.www.mentor.com/products/fv/abv/0-in-cdc/index.cfm.6.Y.Abarbaneletal.FoCs:AutomaticGenerationofSimulationCheckersfromFormalSpecifications.InComputerAidedVerification,volume1855ofLNCS,ISBN:3-540-67770-4,pages538–542,Springer,London,2000.7.D.Borrione,M.Liu,P.Ostier,andL.Fesquet.PSL-basedonlinemonitoringofdigitalsys-tems.InAdvancesinDesignandSpecificationLanguagesforSoCs–SelectedContributionsfromFDL’05.Springer,London,2006.8.M.Boulé,J.-S.Chenard,andZ.Zilic.Addingdebugenhancementstoassertioncheckersforhardwareemulationandsilicondebug.In24thIEEEInternationalConferenceonComputerDesign(ICCD’06),2006.9.M.BouléandZ.Zilic.Efficientautomata-basedassertion-checkersynthesisofpslproperties.InProceedingsofIEEEInternationalHighLevelDesignValidationandTestWorkshop(HLDVT’06),Nov.2006.10.A.Cimatti,M.Roveri,S.Semprini,andS.Tonetta.FromPSLtoNBA:aModularSymbolicEncoding.InFormalMethodsinComputerAidedDesign,FMCAD’06,ISBN0-7695-2707-8,pages125–133,IEEEComputerSociety,SanJose,CA,Nov.2006.11.A.Dahan,D.Geist,L.Gluhovsky,D.Pidan,G.Shapir,Y.Wolfsthal,L.Benalycherif,R.Kamdem,andY.Lahbib.Combiningsystemlevelmodelingwithassertionbasedverifica-tion.InISQED.IEEEComputerSociety,2005. 17AsynchronousOn-LineMonitoringofLogicalandTemporalAssertions25312.H.Foster,A.Krolnik,andD.Lacey.Assertion-BasedDesign.Kluwer,Dordrecht,TheNetherlands,June2003.13.IEEEComputerSociety.IEEEStandardforPropertySpecificationLanguageReferenceManual,(PSL),Oct.2005.14.IEEEComputerSociety.SystemVerilogIEEEStd1800–2005,2005.15.K.Morin-AlloryandD.Borrione.On-linemonitoringofpropertiesbuiltonregularexpres-sionssequences.InForumonspecification&DesignLanguages(FDL’06),Sept.2006.16.K.Morin-Allory,L.Fesquet,andD.Borrione.Asynchronousassertionmonitorsformulti-clockdomainsystemverification.InIEEEInternationalWorkshoponRapidSystemPrototyping,pages98–102.IEEEComputerSociety,Chania,Crete,2006.17.A.PnueliandA.Zaks.PSLmodelcheckingandrun-timeverificationviatesters.InJ.Misra,T.Nipkow,andEmilSekerinski,editors,FM2006:FormalMethods,14thInternationalSymposiumonFormalMethods,Proceedings,volume4085ofLectureNotesinComputerScience,pages573–586.Springer,Hamilton,Canada,August21–27,2006.18.J.SparsøandS.Furber,editors.PrinciplesofAsynchronousCircuitDesign:ASystemsPerspective.Kluwer,Dordrecht,TheNetherlands,2001. Chapter18Transactor-BasedFormalVerificationofReal-TimeEmbeddedSystemsD.Karlsson,P.Eles,andZ.PengAbstractWiththeincreasingcomplexityoftoday’sembeddedsystems,thereisaneedtoformallyverifysuchdesignsatmixedabstractionlevels.Thisisneededifsomecomponentsaredescribedathighlevelsofabstraction,whereasothersaredescribedatlowlevels.Componentsinsingleabstractionleveldesignscommu-nicatethroughchannels,whichcaptureessentialfeaturesofthecommunication.Iftheconnectedcomponentscommunicateatdifferentabstractionlevels,thenthesechannelsarereplacedwithtransactorsthattranslaterequestsbackandforthbetweentheabstractionlevels.Itisimportantthatthetransactorstillpreservestheexternalcharacteristics,e.g.timing,oftheoriginalchannel.Thischapterproposesatechniquetogeneratesuchtransactors.Accordingtothistechnique,transactorsarespecifiedinasingleformallanguage,whichiscapableofcapturingtimingaspects.Theapproachisespeciallytargetedtoformalverification.KeywordsTransactor,formalverification,petri-net,regularexpressions,embeddedsystems18.1IntroductionDevelopersofembeddedsystemsfaceanever-increasingcomplexityoftheirdesigns.Atthesametime,theyalsofaceanever-decreasingtime-to-market.Acommonwaytodealwiththischallengeistodividethedesignintoseveralcomponents,eachcomponentwithitsownresponsibilitiesandfunctionality.Thisdivide-and-conquertechniqueisusuallycombinedwithaniterativetop-downapproach,wherethesystemisinitiallydefinedatahighlevelofabstraction,leavingoutmostlow-leveldetails.Thedesignisthengraduallyrefinedandmoreandmoredetailsareputintoplace.Duringthisprocess,somepartsofthesystemwillbedescribedathighlevelandotherpartsatlowlevel.DepartmentofComputerandInformationScience,Linköpingsuniversitet,58183Linköping,Sweden;Email:{danka,petel,zebpe}@ida.liu.seE.Villar(ed.)EmbeddedSystemsSpecificationandDesignLanguages,255©SpringerScience+BusinessMediaB.V.2008 256D.Karlssonetal.Thissituation,togetherwiththefactthatverificationandtestconsumeasignifi-cantpartofthetotaldevelopmentcost,stressestheneedforefficientverificationmethodsthattargetsystemsdescribedatmixedabstractionlevels.Theabove-mentionedproblemistraditionallysolvedinanunsystematicmanner,wheredevelopersrewritepropertiesandmodifythesysteminanadhocmannerinordertomatchthemixedlevelmodel.Lately,amoresystematicapproach,involv-ingtransactors,hasbeenproposed[4,5].Thekeyissueoftheproblemliesinthefactthattwo(ormore)componentsdescribedatdifferentabstractionlevelscannotcommunicatewitheachother,sincethey,inprinciple,usedifferentprotocols.Onecomponentusesamorehigh-levelprotocolthantheother.Atransactorisamechanismthatbridgesthisgapbytrans-latingthehigh-levelrequestsintotheirlow-leveldittoandviceversa.Moreover,evaluationshaveshownthatusingatransactor-basedverificationapproachismoreeffectivethanatraditionalRTLverificationflowwithrespecttobothfaultandassertioncoverage[1].Usingtransactorsmoreoverhelpsinreusingtestbenchesaswellasassertionsintherefinementprocess.Afewworkshavebeenperformedintheareaofautomaticallygeneratingthistypeoftransactors,basedonprotocolconversiontechniques[2,3].Bombierietal.[4]startfromamaster-bus-slavecommunicationframeworkthatcontainsinforma-tiononhowcommunicationiscarriedoutatdifferentabstractionlevelsonthespecifiedinfrastructure(bus).Fromthisframework,theauthorsextractamaster,busoraslavetransactorfromahightolowlevelorviceversa.TheirextractionalgorithmisbasedonExtendedFiniteStateMachines.Itdoes,however,nothandletimingaspectsexplicitlyandisonlyapplicableonbus-basedprotocols.Balarinetal.[5]useSequentialExtendedRegularExpressions(SERE)tospec-ifytherelationbetweenthetwointerfacesofthetransactorandtoautomaticallygeneratethecorrespondingtransactor.Thetransactorsaregeneratedinaprogram-minglanguagesuchasC++,VerilogorSCE-MI,inordertofacilitateintegrationwithexistingsimulationtools.Theapproachsupportstoalesserextentformalmethods,anditcompletelylacksthesupportfortime.Protocolsareoftendescribedusingvariouskindsofregularexpression-likelan-guages.AlthoughSEREs[5]inprinciplearesufficientlyexpressive,theydonotsupportthenotionoftime.TimedRegularExpressions[6],ontheotherhand,lackseveralusefulfeatures,suchasvariablesandconditions.TheapproachproposedinthischaptercombinesSEREswithtimedregularexpressionsbyaddingatimingfeatureontopofSEREs.Wecalltheresultinglan-guageTimedSERE(TSERE).Bydoingthis,weareabletocreatetransactorssuit-ableforformalverificationinacomponent-basedreal-timesettingwithmixedabstractionlevels.Theapproachmoreoverwidensthescopeofresponsibilityoftransactorsfromapureprotocolconvertertoasemirefinedcommunicationchannel.Thechapterisorganisedintosevensections.Section18.1introducesandmoti-vatestransactor-basedverification.Next,Section18.2providesanoverviewoftheproposedapproach.Section18.3presentsthePetri-netbaseddesignrepresentationthatisusedthroughoutthechapter,andSection18.4definestheTimedSequential 18Transactor-BasedFormalVerificationofReal-TimeEmbeddedSystems257ExtendedRegularExpressionlanguagethatisusedforspecifyingtransactors.Section18.5describesthemechanismtogeneratetimedPetrinetsfromtheformaldescriptionandSection18.6presentsafewcasestudies.Section18.7concludesthechapter.18.2OverviewIntheproposedapproach,asystemconsistsofseveralcommunicatingcomponents,asindicatedinFig.18.1.Eachcomponentimplementsawell-definedfunctionality,andtheyinteractwithothercomponentsandtherestofthesystemthroughports,depictedinthefigurewithcirclesattheedgesofthecomponent.Channelsareinsertedbetweencommunicatingcomponents.Thechannelsmodeltheprotocol,delays,noiseandotherpeculiaritiesthatcanoccurinthecom-munication.Theyarehenceonlyanartefactforhigh-levelmodels,thatwillnotoccurorbesynthesisedinthefinalimplementation.Channelscan,fromamodel-lingpointofview,beregardedasaspecialtypeofcomponents,andaredepictedwithdottedlines.Duringthedevelopmentphase,itisoftendesirabletocheckifcertaintemporallogicpropertiesaresatisfiedinthesystem.Suchanalysiscanbeobtainedbyfeed-ingamodelofthesystemintoamodelcheckingtooltogetherwithpropertiestobeverified.Thisproceduregivesaformalproofwhetherthepropertiesaresatisfiedinthesystemornot[7].Atthesametime,thecomponentsareiterativelyrefinedandmoreandmoredetailsareaddedtothesystem.Thisnaturallyleadstoasituationwheresomepartsofthesystemaremorerefinedthanothers.However,itisstilldesirabletooccasion-allyverifythesystemtoensurethattherecentlyperformedrefinementstepsdidnotviolateany,possiblycritical,properties.Whenrefiningthecomponents,theinterfacesofthosecomponentsaresimulta-neouslyrefined.However,theinterfacesaresharedorconnectedwithothercom-ponents,thatarenotyetrefined.Thiscreatesanincompatibilityofinterfacesbetweentheinvolvedcomponentsandchannels.Inordertoovercomethisproblem,thechannelisreplacedbyatransactorbetweentheincompatibleinterfaces,asFig.18.1Targetedsystemtopology 258D.Karlssonetal.demonstratedinFig.18.2.Atransactorcanthusbeseenasachannelconnectingcomponentsatdifferentlevelsofabstraction,orasemi-refinedchannel.Thetrans-actorshallencapsulatethesameexternalbehaviourasthechannelitreplaceswithrespecttodelays,noise,etc.Thetransactortakeshigh-levelrequestsandtranslatesthemintolow-levelones,andviceversa.ItisdescribedinTimedSequentialExtendedRegularExpressions(TSERE),whichisbothintuitiveandsufficientlyexpressiveforthispurpose.TheTSEREs(andtherebyalsothetransactors)aregiveneitherbythedesignerhimself,or,inastandardisedcontext,byathird-partyprovider.TheexampleinFig.18.3willbeusedtoexplaintheapproachinmoredetail.Asenderrepeatedlysendsmessagestoareceiveroverachannel.Atahighlevelofabstraction(Fig.18.3(a)),ittakes2timeunitsforthemessagetobetransportedFig.18.2Systematmixedabstractionlevelwithtransactor(a)Bothcomponentsathighlevel(b)Bothcomponentsatlowlevel(c)Senderathighlevel,ReceiveratlowlevelFig.18.3Explanatoryexample 18Transactor-BasedFormalVerificationofReal-TimeEmbeddedSystems259betweenthetwocomponents.Thisdelayisimplementedinthechannelintercon-nectingthecomponents.Atalowlevelofabstraction(Fig.18.3(b)),themessageisrefinedintotwo:addressanddata.Theprotocolthatthesenderandreceiverhaveagreeduponstatesthatthesemessagesshouldbesentsequentiallywith1timeunitinbetween.Itmoreovertakes1timeunitforeachmessagetoreachthereceiver.Thesenderthussendsthedataatthesametimeastheaddressreachesthereceiver.Itshouldbenotedthatthetotaltimeframeforsendingamessageinthetwoabstractionlevelsisthesame.Inbothcases,thistakes2timeunits.Thus,thechannelpreservesitsexternalbehaviourbetweenabstractionlevels.Atonemoment,duringtherefinementphase,onlyoneofthecomponentsisrefined.Assumethatthiscomponentisthereceiver(Fig.18.3(c)).Atthisstage,thesenderandreceiveradheretodifferentprotocolsandcannotcommunicatewitheitherofthehigh-levelorlow-levelchannels.Instead,thechannelisreplacedwithatransactorthattranslatesthehigh-levelmessageintothestipulatedsequenceoflow-levelones.Thetransactorconsequentlyhastoanalysethemessagefromthesenderanddivideitintotwo.Thefirstmessageshouldcontainthedestinationaddress,whereasthesecondoneshouldcontainthedata.Thetransactorthenforwardsthetwopiecestothereceiverwith1timeunitdifference.Thetransactorcanbesaidtobeamixofthetwoversionsofthechannel.It,however,alsocontainsadditionalprotocolinformationnotexplicitinthechannels,e.g.howtosplitthehigh-levelmessageandthetimeseparationbetweentheaddressanddatatransmission.Therefore,theinformationcapturedinthechannelsisnotsufficientforformulatingtheTSEREs.Inaddition,thetransactorrespectstheexternaltimingbehaviourofthechannels.18.3VerificationFlowandDesignRepresentationThissectionintroducestheverificationflowandthePetri-netbaseddesignrepre-sentationusedinthischapter.18.3.1VerificationFlowFigure18.4presentstheoverallverificationflowwheretheworkdescribedinthischapterisputintocontext.Theflowcentersaroundacomponent-basedverificationmethodology[7],whichacceptsthreeentitiesasinput:amixed-levelmodel,trans-actorandTimedComputationTreeLogic(TCTL)properties[8].Themixed-levelmodelisobtainedfromtraditionalrefinementstepsofahigh-levelmodel.ThedesignerthenwritesTSEREsdescribingthecommunicationdis-crepanciesarisenfromthemixedabstractionlevelsinthesemirefineddesignandgeneratesatransactoroutofthem(thefocusofthischapter).TheTCTLformulasexpressthereal-timepropertiestobeverified. 260D.Karlssonetal.Fig.18.4VerificationflowIntheverificationmethodology,anabstractionofthemodelisfirstobtainedwithrespecttothecomponentsandchannelsreferredtobytheproperties.TheabstractedmodelistheninputtotheUPPAALmodelchecker[9],byfirsttranslat-ingthePetri-netmodel[10]intoTimedAutomata[11],theinputlanguageofUPPAAL.Iftheresultofthemodelcheckingwasfalse,themodelmightneedtoberefined(relativetotheabstractiondoneintheverificationmethodology,notthedesignitself)basedondiagnosticinformationobtainedfromthemodelchecker.Incasetherefinementoftheabstractionfails,thepropertiesareconcludednottobesatisfied.If,ontheotherhand,themodelcheckingresultwastrue,itcanbeconcludedthatthepropertiesholdinthemodel.18.3.2TheDesignRepresentation:PRES+ThecomponentsaswellasthesystemasawholeareassumedtobemodelledinadesignrepresentationcalledPetri-netbasedRepresentationforEmbeddedSystems(PRES+)[10].ItisaPetri-netbasedrepresentationwiththeextensionslistedbelow.Figure18.5showsanexampleofaPRES+model.1.Eachtokenhasavalueandatimestampassociatedtoit.2.Eachtransitionhasafunctionandatimedelayintervalassociatedtoit.Whenatransitionfires,thevalueofthenewtokeniscomputedbythefunction,usingthevaluesofthetokenswhichenabledthetransitionasarguments.Thetimestampisincreasedbyanarbitraryvaluefromthetimedelayinterval.Ifthetimedelayintervalisnotexplicitlystated,itisassumedtobe[0..0].InFig.18.5,thefunc-tionsaremarkedontheoutgoingedgesfromthetransitions.3.ThePRES+netisforcedtobesafe,i.e.oneplacecanatmostaccommodateonetoken.Atokeninanoutputplaceofatransitiondisablesthetransition.4.Thetransitionsmayhaveguards.Atransitioncanonlybeenabledifthevalueofitsguardistrue(transitionstandt).45 18Transactor-BasedFormalVerificationofReal-TimeEmbeddedSystems261Fig.18.5AsimplePRES+netPlaceswithoutincomingarcsarecalledin-ports,andplaceswithoutoutgoingarcsarecalledout-ports.Acommonnameforin-portsandout-portsrespectively,isports.Componentsaresubnetsofthewholemodel,delimitedbyports.18.4TimedSequentialExtendedRegularExpressionsTheproposedapproachintroducesTimedSequentialExtendedRegularExpressions(TSEREs)forthespecificationoftransactors.TSEREsconsistofthreetypesofentities:basicentities,termsandoperators.18.4.1BasicEntitiesBasicentitiescannotbestandaloneTSEREs,butconstituteapartofterms.Theyareusedasbuildingblocksforstorage,communicationandcomputation.Thethreecategoriesofbasicentitiesareshownbelow:1.Variables:a,b,cVariablesareusedtostoreandretrievevalues.Variablesareassociatedtoadatatype.Unlessexplicitlystatedotherwise,thedatatypeusedinallexamplesisinteger.Thescopeofavariablestretchesfromitsfirstoccurrencetotheendofthesequence(seethesequenceoperatorbelow)ofthatfirstoccurrence.2.Portlabels:!send,?recPortlabelsareusedtodefinetheinteractionwithothercomponents.!denotesthesendingofa(possiblyempty)messageonthesubsequentout-port,and?denotesreceivingofamessagefromthespecifiedin-port.3.Arithmeticexpressions:(a+b)·3Arithmeticexpressionsperformacomputationonotherbasicentities,followingstandardsyntax.Thisentityallowsexpressingdataprocessing. 262D.Karlssonetal.18.4.2TermsTermsdescribeanactionbycombiningbasicentities.Therearethreedifferenttypesofterms,listedbelow:1.Assignments:a←3,!send←0,b←?recThevariableorout-portontheleft-handsideofthearrowisupdatedtothevalueofthevariable,in-portorarithmeticexpressionontheright-handside.2.Guards:a=4,?rec>10Guardscomparethevalueofavariableorin-portwiththeevaluationofanarithmeticexpression.Iftheguardevaluatestotrue,nothinghappens.Otherwise,theTSEREfails(or,looselyspeaking,reachesadeadend).3.Delays:[0..0],[3..5]Delaysdenotethepassingoftime.Theyareexpressedasintervals,withtheconnotationthatanarbitraryamountoftimefromtheintervalmayelapse.Thisfeatureiscrucialinthecontextofreal-timesystems.18.4.3OperatorsInadditiontoterms,TSEREscanberecursivelycombinedtoexpressmorecom-plexbehaviourwiththefollowingoperators.AssumeαandβbeingarbitraryTSEREs.1.Sequence:α;βαoccursimmediatelybeforeβ.2.Choice:α+βEitherαorβoccurs.3.Concurrency:α|β,α|nαandβoccurconcurrently.Theconcurrencyoperatorisnotconsideredtohaveoccurreduntilbothαandβhavefullyoccurred.α|ndenotesnconcurrentcopiesofα.4.Iteration:αn,α∞,α*,α+Theiterationoperatorsdenoteasequenceofrecurringα.Thelengthofthatsequencedependsonthetypeofiteration.αndenotesasequenceoflengthnandn=∞signifiesaninfinitelylongsequence.Suchasequencecanonlybeescapedifplacedinsidethechoiceoperator.α*denotesasequencewherenisarbitrarilychosenbetween0≤n≤∞,andinthecaseofα+,nisarbitrarilychosenfrom1≤n≤∞. 18Transactor-BasedFormalVerificationofReal-TimeEmbeddedSystems26318.4.4ExampleReturningtotheexampleintroducedinFig.18.3,thehigh-levelandlow-levelchannelsandthetransactorcanbeexpressedwiththefollowingTSEREs:1.High-levelchannel:(m←?send;[2..2];!rec←m)∞2.Low-levelchannel:(a←?sndaddr;[1..1];!recaddr←a;d←?snddata;[1..1];!recdata←d)∞3.Transactor:(m←?send;[1..1];!recaddr←m.addr;[1..1];!recdata←m.data)∞Theinfiniteiterationonthewholeexpressionisnecessarytoenablethetransactortoprocessseveralrequests.Withouttheiteration,thetransactorandchannelswouldstopworkingafterthefirstrequest.Asanotherexample,consideravariantofthelow-levelchannelwhereeithertheaddressanddataaresentsimultaneously,orwereceivearesetrequest.Equation18.1showsthecorrespondingTSERE.(((a←?sndaddr;[1..1];!recaddr←a)|(d←?snddata;[1..1];!recdata←d))+?reset)∞(18.1)Ifstatementscanbeexpressedusingguardstogetherwiththechoiceoperator.Incombinationwithiteration,thisstructureallowsformulatingboundedloops,asdemonstratedinEq.18.2.αn⇔i←0;((i10(c)Delays:[3..5]Fig.18.7PRES+patternsforTSEREterms18.5.1PatternsforBasicEntitiesVariablesarerepresentedbyaplace(Fig.18.6(a)),initiallywithoutatoken.Whenthevariableisassignedavalueforthefirsttime,andthevariableentersitsscope,atokencontainingtheinitialvalueisputintheplace.Fromthatpointon,atokenshallalwaysresideinthatplaceduringthewholelifetimeofthevariable.Thelastterminthesequence,wherethescopeofpossiblyseveralvariablesends,shouldconsumethetokensintheplacescorrespondingtothosevariables.Notstoringval-ueswhennotneededreducesstatespace,andthereforemitigatestheeffectsofstatespaceexplosion.Thisisimportantforefficientmodelchecking. 18Transactor-BasedFormalVerificationofReal-TimeEmbeddedSystems265(a)Sequence:α;β(b)Choice:α+β⏐n(c)Concurrency:α⏐β,α(d)Possiblyinfiniteiteration:α∞α∗,α+Fig.18.8PRES+patternsforTSEREoperatorsPortlabelsarealsomodelledwithasingleplace(Fig.18.6(b)).Theseplaceswillserveasportsofthetransactor.?labelsserveasin-portsand!labelsasout-ports.Therefore,thetransactorcanonlyconsumetokensfrom?labelports,andanalogouslyonlyputtokensin!labelports.Arithmeticexpressionsaremodelledintwostages:fetchingvariablevaluesandcomputation(Fig.18.6(c)).Thevalueofeachvariableinvolvedintheexpressionmustbeexplicitlyfetchedandstoredinatemporaryplace.ThisarrangementisduetothefactthatPRES+transitionsonlyareassociatedtoonefunction.Withoutthefetchingsteps,theinvolvedvariableswouldchangevaluestothevalueoftheexpression,whichisnotthedesiredbehaviour.ThefetchingofvariablevaluesisrealisedbytransitionstandtinFig.1218.6(c),forvariablesaandbrespectively.Thetransitionsconsumethetokenfromthevariableplaceandimmediatelyputitbackwiththesamevalue.Inthecaseof?portlabels,thetokenisneverputback.Acopyofthevalueismoreo-verstoredinatemporaryplace,a’andb’respectively.Thesetokensarethenusedinthefinalcomputationstage,transitiont,insteadofdirectlyaccessing3thevariableplaces.Thefetchingstagesandthefinalcomputationstageareconnectedinasequencewiththehelpofintermediateplaces,ptop.The14resultoftheexpressionislocatedintheexitplaceofthearithmeticexpression. 266D.Karlssonetal.18.5.2PatternsforTermsAssignmentsarerealisedinasimilarwayasvariablefetching,withthedifferencethatthevalueofthetokenisupdated(Fig.18.7(a)).Thenewvalueislocatedintheentryplaceinthecaseofarithmeticexpression,or,inthecaseofaconstant,thetransitionfunctionissettothatconstant.Attentionmustbepaidtoiftheassignmentdenotestheinitialassignmenttothevariableinquestionornot.Ifitis,thereisnotokeninthevariableplacetobeconsumedandconsequentlythereshallnotbeanarcfromtheplacetothetransition.Iftheassignmentisanupdateofanalreadyinitialisedvariable,thetokenmust,onthecontrary,beconsumedbeforetheupdateisactuated.Inthecaseof!portlabels,tokensareneverconsumedfromwithinthetransactor.Asanoptimi-zationwhenthenewvalueisanarithmeticexpression,theassignmentcanbemergedwiththecomputationstageofthearithmeticexpression.Guardsareimplementedasvariablefetchingwithoutcreatingatemporarycopy,withtheadditionthatthetransitionguardissettotheTSEREguardexpression(Fig.18.7(b)).DelaysaremodelledwithatransitionwiththetimedelayintervalstipulatedbytheTSEREdelayexpression(Fig.18.7(c)).ThemodellingofdelaysispreferablyoptimisedbymovingthetimedelayintervaltothefirsttransitionofthesubsequentTSERE,ifsuchexists.18.5.3PatternsforOperatorsTheoperatorpatternscombineseveralsubpatternstoformamorecomplexbehav-iour.InFig.18.8,thesubpatternsaredrawnascloudswitharrowsfrom/toitsentryandexitplaces.Theresultingcomplexpatternisalsoassignedentryandexitplaces,indicatedinthefiguresinthesamewayaswiththeterms.Sequencesarerealisedbymergingtheexitplaceofthefirstsubpatternwiththeentryplaceofthesecond(Fig.18.8(a)).Theentryplaceofthefirstsubpatternbecomestheentryplaceofthewholesequence,andtheexitplaceofthesecondsubpatternbecomestheexitplaceofthewholesequence.Inthisway,whenthefirstsubpatternhasfinishedexecuting,atokenisputinthesharedmiddleplace,whichenablestheexecutionofthesecondsubpattern.Inthepatternforthechoiceoperator(Fig.18.8(b)),theentryandexitplacesofthesubpatternsaremerged,sothatallsubpatternssharethesameentryplaceandthesameexitplace.Whenatokenappearsintheentryplace,thisleadstotheenablingofallsubpatterns,outofwhichoneischosenrandomly.Ifthefirsttermofasubpat-ternisaguardthatevaluatestofalse,thatsubpatterncannaturallynotbechosen.Whenatokenarrivesintheentryplaceoftheconcurrencypattern(Fig.18.8(c)),theentryplacesofeachsubpatternmustalsobemarkedtoenabletheexecutionofeachcorrespondingsubpattern.Thisisachievedbyintroducinganadditionaltransition(t)1withtheentryplacesofallsubpatternsasoutputandtheentryplaceofthewholepatternasinput.Asimilar,butcontrary,constructisalsoinsertedattheexitplaces(t),2 18Transactor-BasedFormalVerificationofReal-TimeEmbeddedSystems267implementingthesynchronisationofthesubpatternsupontheircompletion.Thecon-currencyoperatorisnotconsideredcompleteduntilallsubexpressionsarecompleted.Iterationisaccomplishedbyconnectingtheexitplaceofthesubpatterntoitsentryplaceviaatransition(tinFig.18.8(d)).Thisprocedurecan,inthecaseof1α∞andα*,beoptimisedbyinsteadmergingtheentryandexitplacesofthesubpat-tern.Theentryplaceofthesubpatternisalsotheentryplaceoftheiteration.Forα*iterations,theexitplaceisthesameastheentryplace,whereasforα+theexitplaceoftheiterationistheexitplaceofthesubpattern.α∞iterationsdonothaveanexitplaceduetotheirinfinitenature.FiniteloopsareimplementedbasedonEq.18.2.WhenaPRES+modelhasbeengeneratedforthewholeTSERE,aninitialtokenisputintheentryplaceofthefinalmodel,toindicatethefirstterm.18.5.4ExamplesLetuscontinuethesenderandreceiverexampleintroducedinFig.18.3,andwheretheTSEREsforthechannelswerelistedinSection18.4.4.Figure18.9providesthe(a)ThegeneratedtransactorfromFig.18.3(c)(b)ThePRESS+modelcorrespondingtoEq.18.1Fig.18.9ExamplesofPRES+modelsgeneratedfromTSEREs 268D.Karlssonetal.PRES+modelsresultingfromthepresentedapproach,includingcertainoptimizations.Thecoreofthetransactorisasequenceofreadingandwritingonportscom-binedwithsimplearithmeticexpressions(Fig.18.9(a)).Transitionstandtmodel24thevariablefetchingstagesofthearithmeticexpressions,whiletransitionstandt35combinethecomputationstageswiththeassignmentonportsrecaddrandrecdatarespectively(optimization).Thedelaysaremoreoveraddedtothefirsttransitionsinthesubsequentterms,inthiscasetandt.Itshouldmoreoverbenotedhowthe24scopeofvariablemismodelled.Transitiontrealisesthefirstassignmenttom,1thereforeitonlyputsatokenwiththeinitialvalueinplacem.Astransitiontisthe5lasttransitioninitsscope,itconsumesthetoken,nomatteritneedsthevalueornot.Transitiontmodelstheinfiniteloop.6Figure18.9(b)presentsthePRES+modelcorrespondingtoEq.18.1.Insidetheiteration,thereisachoicebetweeneithertwoconcurrentstatementsorasinglereadingofreset.Iftheresetisnotimmediatelypresent,thetwoconcurrentsequencesarelaunched.Iftheresetispresent,thereisanon-deterministicchoicebetweenthetwooptions.Theloopisinthisfigureoptimisedinthesensethattheexitplaceofthechoiceoperatorismergedwithitsentryplace.18.6CaseStudiesTheproposedapproachhasbeenappliedontwoexamples:theexamplefromFig.18.3andanAMBA-basedprotocol.Themodelswereformallyverifiedonhigh,lowandmixedlevelsofabstractionusingaLinuxmachinewithanIntelPentium4,2.8GHzprocessorand2GBofmemory.TheAMBAexamplewasmoreoververifiedwithdifferentconfigurationsonthenumberofmasters(M)andslaves(S).Bothexampleswerecheckedforthesametwoproperties:nodeadlockandthatsentmessageswillarriveattheirdestinations.Tables18.1and18.2presenttheverificationtimesinsecondsfortherespectiveexample.ThetablesmoreoverindicatethesizesoftheTSEREs,whichdefinethechannels/transactors,asthenumberoftermsandoperatorsintheexpression.ThesizeoftheentireverifiedPRES+modelisindicatedbythenumberoftransitions.Thesenumbersonlygiveahinttothesizeoftheexamplesandarenotdirectlyrelatedtoverificationtime.Theseresultsindicatethereasonablenessoftheproposedapproach.Table18.1ResultsfromtheexamplegiveninFig.18.3AbstractionlevelNodeadlockSentwillarriveHigh0.12s0.13sLow0.06s0.09sSenderhigh–receiverlow0.11s0.06s 18Transactor-BasedFormalVerificationofReal-TimeEmbeddedSystems269Table18.2ResultsfromtheAMBAexampleM–SAbstractionlevelNodeadlockSentwillarrive1–1High0.33s0.12sLow0.19s0.22sMhigh–Slow0.19s0.17sMlow–Shigh0.30s0.40s1–2High0.50s0.46sLow0.80s1.68sMhigh–Slow0.24s0.35sMlow–Shigh1.44s3.57s2–1High0.19s0.43sLow0.48s1.53sMhigh–Slow0.38s0.84sMlow–Shigh1.43s6.59s2–2High5.01s18.99sLow5.43s22.57sMhigh–Slow5.39s17.77sMlow–Shigh42.06s200.5s18.7ConclusionsThischapterhaspresentedanapproachtogeneratetransactorsforreal-timeembeddedsystems,suitableforformalverification.Theapproachassumesadesignwherecomponentscommunicateoverchannels,andthatthosechannelscaptureallthecharacteristicsofthecommunication.Duringthedevelopment,moreandmorecomponentsarerefinedleadingtoamodelwithmixedabstractionlevels.Insuchmodels,thecomponentscannotdirectlycommunicateduetoprotocoldiscrepancies.Inordertoovercomethesediscrepancies,thechannelsinterfacingcomponentsofdifferentabstractionlevelsarereplacedwithtransac-tors.Thebehaviourofthetransactors,i.e.themappingofrequestsbetweenabstractionlevels,isdescribedusingTSEREs,whichareautomaticallyconvertedintothedesignrepresentationused,PRES+.TheresultingPRES+modelcanthenbeanalysedbyaformalverificationtool.References1.BombieriN,FummiF,PravadelliG(2006)OntheEvaluationofTransactor-basedVerificationforReusingTLMAssertionsandTestbenchesatRTL.Proc.ACM/IEEEDesignandTestinEurope,Munich,Germany,6–10March2.AkellaJ,McMillanK(1991)SynthesizingConvertersbetweenFiniteStateProtocols.Proc.InternationalConferenceonComputerDesign,Cambridge,MA,Oct.15–15,pp.410–4133.PasseroneR,RowsonJA,Sangiovanni-Vincentelli,A(1998)AutomaticSynthesisofInterfacesbetweenIncompatibleProtocols.Proc.DesignAutomationConference,SanFrancisco,CA,June,pp.8–134.BombieriN,FummiF,PravadelliG(2006)ATLMDesignforVerificationMethodology.IEEEPh.D.ResearchinMicroelectronicsandElectronics,Otranto(LE),Italy,11–15June,337–340 270D.Karlssonetal.5.BalarinF,PasseroneR(2006)FunctionalVerificationMethodologyBasedonFormalInterfaceSpecificationandTransactorGeneration.Proc.DesignandTestinEurope,Munich,Germany,pp.1013–10186.AsarinE,CaspiP,MalerO(1997)AKleeneTheoremforTimedAutomata.Proc.LogicinComputerScience,Warsaw,Poland,June,pp.160–1717.KarlssonD,ElesP,PengZ(2007)FormalVerificationofComponent-basedDesigns.JournalofDesignAutomationforEmbeddedSystems11(1):49–908.AlurR,CourcoubetisC,DillDL(1990)ModelCheckingforReal-timeSystems.TheoreticalComputerScience414–4259.UPPAALhomepage:http://www.uppaal.com/10.CortésLA,ElesP,PengZ(2000)VerificationofEmbeddedSystemsUsingaPetriNetBasedRepresentation.Proc.InternationalSymposiumonSystemSynthesis,Madrid,Spain,pp.149–15511.AlurR,DillDL(1994)ATheoryofTimedAutomata.TheoreticalComputerScience126:183–23512.KozenDC(1997)AutomataandComputability.Springer,NewYork. Chapter19ACase-StudyinProperty-BasedSynthesis:GeneratingaCacheControllerfromaProperty-SetMartinSchickel,MartinOberkönig,MartinSchweikert,andHansEvekingAbstractProperty-basedsynthesishasbecomeamoreprominenttopicduringthelastyears,beingusedinmultipleareaslike,e.g.formalverificationanddesignautomation.Wewillshowhowaproperty-basedformalspecificationofacachecontrollerforaMIPScorecanbeusedtoautomaticallygenerateafunctionalimplementationofthatcontrollerandhowadditionalperformanceinformationaboutthecompletesystemcanbegainedfromdoingso.KeywordsPropertyBasedDesign,Synthesis,FormalVerification,Cando-Objects19.1IntroductionTheintegrationofdesignandverificationefforthasstronglyimprovedduringthelastdecade.ManyEDAcompaniesrequiretheirdesignerstoincludeassertionsintothehardwaredescriptions–atechniqueknownasassertion-baseddesign(ABD).Also,formalspecifications,consistingofpropertiesandassertions,arenolongeronlydevelopedduringtheverificationofadesign,butalsobeforeandduringitscreation.Lookingatthisdevelopment,theobviousquestioniswhetherthosefor-malspecificationsusedtoverifydesignscanalsobeusedtoautomaticallygeneratehardwareimplementingtheproperties,therebyassuringagoldenmodelwhichiscorrectbyconstruction.Inthelastyears,somesignificantprogresshasbeenmadeinthisarea,enablingtheautomaticgenerationofprototypemodelsfromeverlargerandmorecomplexsetsofproperties.Inusingthisapproach,wecanassurethatadesignverifiedusingComputerSystemsLab,DarmstadtUniversityofTechnologyDarmstadt,Germany;Email:{schickel,oberkoenig,schweikert,eveking}@rs.tu-darmstadt.deE.Villar(ed.)EmbeddedSystemsSpecificationandDesignLanguages,271©SpringerScience+BusinessMediaB.V.2008 272M.Schickeletal.acompletesetofpropertieswillbeworkingexactlyasthegoldenmodelgeneratedfromthem,therebyformallyrelatingtheuntilnowunrelatedspecificationlan-guagesformodelsandverification.InthefollowingsectionswewilldiscusstheresultsofourexperimentswithasetofpropertiesdescribingthefunctionalityofacachecontrollerforaMIPS.Usingthesepropertieswewantedtoreachtwodifferentgoals:Firstly,wewantedtoknowwhetheritwaspossibletogenerateafunctioningsimulationmodelofthecachecontrollerandsimulateittogetherwithaMIPScore.Secondly,wewantedtoseewhetherwewouldbeabletoderiveinformationaboutthebehaviorofasystemconsistingofaMIPScoreandacachecontrolleradheringtotheproperty-setwehad.WeusedtheCandoGen-tool[1]fromDarmstadtUniversitydescribed,e.g.in[2]bySchickeletal.ThistooliscapableofgeneratingVHDL-descriptionsofso-calledCando-ObjectsfromsetsoffinitepropertieswritteninPSL[3,4]orITL[5].TheseCando-Objectsareinessenceblack-boxeddesignswhosebehaviorisrestrictedbythepropertiestheyweregeneratedfrom(hencetheirname:“Candoanythingnotdisallowed”).However,therehavebeenothereffortstoautomaticallysynthesizeexecutablehardwarefromproperties:theProSydprojectandBlueSpec.TheProSydprojectwasfoundedtoresearchpossibleimprovementsinproperty-basedsystemdesign.OneofthedeliverableswasatoolcapableofsynthesizingfunctioninghardwarefromarbitraryPSLproperties.Thetoolfirstconstructsafinitestatemachinefromtheproperties,andthentranslatesthemachineintoahardwaredescriptionlanguage.Whiletheresultsareverygoodwhenthepropertiesonlydescribeasystem’scontrolpath,theusedmethods’complexityisunsuitableforthegenerationofdatapaths[6].Sinceourpropertiesincludethedatapath,thistoolisunsuitableforus.BlueSpecisacompanyfoundedbyArvindMithalfromMIT.Itutilizesthepatentedterm-rewriting-system[7]totranslatepropertieswritteninBlueSpec-SystemVerilogintofunctioninghardware.Thismethodisknowntobehighlyefficientandoftenproducesresultsbetterthanhumandesigners,butitrequirestheusertowritepropertiesinadifferentstylethanthatusedwhenwritingverificationproperties.Thereforeverificationpropertiescannotbeusedforsynthesisusingthismethod.Sinceourpropertieswereverificationpropertieswritteninanotherlanguage(i.e.PSLandITL),thistoolwasalsounsuitable.19.2TheCacheControllerPropertiesForourexperimentwehadobtainedaMIPScorefromopencores.org[8]andasetofpropertiesdescribingthefunctionalityofasimplecachecontroller,whichhadtobetransparentinordertousethenon-modifiedMIPSdesign.Thesetofcachepropertiesdescribesafullyassociativecachemodel(i.e.thedefinitionofcache-hitwasbasically‘anycache-cellhasvaliddataforagivenaddress’).Aleastrecently 19ACase-StudyinProperty-BasedSynthesis273used(LRU)policywasspecifiedaswellasawrite-throughtechnique.Thesizeofthecachewasdeterminedtobeeightcachelinesofeight32bit-instructions(8×256bit),butcouldnotonlybeusedtocacheinstructions,butalsotocachedataneededduringthepipeline’sexecutionstep.Thepropertiesforthecachecanbecategorizedinfivefunctionalgroups:●Manager&-Cachelinevaliditycorrect?●WriteData&-WriteInstructionshandledcorrectly?●Replacement&-LRUalgorithmworkingcorrectly?●Instruction&-ReadInstructionhandledcorrectly?●Memory&-ReadDatahandledcorrectly?OneexamplepropertyisillustratedinFig.19.1.Itdescribestheresetbehaviorofthememorygroup.ItiswritteninVHDL-flavoredITL.19.3ExperimentalResultsAllthepropertiescouldbetransformedintoVHDLdescriptionsofaworkingcircuitmodelincorporatingallthedescribedfunctionality.ThetransformationruntimesarelistedinTable19.1.Thetimespentonthepropertiesinthemanagergroupwasfairlylong.ThiscanbeexplainedbyCandoGen’scurrentinternaluseofBDDswhichmaybecomerathercomplexwhenthenumberofvariablesgrowslargerthan300asisthecasewhencheckingwhetheracache-hithasoccurred.ThisisduetotheBDD-explosionwhichoccursprominentlywhenshift-andmultiplicationoperationsareconcerned.TheeffectsmightbecounteredbyusingAIGs[9]toreplaceorcomplementtheBDD-representationofthecircuits.AhybridAIG/BDD-systemmightcombinethestrengthsofbothrepresentationmethods.propertyresetisassume:att:reset=’1’;prove:att+1:wait_for_mem=’0’;att+1:update_least_recent_mem=’0’;att+1:update_cache_info_mem=’0’;att+1:mem_req_read=’0’;endproperty;Fig.19.1SamplepropertyTable19.1ModelgenerationdataModule#PropsLinesofcodeRuntime(min)Manager493321WriteData4895Replacement51352Instruction523946Memory613413 274M.Schickeletal.CacheRegisterCacheControllerDataAccessBusCtrl.InstrFetchFig.19.2ConnectionofcontrollertoMIPScoreThegeneratedVHDLmodelscouldthenbeconnectedtoformthecompletecachecontrollerandbesimulatedtogetherwiththeMIPScore.Todoso,thecachecontrollerwasconnectedtothecore’smemoryinterfaceasshowninFig.19.2.Thedottedlinesmarktheoriginalconnections.Thesimulationofsmallprecompiledandpreloadedprogramsduringthecourseofdirectedtestingworkedwellandshowedafullfunctionalityofthecache,reducingtheaveragememoryaccesslatency.Thelaststepwastheverificationorformaldeductionofsystemlevelproperties.Sinceoneofthemostprominentpropertiesofacacheistheaccelerationofmemoryaccesses,wedecidedtowritepropertiestoexaminethememoryaccessspeedup.Ontheoriginaldesign,itcanbeproven,thatanymemoryaccesshasthesamelatencyaswasspecifiedwithinthememorydescription.Whenthecachecontrollerisattachedtothedesign,thispropertydoesnotholdanymore.Acounter-exampleshowsthatwhenconsecutiveareasofmemoryareaddressedthememoryaccessmaybecompletedmorequickly.Byrelaxingthepropertytoallowforcompletionwithinacertaintimeframewecanquicklydeter-minetheeffectofthecachetobebetween−3to+1cycleslatency.Thelatterresultsfromthecache’spropertytoreadcompletecachelines,whichmayproveproble-maticwhenmemoryaccessesaresufficientlyrandom.Theproofofthesepropertieswascompletedwithinnegligibletime(lessthan1minperproperty).19.4ConclusionWehaveshownthatitispossibletoautomaticallygeneratehardwarefromproper-tiesandusedthegeneratedmodelduringsimulationandtoprovesystemproperties.Futureresearchwillincludesynthesizabilityofcompleteprocessorcoresfromverificationproperties. 19ACase-StudyinProperty-BasedSynthesis275AcknowledgmentsTheresearchleadingtothispublicationwasconductedwithinthescopeoftheFESTprojectjointlyfundedbytheGermanministryofresearchandeducationandindustrypartners.References1.M.Schickel,V.Nimbler,M.BraunandH.Eveking:CandoGen–AProperty-BasedModelGenerator,UniversityBooth,Nice,France,Date’07.2.M.Schickel,V.Nimbler,M.BraunandH.Eveking:OnConsistencyandCompleteness:ExploitingtheProperty-BasedDesignProcess,Proc.ofFDL’06.3.PropertySpecificationLanguage,ReferenceManual,Version1.1,Accellera,2004,http://www.eda.org/vfv/docs/PSL-v1.1.pdf.4.C.EisnerandD.Fisman:APracticalIntroductiontoPSL,Springer,NewYork,2006.5.UserDocumentation:OneSpinMV360–Version4.1,OneSpinSolutionsGmbH,2006.6.ProSydProjectDeliverable2.3/1:Evaluationoftoolsandmethodologyforproperty-basedlogicsynthesis,www.prosyd.org.7.A.Mithal,J.Hoe.DigitalCircuitSynthesisSystem,U.S.PatentU.S.6,597,664B1,7/2003.8.http://www.opencores.org/projects.cgi/web/minimips/overview9.V.ParuthiandA.Kuehlmann:EquivalencecheckingcombiningastructuralSAT-solver,BDDs,andsimulation,inICCD’2000.