univercm: the universal versatile computational model for heterogeneous system integration

7/29/2019 UNIVERCM: The UNIversal VERsatile Computational Model for Heterogeneous System Integration

1/17

UNIVERCM: The UNIversalVERsatile Computational Model forHeterogeneous System Integration

Luigi Di Guglielmo, Member, IEEE, Franco Fummi, Member, IEEE,

Graziano Pravadelli, Member, IEEE, Francesco Stefanni, and Sara Vinco, Member, IEEE

AbstractDesigners are more and more forced to define innovative models and methodologies for managing integration of

heterogeneous components and heterogeneous Chip Multiprocessors (CMPs) in modern embedded systems. In this context,

component-based design seems the more promising approach, but it suffers from the lack of a widely adopted Model of Computation

(MoC) able to capture component heterogeneity. This paper proposes UNIVERCM, a new model of computation based on the

Heterogeneous Intermediate Format (HIF) with the aim of supporting bottom-up design and system integration from a set of

heterogeneous components. HW and SW components can be described by means of different languages and according to different

MoCs, toward a uniform intermediate description based on a rigorous semantics. A mapping from UNIVERCM to SystemC is proposed

then to obtain a homogeneous description intended for fast simulation, that can be also used as starting point for CMP design flows.

Experimental results show the effectiveness of UNIVERCM in managing system heterogeneity.

Index TermsFormal specifications, modeling, simulation, electronic design automation, multiprocessor

1 INTRODUCTION

THE increasing complexity of modern embedded systemsforces designers to take into account heterogeneous andconflicting aspects, e.g., usage of different abstraction levels,digital HW versus analog components, HW-dependent SWand physical environment [21]. This heterogeneity is

reflected by the widespread use of heterogeneous ChipMultiprocessors (CMPs) [20], processor dies provided withmultiple processor cores with different characteristics.Unfortunately, their heterogeneity results in really difficultverification and validation of the system functionality [35].State-of-the-art methodologies for CMP design [5] [16] [20]start from a homogeneous specification of the systemfunctionality, that is then analyzed to detect the bestprocessing element for each system functionality and todetermine the final system configuration [28]. Thus, a top-down flow is implied.

In real designs, predesigned components may have to be

integrated in the system under construction. Following atop-down flow also for such components would imply to

redesign them at a higher abstraction level, thus increasing

design and verification costs.

In this case, two approaches may be followed. As a firstattempt, each component may be manually mapped to theprocessing unit that addresses better the componentcharacteristics. However, manual mapping limits designspace exploration. Thus, it may lead to a suboptimalsolution [16] and it does not guarantee on the correctnessof the interactions between components.

The opposite approach would imply to combine the top-down flow, used for the portion of the system that is notavailable yet, with a bottom-up approach, adopted for thepredesigned components. The representation of the systembuilt in this way can be the starting point of consolidatedmethodologies for the design of heterogeneous CMPs.

In particular, component-based design allows reusebased and bottom-up design methodologies by assemblingalready developed heterogeneous components with newones coming from different domains (e.g., continuousversus discrete dynamics, HW versus SW, etc.) and fromdifferent abstraction layers (e.g., ESL, TLM, RTL, etc.).However, different domains may be described by means ofdifferent Models of Computations (MoCs) [11], e.g., con-tinuous time, discrete time, discrete events, finite statemachines, synchronous data flow, etc. A MoC givessemantics to the model clearly specifying how it evolvesover time, how concurrency is handled, how the commu-nication protocol works, etc.

Managing MoC heterogeneity is a challenging task thatresearchers are trying to solve by moving toward alternativedirections elaborated in the next Section, i.e., model-baseddesign and cosimulation. In a so wide spectrum of alter-native and complementary solutions, we propose a frame-work (Fig. 1) for managing heterogeneity that relies on:

. an interchange format, the Heterogeneous Inter-mediate Format (HIF), and a set of front/back-endtools (HIFSuite) which allow automatic conversion

IEEE TRANSACTIONS ON COMPUTERS, VOL. 62, NO. 2, FEBRUARY 2013 225

. L.D. Guglielmo and S. Vinco are with the Department of ComputerScience, University of Verona, Strada le Grazie 15, Verona 37134, Italy.E-mail: {luigi.diguglielmo, sara.vinco}@univr.it.

. F. Fummi, G. Pravadelli, and F. Stefanni are with the Department ofComputer Science, University of Verona and EDALab s.r.l., Strada leGrazie 15, Verona 37134, Italy.E-mail: {franco.fummi, graziano.pravadelli, francesco.stefanni}@univr.it.

Manuscript received 31 Jan. 2012; revised 16 Apr. 2012; accepted 12 June

2012; published online 20 June 2012.Recommended for acceptance by Z. Zilic, P. Mishra, and S. Shukla.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number TCSI-2012-01-0065.Digital Object Identifier no. 10.1109/TC.2012.156.

0018-9340/13/$31.00 2013 IEEE Published by the IEEE Computer Society


2/17

of several kinds of descriptions (e.g., SystemC,VHDL, Verilog, CIF, C/C++) toward HIF and viceversa [9];

. a universal computational model, UNIVERCM (UNI-versal VERsatile Computational Model), which is

able to capture the main features of continuous anddiscrete dynamics of HW components as well ashardware-dependent SW (HdS), to give a precisesemantics to HIF models [15];

. extension of HIF converters to be compliant withUNIVERCM following the rules described in thispaper, thus guaranteeing correct integration ofheterogeneous modules; and

. SystemC as the target language for an efficienthomogeneous simulation automatically generatedfrom UNIVERCM.

In this way, our framework supports bottom-up design,

system integration, adaptation, and reuse by allowingautomatic translation of heterogeneous components, de-scribed by means of different languages and according todifferent MoCs, toward a uniform intermediate descriptionbased on a rigorous semantics. Then, the so obtainedhomogeneous intermediate description can be automati-cally converted into SystemC, that can be also used as astarting point for CMP design flows.

The paper is organized as follows: Section 2 presentsrelated works and the current state of the art. Section 3provides the formal definition of UNIVERCM. Section 4outlines the mapping from heterogeneous models to UNI-

VERCM and the mapping from UNIVERCM to a homoge-neous representation. Section 5 presents application of theUNIVERCM methodology to two complex case studies,followed by a comparison with other modeling and integra-tion frameworks. Finally, conclusions and future works arereported in Section 6.

2 RELATED WORK

CMPs are widespread architectures for heterogeneousdomains, since they allow to meet performance, power,and space requirements while retaining a high level of

flexibility. All such characteristics make it hard to designand verify CMPs and to map the target application to theprocessing elements, in order to meet timing and perfor-mance requirements [20].

In the literature, the main approaches to ease the designof CMPs are based on the consolidated flows for the designof heterogeneous multiprocessors. Design starts from ahigh-level model of the desired system [5], that is parti-tioned and allocated to the processing elements according toinformation about the affinity toward a set of processingelement classes and the estimated system requirements.CMPs are more customized to the application space thantraditional multiprocessor programmable systems [26] [20].However, once that the considered cost function is custo-mized for CMP configuration evaluation, heterogeneousmultiprocessor design flows can be applied to CMP design.

As previously stated, the starting point of most of designflows is a homogeneous high-level model of the system.Brandolese et al. [5] starts from a behavioral synthesizabledescription of the system written in SystemC, that isanalyzed and simulated to get for static and dynamicinformation about the system. Bertels et al. [3] provides atoolchain that, starting from a C application, generates thefinal code for the target platform. Other approaches startfrom descriptions written by using MoCs [16]. MoC-baseddesign flows allow to restrict design space exploration, asthe constrained application behavior increases predictabil-ity and allows to detect problems early in the design flow.

When the starting description needs to cover hetero-geneous domains, the main approaches are 1) Model-BasedDesign (MBD) frameworks and related methodologies,relying either on a single MoC or on the integration ofdifferent MoCs, and 2) cosimulation, which exploits differ-ent simulation environments to take care of the hetero-geneity of the system [7].

Stateflow [22], Ptolemy/Ptolemy II [10], and Metropolis

[2] are among the most relevant MBD frameworks. In MBD,the system model is at the center of the design process and itis continually refined throughout the development flow.Thus, MBD approaches rely on strict top-down methodolo-gies which make reuse of already existing components verydifficult. Finally, integrating different MoCs is far fromtrivial, since their semantics can be incompatible [21]. Dialloet al. [8] and Sander and Jantsch [27] provide metamodelsand formalismsfor high-level modeling and refinement,that,starting from a formal specification model or combiningheterogeneous components, provide design transformationsfor refinement. Also these approaches rely on top-down

flows. Thus, neither these approaches are suited for reuseand bottom-up flows.

On the contrary, bottom-up methodologies and compo-nent reuse are supported by several cosimulation frame-works [4], [13], [31] for the implementation of virtual systemprototypes. In such frameworks, a system-level language,like SystemC [23], is applied in combination with anabstract canonical real-time operating system and/or aninstruction set simulator, and/or a simulation engine forcontinuous behaviors. However, co-simulation assembliesheterogeneous components without providing a rigorousformal support, thus making integration and validation

very hard tasks.In the context of both MBD and cosimulation, several

MoCs, description languages, and libraries of componentshave been proposed, which allow to describe different

226 IEEE TRANSACTIONS ON COMPUTERS, VOL. 62, NO. 2, FEBRUARY 2013

Fig. 1. The proposed framework.


3/17


4/17

3. A valve, whose aperture affects the incoming flow ofwater.

4. A controller that acts on the aperture of the valve inorder to keep the water level in a safe interval.

5. A software driver that sets the legal upper and lowerbounds accepted for the water level and themaximum number of warnings accepted before thesystem is halted.

3.3 UNIVERCM Conventions

A UNIVERCM automaton allows to describe nondetermi-

nistic mixed digital/analog and discrete/continuous sys-

tems, made of both software and hardware components.Some conventions are recalled:

. A predicate defined over a set X of variables,consists of a boolean formula whose free variablesare from X. PredX represents the set of all thepredicates over X.

. Given a set X, the notation jXj represents the

cardinality of X.. Given the set X and the natural number n, the

notation Xn represents the set of vectors made ofn values in X.

. f : X ! Y denotes a function f with domain X andcodomain Y.

. Given a set X, Parts(X) is the set of all possiblesubsets of X.

. Given a real-valued variable x, _x denotes the firstderivative of x w.r.t. the time.

. Given function f, _f is the first derivative of f w.r.t.the time.

.

Given two valuesa

andb

, a; b

denotes the set ofvalues between a and b, including a and b. Instead,by using the notation a; b the endpoints a and b areexcluded.

. IR0 represents the set of positive real numbers,including zero (IR0 0; 1[ ).

. Let v be a vector containing the values of a set ofvariables in X and let x be a variable in X, vjxdenotes the value of x stored in v.

3.4 Syntax of UNIVERCM

The formal syntax of a UNIVERCM is defined as follows:

Definition 1. A UNIVERCM automaton is a tuple hS; s0; AA;

V; W; C; _C; L;EDG;flow;inv; PSi defined as:

. S is the finite set of states.

. s0 is the initial state, s0 2 S.

. AA is the alphabet of values for discrete variables.

. V is the finite ordered set of discrete variables,evaluated on AA.

. W is the finite ordered set ofwire variables, evaluatedon AA.

. C is the finite ordered set of continuous variables,evaluated on IR. _C is used to denote the set of firstderivatives of the variables c 2 C.

. L is a set of labels, that are used for synchronization.Such a set will contain labels used for synchronizationand a label for each variable in W. Given variablex 2 W, the associated label is denoted with lx.

. EDG S S Evar Uvar Elabel Ulabel PE isthe set of edges, where:

- S S represents the source state and the destina-tion state of each edge.

- Evar PredV; W; C i s the s et o f b oo le anpredicates over variables in V, W, and C. Thesepredicates are used to check when an edge can betraversed.

- Uvar ffjf : AAjVj AAjWjIRjCj!AAjVjAAjWj

IRjCjg is the set of update functions for variables inV, W, and C.

- Elabel PartsL, Ulabel PartsL are the sets

of all possible subsets of L. An element of Elabelrepresents the subset of labels that are used tocheck whether an edge can be traversed. Anelement of Ulabel represents the subset of synchro-nization labels issued traversing an edge.

- PE NN is the set of natural numbers used toprovide each edge with a priority, where 0 is thehighest priority.

. PS : S ! NN is a function that associates to each statea priority, where 0 is the highest priority.

. inv : S ! PredV; W; C is a function that, given astate, produces a predicate over variables in V, W, andC. This predicate must be satisfied in order to remaininto the corresponding state.

. flow : S ! PredV; W; C; _C is a function that, givena state, produces a predicate over variables in V, W, C,and _C. This predicate constraints the evolution ofcontinuous variables into the corresponding state.

. init: fs0g ! PredV; W; C is a function that, giventhe initial state, produces a predicate over variables inV, W, and C. This predicate constraints the initialvalues for the variables.

. atomic : S ! IB is a function that, given a state,returns true if the state is contained in an atomic section.

A UNIVERCM automaton can be depicted as shown in

Fig. 2. Circles represent states and arrows between states

stand for edges. The double circle designates the initial

state. Balloons contain the priority (i.e., PS) and the

predicates (i.e., inv, flow, and atomic) relative to states.

Rectangles, instead, contain the priority (i.e., PE), the

enabling conditions (i.e., Evar and Elabel) and the updates

(i.e., Uvar and Ulabel) of the edges.

3.4.1 Exemplification of Syntax

This Section exemplifies the definition of syntax given in

Section 3.4 to three of the automata composing the water

tank system: valve, controller, and driver, to show how

UNIVERCM applies for analog HW, digital HW as well as

software.


Fig. 2. Graphical representation of a UNIVERCM automaton.


5/17

The behavior of the valve is described in Fig. 3. Theaperture of thevalve valve aperture is increased or decreasedbetween two extremes: 0 (closed) and a threshold(open). The

valve reacts to a set of labels.START

leads the valve to aninitial (reset) state, while OPEN, and CLOSE start theoperation of opening and closing the valve. The openingand closing times that result from the dynamics are fixed andequal to Ta. The syntax of the valve is the following:

. S fINIT; IDLE; CLOSE; OPENg;

. s0 INIT;

. AA fv j v 2 0; 1 ^ v 2 QQg;

. V fa thresholdg;

. C fvalve apertureg;

. L fSTART; OPEN; CLOSEg; and

. EDG PS, inv, and flow are omitted for lack of

space, but are visible in Fig. 3.Fig. 4 describes the behavior of the digital controller. It is

activated by the driver (on receipt of the ACTIVATE label).The controller resets the analog hardware (i.e., the valveand the evaluator) by issuing a START label. Furthermore,it manages the maximum aperture of the valve (i.e.,a threshold). When the controller receives the HIGH andLOW labels from the evaluator, it issues the correspondingCLOSE and OPEN labels for the valve. If the controllerreceives more than error threshold warnings of type HIGHor LOW, it stops the system by raising an ERROR label forthe driver and a CLOSE label for the valve. The syntax of

the controller automaton is defined as

. S fDISABLED; ACTIVEg;

. s0 DISABLED;

. AA fv j v 2 0; 1 ^ v 2 QQg [ IN;

. V fa threshold; error count; error thresholdg;

. C ;;

. L fINVOKE; ACTIVATE; START; LOW; HIGH;OPEN; CLOSE; ERRORg; and

. EDG PS, inv, and flow are omitted for lack ofspace, but are visible in Fig. 4.

Fig. 5 describes the behavior of the driver application

communicating with the controller. The driver is invokedby the INVOKE label. It activates the controller (with anACTIVATE label) and it sets the value of Xhigh and Xlow,respectively lower and upper limits of the safe water level

required in the tank. On receipt of an ERROR label from the

controller, the driver resets and halts the system. The syntax

of the driver automaton is defined as

. S fINIT; ACTIVE; HANDLE; RESET; RETURNg;

. s0 INIT;

. AA QQ;

. V fXhigh; Xlow; error thresholdg;

. C ;;

. L fACTIVATE; ERROR; RETURNg; and

. EDG PS, inv, and flow are omitted for lack ofspace, but are visible in Fig. 5.

3.5 Semantics of UNIVERCM

Semantics of automata computation is defined via the

concept of transition relation between configurations, as

described in the reminder of this Section.

Definition 2. The semantics of a UNIVERCM automaton is

given by a timed transition system hQ; ,!ATOMi, where:

. Q is the set of configurations. A configuration is afive-tuple.

hs;v;w;c; LAi 2 S AAjVj AAjWj IRjCj

PartsL;

where s is the current state, v, w, and c are vectors

storing the current values of discrete and continuous

variables and LA is the set of currently active labels.. The initial configuration is a five-tuple.

hs0; v0; w0; c0; ;i 2 S AAjVj AAjWj IRjCj

PartsL;

GUGLIELMO ET AL.: UNIVERCM: THE UNIVERSAL VERSATILE COMPUTATIONAL MODEL FOR HETEROGENEOUS SYSTEM INTEGRATION 229

Fig. 3. Graphic representation of the valve automaton.

Fig. 4. Graphic representation of the controller automaton.

Fig. 5. Graphic representation of the driver automaton.


6/17

where s0 is the initial state, no labels are active, and v0,

w0, and c0 contain the initial values of discrete and

continuous variables as stated by the predicate inits0.. Uwire. AA

jWj AAjWj ! PartsL is the function that,given two vectors w; w0 2 AAjWj storing the values ofvariables in W, returns a set of events. The setreturned LW 2 PartsL) is such that, for each x 2 W,then lx 2 LW iff wj

x6 w0j

x, i.e., a label is generated

for each wire that has changed its value.. Given a configuration hs;v;w;c; LAi 2 Q, let be

EDG,! EDG the set of candidate edges for sucha configuration, i.e., the set of edges that can betraversed because the conditions on both variables andevents are met. An edge hs; s0; envar; upvar; enlabel;uplabel; pi 2 EDG,! if and only if:

- envarv;w;c true, i.e., the predicate envar istrue;

- enlabel LA, i.e., the set of labels required totraverse the edge enlabel is contained into the set of

active labels LA;

. ,! is the transition relation. Given two configura-tions,

hs;v;w;c; LAi; hs0; v0; w0; c0; L0Ai 2 Q;

hhs;v;w;c; LAi; hs0; v0; w0; c0; L0Aii 2 ,!

if and only if at least one of the following holds:

- Action transition. An action transition from astate si to a state sj happens if there exists an edgebetween si and sj such that the predicates in Evarare satisfied, the labels in Elabel are contained in theset of active labels, and the priority of the edge is nolower than the priority ofsi. The effect of an actiontransition consists of updating the variablesaccording to the functions in Uvar and activatingthe labels in Ulabel (i.e., adding labels in Ulabel toLA). Wire variables behave like signals of an HDL,i.e., the effect of their changes is visible when allautomata have completed their move, while con-tinuous and discrete variables are instantaneouslyupdated. During an action transition, the passingof time is blocked. The formal definition follows:

. 9 e hs; s0

; envar; upvar; enlabel; uplabel; pi 2EDG,! for the configuration hs;v;w;c;LAi 2 Q such that

8e2 hs; s00; en00var; up

00var; en

00label;

up00label; p00i 2 EDG,!

for configuration hs;v;w;c; LAi 2 Q,p p00, i.e., one among the transitionswith the highest priority is taken.

invsv;w;c true ) p PSs,i.e., the priority of the action transitionmust be no lower than the priority of thedelay transition on state s.

hv0; w0; c0i upvarv;w;c, i.e., the va-lues of discrete and continuous variablesare updated according to upvar;

L0A uplabel [ Uwirew; w0, i.e., L0A is

the set of labels activated by the edge andby the update of variables in W;

- Delay transition. Differently from action transi-tions, a delay transition does not change thecurrent state si. Given a time threshold and afunction f, a delay transition allows the elapsingof the time in si until the time instant . Thefunction f specifies the evolution in si of thecontinuous variables w.r.t. the time so that boththe inv and the flow predicates of si are satisfied.A delay transition may happen if the priority ofsiis no lower than the priority of edges, outgoingfrom si, which satisfy the conditions for firing anaction transition. The formal definition follows:

. s0 s, i.e., the current state does not change;

.

L0

A ;, i.e., the active label set is emptied;. v0 v and w0 w, i.e., discrete and wire

variables preserve their values;. 8 e hs; s00;en00var; up

00var; en

00label; up

00label; p

00i 2EDG,! for configuration hs;v;w;c; LAi 2Q, PSs p

00, i.e., the priority of the delaytransition on state s must be no lower than thepriority of any candidate action transitionwith initial state s;

. 9 2 IR0 ; 9f : 0; AAjVj AAjWj ! IRjCj

where 0; is the considered time intervaland the following hold:

_f: 0; AAjVj AAjWj ! IRjCj, i.e., f isderivable and _f is the first derivative off;

f0; v ; w c, i.e., at time instant 0, thecontinuous variables have value c;

f;v;w c0, i.e., at time instant , thecontinuous variables have value c0;

8t 2 0; invsv; ft;v;w true,i.e., the evolution of continuous variablessatisfies the predicate inv;

8t 2 0; flowsv; ft ;v;w;

_ft ;v;w true;

i.e., the evolution of continuous variablessatisfies the predicate flow.

This means that, given a time threshold anda function f that specifies the evolution ofcontinuous variables into the state s (f isderivable into the time interval 0; ), thedelay transition allows a continuous evolu-tion until the time instant . In particular,until that instant, both the inv and the flowpredicates must be satisfied, and, as aconsequence, the values of continuous vari-ables evolve from c to c0 as specified by thefunction f.



7/17

. ,!ATOM is the atomic transition relation. Asequence of action transitions si ! si1 ! !sj1 ! sj happens atomically when the atomicfunction of all intermediate states is true and theatomic function of the source state si and destina-tion state sj is false. In this case, labels to beactivated by the intermediate transitions, as well asupdating of wire variables, are accumulated andbecome visible when sj is reached. The atomictransition is built incrementally with respect to thetransition relation. Note that, since boundaries of theatomic section are clear and distinguished from theinner parts of the atomic section, it is not necessaryto separate two atomic transitions with a nonatomictransition.

Given two configurations, q hs;v;w;c; LAi,

q0 hs0; v0; w0; c0; L0Ai 2 Q, hq; q0i 2 ,!ATOM if and

only if one of the following holds:

- Base atomic transition: automaton evolution

follows the transition relation and atomicity is nothandled:

. hq; q0i 2,!, i.e., a transition between q and q0

is either an action or delay transition;. atomics false, i.e., s is not included

into an atomic section; and. atomics0 false, i.e., s0 is not included

into an atomic section.- Atomic transition: There exists an ordered

sequence of configurations qj . . . qk 2 Q, suchthat:

. qj q hs;v;w;c; LAi, i.e., q is the startingconfiguration of the sequence;

. atomic(s) = false;

. qk q0 hs0; v0; w0; c0; L0Ai, i.e., q

0 is the lastconfiguration of the sequence;

. atomic(s0) = false;

. For any i 2 j; k 2, an intermediate config-uration qi1 hsi1; vi1; wi1; ci1; LAi1 iis such that atomicsi1 true, i.e., si1 isincluded into an atomic section, and thereexists a support configuration q00i1 hs

00i1;

v00i1; w00i1; c

00i1; L

00Ai1

i 2 Q such that:

hqi; q00i1i 2,!, and, imperatively, theconfiguration q00i1 is reached from theconfiguration qi in one action transitionof the transition function ,!;

si1 si1, i.e., the state si1 in qi1 isequal to the state s00i1 in q

00i1;

vi1 v00i1, i.e., the value of discretevariables vi1 in qi1 is equal to thevalue of discrete variables v00i1 in q

00i1.

This means that the value of variables inV may be updated in the intermediateconfigurations of the sequence;

ci1 c00i1, i.e., the value of continuousvariables ci1 in qi1 is equal to the valueof continuous variables c00i1 in q

00i1. This

means that the value of variables in Cmay

be updated in the intermediate config-urations of the sequence;

wi1 wi, i.e., the value of variables inW is never updated in the intermediateconfigurations of the sequence;

LAi1 LAi , i.e., in the intermediateconfigurations of the sequence, the setof active labels is neither updated noremptied. Only the labels that have beenactive in the first configuration of thesequence (i.e., qj) remain active;

. s0 s00k1, i.e., the automaton state specifiedin the last support configuration q00k1;

. v0 v00k1, i.e., the set of values for discretevariables specified in the last support config-uration q00k1;

. c0 c00k1, i.e., the set of values for continuousvariables specified in the last support config-uration q00k1; and

. w0 is such that 8x 2 W, w0jx fxk, where

the function fx, used to define the value ofeach single wire variable, is defined as

fxi

wjx; if i jw00i jx if j < i k

and the update

upvarjx of the actiontransition is not

the identity f unction

fxi 1 otherwise:

8>>>>>>>>>>>>>>>:

This means that the function fx analyzes the

support configurations in a backward fash-

ion, and for each wire variable x, the functionlooks for the latest update upvar that changesthe value of x.

. L0A fLk [ Uwirewj; wk, where the func-tion fL is such that:

fLi ;; if i jfLi 1 [ L

00Ai

n Uwirewi; w00i1; if j < i k:

8

univercm: the universal versatile computational model for heterogeneous system integration

Documents