Handbook of Hardware/Software Codesign

1314 Pages·42.528 MB·English

by  Soonhoi Ha, Jürgen Teich (eds.)

HOPES: Programming Platform Approach
for Embedded Systems Design
SoonhoiHaandHanwoongJung
Abstract
HopeOfParallelEmbeddedSoftware(HOPES)isadesignenvironmentforem-
bedded systemssupporting alldesign stepsfrombehavior specification tocode
synthesis, including static performance estimation, design space exploration,
and HW/SW cosimulation. Distinguished from other design environments, it
introduces a novel concept of “programming platform” called Common Inter-
mediate Code (CIC),which can beunderstood as ageneric execution model of
heterogeneousmulti-processorarchitecture.IntheCICmodel,eachapplication
is specified by a multi-mode Synchronous Data Flow (SDF) graph, called
MTM-SDF. Each mode of operation is specified by an SDF graph and mode
transition is expressed by an Finite-State Machine (FSM) model. It enables
a designer to estimate the performance and resource demand by constructing
staticschedules of the application with varying number of allocated processing
elements at each mode. At the top level, a process network model is used to
expressconcurrentexecutionofmultipleapplications.Aspecialprocess,called
controltask,isintroducedtospecifythesystem-leveldynamismthroughanFSM
modelinside.WithagivenCICmodelandasetofcandidatetargetarchitectures,
HOPESperformsdesignspaceexplorationtochoosethebestHW/SWplatform,
assuming that a hybrid mapping policy is used to map the applications to the
processingelements.HOPESsynthesizesthetargetcodeautomaticallyfromthe
CICmodelwiththemappinginformation.Theoveralldesignflowisverifiedby
thedesignoftworeal-lifeexamples.
Contents
1 Introduction............................................................... 2
2 CommonIntermediateCode(CIC)Model....................................... 7
2.1 ExtendedSDFModelforApplicationSpecification.......................... 9
S.Ha((cid:2))•H.Jung
SeoulNationalUniversity,Gwanak-ro1,Gwanak-gu,Seoul,Korea
e-mail:[email protected];[email protected]
©SpringerScience+BusinessMediaDordrecht2016 1
S.Ha,J.Teich(eds.),HandbookofHardware/SoftwareCodesign,
DOI10.1007/978-94-017-7358-4_1-1
2 S.HaandH.Jung
2.2 DynamicBehaviorSpecificationattheTop-LevelSpecificationofthe
CICModel........................................................... 14
3 DesignSpaceExplorationinHOPES........................................... 16
3.1 StaticSchedulingTechniqueofanMTM-SDFGraph......................... 18
3.2 DynamicMapping..................................................... 22
4 CICTranslator:AutomaticCodeSynthesisfromtheCICModel.................... 23
5 ExperimentalResults........................................................ 25
6 CurrentStatusandConclusion................................................ 28
References................................................................... 29
Acronyms
API ApplicationProgrammingInterface
BDF BooleanDataFlow
CIC CommonIntermediateCode
FSM Finite-StateMachine
GA GeneticAlgorithm
GUI GraphicalUserInterface
KPN KahnProcessNetwork
MTM ModeTransitionMachine
NoC Network-on-Chip
OS OperatingSystem
PIM PlatformIndependentModel
PSDF ParameterizedSynchronousDataFlow
QoS QualityofService
SADF Scenario-AwareDataFlow
SDF SynchronousDataFlow
SMP SymmetricMulti-Processing
SysteMoC SystemCModelsofComputation
WCRT Worst-CaseResponseTime
1 Introduction
HOPES is under development as a generic design environment to support a wide
rangeofembeddedsystemarchitecturesfromsystemonachip(SoC)tonetworked
embeddedsystems.Startingfromatarget-independentbehaviorspecificationanda
given set of candidate hardware architectures and available processing elements,
we can explore the design space to find an optimal system configuration and
mappingofapplications,andsynthesizethesoftwareandhardwarecomponentsin
aunifiedframework.TheabstracttargetarchitectureassumedinHOPESconsistsof
heterogeneousprocessingelementsthatareconnectedthroughanetwork.HOPES
was originally introduced as a parallel programming environment for nontriv-
ial heterogeneous multiprocessors with various design constraints on hardware
cost, power, and real-time performance [15]. However, HW/SW codesign can
HOPES:ProgrammingPlatformApproachforEmbeddedSystemsDesign 3
be naturally supported by HOPES, since a hardware IP can be regarded as a
processingelement.
As the system complexity incessantly grows with more processing elements
integrated, design reuse of hardware platforms and IPs becomes the de facto
practice to mitigate the difficulty of hardware validation. Then the HW/SW code-
sign methodology is transformed to an embedded SW development methodology
for a given hardware platform. Since the proportion of software components
keeps increasing, HOPES puts more emphasis on the implementation of software
components unlike our previous HW/SW codesign environment, PeaCE (Ptolemy
extension as a Codesign Environment) [7]. While PeaCE focuses on the codesign
of hardware and software modules that includes HW/SW partitioning, HW/SW
cosynthesis, and HW/SW cosimulation, it takes little account of multi-processor
architecturethatheavilyaffectstheparallelexecutionofsoftware.
Asystematicdesignmethodologycanbeunderstoodasasequenceofstepsthat
refine a higher level of abstraction to a lower level from initial specification to
final implementation, which is summarized as the following phrase: “design is to
represent”. Since refinement keeps the properties of the higher abstraction, how
to specify the behavior is a key factor to distinguish various HW/SW codesign
methods. Actor models that specify an application as a set of concurrent actors
are widely adopted in the HW/SW codesign methodology since they express the
potential parallelism of an application explicitly and parallelizing an application
can be simply realized by mapping actors to the processing elements. Actors are
connected to each other through channels that represent the flow of data samples
between actors. Among many actor models, SDF is chosen as the baseline actor
model of HOPES since it is a formal model that enables us to evaluate each
design decision through static analysis. General introduction to data-flow models
can be found in chapter (cid:2)“SysteMoC: A Data-Flow Programming Language for
Codesign”.
IntheSDFmodel[17],anapplicationisspecifiedwithadata-flowgraphwhere
a node represents a function module, or a task, and an arc is a FIFO queue that
deliversdatasamplesfromanoutputportofthesourcenodetoaninputportofthe
destinationnode.Aninput(oranoutput)portisassociatedwithanintegernumber
that indicates how many samples to consume (or to produce) per task execution;
the number is called the sample rate of the port. Figure 1a shows a simple SDF
graph representation of an application. A node becomes runnable only when all
input arcs have no fewer samples queued than the specified sample rate. And the
sample rates are fixed at run time in the SDF model. Then we can determine the
mappingandschedulingoftheSDFgraph,whichistodeterminewhereandinwhat
ordertoexecutethetasksonagiventargetarchitecture,atcompiletime.Foreach
arc,wecandetermine therelativeexecution ratesbetween thesourcetaskandthe
destinationtask,comparingtheoutputsamplerateofthesourceportandtheinput
samplerateofthedestinationport.Forinstance,theexecutionrateoftaskC should
betwicehigherthanthatoftaskAinFig.1a,inordertomakethenumberofsamples
producedfromthesourcetaskthesameasthenumberofsamplesconsumedbythe
4 S.HaandH.Jung
a b
time
1 1
A B 2 PE1 A C C
2 1
1 PE2 B D D
C D
1 1
c d
1 1
A B 1 AB AC BD CD
2 1 1 Buffer size 1 2 2 2
C D
1 1 Latency: 7
Fig.1 (a)AnexampleSDFgraphwithannotatedsampleratesonthearcs,(b)amappingand
schedulingresultoftheSDFgraphontotwoprocessingelements,(c)anexampleSDFgraphthat
hasabufferoverflowerror,and(d)thebufferrequirementofeacharcandtheestimatedlatency
forthestaticschedulingresultof(b)
destinationtask.AniterationofanSDFgraphisdefinedbythesetoftaskexecutions
thatsatisfytherelativeexecutionratesoftaskswithminimumnumberofexecutions.
AnSDFgraphissaidtobeconsistentiftherelativeexecutionratesoftasksare
satisfiedforallarcs.IncasethereisanypossibilityofbufferoverflowonanyFIFO
arcordeadlock,wecannotfindavalidscheduleofanSDFgraph.Figure1bshows
anexampleofastaticschedulingresultonatargetarchitecturewithtwoprocessing
elements.ForaconsistentSDFgraph,wecanrepeatthescheduleiterativelywithout
bufferoverflow.Figure1cshowsanSDFgraphexamplethathasabufferoverflow
error on arc AC by giving a wrong sample rate at the output port of node B. Such
static analyzability is a very desirable feature for embedded system design since
it enables us to detect a class of design errors by static analysis [17]. Moreover,
once the mapping and scheduling decision is made, we can determine the buffer
requirementsforallarcsandestimatethereal-timeperformanceoftheapplication.
Wecaneasilycheckwhetherthedesignconstraintsonthehardwarerequirementand
real-timeperformance canbe satisfiedornot.For instance, thebuffer requirement
and the estimated latency associated with the static scheduling result of Fig.1b is
summarizedinFig.1d.
WhiletheSDFmodelhastheaforementionedbenefitsfromitsstaticanalyzabil-
ity,ithasseverelimitationstobeusedasageneralmodelforbehaviorspecification.
First,itisnotpossibletospecifythedynamicbehaviorofanapplicationsincethe
sample rate of a port may not change dynamically. Second, it does not allow the
use of shared memory for inter-node communication since the access order to the
shared memory may change depending on the execution order of nodes. So the
synthesized code may require much larger memory than a manually written code
thatusuallyusessharedvariablesforcommunicationbetweenfunctionmodules.To
overcomethoselimitations,wehaveproposedseveralextensionstotheSDFmodel
inHOPES.WeusetheFSMmodelincombinationwiththeSDFmodeltoexpress
the dynamic behavior of an application [10]. Furthermore, a special actor, called
libraryactor[20],isintroducedtohandlesharedresourcesefficientlywithoutside
effects.
HOPES:ProgrammingPlatformApproachforEmbeddedSystemsDesign 5
FollowingtheheritageofheterogeneousmodelingofPtolemy[3]andPeaCE[7],
HOPES uses a process network model at the top level to express concurrent
execution of multiple applications. An application is modeled as a single process
at the top level while the internal behavior of an application is specified by the
extendedSDFmodel.Thesystem-leveldynamicbehaviorisspecifiedbyacontrol
task whose behavior is specified by the FSM model in the top-level task graph.
TheoverallspecificationmodelofHOPESiscalledtheCICmodel,whichwillbe
explainedinthenextsectionindetail.
There is a clear distinction between HOPES and the other model-based design
environments. As the name implies, the CIC model is not defined as a front-end
specificationmodel,butanintermediatespecificationmodel,meaningthatHOPES
design environment can accommodate various front-end specification models as
long as the front-end specification model can be translated into the CIC model.
In fact, the CIC model can be understood as an execution model of tasks at the
OperatingSystem(OS)level.AttheOSlevel,thesystembehaviorisrepresentedas
asetoftasksnomatterwhatthefront-endspecificationmodelis.Communication
and synchronization between tasks and scheduling of tasks are heavily dependent
upon the underlying software platform and hardware platform. In HOPES, we
proposetodefinetheexecutionmodeloftasksattheOSlevelandenforcethesystem
tokeepthesemanticsoftheexecutionmodel.Then,theCICmodelwillbeableto
run on any hardware and software platform since the execution model is defined
asplatform-independent.So,weintroduceanewnotionofprogrammingplatform
that hides the underlying software and hardware platform from the application
programmer.AsaprogrambasedonthevonNeumannexecutionmodelcanberun
onanyvonNeumannprocessor,anyprogrambasedontheCICexecutionmodelcan
berunonanytargetarchitecturethatkeepstheCICexecutionmodel,weenvision.
SincetheCICmodelisbasedonformalmodelsofcomputation,wecanenjoythe
benefitsofstaticanalyzabilityofthosemodelstoreducethedesigntimeandcost.
EventhoughthesameSDFmodelisusedforbehaviorspecificationinHOPES
andPeaCE,thegranularityofanodeisquitedifferent.InHOPES,anSDFnodeisa
unitofmappingandschedulingattheOSlevel.Itimpliesthatthenodegranularity
shouldbeaslargeasathreadtomakethethreadswitchingoverheadinsignificant.
On the other hand, PeaCE assumes mixed granularity of SDF nodes in the initial
specification of an application and clusters them to define a thread or a task at
the code synthesis step. In our previous work [15], an SDF graph specification of
PeaCE has been translated to the CIC model by clustering the nodes to increase
the granularity while keeping the potential parallelism as much as possible. It is
possibletospecifythesystembehaviorwiththeCICmodelmanually,regardingthe
CICmodelasthefront-endspecification.Inthiscase,itistheresponsibilityofthe
programmertodefinethegranularityofthenodetotrade-offtheparallelismandthe
schedulingoverhead.
Intheconventionalmodel-drivensoftwaredevelopmentapproaches,thesystem
behavior is specified by a Platform Independent Model (PIM) that is translated
into a platform-specific model (PSM) manually for a given hardware platform.
Then the target code is generated from the translated PSM. Even though the CIC
6 S.HaandH.Jung
model is a platform-independent model, there is no need to translate it to a PSM
since the CIC model can be executed in any hardware platform that supports the
proposed execution model. The HOPES framework is distinguished from other
model-based design frameworks that use a specific model of computation for
behavior specification, which include Daedalus [19], DAL [21], CompSOC [6],
andKoski [12].Ontheotherhand,asmentionedabove,HOPESdoesnotassume
any specific model for behavior specification as long as it can be translated into
the CIC model. Even though the CIC model is based on three different models
of computation, its model composition rule is different from that of Ptolemy [3]
whichallowshierarchicalcompositionofmodelswithoutlimitationonthedepthof
hierarchyandonthekindsofmodels.
Figure2showstheoveralldesignflowinHOPES.Theinputinformationconsists
ofthefront-endspecificationofsystembehaviorandthesetofcandidateplatforms
and hardware components. As explained above, the CIC model is generated
manually or by an automatic translator from a different front-end specification of
system behavior. We perform static analysis at the CIC level to detect the buffer
overflow and deadlock errors for SDF specifications and to analyze the timing
requirements that will be expressed in the proposed FSM model. The next step
is to explore the architectural design space by selecting the hardware platform
and processing elements and mapping the applications to the target architecture.
Note that the profiling information of tasks for all kinds of candidate processing
elementsisassumedtobegiven.TheDSEstepproducesahandfulofselectedtarget
architectures and associated mapping results of applications. Note that if a target
architecture is given as an input, it just determines the mapping of applications to
thetargetarchitecture.
Foreachcandidatesolution,theCICtranslatorgeneratesatargetCcodeforeach
processor.WeneedtodevelopaseparateCICtranslatorforeachtargetarchitecture
A set of CIC model
applica(cid:2)ons (Behavior specifica(cid:2)on)
Task profiling
Sta(cid:2)c analysis
informa(cid:2)on
Mul(cid:2)-core host:
Func(cid:2)onal
Constraints
Design space explora(cid:2)on Simula(cid:2)on
(performance,
resource, etc)
(HW pla(cid:3)orm selec(cid:2)on &
HSIM: HW/SW
mapping/scheduling of
A set of cosimula(cid:2)on
applica(cid:2)on tasks
candidate
architectures IBM Cell
CPU/GPU
CIC translator
Fig.2 DesignflowofHOPES
HOPES:ProgrammingPlatformApproachforEmbeddedSystemsDesign 7
as we need a different compiler for a different von Neumann processor. A multi-
core host processor is a base target platform for functional simulation. The CIC
translator generates a multi-threaded C code for functional simulation. Another
target platform that HOPES supports is the parallel simulator, called HSIM [26],
that has been developed to simulate the target architecture without real hardware
platform.Ahandfulofselectedarchitectureswillbeevaluatedmoreaccuratelyby
HSIM simulation. Other target platforms that HOPES supports will be explained
later.
Therestofthischapterisorganizedasfollows.TheCICmodelwillbeexplained
in the next section, which will be followed by Sect.3 that explains the mapping
andschedulingtechniquesoftheCICmodel.Section4explainstheCICtranslator.
PreliminaryexperimentalresultswillbediscussedinSect.5.Thecurrentstatusof
HOPESdevelopmentispresentedwithconcludingremarksinSect.6.
2 CommonIntermediateCode(CIC)Model
Asexplainedabove,theproposedCICmodeladoptsahierarchicalcompositionof
different models of computation to express the system behavior at two different
levels. At the top level, the CIC model expresses the system behavior with a
process network. If an application can be specified by the extended SDF graph,
theapplicationisencapsulatedasasupernodethatcontainsanextendedSDFgraph
atthebottomlevel.Notethatthetop-levelprocessnetworkandtheextendedSDF
modelthemselvescanbespecifiedinahierarchicalfashion.
Thetop-levelprocessnetworkconsistsofCICtasksandchannelsasdepictedin
Fig.3. There are two types of CIC tasks depending on the triggering condition of
tasks:time-drivenanddata-driven.Atime-driventaskistriggeredbyapre-defined
period that is given as a parameter. So it consumes the most recent sample from
the input buffer channel. The input channels of a time-driven task are single-entry
buffers that store the most recent data samples. An I/O task that interfaces with
the outside is usually designated as a time-driven task. On the other hand, a data-
driventaskistriggeredbythearrivalofdatasamplesontheinputports.Theinput
channels of data-driven tasks are assumed to be FIFO queues. A data-driven task
Task : (cid:2)me-driven (t)or Port: Fixed sample rate (f)or
data-driven (d) unspecified (u)for varying sample rates
Input task (q) Compute (b) Output task
(t) task (d) (t)
Channel: FIFO queue (q)or buffer (b)
Fig.3 CICtaskgraph
8 S.HaandH.Jung
TASK_INIT{ /* task initialization code */ };
TASK_GO {
/* generic API for data read from an input port */
MQ_RECEIVE(port_name, data, size);
...
/* generic API for system service request */
SYS_REQ(command, argument_list);
...
/* generic API for data write to an output port */
MQ_SEND(port_name, data, size);
}
TASK_WRAPUP { /* task wrapup code */ };
Fig.4 CICtaskcodetemplate
basically follows the semantics of the Kahn Process Network (KPN) model that
performsblockingreadandnon-blockingwriteaccesstothechannels.
As shown in Fig.4, the code template of a CIC task consists of three sections,
enclosed by three keywords, TASK_INIT, TASK_GO, and TASK_WRAPUP. As
the name implies, the TASK_INIT section is executed when the task is initialized
and the TASK_WRAPUP section is executed just before it is terminated. The
TASK_GO function is the main body that will repeat until the task is terminated.
A CIC task accesses a channel with target-independent generic APIs, MQ_SEND
andMQ_RECEIVE.TheMQ_RECEIVEAPIperformsblockingreadoperationto
the associated input port while the MQ_SEND API performs non-blocking write
operation to the associated output port. Since the CIC model is defined at the OS
level, the CIC task assumes that there is a supervisor that schedules the CIC tasks
andprovidessupervisoryservicestotheCICtasks.Thus,wedefineanothergeneric
API, SYS_REQ, that requests a service to the supervisor. The first argument of
theSYS_REQAPIdefinestheservicecommandwhoselistwillbeshownlater.In
principle,aCICtaskdoesnotuseplatform-specificAPIsforportability.Thegeneric
APIswillbetranslatedintotarget-specificAPIsatthecodegenerationstep.Wemay
defineaCICtaskthatusesplatform-specificAPIsforefficientimplementationatthe
expenseofportability.
Thenumberofdatasamplesconsumedorproducedperexecutionofataskcan
bespecifiedexplicitlyforeachinputoroutputport.Thesamplerateisspecified,if
it is fixed and not changing at run time. Otherwise, the sample rate is assumed to
bevaryingatruntime.Iftheinputsampleratesofallinputportsarespecified,the
data-driven task becomes an SDF task that follows the execution semantics of the
SDFmodel.IfalltasksinaCICsubgraphareSDFtasks,theCICsubgraphbecomes
anSDFsubgraph.SincetheSDFmodelhasmanymeritsfromstaticanalyzability,
itishighlyrecommendedtoidentifySDFsubgraphsasmuchaspossibleatthetop
leveluntilnomoreSDFsubgraphcanbeidentified.Andeachsubgraphisreplaced
byasupernodeatthetopleveltomakeitatwo-levelhierarchicalgraph.Toalleviate
HOPES:ProgrammingPlatformApproachforEmbeddedSystemsDesign 9
thedifficultyofidentifyingtheSDFsubgraphautomatically,itisrecommendedto
specifyanapplicationwiththeextendedSDFmodelmanuallyinsideasupernode.
2.1 ExtendedSDFModelforApplicationSpecification
Inthissubsection,weexplainacoupleofextensionsthataremadetoovercomethe
limitations of the SDF model while preserving the benefits of static analyzability.
ThefirstextensionistousetheFSMmodeltoexpressthedynamicbehaviorofthe
application.Thesecondistointroduceaspecialactor,calledlibraryactor,toallow
taskstoshareHWorSWresources.
2.1.1 DynamicBehaviorSpecification
There exist several approaches that have been proposed to increase the expression
capabilityoftheSDFmodeltosupportintra-applicationdynamism.Oneapproach
is to extend the SDF model itself. Dynamic Data Flow (DDF) and Boolean Data
Flow(BDF)aretwoexamplesofthisapproachwheretheyintroducespecialkinds
of nodes that may have varying sample rates [2]. Since BDF was proven to be
Turing equivalent and DDF is a super set of BDF, their expression capability
is maximal in theory. But they compromise some benefits of static analysis and
efficientimplementation.
Another approach is to express the dynamism of an application as a set of
modes that the application takes and each mode is specified by an SDF graph.
This approach assumes that the number of possible dynamic behaviors, or modes,
is finite. Then the dynamic behavior can be expressed as dynamic mode change.
Thereareseveralwaystospecifymodechange.InParameterizedSynchronousData
Flow (PSDF), the dynamic behavior of a task is modeled by parameters, and the
modechangeisrealizedbychangingtheparametersatruntimebeforestartingan
iterationofaschedule[1].Anapplicationisspecifiedbyatupleofgraphs,initgraph
andbodygraph,wherethebodygraphspecifiestheapplicationbehaviorandtheinit
graphsetstheparametervaluestochangethemodebeforeanewiterationstarts.
The other way is to combine the SDF model with another computation model,
usually FSM to express the mode change. In the *-chart approach [5], each state
of a finite state machine contains an SDF graph inside to make a hierarchical
composition of SDF and FSM models. The state change in the FSM can be
understood as the mode change of the SDF model. In the SystemC Models of
Computation (SysteMoC) approach [9], a task is associated with an FSM that
determines the execution behavior of the task. FSM-based SADF, shortly FSM-
SADF, is a restricted form of Scenario-Aware Data Flow (SADF) that specifies
eachmodeofoperation,calledscenario,withanSDFgraph[22,23].AnSDFtask
mayhavemultipleversionsofdefinitiondependingonthemodeofoperationwhile
a special control actor, called detector, that has an FSM inside sends the control
informationtonormalSDFtaskstochangethemodeofoperation.
HOPESusesasimilarapproachasFSM-SADF;anSDFtaskmayhavemultiple
behaviors and a tabular specification of an FSM, called Mode Transition Machine
10 S.HaandH.Jung
(MTM),describesthemodetransitionrulesfortheSDFgraph.AnMTMisdefined
as a tuple {Modes, Variables, Transitions} where Modes and Variables represent
a set of modes and a set of mode variables respectively, and Transitions is a set
of transitions that consists of the current mode, a Boolean function of conditions,
and the next mode. A Boolean function of transition condition is defined by a
simplecomparisonoperationbetweenamodevariableandavalue.AnMTM-SDF
specification of an H.264 decoder is shown in Fig.5. The H.264 decoder has two
modes of operation: I-frame and P-frame. In the I-frame mode, the sample rate of
each port in red boxes becomes zero while the sample rate of each port in blue
boxesbecomeszerointheP-framemode.TheMTMisquitesimplesinceitneeds
to distinguish two modes of operation by a single mode variable. Remind that the
granularity of a CIC task is large and the dynamic behavior inside a task is not
visibleattheCIClevel.Thus,anMTMisnotcomplexingeneralforstream-based
applications.
Mode transition is enabled by setting the mode variable so as to satisfy the
transitioncondition.Butactualmodetransitionoccursonlyattheiterationboundary
of the SDF schedule. Since an SDF graph has a well-defined notion of iteration
andeachtaskknowshowmanytimesitshouldbeexecutedineachiteration,mode
transitioncanbeperformedautonomouslybyindividualtaskswithoutglobaltiming
synchronization. A mode variable can be set by the hidden supervisor, which will
bediscussedinthenextsubsection.Oradesignatedtaskmaysetthemodevariable.
A stream-based application usually starts with parsing a header information that
determinesthemodeofoperation,followedbyprocessingastreamofdata.Inthis
case,theSDFtaskthatparsestheheaderinformationisdesignatedasaspecialtask
thatmaychangethemodevariable.Tosatisfytherestrictionthatthemodetransition
occurs at the iteration boundary, the designated task should be the first task in the
SDFschedule.IntheH.264decoderofFig.5,RealFileHisdesignatedasthespecial
taskthatdeterminesthemodeofoperation.
TheinternalbehaviorofanSDFtaskshouldbedefinedmanuallydependingon
themodeofoperation.ThecodeskeletonofanMTM-SDFtaskisshowninFig.6;
a task first checks the current mode of its MTM before starting the next iteration.
Ifitisdesignatedasaspecialtask,itmaychangethemodevariable.Basedonthe
modeofoperation,thesampleratesofSDFgraphcanbechanged.Forinstance,the
sampleratesfortheinputandoutputarcsofIntraPredY/U/V tasksbecomeallzero
for the P-frame mode and the sample rates for the output arcs of InterPredY/U/V
tasksbecomezerofortheI-framemodeofoperation.Notethatthefeedbackinput
arcsofInterPredY/U/Vtasksdonotchangethesampleratessincetheyneedtostore
thepreviousframefedbackfromtheDeblocktaskevenintheI-framemode.
2.1.2 LibraryTask
Inadditiontodynamicbehaviorspecification,anotherextensionismadetotheSDF
graph by introducing a special task, called library task, to allow the use of shared
resources inthe SDF model. A librarytaskis asharable and mappable object that
definesasetoffunctioninterfacesinside.Figure7showsanSDFgraphthatconsists
of three normal SDF tasks (T1–T3) and three library tasks (L4–L6). Connection