SystemDesign:TraditionalConceptsandNewParadigms

AlbertoFerrari
PARADESEEIG,
ViaSanPantaleo,66,00186Rome,Italy
aferrari@parades.rm.cnr.it

Abstract
Recentadvancesinsystemdesignarepresented.The
shift towards flexible hardware architectures that can
supportavarietyofapplicationsviaprogrammabilityand
reconfigurabilityisunderlined.Essentialtothisprocess
isthedefinitionanduseofplatforms.Wegiveanabstract
definitionofplatformandshowitsuseinsystemdesign
drawing examples from the automotive system design
field.

1.Introduction
System design is undergoing a series of radical
transformationstomeetperformance,quality,safety,cost
and timetomarket constraints introduced by the
pervasive use of electronics in everyday objects. An
essentialcomponentofthenewsystemdesignparadigm
istheorthogonalizationofconcerns,i.e.,theseparationof
the various aspects of design to allow more effective
exploration of alternative solutions. In particular, the
pillarofthedesignmethodologythatwehaveproposed
overtheyearsistheseparationbetween:
function (what the system is supposed to do) and
architecture(howitdoesit);
communicationandcomputation.
Themappingoffunctiontoarchitectureisanessential
stepfromconceptiontoimplementation.Whenmapping
thefunctionalityofthesystemtoanintegratedcircuit,the
economicsofchipdesignandmanufacturingareessential
todeterminethequalityandthecostofthesystem.Since
the mask set and design cost for Deep SubMicron
implementations is predicted to be overwhelming, it is
importanttofindcommonarchitecturesthatcansupporta
varietyofapplications[1].Toreducedesigncosts,reuse
isamust.Inparticular,sincesystemdesignerswilluse

AlbertoSangiovanniVincentelli
DepartmentofEECS,
UniversityofCaliforniaatBerkeley,
PARADESEEIG,
ViaSanPantaleo,66,00186Rome,Italy
alberto@ic.eecs.berkeley.edu
more and more frequently software to implement their
products,thereisaneed fordesignmethodologiesthat
allowthesubstantialreuseofsoftware.Thisimpliesthat
thebasicarchitectureoftheimplementationisessentially
fixed,i.e.,theprincipalcomponentsshouldremainthe
same within a certain degree of parameterization. For
embeddedsystems,whichwebelievearegoingtobethe
dominant share of the electronics market, the basic
architecture consists of programmable cores, I/O
subsystemandmemories.Afamilyofarchitecturesthat
allow substantial reuse of software is what we call a
hardwareplatform.Webelievethathardwareplatforms
willtakethelionsshareoftheICmarket.However,the
conceptofhardwareplatformbyitselfisnotenoughto
achieve the level ofapplication software reuse we are
lookingfor.Tobeuseful,thehardwareplatformhastobe
abstractedatalevelwheretheapplicationsoftwareseesa
highlevel interface to the hardware that we call
Application Program Interface or API. There is a
software layer that is used to perform this abstraction.
This layer wraps the different parts of the hardware
platform: the programmable cores and the memory
subsystem via a RealTime Operating System (RTOS),
the I/O subsystem via the Device Drivers, and the
network connection via the network communication
subsystem. This layer is called the software platform.
The combination of the hardware and the software
platformsiscalledthesystemplatform.
Inthispaper,wefirstreviewtheprinciplesofsystem
design,thenofferarigorousdefinitionofplatformsand
showamethodologyfortheirselectionanduse.Wepoint
to a forthcoming book for a detailed discussion of
platformbased design using a less specific and formal
view[1].

2.SystemDesignPrinciples
The overall goal of electronic system design can be
summarizedasfollows:
Minimize
productioncost,
developmenttimeandcost
subject to constraints on performance and
functionalityofthesystem.

2.1.Productioncost
Manufacturingcostdependsmainlyonthehardware
componentsoftheproduct.Minimizingproductioncostis
theresultofabalancebetweencompetingcriteria.Ifwe
thinkofanintegratedcircuitimplementation,thenthesize
of the chip is an important factor in determining
productioncost.Minimizingthesizeofthechipimplies
tailoringthehardwarearchitecturetothefunctionalityof
the product. However, the cost of a stateoftheart
fabricationfacilitycontinuestorise:itisestimatedthata
new 0.18m highvolume manufacturing plant costs
approximately $23B today. This increasing cost is
prejudicing the manufacturers towards parts that have
guaranteedhighvolumeproductionformasinglemask
set(orthatarelikelytohavehighvolumeproduction,if
successful.) This translates to better response time and
higher priorities at times when global manufacturing
resourcesareinshortsupply.
Inaddition,theNREcostsassociatedwiththedesign
andtoolingofcomplexchipsaregrowingrapidly.The
ITRSpredictsthatwhilemanufacturingcomplexSystem
onChipdesignswillbepractical,atleastdownto50nm
minimumfeaturesizes,theproductionofpracticalmasks
andexposuresystemswilllikelybeamajorbottleneckfor
thedevelopmentofsuchchips.Thatis,thecostofmasks
will grow even more rapidly for these fine geometries,
addingevenmoretotheupfrontNREforanewdesign.
Asinglemasksetandprobecardcostforastateofthe
artchipisover$1Mforacomplexparttoday,upfrom
lessthan$100Kadecadeago(note:thisdoesnotinclude
thedesigncost).Inaddition,thecostofdevelopingand
implementing a comprehensive test for such complex
designswillcontinuetorepresentanincreasingfraction
of a total design cost unless new approaches are
developed.

AsaconsequenceofthisevolutionoftheIntegrated
Circuit world, if we determine a common hardware
denominator(whichwecancallfornow,platform)that
couldbesharedacrossmultipleapplications,production
volume increases and overall costs may eventually be
(much) lower than in the case when the chip is
customizedfortheapplication.
Ofcourse,thechoiceoftheplatformhastobebased
onproductionvolumebutwecannotjustforgetthesizeof
theimplementationsinceaplatformthatcansupportthe
functionalityandperformancerequiredforahighend
productmayendupbeingtooexpensiveforotherlower
complexityproducts.Todaythechoiceofaplatform is
more an art than a science. We believe that a system
designmethodologymustassistdesignersinthisdifficult
choice with metrics and with early assessments of the
capabilityofagivenplatformtomeetdesignconstraints
(see for a comprehensive discussion of metrics to be
adoptedforplatformbaseddesign).

2.2.DevelopmentCost&Time
As the complexity of the products under design
increases,thedevelopmenteffortsincreaseexponentially.
Hence to keep these efforts in check a design
methodologythatfavors reuse andearlyerrordetection
isessential.Inaddition,developmenttimemustbeshorter
and shorter to meet timetomarket requirements. Short
developmenttimesoftenimplychangesinspecifications
whiletheproduct isbeingdesigned.Hence,flexibility,
i.e., the capability of the platform toadapt to different
functionalities without significant changes, is a very
importantcriteriontomeasurethequalityofaplatform.
Note that flexibility and reuse are related: the more
flexibleaplatformis,themorereusable.Inadditionto
theabilitytocoverdifferentbehaviors,anotherimportant
qualityofaplatformistherangeof performance.The
flexibility/performancetradeoffisverycomplexanditis
strictlyrelatedtotheabilityoftheplatformtomatchaset
of applications. For example, a hardware block
implementingadigitalfilterwithhardwired tapsisnot
flexiblesinceitcannotperformanyotheroperation.The
samefunctionofdigitalfilteringcanbeachievedusinga
softwareprogrammable Digital Signal Processor (DSP)
thatisclearlymuchmoreflexiblesinceitcanperforma
largesetofoperations.Limiting,forsakeofsimplicity,
thesetofbehaviortotheclassoffiniteimpulseresponse
(FIR)digital filters,thelengthofthefilterresponseor
number of taps characterize the filtering function, the

1.1.1.DesignReuse
maximum sampling frequency its performance. The
filtering function implemented as a hardware block is
limited to a fixed number of taps, while the filtering
function implemented on a DSP can have a variable
numberoftaps,onlylimitedbytheavailablememoryof
theDSP.Ontheotherhand,theperformancerangeforthe
hardware implementation of the digital filter is fairly
large, while for the DSP implementation is lower and
decreaseswiththenumberoftaps.
2.2.1.Flexibility
The most flexible platforms include software
programmable components. In this case, flexibility is
achieved using a machine able to perform a set of
instructions specified by the instruction set architecture
(ISA).Theexecutionofthesequenceofinstructions,or
instructionstreamstoredinmemory,realizesthedesired
behavior(Processorunit,microcodeunit).Powerful32
bit microprocessors are very flexible since they can
perform an almost unlimited number of functions with
goodperformance,small8bitmicroprocessorshavethe
samefunctionalflexibilitybuttheirperformanceisclearly
muchmorelimited.
Anintermediatepointbetweensoftwareprogrammable
componentsandhardwareblocksinthespaceofflexible
objectsconsistsofreconfigurableparts.Reconfigurable
components are characterized by hardware that can
changethelogicfunctionitimplementsbychangingthe
interconnectionpatternamongbasicbuildingblocksand
the function implemented by the basic building blocks
themselves. For some reconfigurable components this
change can be done only once at design time (for
example,FPGAswithantifusesandEPROMs),forsome,
itcanbedonemanytimesevenatruntime(FPGAswith
RAMlikecells,EEPROMs,FlashEEPROMs).Thereare
reconfigurable components where the basic building
blocks have large granularity and reconfiguration is
achievedbychangingappropriateparametersinmemory.
An example is the runtime reconfigurability of
microprocessorbased systemswhere peripherals can be
connected with different patterns according to the
application.Reconfigurablecomponentshavebeenused
foryearsnotonlyforfastprototypingbutalsoforfinal
productsintheinitialstagesoftheirmarketintroduction.
Becauseoftheirsuperiorperformanceintermsofspeed
and power consumption with respect to instructionset
machines,reconfigurablecomponentsareavalidchoice
for several systems. Research has been carried out to

identifynovelreconfigurablearchitecturesthataremore
flexibleandmoreperformingthanthepresentchoices[3].

Designreusecanbeachievedbysharingcomponents
among different products (reuse in space) and across
differentproductgenerations(reuseintime).
Reuseintime has to bridge the technology gap
betweentwo(orevenmore)generations.Reuseinspace
is based on commonality among different products. It
dependsonthecapabilityofdesignerstopartitiontheir
designssothatsimilaritiesamongdifferentproductsare
factored ascommonterms.Bothreuseandearly error
detectionimplythatthedesignactivitymustbedefined
rigorously so that all phases are clearly identified and
appropriatechecksareenforced.Tobeeffective,adesign
methodologythataddressescomplexsystemshastostart
at high levels of abstraction. In several system and IC
companies, designers are used to working at levels of
abstractionthatare tooclosetoimplementationsothat
sharing design components and verifying before
prototypes are built is nearly impossible. Design
methodologiesthataddressthisproblememergedrecently
anddesigntoolsandenvironmentscanbeputinplaceto
help supporting this design methodology (see the Polis
andVCCFelixdesignsystemsandthemethodologythey
support)[2][6].
DesignreuseismosteffectiveinreducingNREcosts
anddevelopmenttimewhenthecomponentstobeshared
are close to final implementation. For hardware
components,reuseattheimplementationlevelmeansre
use ofphysical components avoiding new mask design
and production. On the other hand, it is not always
possibleordesirabletosharedesignsatthislevelsince
minimalvariationsinspecificationmayresultindifferent,
albeitsimilar,implementations.

Theultimategoalistocreatealibraryoffunctionsand
of hardware and software implementations that can be
usedforallnewdesignsofacompany.Itisimportantto
haveamultilevellibrarysinceitisoftenthecasethatthe
lowerlevelsthatareclosertothephysicalimplementation
changeduetotheadvancesintechnologywhilethehigher
levelstendtobestableacrossproductversions.
Design reuse is desirable both at hardware and
softwarelevel:

By fixing the hardware architecture, the

customizationeffortisentirelyatthesoftwarelevel.
This solution has obvious advantages in terms of
design cycles since hardware development and
production cycles are indeed longer than their
softwarecounterpart.
BasicsoftwaresuchasRTOSanddevicedriverscan
beeasilysharedacrossmultipleapplications if they
are written following the appropriate methodology.
Thisistrueinparticularfordevicedriversaswillbe
discussedindetailslater.
Application software can be reused if a set of
conditionsaresatisfied:
Eachfunctionisdecomposedinpartswiththe
goalofidentifyingcomponentsthatarecommon
across different products. In the best case, the
entire functionality can be shared. More often,
subcomponentswillbeshared.Inthiscase,the
decompositionprocessisessentialtomaximize
design reuse. The tradeoff here is the
granularityofthecomponentsversusthesharing
potential.Thesmallerthepartsare,theeasieris
to share them but the smaller is the gain. In
addition, sharing does not come for free.
Encapsulationisnecessaryforbothhardwareand
software to prevent undesired side effects.
Encapsulationtechniqueshavebeenextensively
used in large software designs (object
orientation) but only recently have caught the
attentionofembeddedsystemdesigners[7].

Highlevellanguages(e.g.,C,C++,Java)are
easily retargetable to different processors.
However,standardcompilersandinterpretersfor
theselanguagesarenotefficientenoughforthe
tight requirements that system designers must
satisfy. Hence they often exploit the micro
architecture of the processor to save execution
timeandmemory,thusmakingthereusability
of their software across different
microprocessors almost impossible. If super
optimized object code generation with the
executiontimeversusmemoryoccupationtrade
offmadevisibletothedesignerswereavailable,
then reusability would be finally easy to
achieve. Our research groups and others have
attacked this very topic to allow embedded
system designers to focus on the highlevel
aspectsoftheirproblem(seethecodegeneration
techniquesofPolis[6],softwaresynthesisofdata

flowgraph[8]andsupercompilationforVLIW
architecture[9]).

3.DesignMethodology
Oncethecontextofthedesignmethodologyisset,we
canmoveontodefinesomeimportantconceptsprecisely
thatformthefoundationofourapproach.

3.1.Function
Asystemimplementsasetoffunctions.Afunctionis
anabstractviewofthebehaviorofthesystem.Itisthe
input/outputcharacterizationofthesystemwithrespectto
its environment. It has no notion of implementation
associatedtoit.Forexample,whentheengineofacar
starts(input),thedisplayofthenumberofrevolutionsper
minuteoftheengine(output)isafunction,whilewhen
theenginestarts,thedisplayindigitalformofthenumber
of revolutions per minute on the LCD panel is not a
function.Inthiscase,wealreadydecidedthatthedisplay
deviceisanLCDandthattheformatofthedataisdigital.
Similarly,whenthedrivermovesthedirectionindicator
(input),thedisplayofasignthatthedirectionindicatoris
useduntilitisreturnedinitsbasepositionisafunction,
whilewhenthedrivermovesthedirectionindicator,the
emissionofanintermittentsounduntilitisreturnedtoits
basepositionisnotafunction.
Thenotionoffunctiondependsverymuchonthelevel
ofabstractionatwhichthedesignisentered.Forexample,
thedecisionwhethertousesoundorsomeothervisual
indicationaboutthedirectionindicatormaynotbeafree
parameter of the design. Consequently, the second
descriptionoftheexampleisindeedafunctionsincethe
specificationisintermsofsound.However,eveninthis
case,itisimportanttorealizethatthereisahigherlevel
ofabstractionwherethedecisionaboutthetypeofsignal
is made. This may uncover new designs that were not
evenconsideredbecauseoftheentrylevelofthedesign.
Ourpointisthatnodesigndecisionshouldeverbemade
implicitlyandthatcapturingthedesignathigherlevelsof
abstractionyieldsbetterdesignsintheend.
Thefunctionstobeincludedinaproductmaybeleft
tothedecisionofthedesignerormaybeimposedbythe
customer.Iftherearedesigndecisionsinvolved,thenthe
decisionsaregroupedinadesignphasecalledfunction(or

sometimesfeature)design.Thedecisionsmaybelimited
orrangequitewidely.

3.2.Architecture
Anarchitectureisasetofcomponents,eitherabstract
orwithaphysicaldimension,thatisusedtoimplementa
function.Forexample,anLCD,aphysicalcomponentof
an architecture, can be used todisplay the number of
revolutionsperminuteofanautomotiveengine.Inthis
case, the component has a concrete, physical
representation.Inothercasesitmayhaveamoreabstract
representation.Ingeneral,acomponentisanelementwith
specifiedinterfacesandexplicitcontextdependency.The
architecturedeterminesthefinalhardwareimplementation
andhenceitisstrictlyrelatedtotheconceptofplatform.
The most important architecture for the majority of
embedded designs consists of microprocessors,
peripherals, dedicated logic blocks and memories. For
someproducts,thearchitectureiscompletelyorinpart
fixed. In the case of automotive body electronics, the
actualplacementoftheelectroniccomponentsinsidethe
bodyofthecarandtheirinterconnectionsiskeptmostly
fixed,whilethesinglecomponents,i.e.,theprocessors,
may vary to a certain extent. A fixed architecture
simplifies the design problem a great deal but limits
designoptimality.Thetradeoffisnoteasytoachieve.
We call an architecture platform, a fixed set of
components with some degrees of variability in the
performance or other parameters of one or more of its
components.

3.3.Mapping
Theessentialdesignstepthatallowsmovingdownthe
levelsofthedesignflowisthemappingprocess,where
thefunctionstobeimplementedareassigned(mapped)to
the components of the architecture. For example, the
computationsneededtodisplayasetofsignalsmayallbe
mapped to the same processor or to two different
components of the architecture (e.g., a microprocessor
and a DSP). The mapping process determines the
performance and the cost of the design. To measure
exactlytheperformanceofthedesignanditscostinterms
ofusedresources, itisoftennecessary tocompletethe
design, leading to a number of time consuming design
cycles. This is a motivation for using a more rigorous
designmethodology.When themappingstepiscarried

out,ourchoiceisdictatedbyestimatesoftheperformance
oftheimplementationofthatfunction(orpartofit)onto
the architecture component. Estimates can be provided
eitherbythemanufacturersofthecomponents(e.g.,IC
manufacturers) or by system designers. Designers use
theirexperienceandsomeanalysistodevelopestimation
models that can be easily evaluated to allow for fast
designexplorationandyetareaccurateenoughtochoose
agoodarchitecture.Giventheimportanceofthisstepin
any application domain, automated tools and
environmentsshouldsupporteffectivelythemappingof
functionstoarchitectures[2][6].
Themappingprocessisbestcarriedoutinteractivelyin
the design environment. The output of the process is
either:
amappedarchitectureiterativelyrefinedtowardsthe
finalimplementationwithasetofconstraintsoneach
mapped component (derived from the toplevel
designconstraints)or
a set of diagnostics to the architecture and
function selection phase in case the estimation
processsignalsthatdesignconstraintsmaynot
bemetwiththepresentarchitectureandfunction
set. In this case, if possible, an alternative
architecture is selected. Otherwise, we have to
workinthefunctionspacebyeitherreducingthe
number of functions to be supported or their
demandsintermsofperformance.

3.4.LinktoImplementation
Weenterthisphaseoncethemappedarchitecturehas
been estimated as capable of meeting the design
constraints.Wenowhavetheproblemofimplementing
the components of the architecture. This requires the
developmentofanappropriatehardwareblockorofthe
softwareneededtomaketheprogrammablecomponents
perform the appropriate computations. This step brings
the design to the final implementation stage. The
hardware block may be found in an existinglibrary or
mayneedaspecialpurposeimplementationasdedicated
logic.Inthiscase,itmaybefurtherdecomposedintosub
blocksuntileitherwefindwhatweneedinalibraryorwe
decidetoimplementitbycustomdesign.Thesoftware
componentsmayexistalreadyinanappropriatelibraryor
may need further decomposition into a set of sub
components, thus exposing what we call the fractal
natureofdesign,i.e.,thedesignproblemrepeatsitselfat

every level of the design hierarchy into a sequence of

nestedfunctionarchitecturemappingprocesses.

4.HardwarePlatforms
Productfeaturescanbeusedasametricformeasuring
thecomplexityofthefunctionalityofaproduct.Figure1
showssixdifferentproductsinthesameproductfamily
rankedaccordingtoproductfeaturesandlinedupintime
ofintroductioninthemarketplace.Wecangroupthese
productsintotwoclasses:highend(A,B,C)andlowend
(D,E,F), according to the number of features and their
overallcomplexity. Ifweusethesamearchitecturefor
bothclasses,thenthehardwarepartofthedesignisfully
reused while software may need to be partially
customized.Ifindeedthehighendclassstrictlycontains
thefeatures(functions)oftheother,thensoftwaredesign
canalsobeinlargepartreused.Thusevenifunitcost
were higher than needed for the lowclass products,
designcostsandNREsmaypushtowardsthissolution.
Wehavewitnessedthismovetowardsreducingproduct
variantsinanumberofoccasionsbothinsystemandIC
companies. The common architecture can then be
identified as a platform. We feel that, given its great
importance,adefinitionofhardwareplatformisneeded
since different interpretations have been used of this
commonlyusedterm.
Reuse in Space
Features

A
B
Next D

C
D

Reuse in Time
E

F
Gen-X

Time

Figure 1: Product Space

Aswehavediscussedearlier,ahardwareplatformisa
rather warm and fuzzy concept that is related to a
commonarchitectureofsort.Webelievethatitispossible
togeneralizethebasicideatoencompassnotonlyafully
specified architecture but it is also a family of
architecturesthatsharesomecommonfeature.Hencewe
prefer toidentifyaplatform withtheset ofconstraints
that can be used to test whether a given architecture
belongstothefamily.

AHardwarePlatformisafamilyofarchitecturesthat
satisfyasetofarchitecturalconstraintsthatareimposed
toallowthereuseofhardwareandsoftwarecomponents.
Thestrengthofhardwareandsoftwarearchitectural
constraintsdefinesthelevelandthedegreeofreuse.The
strongerthearchitecturalconstraintsthemorecomponent
reuse can be obtained. On the other hand, stronger
constraintsimplyalsofewerarchitecturestochoosefrom
and, consequently, less applicationdependent potential
optimization.
The Personal Computer(PC) [5] platform isa good
exampleoftighthardwareandsoftwareconstraintsthat
enable design reuse (both in space and in time). The
essential constraints that determine the PC hardware
platformsare:
thex86instructionsetarchitecture(ISA)thatmakes
it possible to reuse the operating system and the
softwareapplicationatthebinarylevel1;
afullyspecifiedsetofbusses(ISA,USB,PCI)that
makeitpossibletousethesameexpansionboardsor
ICsfordifferentproducts2;
legacy support for the ISAinterrupt controller that
handles the basic interaction between software and
hardware.
afullspecificationofasetofI/Odevices,suchas
keyboard,mouse,audioandvideodevices.
AllPCssatisfythissetofconstraints.Thedegreesof
freedom for a PC maker are quite limited! However,
withouttheseconstraintsthePCwillnotbewhereitis
today.Onewonderswhythissuccesshasnotpercolated
intheembeddedsystemdomain!Thisquestionwillbe
answeredinthefollowingparagraphs.
An embedded system hardware platform is a
combinationofthreemainsubsystems 3:processingunit,
memory,andI/O.
1. Strong cost and packaging requirements impose
keeping the hardware components at minimum
1

Infact,theMSDOSoperatingsystemcanberunon
anycompatiblex86microprocessor.
2

Notethatexpansionboardreusabilityislimitedby
thetechnologyused.
3
Mainlyforasingleprocessorsystem

2.

complexityandsize,thusmakingtheadoptionofthe
platformconceptmoredifficult.
The interaction with the environment is frequently
verycomplexandapplicationdependent.Hence,the
I/Osubsystemisanintegralandessentialpartofthe
architecture as it cannot be assumed to be equal
acrosstheapplicationspaceasisthecaseforthePC
domain. Consequently, the architecture itself is
applicationspecificandnotreusableacrossdifferent
applicationdomains.Evenforthesameapplication
domain,embeddedsystemscandifferverymuchin
theirI/Osubsystems.Inthecardashboardexample,
lowend and highend products have completely
different I/O requirements: the latter use very
complex display and communication devices while
the former use simple display and serial
communication.

Figure3 showssixproductsrequirementscoveredby
two different instances of a unique hardware platform:
highandlowend.TheI/Odimensionisaprojectionofa
verycomplexspacewherecharacteristicssuchasnumber
ofdigitalI/Os,numberofPWMchannels,numberofA/D
converters, number of input captures and output
compares, and specific I/O hardware drivers are
represented.
Memory

CPU

Memory
I/O

CPU

Figure 3: Platforms for different product classes

40 MIPS
30 MIPS
10 MIPS
I/O

Thetwohardwareplatforminstancesarealsoshownin
thefeatures/timespace(Figure4).Thediversificationof
hardwarearchitecturesshouldbecarefullyhandledsince
itreducestheproductionvolumeofeachdiversification.
Features

Figure 2: Example of platform space

High-end

Figure 2 shows different versions of an embedded

systemplatformparameterizedwithrespectto:
processingunitperformance;
speed and footprint for the memory system (RAM,
ROM,Flash,EEPROM...);
analog channels, timing and digital channels,
communicationspeedfortheI/Osubsystem.
Notethatthehardwareplatformisafamilyofpossible
productsfullyidentifiedbythesetofconstraints.When
we define a product, we need to fully specify its
components.
Given a hardware platform, we define a hardware
platform instance as a particular architecture in the
hardware platform where all components are fully
specified.

D
E

Low-end

F
Gen-X

Time

Figure 4: Platforms in the feature/time space

Seenfromtheapplicationdomain,theconstraintsthat
determinethehardwareplatformareoftengiveninterms
ofperformanceandsize.Forthedashboardexample,
we require that, to sustain a set of functions, a CPU
shouldbeabletorunatleastat agivenspeedandthe
memorysystemshouldbeofatleastagivennumberof
bytes.Sinceeachproductischaracterizedbyadifferent
set of functions, the constraints identify different
hardware platforms where more complex applications

yieldstrongerarchitecturalconstraints.Comingfromthe
hardwarespace,productionanddesigncostsimplyadding
hardwareplatformconstraintsandconsequentlyreducing
thenumberofchoices.Theintersectionofthetwosetsof
constraints defines the hardware platforms that can be
usedforthefinalproduct.Notethat,asaresultofthis
process,wemayhaveahardwareplatforminstancethatis
overdesigned for agivenproduct, that is,some ofthe
power of the architecture isnot usedto implement the
functionalityofthatproduct.Overdesignisverycommon
for the PC platform. In several applications, the over
designedarchitecturehasbeenaperfectvehicletodeliver
newsoftwareproductsandextendtheapplicationspace.
Webelievethatsomedegreeofoverdesignwillbesoon
acceptedintheembeddedsystemcommunitytoimprove
designcostsandtimetomarket.Hence,thedesignofa
hardwareplatformistheresultofatradeoffinacomplex
spacethatincludes:
The size of the application space that can be
supported by the architectures belonging to the
hardwareplatform.Thisrepresentstheflexibilityof
thehardwareplatform;
Thesizeofthearchitecture spacethat satisfiesthe
constraints embodied in the hardware platform
definition. This represents the degrees of freedom
that architecture providers have in designing their
hardwareplatforminstances.
Onceahardwareplatformhasbeenselected,thenthe
designprocessconsistsofexploringtheremainingdesign
spacewiththeconstraintssetbythehardwareplatform.
These constraints can not only be on the components
themselvesbutalsoontheircommunicationmechanism.
When we march towards implementation by selecting
components that satisfy the architectural constraints
definingaplatform,weperformasuccessiverefinement
processwheredetailsareaddedinadisciplinedwayto
produceahardwareplatforminstance.

Application Space
Application Instance

System
Design Space
Exploration
Specification

Architecture Instance

Architectural Space

Figure 5 Architectural space implementing the

application instance (at different cost).

Ideallythedesignprocessinthisframeworkstartswith
thedeterminationofthesetofconstraintsthatdefinesthe
hardwareplatformforagivenapplication.Inthecaseofa
dashboard,weadvocatetostartthedesignprocessbefore
splittingthemarketintohighendandlowendproducts.
Theplatformthusidentifiedcanthenberefinedtowards
implementationbyaddingthemissinginformationabout
components and communication schemes. If indeed we
keeptheplatformuniqueatalllevels,wemayfindthat
thecostforthelowendmarketistoohigh.Atthispoint
thenwemaydecidetointroducetwoplatforminstances
differentiated in termsof peripherals, memory size and
CPUpowerforthetwomarketsegments.Ontheother
hand,bydefiningthenecessaryconstraintsinviewofour
approach,wemayfindthataplatformexiststhatcovers
both the lowend and the highend market with great
designcostandtimetomarketimprovements.

Application Space

Figure6showsgraphicallythefeaturesofanhardware
platform. The cone above the point represent its
flexibility, the cone below represents its generality. In
general, hardware platforms tend to have a large cone
aboveandasmallconebelowtowitnesshowimportant
design reuse and standards are versus the potential
optimizationofferedbylooseconstraints.

Application Instances

Platform
Specification

System
Platform

Platform
Design Space
Exploration

Platform Instance

Architectural Space

Figure 6. The system platform concept forces the

design exploration to find somewhere in the
abstraction a common solution.

Hardware platform-based design optimizes globally

the various design parameters including, as a measure of
optimality, NRE costs in both production and design.
Hardwareplatformbaseddesignisneitheratopdownnor
abottomupdesignmethodology.Rather,itisameetin
themiddleapproach.Inapuretopdowndesignprocess,
application specification is the starting point for the
designprocess.Thesequenceofdesigndecisionsdrives
thedesignertowardasolutionthatminimizesthecostof
the architecture. Figure 5 shows the single application
approach, the bottom of the figure shows the set of
architecturesthatcouldimplementthatapplication.The
designprocess,theblackpath,selectsthemostattractive
solution as defined by a cost function. In a bottomup
approach, a given architecture (instance of the
architectural space) is designed to support a set of
differentapplicationsthatareoftenvaguelydefinedandis
in general much based on designer intuition and
marketinginputs.

An essential feature to achieve reusability of a

hardware platform is that the application designer
seesitasauniqueobjectinhisdesignspace,.For
example,inthePCworld,theapplicationsoftware
designerseesnodifferenceamongthedifferentPCs
that are satisfying the PC platform architectural
constraints.

5.SoftwarePlatform
The concept of hardware platform by itself is not
enoughtoachievethelevelofapplicationsoftwarereuse
wearelookingfor.Tobeuseful,thehardwareplatform
has to be abstracted at a level where the application
softwareseesahighlevelinterfacetothehardwarethat
wecallApplicationProgramInterfaceorAPI.Thereis
asoftwarelayerthatisusedtoperformthisabstraction
(Figure 7). This layer wraps the essential parts of the
hardwareplatform:
theprogrammablecoresandthememorysubsystem
viaaRealTimeOperatingSystem(RTOS),
theI/OsubsystemviatheDeviceDrivers,and
the network connection via the network
communicationsubsystem4.
Thislayeriscalledthesoftwareplatform5.
In our conceptual framework, the programming
languageistheabstractionoftheISA,whiletheAPIis
the abstraction of a multiplicity of computational
resources(concurrencymodelprovidedbytheRTOS)and
available peripherals (Device Drivers). 6 There are
different efforts that try to standardize the API [12], [13],
[14]. In our framework, the API is a unique abstract
representation of the hardware platform. WithanAPIso
defined,theapplicationsoftwarecanbereusedforevery
platforminstance.
Ofcourse,thehighertheabstractionlayeratwhicha
platformisdefined, themoreinstancesitcontains.For
4

Insomecases,theentiresoftwarelayer,includingthe
Device Drivers and the network communication
subsystemiscalledRTOS.
5
Thislayerembedsalsothemiddleware.
6
Thereareseveral languagesthatabstract orembed
directly the concurrency model avoiding the RTOS
abstraction[10],[11].

5.1.RTOS
In our framework, the RTOS is responsible for the
schedulingoftheavailable computingresources andof
the communication between them and the memory
subsystem. Note that in most of the embedded system
applications,theavailablecomputingresourcesconsistof
a single microprocessor. However, in general, we can
imagine a multiple core hardware platform where the
RTOS schedules software processes across different
computingengines.Thereisabattletakingplaceinthis
domain to establish a standard RTOS for embedded
applications.Forexample,traditionalembeddedsoftware
vendorssuchasISIandWindRiverarenowcompeting
with Microsoft that is trying to enter this domain by
offeringWindowsCE,astrippeddownversionoftheAPI
ofitsWindowsoperatingsystem.Inouropinion,ifthe
conceptual framework we offer here is accepted, the
precisedefinitionofthehardwareplatformandofthe
APIshouldallowtosynthesizeautomaticallyandinan
optimal way most of the software layer, a radical
departure from the standard modelsborrowed from the
PCworld.Softwarereuse,i.e.platformretargetability,
can be extended to these layers (middleware)
hopefully resulting more effective than binary
compatibility.

thephysical domain,andareceiver, that livesinthe

virtual domain. At the application level, the acquired
value is an image, i.e. a representation with a certain
precision and time validity, of the physical variable
correctly sampled and quantized. No details about the
sensor, analogtodigital converter and other hardware
componentsareknown.Usingtheanalogywithprotocols,
toimplement thiscommunicationthree mainlayersare
identified:thepresentation,transportandphysicallayer.
For the sensor, i.e. the sender, the presentation and
transport layers serve as a transducer of the physical
variable to an electrical variable, which is transported,
with wires, to the hardware of the system. I/O
communication is asymmetric, i.e. the communication
behavior is typically sampling andquantization for the
linkfromtheenvironmenttothesystemandholdforthe
oppositedirection.

Software
Software Platform

Inthisscheme,theacquisitionofaphysicalvariableis
seenasacommunicationbetweenasender,thatlivesin

Hardware

Hardware Platform
Input devices

Output Devices

network

Software Platform

RTOS

5.2.DeviceDrivers
The virtualization of input and output devices has
beenthegoldenruletodefinegenericandobjectoriented
interfacestotherealword.TheI/Osubsystemisthemost
important differentiator between PCs and embedded
systems.Inourframework,thecommunicationbetween
software processes and the environment, i.e. physical
processes, is refined (input/output refinement) through
different software and hardware layers (Figure 8). The
device drivers identify the software layers. The layer
structure is introduced to achieve reusability of
componentsbelongingtoeachlayer.

Platform API

Application Software

Device Drivers
BIOS

Network Communication

example,tosharesourcecode,weneedtohavethesame
operatingsystembutnotnecessarilythesameinstruction
set, while to share binary code, we need to add the
architecturalconstraintsthatforcetousethesameISA,
thusgreatlyrestrictingtherangeofarchitecturalchoices.

Figure 7: Layered software structure

Thehardwarechannelsare abstracted viaasoftware

layerthatlivesunderneaththedevicedriver:theBasic
I/OsystemorBIOS.Thissoftwarelayermustguarantee
the reliability of the electrical link by continuously
monitoringthelinkanditsquality.TheBIOSrepresents
the transport layer that typically can support different

types of sensors/actuators satisfying bandwidth and

accuracy of the I/O channel. Thus the layering of the
devicedriveroffersanotheropportunityofdesignreuse.
For the receiver, i.e. the application process, the
presentationlayermaskstheoperationsrequiredtoextract
the image of the physical variable out of the electrical
information provided by the transport layer. Typical
operations are filtering, diagnosis and recovery of the
sensorsignalandsensorcalibration.
In this communication abstraction, transducers
implementthetranslationofthephysicalvariabletowards
itselectrical representation anddevicedriversrepresent
itsabstractiontowardstheapplicationsoftwarewithno
attentiontowardsthetransportmechanismthatisleftto
theBIOS.
Application
(sw processes)

Physical Process

Presentation
Layer
Device
Driver
Transport
Layer

Sensor

Actuator

BIOS
Hardware

Physical Layer

Figure 8: IO subsystem as a communication link

5.3.NetworkCommunication
The network communication subsystem supports the
connection between software processes running on
differentelectronicsystems.Informationaboutthestatus
ofremotepartsofthesystemistypicallyexchanged.Ina
car,invehiclecommunicationisrequiredtocontinuously
update the status of physical variables acquired by a
differentelectroniccontrolunit,suchascarspeed,battery
voltageorbrakepedalstatus.Inthesecases,thenetwork
subsystemisthemeantoacquiringaphysicalvariable
fromremotesystemsbutnodifferenceisseenfromthe
applicationsoftwaremakingreusereallyeffective.

6.SystemPlatform
Thecombinationofhardwareandsoftwareplatforms
iscalled systemplatform. Itisthesystemplatformthat
completely determines the degree of reusability of the
applicationsoftwareandidentifiesthehardwareplatform.
Infact,thehardwareplatformmaybedeeplyaffectedby
thesoftwareplatformasinthecaseofthePCplatform.In
fact, the reusability of the application software made
possiblebythePCsystemplatformcomesattheexpense
ofaverycomplexlayeredstructureoftheWindowsO.S.
families and of the size and complexity of the
microprocessor cores supporting the instruction set. In
thisdomain,thispriceiswellworthbeingpaid.
Intheautomotivedomain,theuseoftheOSEK/VDX
RTOS [4] specifications, sponsored by the German
automotivemanufacturers,wasconceivedasatoolforre
usability and flexibility using the PC platform as a
model.However,thepeculiaritiesofembeddedsystems
where cost, reliability and geometric constraints play a
fundamentalrole,makethisapproachmuchmoredifficult
touse.TheOSEKinitiativeintendstosetastandardfor
operatingsystemstobeusedinthecarsothatsoftware
producedbydifferentvendorscouldbeeasilyintegrated.
OSEK constrains the RTOS and part of the network
communication system, but does not constrain any
input/output system interface exposing the hardware
detailsoftheI/Osubsystemtothesoftware.Becausein
the OSEK specification a device driver API is not
defined,thisspecificationisnotanarchitecturalconstraint
strong enough to enable alone the reuse of software
componentsevenatsourcecodelevel,lettingeachsystem
maker define its own interface to interact with the
attached devices. If we add to the OSEK standard for
RTOSandNetworkmanagement,thedefinitionoftheI/O
subsystems and the use of a single ISA, even binary
softwarecomponentscanbereused.Ontheotherhand,
OSEK fully specifies the scheduling algorithm for the
operating system. It does guarantee that no priority
inversionoccursbutitdoesnothelpinasubstantialway
tomaketheverificationofthetimingpropertiesofthe
application any easier. In our opinion, this is an over
specificationwithrespect tosoftwarereusabilitysince,
eveniftheschedulingalgorithmisnotfullyspecified,we
canstillreusesoftwareatthesourcelevel.Thejuryis
still out to determine whether the overall OSEK
constraints are so strong that economic and efficient
solutions are eliminated a priori. We doubt that this
specification in its present form is going to yield the

desiredresultsjustbecauseofthedifficulttradeoffspace
thatembeddedapplicationsentail.

[6] F. Balarin et al, HardwareSoftware CoDesign of

EmbeddedSystems:thePolisapproach,Kluwer,1997

7.Conclusions

[7] B. Selic, Using UML for modeling complex real time

systems. In Proceedings of ACM Workshop on Languages,
Compilers,andToolsforEmbeddedSystems,pages25060,19
20June1998

In this paper we presented a conceptual view of

platformbaseddesign.Thisviewencompasseshardware
andsoftwareplatformsforembeddedsystems.Itisbased
onsemiformaldefinitionsofthevariouscomponents.It
allowstheuseofdesignmethodologiesthatfavorglobal
optimizationacrossmultipleobjectives,fromproduction
cost to design cost and time. We have used this
frameworktoplaceapproachestoplatformbaseddesign
inthePCworldandintheautomotiveworldincontext.
WebelievethatplatformswilldominatesystemandIC
designintheDeepSubMicronera.Webelievethatmuch
remainstobedonetoextendtheseconceptsandusethem
indifferentapplicationdomains.

[8] J.L.Pino,S.Ha, E.A.Lee,J.TBuck,Softwaresynthesis

forDSPusingPtolemy,JournalofVLSISignalProcessing,Jan.
1995,vol.9,(no.12):721
[9] P.Faraboschi,G.Desoli,J.A.Fisher,Thelatestwordin
digital and media processing, IEEE Signal Processing
Magazine,March1998,vol.15,(no.2):5985.
[10] InternationalOrganizationforStandardization.Information
technology Programming Languages Ada. AdaReference
Manual.1995

8.Acknowledgments

[11] G. Berry. The Foundations of Esterel.

http://www.inria.fr/meije/Esterel.1998

WethankAntoninoDamiano,NicolaStaiano(Magneti
Marelli),LucianoLavagno(CadenceBerkeleyLab)and
Marco Antoniotti (PARADES) for their insights and
suggestions.

[12] POSIX: Portable Operating System Interface for UNIX.

The1003.0/1003.1bIEEEPOSIXStandard.Seealso TheISO
JTC1/SC22/WG15POSIXandtheIEEE'sPortableApplication
Standards Committee web sites (http://anubis.dkuug.dk/
JTC1/SC22/WG15andhttp://www.pasc.org).

9.References

[13] K.Arnold,J.Gosling.TheJavaProgrammingLanguage.
AddisonWesley,ISBN0201310066

[1] G. Martin and H. Chang, et al, Surviving the SOC

Revolution: A Guide to Platform Based Design, Kluwer
AcademicPublishers,September1999.
[2] G. Martin and B. Salefski. Methodology and

Technology for Design of Communications and

MultimediaProductsviaSystemLevelIPIntegration,In
Proceedings of the Design, Automation and Test in
Europe.February1998.
[3] John R. Hauser and John Wawrzynek. Garp: A MIPS
ProcessorwithaReconfigurableCoprocessor.In Proceedings
oftheIEEESymposiumonFieldProgrammableGateArrays
forCustomComputingMachines,pages1221.April1997.
[4] OSEK/VDX, Operating System v. 2.0r1, (http://www
iiit.etec.unikarlsruhe.de/~osek)
[5] Intel Corp. and Microsoft Corp. PC 99 System Design
Guide.(http://www.pcdesguide.org)

[14] K.Arnoldetal,TheJINISpecification, AddisonWesley,

ISBN0201616343(seealsohttp://www.sun.com/jini/specs).