Benchmarking, System Design and Case-studies for Multi-core based Embedded Automotive Systems

0.58 MB·

by  Piotr Dziurzanski

Benchmarking, System Design and Case-studies for
Multi-core based Embedded Automotive Systems
Piotr Dziurzanski, Amit Kumar Singh, Leandro S. Indrusiak Bjo¨rn Saballus
Department of Computer Science Robert Bosch GmbH
University of York Corporate Sector Research and Advance
Deramore Lane, Heslington, York, YO10 5GH, UK Engineering - Software (CR/AEA2)
Postfach 30 02 40, 70442 Stuttgart, Germany
{PD678, Amit.Singh, Leandro.Indrusiak}@york.ac.uk [e-mail]
6
1
0 Abstract—In this paper, using of automotive use cases as a benchmark suite for microcontrollers aimed at making
2 benchmarks for real-time system design has been proposed. The automotive end products more energy efficient and robust.
use cases are described in a format supported by AMALTHEA
n Thesebenchmarksuitesarelicensedforcorporateoracademia
platform, which is a model based open source development
a researchers and thus their availability is limited.
J environment for automotive multi-core systems. An example
of a simple Electronic Control Unit has been analysed and
4 MiBench[6]isasetof35embeddedapplicationsforbench-
presented with enough details to reconstruct this system in
1 any format. For researchers willing to use AMALTHEA file marking purposes. Six C-codes are categorised as automotive

format directly, an appropriate parser has been developed and and industrial control, but they are just standard algorithms
]
C offered1.Anexampleofapplyingthisparserandbenchmarkfor (basic math, bitcount, quick sort, and image recognition) used
optimising makespan while not violating the timing constraints
D often in that domain. However, no whole automotive applica-
byallocatingfunctionalitytodifferentNetworkonChipresource
s. is demonstrated. tion implemented in an Electronic Control Units (ECUs) can
c be found in this suite. For automotive multi-core microcon-
[ I. INTRODUCTION troller, more realistic use cases, such as described in [8], are

needed.
1 Evaluating automotive real-time multicore system design
v
algorithms using some industrial application benchmarks can Recently, a model based open source development environ-
8
0 be viewed as a factor to increase the reliability of the al- ment for automotive multi-core systems called AMALTHEA
7 gorithms. Since a limited number of these benchmarks is hasbeendeveloped[1].Theresultingtoolplatform,distributed
3 publicly available, new sets of industrial use cases are usually under an Eclipse public license, supports multi-core automo-
0
welcomed by the real-time research community [9]. One of tive systems compatible with the AUTOSAR (AUTomotive
.
1 such benchmarks is an autonomous vehicle, introduced in OpenSystemARchitecture)standard[2].Inthispaper,apossi-
0
[11],anotherareal-timejetengineperformancecalculator[9]. bilityofusingtheAMALTHEAplatformforgeneratinganew
6
1 Some researchers address the lack of application benchmarks suites of automotive benchmarks is investigated. DemoCar,
: by generating synthetic benchmarks, imitating real industrial a simple engine control application provided as an example
v
i processes [4]. in the AMALTHEA platform distribution is presented and
X According to [3], one of the most crucial issues of automo- analysed. Since the authors of the AMALTHEA environment
r tive industry is to boost the technology to reduce emissions hasnotprovidedaC-basedcodeforparsingAMALTHEAfile,
a
andincreasefueleconomyofcars.Further,inthesamereport we have developed a simple C++ parser and offered it to the
it is being forecasted that the market for automotive engine community1. The architecture and main functions of this tool
management systems will grow 8.09% annually, reaching are explained in this paper. As a case-study, one example of
197 billion USD by 2019. Therefore, sooner or later, the a system design using this ECU is demonstrated.
growing importance of automotive system benchmarking can
be predicted. In the following section, some basic information about
Some basic automotive algorithms, including controller ECUsareprovided,includinganAMALTHEAautomotiveap-
areanetwork(CAN),tooth-to-spark,angle-to-timeconversion, plicationmodeldescription.Then,insectionIII,AMALTHEA
road speed calculation, and table lookup and interpolation file format is explained. Section IV provides details about
are present in AUTOBENCHTM suite from the Embedded the DemoCar ECU, which can be parsed by an open-source
Microprocessor Benchmark Consortium (EEMBC). The same parser1 prepared by the authors to read AMALTHEA format
consortium cooperates with Volkswagen Group to establish files and presented in section V. An example of its usage in
a genetic-algorithm-based resource allocation is presented in
1http://www.dreamcloud-project.org section VI. Section VII concludes the paper.
II. BACKGROUNDINFORMATION Runnables communicate with each other using labels, data
elementslocatedinmemorywithcertainbitlength.Activations
Electronic Control Units (ECU) are omnipresent in con-
may be single, sporadic, periodic or performed according to
temporary cars. Their primary role is to measure, control and
a custom pattern. Stimulus and clock objects are described in
steer physical actuators of cars like braking, engine control,
stimuli model.
transmissionsystems,headunits,carmultimediasystems,etc.
There exists a number of ECU standards. Component based
IV. DEMOCAREXAMPLE
software design model is standardized by AUTOSAR [2],
whichintroducesfourbasicelementsofabstractrepresentation We evaluate the AMALTHEA framework with a simplified
of an automotive application: model of an engine control application named DemoCar. It
consists of 6 tasks presented in Table I. Four of them are
• executable entities (called runnables),
periodic, activated respectively every 5ms, 10ms, 20ms, and
• events that trigger execution of runnables,
100ms,withrelativedeadlinesequaltotheperiods.Twotasks
• labels representing data elements that can be read or
areaperiodic:CylNumTriggeredTaskandActuatorTask,which
written by runnables,
are invoked by an RTOS. These tasks have no deadlines.
• data dependencies between runnables and labels.
The runnables executed by these tasks are listed in Tab. II.
A runnable can be seen as an atomic execution entity,
The labels used in the DemoCar use case are itemised in Tab.
generated from, e.g., a function written in C language or a
III. They are read and written by runnables, as indicated in
Simulink model. Each runnable is triggered with an event.
the 3rd and 4th columns of Table II. For example, runnable
After its occurrence, the runnable should be executed and
OperatingModeSWCEntity in Task20ms determines the mode
finished before its deadline. Events may be either periodic
in which the engine is currently operating using six read
(for instance, occurring every 5ms) or aperiodic (for instance,
labels.Theselabelsformconditionsformodechanging,which
depending on value of certain labels). Runnables are executed
is illustrated in Fig. 1. To make this figure more readable,
inorderrespectingthedependenciesbetweenreadandwritten
these conditions have been removed from the figure, but for
labelssothatwritersaretobeexecutedpriortoreadersofthe
exampletochangethecurrentmodefromPowerUptoStalled,
same label. If more than one event occurs at the same instant,
expression PowerUpComplete∧IgnitionOn shall be true,
they can be handled in a nondeterministic order.
whereas to move to WaitForPowerDownDelay from all the
An AUTOSAR model, however, is too detailed for per-
states drawn on the right side of PowerUp IgnitionOn must
forming fast design decision, since software components
equal false.
(runnables) are given in compilable C-codes which require
The static structure of DemoCar is visualized in Figure 2.
a selected RTOS code and run-time environment. Therefore,
Labels are depicted as ellipses and Runnables as rectangles.
all necessary data, such as runnable size, dependency, their
Thecolorforlabelsdenotestheoperationperformed.Labelsto
execution time, as well as label sizes and execution semantics
bereadaregreen,whereaslabelstobewrittenarelight-violet.
are described by relatively simple AMALTHEA format. The
Thecolorofrunnablesrepresentstheperiodoftheiractivation.
possibility of optimizing the runnable and task mapping of
Red stands for high activation rate (5ms period), orange for
an application described by an AMALTHEA file is presented
10ms, yellow for 20ms and white for 100ms period. Light-
later in this paper.
blue rectangles indicate runnables started on an asynchronous
III. AMALTHEAFILEFORMAT event,eitheronmessage-receptionorstartingofthesystem.To
Despite being a rather compact format, AMALTHEA in- improve the readability of this figure, some arrows have been
cludesenoughinformationforsolvingdifferentsystemdesign drawnwithdifferentcolorswhichhavenoparticularmeanings.
problems. In this section, this format is briefly described. In the AMALTHEA format, each runnable contains an
Both hardware and software models of the system under instruction list which includes a set of labels to be read
development are stored in a file based on the XML format. and write to, and the runnable computation time. For exam-
The hardware model describes a system typically composed ple, in runnable APedSensor, two voltage values from two
of a number of ECUs, microcontrollers, cores, memories, sensors (stored in labels APedSensor1Voltage and APedSen-
network, etc. Software model describes processes, labels and sor2Voltage, reflecting the current accelerator pedal position,
activations. represented as PedalAngles in Figure 2) are read. Then, they
The processes generalize tasks and Interrupt Service Rou- are transformed into the corresponding percentage value and
tines (ISR). They may be characterised with certain priority, written to other labels: APedPosition1 and APedPosition2.
used during process scheduling, or activation represented by EcuBrakePedalSensorreadsthebrakepedalpositioninvoltage
certainstimulus.Anyprocesscancontaincallstoothertasksor delivered by the sensor and translates it to a percentage of
ISRs together with their execution orders. Alternative execu- brake pedal position. MassAirFlowSensor reads the current
tionpathscanbedefinedbasedonlabelvaluesorprobabilities. mass air flow value from sensor in voltage and translates it
A process can activate another process, invoke a runnable or to a value in kg/h. ThrottleSensor reads the throttle position
synchronise tasks using events issued by operating system. from two redundant sensors in voltage and transforms them
WaitForAFR
PowerDownECU PowerUp Stalled Cranking IdleOpenLoop IdleClosedLoop Drive WaitForOverrun Overrun
Feedback
WaitForPower
DownDelay
Fig.1. DemoCaroperatingmodesdescribedbyaFiniteStateMachinestoredinOperatingModeSWCEntityrunnable
TABLEI TABLEIII
TASKSINDEMOCARBENCHMARK LABELSINDEMOCARBENCHMARKANDTHEIRLENGTHS(INBITS)
Name Activation Priority Name Bitlength Name Bitlength
CylNumTriggeredTask aperiodic 30 AcceleratorPedalPosition1 16 InjTimeCyl3 16
ActuatorTask aperiodic 25 AcceleratorPedalPosition2 16 InjTimeCyl4 16
Task5ms period5ms 20 AcceleratorPedalPositions 16 InjTimeCyl5 16
Task10ms period10ms 15 AFRFeedbackFlag 1 InjTimeCyl6 16
Task20ms period20ms 10 BaseFuelMassPerStroke 16 InjTimeCyl7 16
Task100ms period100ms 5 BatteryVoltage 16 InjTimeCyl8 16
BatVoltCorr 16 InletAirTemperature 8
CoolantTemperature 8 LambdaCat1 16
CrankFlag 1 LambdaCat2 16
CylinderNumber 8 MafRateOut 16
DesiredThrottlePos 16 MAFSensor 16
to percentage and determines a voted throttle position value.
DesiredThrottlePosOut 16 MAFSensorVoltage 8
APedVoterreadstheacceleratorpedalpositionsandcomputes EngineSpeed 16 OverrunFlag 1
FuelEnabled 1 OverrunFuelShutoffFlag 1
a voted accelerator pedal position. BaseFuelMass reads the
IdleFlag 1 OverrunIgnitionRetard 8
mass air flow from MassAirFlowSensor and determines the IdleIgnitionCorrection 8 PedalAngle1 16
IdleOLFlag 1 PedalAngle2 16
basefuelmassperstroke.CylNumObserverobservesrequests
IdleSpeedSetpoint 16 PowerUpComplete 1
fortheinjectiontimeandignitiontimeparametersforspecific IdleThrottleCorrection 16 RateOfThrottleChange 16
IgnitionOn 1 ThrottleAngle1 16
cylinders. IgnitionTimeActuation reads the pre-calculated ig-
IgnitionTime1 16 ThrottleAngle2 16
nition time value from IgnitionTimingSWC. IgnitionTiming IgnitionTime2 16 ThrottleImpulseBeta1 16
IgnitionTime3 16 ThrottleImpulseBeta2 16
reads the determined mass air from BaseFuelMass and deter-
IgnitionTime4 16 ThrottlePosition1 16
mines the optimal ignition time for combustion process. In- IgnitionTime5 16 ThrottlePosition2 16
IgnitionTime6 16 TotalFuelMassPerStroke 16
jectionTimeActuation reads the pre-calculated total fuel mass
IgnitionTime7 16 TransientFuelMassPerStroke 16
perstrokefromTotalFuelMassandtransformsittoaninjection IgnitionTime8 16 TriggeredCylinderNumber 8
IgnitionTiming 8 UpdatePeriod 16
time value. ThrottleActuator takes the new throttle position to
InjTimeCyl1 16 VehicleSpeed 16
be set as a percentage value and transforms it to a voltage InjTimeCyl2 16 VotedPedalPosition 16
value. ThrottleController determines the desired throttle po-
sition using the voted pedal position and determines the new
V. PARSINGAMALTHEAMODEL
throttlepositiontobeset.TotalFuelMassreadsthedetermined
transient fuel mass per stroke from TransientFuelMass and One of the issues hindering the community from using
determines the total fuel mass per stroke. TransientFuelMass AMALTHEA files as benchmark for research is the lack of
reads the base fuel mass per stroke from BaseFuelMass and C++ based parser in the platform release. To overcome this
compensates this mass for specific wall-wetting effects in the limitation, we have developed a software module to read
intake system. More details on some of these runnables are and parse AMALTHEA file format. The main classes of this
provided in [5]. module, together with their dependencies, are presented in
Figure 3. In the proposed implementation, Apache Xerces
It is worth noting the compactness of the format. For
C++2,athird-partytoolforparsing,validating,serializingand
example, APedSensor is described by only 15 xml lines,
manipulating XML, is used by the AmaltheaSystem singleton
whereas its total code in C language requires 163564 bytes.
class. This class includes containers (both lists and maps) for
Despite this brevity, it is possible to extract all dependencies,
mainentitiespresentintheAMALTHEAfiletogetherwiththe
as the labels to be read and written by this runnable are
appropriate member access functions. It is treated as the entry
provided explicitly. Additionally, the memory footprint size,
and execution time distribution is also provided. 2https://xerces.apache.org/xerces-c/
TABLEII
RUNNABLES,THEIRMEMORYFOOTPRINTINBITS(SIZE),READANDWRITTENLABELS,LOWER(BESTCASEEXECUTIONTIME-BCET)ANDUPPER
BOUND(WORSTCASEEXECUTIONTIME-WCET)OFEXECUTIONTIME(INµS)
Task Runnable Size Readlabels Writtenlabels BCET WCET
k
ylNum-geredTas CylNumObserverEntity 55600 CylinderNumber TriggeredCylinderNumber 434 1145
Cg
Tri
IgnitionSWCSyncEntity 72512 IgnitionTiming, EngineSpeed, TriggeredCylin- IgnitionTime1,IgnitionTime2,IgnitionTime3,Ig- 2728 4921
ctuator-Task InjectionSWCSync 69824 TdeortNaluFmuebleMrassPerStroke, CrankFlag, Triggered- ntIiniotjinToTinmiTmeiCme7ye,l41I,g,IngiIntniiojtTinoiTnmiTmeiCme8yel52,,IgInnijtTioimnTeiCmyel63,,IgInnij-- 1644 3302
A CylinderNumber,EngineSpeed,BatVoltCorr TimeCyl4, InjTimeCyl5, InjTimeCyl6, InjTime-
Cyl7,InjTimeCyl8
MassAirFlowSWCEntity 56608 MAFSensorVoltage MAFSensor 55 172
ms ThrottleSensSWCEntity 58816 ThrottleAngle1,ThrottleAngle2 ThrottlePosition1,ThrottlePosition2 113 337
5
Task APedSensor 66288 PedalAngle1,PedalAngle2 sAitcicoenl2eratorPedalPosition1, AcceleratorPedalPo- 555 964
APedVoterSWCEntity 56832 AcceleratorPedalPosition1, AcceleratorPedalPo- VotedPedalPosition 87 287
sition2
ThrottleCtrlEntity 70944 CoolantTemperature,EngineSpeed,MAFSensor, BaseFuelMassPerStroke,MafRateOut 3664 5783
ThrottlePosition1,ThrottlePosition2
ThrottleActuatorEntity 128464 CoolantTemperature, CrankFlag, DesiredThrot- RateOfThrottleChange, ThrottleImpulseBeta1, 3788 5913
tlePosOut, EngineSpeed, FuelEnabled, Inle- ThrottleImpulseBeta2
tAirTemperature,OverrunFlag,UpdatePeriod
BaseFuelMassEntity 70944 CoolantTemperature,EngineSpeed,MAFSensor, BaseFuelMassPerStroke,MafRateOut 3664 5783
ThrottlePosition1,ThrottlePosition2
ThrottleChangeSWCEntity 128464 CoolantTemperature, CrankFlag, DesiredThrot- RateOfThrottleChange, ThrottleImpulseBeta1, 3788 5913
tlePosOut, EngineSpeed, FuelEnabled, Inle- ThrottleImpulseBeta2
ms tAirTemperature,OverrunFlag,UpdatePeriod
10 TransFuelMassSWCEntity 128464 InletAirTemperature, CoolantTemperature, TransientFuelMassPerStroke 3985 6376
k
Tas MRaatfeROaftTeOhruott,tleChEannggien,eSpeTehdr,ottleIUmppdualtseePBeeritoad1,,
ThrottleImpulseBeta2, OverrunFuelShutoffFlag,
CrankFlag, FuelEnabled, BaseFuelMassPer-
Stroke
IgnitionSWCEntity 66784 CrankFlag, MafRateOut, EngineSpeed, IgnitionTiming 3047 4537
InletAirTemperature, OverrunIgnitionRetard,
IdleFlag, IdleOLFlag, IdleIgnitionCorrection,
CoolantTemperature
TotalFuelMassSWCEntity 66432 CrankFlag, LambdaCat1, LambdaCat2, TotalFuelMassPerStroke 743 1354
CoolantTemperature, OverrunFuelShutoffFlag,
TransientFuelMassPerStroke
OperatingModeSWCEntity 139392 EngineSpeed, VehicleSpeed, IgnitionOn, OverrunFuelShutoffFlag, IdleFlag, IdleOLFlag, 18612 39281
ms PowerUpComplete, VotedPedalPosition, CrankFlag, OverrunFlag, FuelEnabled, AFR-
0 IdleSpeedSetpoint FeedbackFlag, OverrunIgnitionRetard, Update-
k2 Period
Tas IdleSpeedCtrlSWCEntity 66976 IdleFlag,EngineSpeed,CoolantTemperature IdleSpeedSetpoint, IdleThrottleCorrection, 913 1686
IdleIgnitionCorrection
ms
0 APedSensorDiag 66288 PedalAngle1,PedalAngle2 102 235
0
k1 InjBattVoltCorrSWC 56928 BatteryVoltage BatVoltCorr 290 547
Tas
LambdaCat
APedSensor APedVoterSWCEntity
PedalAngles
APedSensorDiag
VehicleSpeed
ThrottleCtrlEntity ThrottleActuatorEntity DesiredThrottlePos
EngineStartUpStates OperatingModeSWCEntity TotalFuelMassSWCEntity
ThrottleChangeSWCEntity
TransFuelMassSWCEntity
EngineSpeed IdleSpeedCtrlSWCEntity
InjectionSWCSync InjectionTime
IgnitionSWCEntity
IgnitionSWCSyncEntity IgnitionTimes
MAFSensorVoltage MassAirFlowSWCEntity
BaseFuelMassEntity
ThrottleAngles ThrottleSensSWCEntity
Temperatures
CylinerNumber CylNumObserverEntity TriggeredCylinderNumber
BatteryVoltage InjBattVoltCorrSWC
Fig.2. StaticstructureofDemoCarECU
TABLEIV
AMALTHEASYSTEMCLASSMEMBERFUNCTIONSRETURNING
Stimulus * CoreType INFORMATIONFETCHEDFROMANAMALTHEAFILESOFTWAREMODEL
1
Function Description
Runnable * 1 Task * 1 AmaltheaSystem Core Label* GetLabel(int In- ReturnsLabelobjectstoredintheinternallistinthe
dex); Indexposition
1 * intGetNoOfLabels(); Returns the number of Label objects stored in the
internallist
Quartz Label* GetLabel(string ReturnsLabelobjectwiththeprovidedID
Instruction
IDIn);
Label* GetLabelBy- ReturnsLabelobjectwiththeprovidedname
Name(stringNameIn);
int GetIndexOfLa- ReturnspositionoftheprovidedLabelobjectinthe
ExecutionCyclesDeviationInstruction RemoteAccessInstruction bel(Label*LabelIn); internallist
Runnable* ReturnsRunnableobjectstoredintheinternallistin
GetRunnable(intIndex); theIndexposition
ExecutionCyclesConstantInstruction GroupInstruction Label Runnable* ReturnsRunnableobjectwiththeprovidedID
GetRunnable(stringIDIn);
intGetNoOfRunnables(); ReturnsthenumberofRunnableobjectsstoredinthe
internallist
int GetIndex- ReturnspositionoftheprovidedRunnableobjectin
OfRunnable(Runnable* theinternallist
Fig.3. UMLclassdiagramofAMALTHEAfileparser RunnableIn);
Stimulus*GetStimulus(int ReturnsStimulusobjectstoredintheinternallistin
Index); theIndexposition
intGetNoOfStimuli(); ReturnsthenumberofStimulusobjectsstoredinthe
point to the module whose interface can be used to fetch both internallist
Task*GetTask(intIndex); ReturnsTaskobjectstoredintheinternallistinthe
thesoftwareandhardwaremodelsfromtheAMALTHEAfile. Indexposition
intGetNoOfTasks(); Returns the number of Task objects stored in the
internallist
Label* GetLabelWithIn- ReturnsLabelobjectstoredintheinternallistinthe
A. Parsing AMALTHEA Software Model
dex(intIndex); Indexposition
Runnable* GetLabels- ReturnsaRunnableobjectreadingfromtheprovided
The classes representing entities of the AMALTHEA soft- Dest(Label*LabelIn); Labelobject
Runnable* GetLa- Returns a Runnable object writing to the provided
waremodelaredepictedleftandbeneaththeAmaltheaSystem
belsSource(Label* Labelobject
class in Figure 3. The Label class represents data elements, LabelIn);
Runnable represents executable entities that perform calcula-
tion and read/write accesses to labels, Task represents clusters TABLEV
of runnables. The objects of these classes are created and AMALTHEASYSTEMCLASSMEMBERFUNCTIONSRETURNING
INFORMATIONFETCHEDFROMANAMALTHEAFILEHARDWAREMODEL
stored by the AmaltheaSystem class. Its member function
can be used to obtain the needed data. The most important
Function Description
functions returning information about the software model CoreType* GetCoreType(string ReturnsCoreTypeobjectwiththeprovided
fetchedfromanAMALTHEAfilearesummarisedinTableIV. IDIn); ID
Quartz*GetQuartz(stringIDIn); ReturnsQuartzobjectwiththeprovidedID
TheAMALTHEAsoftwaremodelisstoredinthefollowing Core*GetCore(stringIDIn); ReturnsCoreobjectwiththeprovidedID
Core*GetCore(intIndex); ReturnsCoreobjectstoredintheinternallist
way. For each runnable, a job object is created, whereas the
intheIndexposition
runnable execution order defined inside a task is reflected intGetNoOfCores(); ReturnsthenumberofCoreobjectsstored
intheinternallist
into dependencies of these job objects. All the dependencies
described by stimuli are reproduced in a similar manner.
VI. CASESTUDY:RESOURCEALLOCATIONFOR
B. Parsing AMALTHEA Hardware Model
AUTOMOTIVEDEMOCARBENCHMARKREPRESENTEDIN
The classes representing entities of the AMALTHEA hard- AMALTHEAFORMAT
ware modelare depictedright tothe AmaltheaSystem classin For the example DemoCar benchmark to be executed on
Figure 3. The Core class represents a processing core execut- a multi-core embedded system, we evaluate makespan (also
ing tasks. Each core is associated with a particular CoreType known as response time) and number of violated deadlines
element,wherethenumberofclockticksneededforexecuting during one hyperperiod (i.e., the least common multiple of
a single instruction is provided. Each core is connected with all runnables’ periods) by allocating runnables and labels to
a Quartz object, providing a clock frequency. In the current differentcores.Inthisexperiment,weuseageneticalgorithm
version of implementation, we ignore the information about that aims to explore the allocation space towards achieving
memories stored in the AMALTHEA file, but we plan to solutions with optimised timing behaviour [10]. For demon-
add it in future releases of the parsing module. The member stration, a Network on Chip (NoC) based multi-core platform
functions returning information about the hardware model withXYroutingalgorithmhasbeenchosen.FortheDemoCar
fetchedfromanAMALTHEAfilearesummarisedinTableV. application, the size of the mesh has been initially configured
120 VII. CONCLUSIONS
140000 Makespan
Missed deadlines AMALTHEA open source development environment for
100
120000 multi-coresystemscanbeusedtogenerateautomotivebench-
n [ms]Makespa 1 068000000000000 468000 Missed deadlines mchinaaassorektsbhs,eeserfinomfirdillereaesrfacotlro-ritmbidmeaedtmes.iocnnosdmtermtaatuielndsitDsyoemstthroiavCtianirtgecxfaoanrmbcpelloers.eeTc-thooin-sslistfryeusctuetesmde
40000 TofacilitateusingAMALTHEAtogeneratebenchmarks,an
20 AMALTHEAformatparserhasbeendevelopedandpublished.
20000
Thisparserhasbeenintegratedwithageneticalgorithmframe-
0 0 work and schedulability analysis to perform a functionality to
0 10 20 30 40 50 60 70 80 90 100
multi-core system resources allocation optimisation.
Generation
350
140000 Makespan REFERENCES
Missed deadlines
300 [1] AMALTHEA: Model Based Open Source Development Environ-
120000
ment for Automotive Multi-Core Systems, 2015, http://www.amalthea-
250
n [ms]Makespa 1 068000000000000 125000 Missed deadlines [[23]] AAphErtnUutopgtjTo:ei/nOmc/ewtS.oowTAtriyvwgRpe/..:aeu,EtConAsgoUaimnrT.eoporomgMn/eo.antintvsaeg&emROeenpgteinoSnys-SteyImnsdteumMstrayrkATetRrecnbhdyisteV&cteuhFrieoc,lreeca2Ts0yt1pt5eo,,
2019,MarketsandMarkets,December2013,168Pages.
40000 100 [4] A. Burkimsher, I. Bate, L.S. Indrusiak, A characterisation of the
workload on an engineering design grid, Proceedings of the High
20000 50
Performance Computing Symposium (HPC’14). Society for Computer
0 0 SimulationInternational,Article8,2014,8pages.
0 10 20 30 40 50 60 70 80 90 100 [5] P. Frey, Case Study: Engine Control Application, Technical Report,
Generation Universita¨tUlm,2010,129Pages.
[6] M.R.Guthaus,J.S.Ringenberg,D.Ernst,T.M.Austin,T.Mudge,R.B.
Fig.4. Misseddeadlines(grey)andmakespan(black)valueoptimizationfor Brown,MiBench:Afree,commerciallyrepresentativeembeddedbench-
DemoCarimplementedon2x2mesh-basedNoCwithfour(above)andthree marksuite,IEEEInternationalWorkshoponWorkloadCharacterization
(below)activecores (WWC-4),Pages3-14,2001.
[7] L.S.Indrusiak,P.Dziurzanski,AnIntervalAlgebraforMultiprocessor
ResourceAllocation,TheInternationalConferenceonSystems,Archi-
tectures,ModelingandSimulation(SAMOS’15),2015,8pages.
[8] J. Park, J. Harnisch, M. Deubzer, K. Jeong et al., Mode-Dynamic
TaskAllocationandSchedulingforanEngineManagementReal-Time
as 2x2. The application model has been extended with com- SystemUsingaMulticoreMicrocontroller,SAEInt.J.Passeng.Cars-
Electron.Electr.Syst.,Volume7,Issue1,2014,Pages133–140.
munication messages between tasks and labels. The genetic
[9] M.Y. Qadri, D. Matichard, K.D. McDonald Maier, JetBench: an
algorithm is then executed to perform both task and label open source real-time multiprocessor benchmark, Proceedings of the
allocations to cores during 100 generations of 20 individuals 23rd international conference on Architecture of Computing Systems
(ARCS’10),2010,Pages211-221.
each. The makespan has been evaluated using the technique
[10] M.N.S.M. Sayuti, L.S. Indrusiak, Real-time low-power task mapping
describedin[7].Thefirstfullyschedulableallocationhasbeen inNetworks-on-Chip,IEEEAnnualSymposiumonVLSI(ISVLSI’13),
found in the 92-nd generation. The makespan value decreases 2013,Pages14–19.
[11] Z.Shi,A.Burns,L.S.Indrusiak,Schedulabilityanalysisforrealtimeon-
with the generation number, which shows that optimized
chipcommunicationwithwormholeswitching,InternationalJournalof
allocations are achieved with increased generation (Figure 4 EmbeddedandReal-TimeCommunicationSystems(IJERTCS),Volume
top). 1,Number2,2010,Pages1-22.
ThenonecoreoftheNoChasbeenswitchedoffforenergy
conservationreason.Forthis3-coreplatform,thefullyschedu-
lableallocationhasbeenfoundinthe94-thgeneration(Figure
4 bottom). A fully schedulable allocation has not been found
for 2x2 mesh NoC with two disabled cores, despite analysing
muchwidersearchspacethanpreviously-spanningoverfour
islands with 100 individuals each. The best found allocation
leads to violation of 216 out of 1204 deadlines. The average
execution time of performing the DemoCar schedulability
analysis has been less than 0.1s, whereas the total parsing
process lasted 0.008s (the computation has been performed
on one core of a typical desktop computer).