System Level Design of Embedded Controllers: Knock Detection, a Case Study inthe Automotive Domain

LeonardoMangeruca�, Alberto Ferrari

�, AlbertoSangiovanni-Vincentelli

��� �,

AndreaPierantoni�, MichelePennese

�

�PARADES,Via SanPantaleo,66,00186Roma,Italy�

MagnetiMarelli PowertrainS.p.A,Via Timavo, Bologna,Italy�EECSDept.,Universityof Californiaat Berkeley, CA 94720

Abstract

We presenta casestudyin thedesignof automotiveenginecontrollers: the developmentof a knock detectionalgorithmand its implementationin an optimizedplatform. Thedesignproblem is complicatedby the needof using heterogeneousmodelsof computationanddifferentdesignenvironments.Theuseof differentdesignenvironments,onefor functionaldesignandonefor architectural designspaceexploration, requirestotransforma modelof computationinto another. We describehow we solvedthis problemand we presentthe final designwith thetrade-offsexplored.

1 Introduction

Knock detectionis an important, computeintensive taskin modernautomotive enginecontrol. The implementationofcontrollersthatincludeknockdetectionoftenrequiresaDSPasa co-processorin a standardmicro-controllerarchitecturethusaddingcostanddesigncomplexity. Sinceknock detectionisbecominganintegral partof enginecontrollers,it makessenseto explore alternative implementations.To do so, we needtoevaluatea numberof architecturesthat arebasedon differentselectionsof componentssuchasmicro-processors,memoriesandinterconnectionschemes.

The evaluationhasto be carriedout by mappingcomputa-tion to processingelementswhile makingsurethat timing andother physicalconstraintsare satisfied. This designproblemis typical of embeddedsystemsin other industrial segments.Methodologieshave beenproposedfor embeddedsystemde-signincludingarchitecturedesignspaceexploration.However,theflow from algorithmanalysisto implementationis not sup-ported today by a unified tool environment thus forcing ad-vanceddesignersto work with a patchwork of tools and for-mats.

Themostseriousproblemfor designersis actuallythemis-matchof the modelsof computationusedby different tools.There is no guaranteethat what hasbeenmodeledand sim-ulatedat a certainlevel of abstractionis consistentwith otherlevelsof abstractions.Consistency canonly beverifiedby care-ful mappingof amodelof computationinto another. Thisis stillanopenproblemin generalin absenceof anencompassingthe-ory of models.We discussin detailsthis andotheraspectsofsystemlevel designwhile presentingour solutionto thedesignof theknockdetectionfunctionin enginecontrollers.

The paperis structuredasfollows: in Section2, the knockdetectionproblem is presented. In Section 3, the designmethodologyis presented.In Section4 andSection5, thegen-eralaspectsof transformingthemodelof computationusedinSimulink for hybrid systemsimulationinto themodelof com-putationsupportedby the VCC designenvironment,are de-scribed.Experimentalresultsfor thedesignexplorationphasearepresentedin Section6 andconclusionsarepresentedin Sec-tion 7.

2 The Design Problem

In aninternalcombustionengine,anair-fuel mix is first in-jectedinto the combustion chamberof a cylinder. After themix is compressedby thepiston,a sparkis generatedto ignitethemix. At a first glance,it seemsthatmaximumefficiency isachievedwhenthesparkis givenexactlyattheendof thepistonrun (Top DeadCenter, TDC). However, it is actuallybestfromfuel efficiency point of view to give thesparkbefore theTDC.Sparkadvanceis measuredin negativeanglescorrespondingtothe positionof the pistonwith respectto the TDC. Whenthesparkis given, the combustionwave propagatesfrom the topof thecylinder towardsthebottomgeneratingtheforceneededto pushbackthe pistonandgeneratetorquefor the motion ofthe car. Knocking refersto an unwantedsecondarycombus-tion processthat is not controlledby thesparkbut by pressureand temperatureat the peripheryof the combustionchamber.Knocking exercisesforceson the piston and the combustionchamberthat may causeenginefailure and, as such,shouldbe carefully avoided. The probability of knocking is propor-tional to sparkadvance.In standardengines,knockingis thenminimizedopen-loopby settingan a priori limit on sparkad-vance. In turbo-chargedengines,an open-loopstrategy is toorisky giventhehigh temperaturesandpressionsthatdevelopinthecombustionchamber. Hence,measurementsaretakenthatdetectknockingasit ensues,thusallowing a closed-loopcon-trol of thesparkadvanceto eliminateknocking.Becauseof therelentlesspursueof reductionsin fuel consumptionandpollu-tion, knock detectionis becominga requirementfor any typeof enginesincegreaterefficiency canbeachievedby sparkad-vancesthatareontheedgeof causingknocking.Enginecontrolalgorithmsactuallyuseknockingsensorsto regulatesparkad-vance.

Knockingis not trivial to detect.Addingsensorsto thecom-bustionchambersis obviously out of thequestion.Theeffectsof knockingcanbesensedasforcesactingon thetransmission

Figure 1. Cylinder Pressure Cycle with and with-out knoc k phenomen

Figure 2. Signal of acceler ometer and in-c ylinderpressure sensor

due to high frequency componentsaddedby knocking to theprimary pressurecycle betweenthe TDC (Top DeadCenter)andthefollowing ����� ����� Fig. 1.

The vibrations generatedin the combustion chamberaretransmittedto theenginemechanicalstructureandcanbemea-suredvia a piezoelectricor quartzaccelerometerplacedon thecylinder block. The maximummeasurablefrequenciesduetoknockingon theengineblock arelimited to 20KHz. However,the accelerometercollectsall the vibrationscomponentsgen-eratedby the entiremechanicalsystem.The measuredsignalincludes:whitenoisecomponents(dueto randomnoisesasso-ciatedto friction androtation)andpink noiseof low variancerelatedto mechanicalimpulsive effects other than knocking.The relationbetweenknock vibration on the in-cylinder pres-surecycleandtheaccelerometersignalis shown in Fig. 2.

A statisticalanalysisof theaccelerometersignalandof theinput vibrationsshows thata ��������� samplingfrequency fortheaccelerometeroutputsignalis necessary. Thesampledsig-nal is thenfilteredthrougha ����� orderdigital elliptic filter (im-plementedwith 15multiplicationand12accumulationfor eachsample)to estimatetheaccelerometerpowerspectrum.

To estimatetheoverall computationloadthat theknockde-tectionalgorithmimplies,notethat:

� The accelerometersignal is significantonly in an angu-lar window of ���� ���� after TDC. The time window���

correspondingto the angularwindow � � is givenby�����! ���#"$� �&%(') +* ���,"$-/.10 %2� � �&') �3"2-/.40 % 1, andtheconsequentnumberof samplesat thesamplingfrequency576

is 8 6��9�:� " 5763�; � � " 526<%=') �>"�-/.10 % .1 ?A@CB (roundperminute)lies betweenD<E<E<EGFIH<E<E<E .

� At �����J�J� of samplingrateand K�����L-/.10 , thenumberofsamplesin theangularwindow is between8 6(M N#OQPR�; ���:"�������� %(') ��"4K����� %)�9S ��� and 8 6(M N3T<UV�! ����"1�������� %(') ��"K������ %G� K���� .

� Due to the constantangularwindow of integration, thesample population decreasesas the engine speed in-creases.Theratioof thecomputationtime (theproductofnumberof samplesandthe elaborationtime per sample)to engineperiodis constant.

3 The Design Methodology

Thedesignflow we follow is relatedto bothplatform-baseddesign[9] andmodel-baseddesign[11]. Platform-baseddesignis ameet-in-the-middleapproachwheresuccessiverefinementsfrom a high level of abstractioncarry the designto an imple-mentationplatformthatis built bottom-upusingelementsfroman appropriatelibrary. The platform performanceparameters,suchastiming, costandpower consumption,areestimatedtoguidetheselectionof theplatforminstancethatimplementsthedesign.Model-baseddesignindicatesthetop-down partof thedesign. The descriptionof the functionality of the designisdonein formal (or semi-formal)language(model). The lan-guageis usedto simulateand/oranalyzethefunctionaldesign.Whenthedesigneris satisfiedwith his/hersolution,theimple-mentationon theplatformof choiceeitherassoftwarerunningon a micro-processoror hardware is automatically(or semi-automatically)extractedfrom themathematicalmodel.

Thedesignflow callsfor threebasicsteps:functionaldesignandanalysis,platforminstanceselection,implementationof thefunctionalityusingthecomponentsof theplatforminstance.

For engine controllers, functional design consistsof thederivation of appropriatecontrol laws whose mathematicalpropertiesareto be assessedon the closed-loopsystem. Sta-bility, controllability and observability are typical propertiesof interest. Thesepropertiesare in generalproven manually,ensuredby rigoroussynthesistechniquesor heuristicallyana-lyzedby meansof extensivesimulations.Theplant(engineandtransmissionchain) is modeledeitherasa hybrid system,i.e.,a compositionof continuous-timecomponents(whosebehav-ior is capturedwith differentialequations),discrete-timeanddiscrete-eventcomponents[4], or with a continuous-timeaver-agingmodel.Thecontrolleris theresultof theimplementationof mathematicalcontrol laws. Becauseof the implementationplatformsavailabletoday, thecontrolalgorithmsaremostlyim-plementedin software. For this reason,controllersaremostlydescribedin termsof discretetimeor discreteeventmodelsthatoftenresultfrom a refinementprocessof continuous-timecon-trol algorithms. The closed-loopsystemis a complex hybridsystem.Thecaptureof thebehavior andits simulationis todaymonopolizedby theMatlabandSimulinklanguageandsimula-tion tools[1], from TheMathworks.Simulinkusescontinuous-timeasthebasisfor hybridsystemsimulation,thusresultinginratherlongcomputingtimessincea largenumberof samplesisnecessaryto representcontinuouswaveforms.

Platformselectionrequiresanumberof experimentsthataredesignedto explore a constraineddesignspace.For eachex-periment,weneedto mapthefunctionalityof thedesignto thecomponentsof the platform instanceconsideredandestimatetheoverall performance.This stepis supportedby only a fewtools(seefor example[8]). In this case,theestimationprocessmust be supportedby a simulationmechanismthat is blind-ingly fast to be accurateenough.Hence,embeddingthis sys-temin continuous-timeis not feasible.Event-drivensimulationof abstract,simplifiedmodelsis appropriatehere[7]. However,

2

if we do not wish to have inconsistentresults,themodelusedfor functionaldesignmustbecompatiblewith themodelusedfor performanceestimation.Unfortunately, this is not thecasetoday. This phenomenonis only the tip of the iceberg! Theproblemof heterogeneoussystemdesignandanalysisrequiresa deepunderstandingof Modelsof computation(MoCs) thatdefinehow the systemspecificationexecutes,andof their flatandhierarchicalcombinations2 . Theproblemis exacerbatedby thelackof precisedocumentationaboutthesemanticsof thelanguagesusedby differenttools.

Following platform selection,the functionality has to bemappedinto thecomponentsof theplatformandanimplemen-tationderived. Today, this stepis, in general,entirelymanual.Model-basedmethodsconsistsin partiallyautomatingthispro-cessby usingtoolssuchasRealTimeWorkshopby TheMath-worksandTargetLink by dSpace,whichgenerateC codefromthe Simulink intermediateformat directly. Codegenerationisseenasastrategic responseto increasinglylongerdevelopmenttimeandcodingerrors.

In our methodology, the crucial step is then transformingfrom theSimulinksimulationmodelto theVCC internalmodelsothatthebehavior is thesamein bothdomains.

4 From continuous time to discrete event

It is readily shown that transformingthe hybrid model,calledtheD/C modelin thesequel,into a discreteeventspeci-fication,thatwe termtheDE model, is not trivial, in thesensethat careful attentionneedto be placedon the adaptationofthemodelsof computationin the two environments.Considera discretetime logic operator. In thediscretetime domain,thelogicoperatorexecutesateachsamplingtimeinstantandispro-videdwith bothinput valuesat eachsamplingtime instant,i.e.input valuesare synchronized. Instead,in the discreteeventsimulation,eventscorrespondto signalvaluechanges,so thatinput valuesarenot synchronized(two inputsneednot changeat thesametime) andthelogic operator’s functionalityneedtobemodifiedto keepthis into account.For example,in SystemCit is sufficient to locally storeold input values,while in CiertoVCC this is not sufficient, for eventsareasynchronousby defi-nition, andsignalsmight needto beexplicitly synchronizedbymeansof additionalsynchronizingcomponents.

Every simulationin Matlab/Simulinkis carriedout by em-beddingcontinuoustime,discretetimeanddiscreteeventcom-ponentsin thecontinuoustimedomain.Themainconsequenceof this simulationpolicy is thatall signalsaresynchronized,inthesensethateverycomponent“reads”its input valuesat eachsimulationtime instant,andasa resultthesimulationis highlyinefficient, for discretetime anddiscreteeventcomponentsaresimulatedin continuoustime. Thesepointsarespecificto theMatlab/Simulinkenvironment,for in generalmixed-signalsim-ulators[10] gainin efficiency by avoidingcontinuoustimesim-ulationfor discretecomponents.

Hence,thefirst stepto correctlytranslatethespecificationisto partition thestartingmodelinto threesubsystems,eachonecomprisingonly homogeneouscomponents(i.e. eithercontin-uoustime or discretetime or discreteevent). Moreover, forreasonsof efficiency, continuoussignalsmust be avoided indiscreteeventsimulations,beingthereforeessentialthat inter-actingcontinuouscomponentsbehierachicallycomposedin asinglecontinuousmodelthatwill be transformedinto a black-boxcomponent,so thatcontinuoussignalsarenot seenby thediscreteeventsimulator.

2Many MoCshavebeendevisedandused.They differ becauseof character-isticssuchaseaseof modeling,efficency of analysis(e.g. formal verification,simulation,etc.),expressiveness,synthesizability, compositionality[12, 5].

Let usassumethattheoriginalspecificationbemadeupof Wcontinuoustime components,0 discretetime componentsandX discreteevent components,possibly intensively interactingwith oneanother. We furtherassume,asdiscussedabove, thatthe W continuouscomponentsdo not directly interactwith oneanother. Theinterfacesignalsbetweencontinuousanddiscretecomponentsare adaptedby meansof samplers,interpolators(e.g. zero-orderhold) andevent generators(e.g. differentia-tors),globally referredto asadapters.

Thetransformationinto thediscreteeventdomainis carriedout by encapsulatingeachof the W continuouscomponentsto-getherwith its adaptersin a black-boxcomponent,that is thusdiscreteat its interface(thecomputationinsidetheblack-boxisstill continuous).The W black-boxcomponentsaretriggeredby. (.�YZ0 ) differentsamplingclocks.Discretecomponentsareeasilyembeddedin thediscreteeventdomain,thougha trans-formationmight beneededto adaptto thediscreteeventsimu-lator’s MoC. We refer to this problemastheMoC compatibil-ity issue. Transformeddiscretecomponentsarereferredto aswhite-boxcomponents,in contrastto black-boxones.

Amongthecontinuoustimecomponentstherearesomethatdo not interactwith discreteeventcomponents.We call thesePS(purely sampled)components. All othercontinuouscom-ponentsaretermedNPS(non-purelysampled)components. PScomponentscanbesimulatedin thediscreteeventsimulatorasany other white-box component,i.e. their currentlocal stateis “never in the future” (i.e. aheadof the currentsimulationtime). Instead,the local stateof NPScomponentsneedto be“never in thepast”(i.e. behindthecurrentsimulationtime), forthey cangenerateunpredictableeventsin the simulation. Forthesecomponentsit is necessaryto implementtechniquessuchassimulationback-trackingandseparationof postingandcom-mitmentof events.

Thesetechniquescanberealizedlocally insidethecompo-nentwhenever the discreteevent simulatorprovidesa meansof component’s self-scheduling. This is provided for exam-ple in Cierto VCC [8] by the async-eventandin SystemC[2]by a self connection.The back-trackingtechniquecanbe im-plementedby locally copying the currentstateof the compo-nentbeforetakingthetransitionto thenext eventin thefuture,while the separationof event postingandcommitmentcanbedoneby self-scheduling(i.e. by committing an event on theself-connection)at the future event time and by local (at thecomponentlevel) event queuehandling. If new input eventsarereceivedbeforethe self-activation, thenback-trackingcanbe usedto remove the currentself-scheduledevents, recom-putethe future eventsandcommit the new eventson the self-connection.

In thediscreteeventdomainthesimulationfollows thedis-creteeventsimulationparadigm[7], accordingto thefollowingsimpleiterative steps.Notethatsamplingclocksmight beim-plementedboth as timers, if provided by the simulator, or asNPSblack-boxcomponents.

1. integration of the NPS black-boxcomponentsup to thenext unpredictableevent;

2. integrationof thePSblack-boxcomponentsup to thecur-renttime;

3. if no currentevent is in the event queue,the simulationis continuedup to thenext event in thequeueor thenextsamplingeventfrom any of thesamplingclocks;

4. the next instantaneousevents from the queueare con-sumedaccordingto themodelof computationembeddedin thediscreteeventsimulator;

5. go to point1.

3

Figure 3. Top view of the D/C model in Simulink

Figure 4. Flat view of the DE model in Cier to VCC

The transformationinducedby theserules and simulationalgorithm hassomelimitations. For instance,the describeddiscreteeventsimulationsupportsonly strictly causalsystems,henceit doesnot supportalgebraicclosedloops, frequentlyusedin continuous/discretetime domain.This limitation is notstronglyaffecting the designprocess.Indeed,we want to ad-dresscontrol algorithmsthat canbe actually implemented,sothatalgebraicloopsmustberesolvedbeforethetransformation.

Otherimportantlimitations needto be considered.In gen-eral, any model transformationalters the basic model prop-erties,hencemathematicalpropertiesverified on the originalmodel might not hold on the transformedone. For all thesecases,computationalconstraints,underwhich the propertieshave beenvalidated,mustbe propagatedto the discreteeventdomain. While a moreformal treatmentof the transformationis necessaryfor a generalunderstandingof the limitations, ithasbeenconsideredout of thescopeof thispaper.

TheSimulinkspecificationof theknockdetectionalgorithmwastranslatedinto a VCC behavioral descriptionthroughthefollowing steps:

1. the specificationwas initially reorganizedinto a numberof hierarchicalblocksinsideSimulink;

2. for eachleaf block in thehierarchy, C codefor theblockwas automaticallygeneratedusing or Mathworks/Real-Time-Workshopor DSPACE/TargetLink [3];

3. eachC block wasencapsulatedinto a WhiteBoxC3 shellsuitablefor integrationinto theVCC environment;

4. theWhiteBoxCblocksin VCC wereinterconnectedin theVCC environmentto reconstructtheoriginal specificationin thenew semanticdomainprovidedby VCC (Fig. 4).

Step3 is crucial in the adaptationof the original specifi-cationto the new semanticdomaindefinedby the target tool,Cierto VCC in this case. This is generallydue to the MoCcompatibility issue. For example,digital blocks in Simulinkaredefinedthroughthepresenceof triggers, whichactivatethecorrespondingblocks. In VCC behavioral descriptions,everyinput to eachblock is consideredasa trigger, thereforeblockexecutionsin thetwo environmentsarenot in one-to-onecorre-spondence.Moreover, thespecificfiring rule in VCC (simulta-neousinputsto ablockarecomputedoneat timein unspecifiedorder)introducesothersourcesof difficultiesin thetranslation

3WhiteBoxCareleafblockcomponentsspecifiedin asubsetof C language.

S[

imulation (\D/C)

S[

imulation (\DE)

F f

M]

odel (\D/C)

M]

odel (\DE)

f

T^

races (\D/C)

T^

races (\DE)

Simulation Traces (D/C)

Simulation T_

races (DE)

Figure 5. Relations between models, sim ulationsand traces

process,if functionalequivalenceis desired.In contrast,Sys-temCdoesnotsuffer from thisfiring ruleproblem(inputvaluescanbelocally synchronized),but thisis only becausewestartedfrom aMatlab/Simulinkspecification,whosemodelof compu-tationwell adaptsto thatof SystemC.

5 Functional validation

Whenthe MoC compatibility issueapplies,the problemofthe validation of the transformedmodel againstthe originalmodel needto be addressed. Indeed, the needof ensuringthat the two modelsareequivalentstemsfrom therequisiteofcorrectlypropagatingthe systempropertiesfrom the originalmodeldown to implementation.

To addressthis problem two approachesare possible:correct-by-constructiontransformationsandequivalenceveri-fication. The former approachis fairly complex, especiallywhendealingwith different time domainsandMoCs, so thatonly simplepropertiescanberigorouslytreated.Thelatterap-proachon the otherhandis computationallyintractableandisusually replacedby functional validation, which is basedonsimulation,thusbeinga heuristicnon-exacttechnique.This isthe currentapproachin industrialdesignandrequiresa greatdealof designer’s interaction.Equivalenceby simulationis de-finedby meansof equivalenceof simulationtraces.Thissemi-formal definitionof equivalenceis basedon thecomparisonofsimulationresults,requiringa deepunderstandingof the exe-cutionsemanticsof bothsimulatorsandof the transformationbetweenthemodels.In generalthesesimulationtracesarehet-erogeneous,for they are drawn from different time domains.

Fig. 5 shows the relationshipbetweenmodels,simulationsandsimulationtraces.Thechoicefor atransformationbetweenthe models,called ` in Fig. 5, is pairedwith a choiceof atransformationa onthesetof all traces.In moreintuitiveterms,thetransformationa correspondsto asetof rulesfor convertingcontinuousandsampledsignals(or morein generaltraces)intosequencesof eventscalled event signals (or more in generaldiscreteeventtraces).For example,a squarewaveformcanbetransformedinto an event signalby definingan event at eachchangeof value.

Simulationsdefinetime interpretationsof traces,calledsim-ulationtraces,accordingto thespecificMoC of thecorrespond-ing simulators.For example,while discreteevent tracesonlydefinea partialorderbetweenevents,their correspondingsim-ulation tracesaremadeup of a total orderedsetof events,ac-cording to the simulator’s MoC. In other words, the discreteeventsimulatordefinesamappingfrom partialorderedtracestototalorderedtracesdefinedon theunderlyingsimulationtime.

It is clearthatin orderto comparesimulationtraces,weneedto abstractfrom the underlyingsimulationtime. The relationbetweenthesimulationtracescanthenbeestablishedin termsof the transformationa appliedto the setof simulationtraces:

4

Figure 6. Acceler ometric input validation

Figure 7. Energy computation validation

two simulationtraces�:bLc=d

and� b&e

aresaidto beequivalentif a ���b�c(d�%&�f� b&e .

The automationof the transformationprocesscan be ad-dressedby defininga classof functionally invariant transfor-mationsbetweenthemodels,i.e. suchthattheequivalencecon-dition, namely a ���b�c(d�%g�h� b&e

, be satisfiedby construction.Theway to thedefinitionof suchtransformationscanbepavedby introducingspecificdesignstylesat thecontinuous/discretetime level of specification,which thesystemmodelmustcom-ply with. Adapting a legacy specificationto a given designstyleis in generalaneasierproblem,for it requiresanhomoge-neous(in termsof specificationenvironment,time domainandmodelof computation)transformationof the modelspecifica-tion. Note that automatedtransformationsmay ensureexactequivalenceof closedsystems(i.e. wherethe environmentiscomprisedin themodel),for it doesnot rely on equivalencebysimulationtraces.

From the discussionabove it is clearthat functionalequiv-alenceis far from beingstraightforward and,even after auto-matic translation,the viability of functionalvalidationstill re-mainsof inestimablevalue. This hasbeenmadepossibleinVCC by the creationof matlab-probesthat allow to provideVCC simulationdatain *.mat format, suitablefor integrationinto Simulink functionalsimulations. The comparisonof thesimulationdatawithin the Simulink environmentis shown inFig. 6 andFig. 7.

6 Design exploration

The applicationdescribedin Section2 presentsinterestingimplementationtrade-offs thatmustbeaccuratelyinvestigatedespeciallyasregardsits coexistenceonthesamehardwareplat-form with other importantenginecontrol functionalities. Inparticular, real time aspects(dueto filtering functions)of theknockdetectionfunctionalityrequireearlyassessmentsof over-all computationalloadsin order to carefully definethe hard-warepartitionof theplatformsoto minimizecostwithoutcom-promisingperformance.In thesequel,anexampleof architec-tural explorationis presented,showing how early decisionsinthe designprocesscanbe taken by taking advantageof earlydesignspaceexploration.

Behavior adaptation and validation: oncethe behavioraldescriptionwas madeavailable in VCC, it hasbeenadapted

Figure 8. Performance sim ulation: target system

20 40 60 80 100 120 140 1600

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

x 10−3

Buffer Length

Tim

e

Execution Time

Simulated PowerSpecturmDensityFxPtSimulated TimeTask

Figure 9. Results of perf ormance sim ulation

to performarchitecturalexploration. In particular, the PowerSpectrumEstimation(PSE)hasbeenencapsulatedinto a pa-rameterizedfor-loop in orderto performthecomputationusinga bufferizationof the samples.The bufferizationis necessaryto migratethe computationallyintensive PSEtaskfrom hard-wareto software,allowing to tradeoff computationalpowerforsilicon area.Theparameterizationof theloop enablesthesim-ulationof severalbuffer lengthsto look for anoptimumvalue.Themodifiedspecificationhasbeenthenbehaviorally validatedagainsttheoriginal specificationthroughfunctionalsimulationin VCC andSimulink (Fig. 6 andFig. 7).

Mapping of behavior onto architecture: before archi-tectural exploration we needto define the completesystemmodelby mapppingthebehavioral specificationontoanarchi-tecturalmodel, in this casethe JANUS [6] (a dual-processormicro-controllerbasedon ARM7TDMI) VCC architecturalper-formancemodel(Fig. 8). ThePSEandmostof theknockde-tectionfunctionalityhasbeenmappedto software(on the twoprocessors).Thebuffer betweentheA/D converterandthePSEfilter hasbeensimulatedusinga behavioral memory[8], i.e. areferenceto a setof memoryelements(e.g. RAM, registers,etc.)of anarchitecturalmodel.

Architectural exploration: the main purposeof architec-tural explorationin this applicationhasbeenestablishedto betheestimationof thecomputationalloadrequiredby thespeci-ficationandtheanalysisof theinteractionsof theknockdetec-tion with otherenginecontrol functionalities. To accomplishthis, we simulatedthe interactionof theknockdetectionfunc-tionality with a task,thatwe will call TimeTask, of a fixedex-

5

20 40 60 80 100 120 140 1600

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

x 10−3

Buffer Length

Tim

e

Execution Time

Simulated PowerSpecturmDensityFxPtTeoretical Curve of TimeTaskSimulated TimeTask

Figure 10. Comparison with theoretical cur ve

ecutiontime ofS 0ji (whennot preempted),activatedon every

TDC. TheTimeTask is givenlower priority thanthePSEtask,sothat its actualexectutiontime dependson thenumberof in-terruptionsdueto preemptionby thehigherpriority task.Afterthemappingphase,a setof buffer lengthvalueshasbeencon-sideredfor simulation(Fig. 8).

Simulation results: the computationalload of the knockdetectionalgorithmis dominatedby the PSEtask. The com-putationalloadpersamplehasbeenmeasuredto be

*1S � clockcycleson the ARM7TDMI processor. If 8 6 is the numberofsamplesper acquisition,the pure CPU time for this task peracquisitionis givenby

��kGl e �m 8 6 " *nS � %='�57oAp . We usedac-quisitionsof about K���� samplesat K������-(.40 , so that

��kGl e � K���G" *nS � %='n ���qr��� %G�rSs ��C0ji . Eachacquisitionneedto becarriedoutbetweentwo TDC occurrences,i.e. theallottedtimeis���tu�� �� 'n 8wv b&d "4-/.10 %x� �� ') Kx":K����� %7�rS �C0ji . Hence,

thepureCPUloadperacquisitionfor thePSEfunctionality isS�s ��� ')S � �rS �zy . To this theoperatingsystemoverloadneedtobeadded.Sincetheoperatingsystemloadis morethansignif-icant, we consideredsamplingbufferizationto reducecontextswitchingactivity. We exploredseveral buffer dimensionsbytaking the buffer lengthasa parameterin the simulations.AsexpectedtheTimeTask’s actualexecutiontimedecreasesasthebuffer lengthincreases(Fig.9),showing thatthesmallestbufferlengthat which thetaskexecutiontime is minimumis

S{* � ( ���samples,for thebuffer is dividedin two segmentsto avoid sam-pleoverwriting).

Validation of the simulation process: theperformancere-sultswherevalidatedusingasimplifiedmapping,wherespecif-ically the interactionsbetweentheTimeTaskandthe PSEtaskarecarefully investigated.For sucha mappingwe wereabletocomputeby paperandpenciltheexactexecutiontimecurvefortheTimeTask(Fig. 10), showing thatthesmallestbuffer lengthfor which thetaskexecutiontime is minimumis

SS � ( �� sam-ples). Fig. 10 shows that in the simplified mappingthe exe-cutiontime curveobtainedby performancesimulationin VCCcloselyapproximatethetheoreticcurve,providing thesamere-sult for the smallestbuffer lengthensuringthe minimum taskexecutiontime.

7 Conclusions

The designof a knock detectionalgorithm and of its im-plementationhasbeenaddressed.In our flow, a mathematicalmodelof thesystemfunctionality (e.g. a controlalgorithm)isdefinedby thedesigner, who elaboratesthis functionalityuntilthe desiredmathematicalpropertiesaremet. The mathemati-

cal specificationobtainedis thentranslated,possiblyautomati-cally, intoabehavioral specificationwithin adiscreteeventsim-ulation environmentanda setof platformsareconsideredforimplementation.At this stepbehavioral simulationof thenewspecificationis usedto obtaindatafor thefunctionalvalidationagaistthe original specification.Several mappingsof the be-havioral specificationon thearchitecturalmodelsarethentriedout andmerit figure analysisis usedto choseheuristicallyanoptimizedsystemmapping.

The designflow requiredthe useof different tools at dif-ferent levels of abstraction.The mostchallengingprobleminthis exercisewasto relatethedifferentmodelsof computationusedby the two tools. This is anessentialproblemin system-level designwherea unified designenvironmentis still in itsinfancy. We indicatedtheproblemsto solveanddescribedhowwe mappeda modelof computationinto another. Someexper-imentalresultson platformselectionweregiven.

References

[1] http://www.mathworks.com/.

[2] http://www.systemc.org.

[3] http://www.dspaceinc.com/en/Products/PCGS.htm.

[4] A. Balluchi,L. Benvenuti,M. D. Di Benedetto,C.Pinello,and A. L. Sangiovanni-Vincentelli. Automotive enginecontrol and hybrid systems:Challengesand opportuni-ties. Proceedingsof theIEEE, 88, “SpecialIssueon Hy-brid Systems”(invitedpaper)(7):888–912,July2000.

[5] S. Edwards,L. Lavagno,E.A. Lee,andA. Sangiovanni-Vincentelli. Designof embeddedsystems:Formalmod-els, validation,andsynthesis.Proceedingsof the IEEE,85(3):366–390,March1997.

[6] A. Ferrari, S. Garue, M Peri, S. Pezzini, L.Valsecchi,F. Andretta,andW. Nesci. The designand implmenta-tion of a dual-coreplatform for power-train systems.InConvergence2000, October2000.

[7] S. Ghoshand E. Debenedictis. An asynchronousdis-tributeddiscreteeventsimulationalgorithmfor cyclic cir-cuitsusinga data-flow network. In Proceedingof theIn-ternationalConferenceonSystems,ManandCybernetics,October1991.

[8] CadenceDesign SystemsInc. Cierto vcc user guide,1998.

[9] K. Keutzer, S. Malik, A.R. Newton, J.M. Rabaey,and A. Sangiovanni-Vincentelli. System-level design:Orthogonalizationof concernsand platform-basedde-sign. IEEE Transactionson Computer-Aided Design,19(12):1523–1543,December2000.

[10] S. Mayes. Mixed-signalsimulationissuesfor top-downdesign.In ElectronicsEngineer, DesignCornerII , Octo-ber1997.http://www.jat.co.kr/eda/saber/topdown.pdf.

[11] ScottRanville. Practicalapplicationof model-basedsoft-waredesignfor automotive. In Societyof AutomotiveEn-gineers (SAE)Conference, May 2002.

[12] M. Sgroi, L. Lavagno,and A. Sangiovanni-Vincentelli.Formal modelsfor embeddedsystemdesign. IEEE De-signandTestof Computers, 17(2):14–27,April 2000.

6