UNIVERCM: The UNIversal VERsatile Computational Model For Heterogeneous System Integration

UNIVERCM: The UNIversal
VERsatile Computational Model for

Heterogeneous 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
T
HE increasing complexity of modern embedded systems
forces designers to take into account heterogeneous and
conflicting aspects, e.g., usage of different abstraction levels,
digital HW versus analog components, HW-dependent SW
and physical environment [21]. This heterogeneity is
reflected by the widespread use of heterogeneous Chip
Multiprocessors (CMPs) [20], processor dies provided with
multiple processor cores with different characteristics.
Unfortunately, their heterogeneity results in really difficult
verification 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 system
functionality, that is then analyzed to detect the best
processing element for each system functionality and to
determine 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 a
top-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 first
attempt, each component may be manually mapped to the
processing unit that addresses better the component
characteristics. However, manual mapping limits design
space exploration. Thus, it may lead to a suboptimal
solution [16] and it does not guarantee on the correctness
of the interactions between components.
The opposite approach would imply to combine the top-
down flow, used for the portion of the system that is not
available yet, with a bottom-up approach, adopted for the
predesigned components. The representation of the system
built in this way can be the starting point of consolidated
methodologies for the design of heterogeneous CMPs.
In particular, component-based design allows reuse
based and bottom-up design methodologies by assembling
already developed heterogeneous components with new
ones coming from different domains (e.g., continuous
versus discrete dynamics, HW versus SW, etc.) and from
different abstraction layers (e.g., ESL, TLM, RTL, etc.).
However, different domains may be described by means of
different Models of Computations (MoCs) [11], e.g., con-
tinuous time, discrete time, discrete events, finite state
machines, synchronous data flow, etc. A MoC gives
semantics to the model clearly specifying how it evolves
over time, how concurrency is handled, how the commu-
nication protocol works, etc.
Managing MoC heterogeneity is a challenging task that
researchers are trying to solve by moving toward alternative
directions elaborated in the next Section, i.e., model-based
design 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-end
tools (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 Computer
Science, 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 of
Computer Science, University of Verona and EDALab s.r.l., Strada le
Grazie 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:
tc@computer.org, 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
of several kinds of descriptions (e.g., SystemC,
VHDL, Verilog, CIF, C/C++) toward HIF and vice
versa [9];
. a universal computational model, UNIVERCM (UNI-
versal VERsatile Computational Model), which is
able to capture the main features of continuous and
discrete dynamics of HW components as well as
hardware-dependent SW (HdS), to give a precise
semantics to HIF models [15];
. extension of HIF converters to be compliant with
UNIVERCM following the rules described in this
paper, thus guaranteeing correct integration of
heterogeneous modules; and
. SystemC as the target language for an efficient
homogeneous simulation automatically generated
from UNIVERCM.
In this way, our framework supports bottom-up design,
system integration, adaptation, and reuse by allowing
automatic translation of heterogeneous components, de-
scribed by means of different languages and according to
different MoCs, toward a uniform intermediate description
based on a rigorous semantics. Then, the so obtained
homogeneous intermediate description can be automati-
cally converted into SystemC, that can be also used as a
starting point for CMP design flows.
The paper is organized as follows: Section 2 presents
related works and the current state of the art. Section 3
provides the formal definition of UNIVERCM. Section 4
outlines the mapping from heterogeneous models to UNI-
VERCM and the mapping from UNIVERCM to a homoge-
neous representation. Section 5 presents application of the
UNIVERCM methodology to two complex case studies,
followed by a comparison with other modeling and integra-
tion frameworks. Finally, conclusions and future works are
reported in Section 6.
2 RELATED WORK
CMPs are widespread architectures for heterogeneous
domains, since they allow to meet performance, power,
and space requirements while retaining a high level of
flexibility. All such characteristics make it hard to design
and verify CMPs and to map the target application to the
processing elements, in order to meet timing and perfor-
mance requirements [20].
In the literature, the main approaches to ease the design
of CMPs are based on the consolidated flows for the design
of heterogeneous multiprocessors. Design starts from a
high-level model of the desired system [5], that is parti-
tioned and allocated to the processing elements according to
information about the affinity toward a set of processing
element classes and the estimated system requirements.
CMPs are more customized to the application space than
traditional multiprocessor programmable systems [26] [20].
However, once that the considered cost function is custo-
mized for CMP configuration evaluation, heterogeneous
multiprocessor design flows can be applied to CMP design.
As previously stated, the starting point of most of design
flows is a homogeneous high-level model of the system.
Brandolese et al. [5] starts from a behavioral synthesizable
description of the system written in SystemC, that is
analyzed and simulated to get for static and dynamic
information about the system. Bertels et al. [3] provides a
toolchain that, starting from a C application, generates the
final code for the target platform. Other approaches start
from descriptions written by using MoCs [16]. MoC-based
design flows allow to restrict design space exploration, as
the 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-Based
Design (MBD) frameworks and related methodologies,
relying either on a single MoC or on the integration of
different 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 it
is continually refined throughout the development flow.
Thus, MBD approaches rely on strict top-down methodolo-
gies which make reuse of already existing components very
difficult. Finally, integrating different MoCs is far from
trivial, since their semantics can be incompatible [21]. Diallo
et al. [8] and Sander and Jantsch [27] provide metamodels
andformalisms for high-level modeling andrefinement, that,
starting from a formal specification model or combining
heterogeneous components, provide design transformations
for refinement. Also these approaches rely on top-down
flows. Thus, neither these approaches are suited for reuse
and 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 system
prototypes. In such frameworks, a system-level language,
like SystemC [23], is applied in combination with an
abstract canonical real-time operating system and/or an
instruction set simulator, and/or a simulation engine for
continuous behaviors. However, co-simulation assemblies
heterogeneous components without providing a rigorous
formal support, thus making integration and validation
very hard tasks.
In the context of both MBD and cosimulation, several
MoCs, description languages, and libraries of components
have been proposed, which allow to describe different
226 IEEE TRANSACTIONS ON COMPUTERS, VOL. 62, NO. 2, FEBRUARY 2013
Fig. 1. The proposed framework.
aspects of a complex embedded system. For example,
concerning MoCs, Extended Finite State Machines (EFSMs)
[14] are an enhancement of traditional FSMs suited for
describing digital HW components and cycle-accurate
protocols, but they do not support continuous behaviors.
On the contrary, hybrid automata have been defined to
allow the integration of continuous physical dynamics with
discrete behaviors [17].
Concerning description languages, SpecC [6] and Sys-
temC are intended for the specification and design of
digital embedded systems including digital hardware
components and software, while VHDL-AMS [19], Veri-
log-AMS [1], and SystemC-AMS [24] can be used for
representing analog components. In this context, some
works have been proposed in order to either 1) extend the
discrete event simulation semantics of SystemC to support
multiple MoCs [25], 2) introduce heterogeneous specifica-
tion methodologies on top of the standard SystemC kernel
[18], or 3) combine C++, SystemC, and SystemC-AMS to
achieve interoperability [32].
All the proposed approaches and languages do not allow
to integrate already existing components. Thus, the adop-
tion of a unique MoC would guarantee a clear semantics
and, thus, mathematical and rigorous rules for components
integration, adaptation, and reuse [21].
In this context, this paper proposes UNIVERCM to
formally support the composition of heterogeneous compo-
nents in a homogeneous formal description, and the
subsequent generation of a high-level system model, that
can be also the starting point for CMP design flows.
3 DEFINITION OF UNIVERCM
The following sections define UNIVERCM through its
syntax, semantics, and composition. The presentation is
exemplified by referring to a case study.
3.1 UNIVERCM Overview
Even if UNIVERCM is provided with a sound syntax and
semantics, the designer is never required to explicitly and
manually model the system components by using the
UNIVERCM formalism. Indeed, this would lead to a top-
down flow and it would force the designer to have a deep
knowledge of the UNIVERCM formalism, in order to
perform the error-prone and complex task of manually
converting or defining the components in the UNIVERCM
formalism. On the contrary, UNIVERCM is supported by a
framework based on HIFSuite [9], that allows automatic
extraction of a UNIVERCM homogeneous representation
starting from already existing heterogeneous descriptions.
In each UNIVERCM automaton, states model the con-
tinuous dynamics of the system, whereas edges between
states model its discrete dynamics.
UNIVERCM provides three kinds of variables. Discrete
HW, SW, and in general discrete components use discrete
variables (1 in the following), while analog HW and the
environment can exploit continuous variables (c in the
following). HDL signals are modeled by using wire
variables ( in the following). The peculiarity of wire
variables is that, whenever the value of a wire variable n
changes, a label |
n
is activated to notify this change to the
rest of the system.
States are characterized with three predicates, i.e., flow,
invariant, and atomicity. The flow predicate constrains the
evolutionof continuous variables into the state. The invariant
predicate specifies whether it is possible to remain into the
state or not, depending on a set of conditions on variables.
Finally, the atomicity predicate allows to specify sections of
the UNIVERCM automaton that are traversed as one single
transition when executing more automata in parallel.
The activation of an edge between two states is constrained
by a guard and a set of incoming labels, i.e., the edge can be
traversed only if the guard is satisfied and the incoming
synchronization labels are received. When the edge is
traversed, the values of continuous and discrete variables
are updated as specified by an update function associated to
the edge. Furthermore, a set of synchronization labels listed
into the set of outgoing labels of the edge are activated, to
allow synchronization with other automata.
Evolution of UNIVERCM automata is defined as the
transition from one configuration to another, following both
the discrete and the continuous dynamics.
Both edges and states are associated with a priority. By
partially ordering states and edges through priorities, it is
possible to model nondeterministic as well as deterministic
behaviors. If it is possible to both remain into a state and
also traverse any of its outgoing edges, the automaton either
moves across one of such edges (performing an action
transition) or remains in that state (performing a delay
transition) according to the corresponding priorities. In
particular, if the priority associated to the state is higher
than all the ones associated to the outgoing edges that can
be traversed, then the automaton evolves as specified by the
ii. and )|on predicates (i.e., it performs a delay transition).
Otherwise, the edge with higher priority is taken, allowing
the system to follow the discrete evolution specified by the
corresponding action transition. When two or more transi-
tions, regardless of their kind (see Section 3.5), have the
same priority, nondeterminism occurs.
Finally, composition of UNIVERCMautomata defines how
UNIVERCM automata evolve in parallel, by simultaneously
performing continuous or discrete transitions. Composition
does not build the automaton that reflects the behaviors of a
set of starting automata (i.e., the Cartesian product of the
automata), since this would bring to state explosion. On the
contrary, it defines how the automata influence each other
and the resulting modified system semantics.
3.2 Reference Case Study
A water tank system is used as reference case study to
guide the reader with a practical example throughout the
following sections. The water tank system is made of five
components:
1. A tank which is characterized by an uncontrolled
outbound water flow.
2. An evaluator, that checks the level of water in the
tank and compares it with the upper and lower
bounds. If the water level is too low or too high,
warnings are notified to the controller.
GUGLIELMO ET AL.: UNIVERCM: THE UNIVERSAL VERSATILE COMPUTATIONAL MODEL FOR HETEROGENEOUS SYSTEM INTEGRATION 227
3. A valve, whose aperture affects the incoming flow of
water.
4. A controller that acts on the aperture of the valve in
order to keep the water level in a safe interval.
5. A software driver that sets the legal upper and lower
bounds accepted for the water level and the
maximum number of warnings accepted before the
system 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 A of variables,
consists of a boolean formula whose free variables
are from A. 1icd(A) represents the set of all the
predicates over A.
. Given a set A, the notation [A[ represents the
cardinality of A.
. Given the set A and the natural number i, the
notation A
i
represents the set of vectors made of
i values in A.
. ) : A Y denotes a function ) with domain A and
codomain Y .
. Given a set A, 1oit:(A) is the set of all possible
subsets of A.
. Given a real-valued variable r, _ r denotes the first
derivative of r w.r.t. the time.
. Given function ),
_
) is the first derivative of ) w.r.t.
the time.
. Given two values o and /, [o. /[ denotes the set of
values between o and /, including o and /. Instead,
by using the notation [o. /[ the endpoints o and / are
excluded.
. IR
0
represents the set of positive real numbers,
including zero (IR
0
= [0. [ ).
. Let . be a vector containing the values of a set of
variables in A and let r be a variable in A, .[
r
denotes the value of r stored in ..
3.4 Syntax of UNIVERCM
The formal syntax of a UNIVERCM is defined as follows:
Definition 1. A UNIVERCM automaton is a tuple S. :
0
. AA.
1. . c.
_
c. L. 11G. )|on. ii.. T
o
) defined as:
. S is the finite set of states.
. :
0
is the initial state, :
0
S.
. AA is the alphabet of values for discrete variables.
. 1 is the finite ordered set of discrete variables,
evaluated on AA.
. is the finite ordered set of wire variables, evaluated
on AA.
. c is the finite ordered set of continuous variables,
evaluated on IR.
_
c is used to denote the set of first
derivatives of the variables c c.
. L is a set of labels, that are used for synchronization.
Such a set will contain labels used for synchronization
and a label for each variable in . Given variable
r , the associated label is denoted with |
r
.
. 11G _ o o S
.oi
|
.oi
S
|o/c|
|
|o/c|
T
1
is
the set of edges, where:
- S S represents the source state and the destina-
tion state of each edge.
- S
.oi
= 1icd(1. . c) is the set of boolean
predicates over variables in 1, , and c. These
predicates are used to check when an edge can be
traversed.
- |
.oi
= )[) : AA
[1[
AA
[[
IR
[c[
AA
[1[
AA
[[
IR
[c[
is the set of update functions for variables in
1, , and c.
- S
|o/c|
_ 1oit:(L), |
|o/c|
_ 1oit:(L) are the sets
of all possible subsets of L. An element of S
|o/c|
represents the subset of labels that are used to
check whether an edge can be traversed. An
element of |
|o/c|
represents the subset of synchro-
nization labels issued traversing an edge.
- T
1
= NN is the set of natural numbers used to
provide each edge with a priority, where 0 is the
highest priority.
. T
o
: o NN is a function that associates to each state
a priority, where 0 is the highest priority.
. ii. : o 1icd(1. . c) is a function that, given a
state, produces a predicate over variables in 1, , and
c. This predicate must be satisfied in order to remain
into the corresponding state.
. )|on : o 1icd(1. . c.
_
c) is a function that, given
a state, produces a predicate over variables in 1, , c,
and
_
c. This predicate constraints the evolution of
continuous variables into the corresponding state.
. init: :
0
1icd(1. . c) is a function that, given
the initial state, produces a predicate over variables in
1, , and c. This predicate constraints the initial
values for the variables.
. otoiic : o IB is a function that, given a state,
returns true if the state is contained in anatomic 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., T
o
) and the
predicates (i.e., ii., )|on, and otoiic) relative to states.
Rectangles, instead, contain the priority (i.e., T
1
), the
enabling conditions (i.e., S
.oi
and S
|o/c|
) and the updates
(i.e., |
.oi
and |
|o/c|
) 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.
The behavior of the valve is described in Fig. 3. The
aperture of the valve .o|.c ojcitnic is increased or decreased
betweentwo extremes: 0 (closed) ando t/ic:/o|d (open). The
valve reacts to a set of labels. START leads the valve to an
initial (reset) state, while OPEN, and CLOSE start the
operation of opening and closing the valve. The opening
and closing times that result fromthe dynamics are fixed and
equal to T
o
. The syntax of the valve is the following:
. S = INIT. IDLE. CLOSE. OPEN;
. s
0
= INIT;
. AA = . [ . [0. 1[ . . QQ;
. 1 = o t/ic:/o|d;
. c = .o|.c ojcitnic;
. L = START. OPEN. CLOSE; and
. 11G T
o
, ii., and )|on 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 valve
and the evaluator) by issuing a START label. Furthermore,
it manages the maximum aperture of the valve (i.e.,
o t/ic:/o|d). When the controller receives the HIGH and
LOW labels from the evaluator, it issues the corresponding
CLOSE and OPEN labels for the valve. If the controller
receives more than ciioi t/ic:/o|d warnings of type HIGH
or LOW, it stops the system by raising an ERROR label for
the driver and a CLOSE label for the valve. The syntax of
the controller automaton is defined as
. S = DISABLED. ACTIVE;
. :
0
= DISABLED;
. AA = . [ . [0. 1[ . . QQ IN;
. 1 = o t/ic:/o|d. ciioi conit. ciioi t/ic:/o|d;
. c = O;
. L = INVOKE. ACTIVATE. START. LOW. HIGH.
OPEN. CLOSE. ERROR; and
. 11G T
o
Fig. 5 describes the behavior of the driver application
communicating with the controller. The driver is invoked
by the INVOKE label. It activates the controller (with an
ACTIVATE label) and it sets the value of A/iq/ and A|on,
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 = INIT. ACTIVE. HANDLE. RESET. RETURN;
. :
0
= INIT;
. AA = QQ;
. 1 = A/iq/. A|on. ciioi t/ic:/o|d;
. c = O;
. L = ACTIVATE. ERROR. RETURN; and
. 11G T
o
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 Q.
TO`
), where:
. Q is the set of configurations. A configuration is a
five-tuple.
:. .. n. c. L
) o AA
[1[
AA
[[
IR
[c[
1oit:(L).
where : is the current state, ., n, and c are vectors
storing the current values of discrete and continuous
variables and L
is the set of currently active labels.

. The initial configuration is a five-tuple.
:
0
. .
0
. n
0
. c
0
. O) o AA
[1[
AA
[[
IR
[c[
1oit:(L).
Fig. 3. Graphic representation of the valve automaton.
Fig. 4. Graphic representation of the controller automaton.
Fig. 5. Graphic representation of the driver automaton.
where :
0
is the initial state, no labels are active, and .
0
,
n
0
, and c
0
contain the initial values of discrete and
continuous variables as stated by the predicate iiit(:
0
).
. |
niic
. AA
[[
AA
[[
1oit:(L) is the function that,
given two vectors n. n
/
AA
[[
storing the values of
variables in , returns a set of events. The set
returned L
\
1oit:(L) is such that, for each r ,
then |
r
L
\
iff n[
r
,= n
/
[
r
, i.e., a label is generated
for each wire that has changed its value.
. Given a configuration :. .. n. c. L
) Q, let be
11G
_ 11G the set of candidate edges for such

a configuration, i.e., the set of edges that can be
traversed because the conditions on both variables and
events are met. An edge :. :
/
. ci
.oi
. nj
.oi
. ci
|o/c|
.
nj
|o/c|
. j) 11G
if and only if:

- ci
.oi
(.. n. c) = true, i.e., the predicate ci
.oi
is
true;
- ci
|o/c|
_ L
, i.e., the set of labels required to

traverse the edge ci
|o/c|
is contained into the set of
active labels L
;
. is the transition relation. Given two configura-
tions,
:. .. n. c. L
). :
/
. .
/
. n
/
. c
/
. L
/
) Q.
:. .. n. c. L
). :
/
. .
/
. n
/
. c
/
. L
/
))
if and only if at least one of the following holds:
- Action transition. An action transition from a
state :
i
to a state :
,
happens if there exists an edge
between :
i
and :
,
such that the predicates in S
.oi
are satisfied, the labels in S
|o/c|
are contained in the
set of active labels, and the priority of the edge is no
lower than the priority of :
i
. The effect of an action
transition consists of updating the variables
according to the functions in |
.oi
and activating
the labels in |
|o/c|
(i.e., adding labels in |
|o/c|
to
L
). Wire variables behave like signals of an HDL,

i.e., the effect of their changes is visible when all
automata have completed their move, while con-
tinuous and discrete variables are instantaneously
updated. During an action transition, the passing
of time is blocked. The formal definition follows:
. e = :. :
/
. ci
.oi
. nj
.oi
. ci
|o/c|
. nj
|o/c|
. j)
11G
for the configuration :. .. n. c.

L
) Q such that
\e
2
= :. :
//
. ci
//
.oi
. nj
//
.oi
. ci
//
|o/c|
.
nj
//
|o/c|
. j
//
) 11G
for configuration :. .. n. c. L
) Q,
j _ j
//
, i.e., one among the transitions
with the highest priority is taken.
ii.(:)(.. n. c) = tinc == j _ T
o
(:),
i.e., the priority of the action transition
must be no lower than the priority of the
delay transition on state :.
.
/
. n
/
. c
/
) = nj
.oi
(.. n. c), i.e., the va-
lues of discrete and continuous variables
are updated according to nj
.oi
;
L
/
= nj
|o/c|
|
niic
(n. n
/
), i.e., L
/
is
the set of labels activated by the edge and
by the update of variables in ;
- Delay transition. Differently from action transi-
tions, a delay transition does not change the
current state :
i
. Given a time threshold c and a
function ), a delay transition allows the elapsing
of the time in :
i
until the time instant c. The
function ) specifies the evolution in :
i
of the
continuous variables w.r.t. the time so that both
the inv and the flow predicates of :
i
are satisfied.
A delay transition may happen if the priority of :
i
is no lower than the priority of edges, outgoing
from :
i
, which satisfy the conditions for firing an
action transition. The formal definition follows:
. :
/
= :, i.e., the current state does not change;
. L
/
= O, i.e., the active label set is emptied;

. .
/
= . and n
/
= n, i.e., discrete and wire
variables preserve their values;
. \ e = :. :
//
.ci
//
.oi
. nj
//
.oi
. ci
//
|o/c|
. nj
//
|o/c|
. j
//
)
11G
for configuration :. .. n. c. L
)
Q, T
o
(:) _ j
//
, i.e., the priority of the delay
transition on state : must be no lower than the
priority of any candidate action transition
with initial state :;
. c IR
0
. ) : [0. c[ AA
[1[
AA
[[
IR
[c[
where [0. c[ is the considered time interval
and the following hold:
_
): [0. c[AA
[1[
AA
[[
IR
[c[
, i.e., ) is
derivable and
_
) is the first derivative of );
)(0. .. n) = c, i.e., at time instant 0, the
continuous variables have value c;
)(c. .. n) = c
/
, i.e., at time instant c, the
continuous variables have value c
/
;
\t [0. c[ ii.(:)(.. )(t. .. n)) = true,
i.e., the evolution of continuous variables
satisfies the predicate ii.;
\t [0. c[ )|on(:)(.. )(t. .. n).

_
)(t. .. n)) = true.
i.e., the evolution of continuous variables
satisfies the predicate flow.
This means that, given a time threshold c and
a function ) that specifies the evolution of
continuous variables into the state : () is
derivable into the time interval [0. c[), the
delay transition allows a continuous evolu-
tion until the time instant c. In particular,
until that instant, both the ii. and the flow
predicates must be satisfied, and, as a
consequence, the values of continuous vari-
ables evolve from c to c
/
as specified by the
function ).
.
TO`
is the atomic transition relation. A
sequence of action transitions :
i
:
i1

:
,1
:
,
happens atomically when the atomic
function of all intermediate states is true and the
atomic function of the source state :
i
and destina-
tion state :
,
is false. In this case, labels to be
activated by the intermediate transitions, as well as
updating of wire variables, are accumulated and
become visible when :
,
is reached. The atomic
transition is built incrementally with respect to the
transition relation. Note that, since boundaries of the
atomic section are clear and distinguished from the
inner parts of the atomic section, it is not necessary
to separate two atomic transitions with a nonatomic
transition.
Given two configurations, = :. .. n. c. L
),
/
= :
/
. .
/
. n
/
. c
/
. L
/
) Q, .
/
)
TO`
if and
only if one of the following holds:
- Base atomic transition: automaton evolution
follows the transition relation and atomicity is not
handled:
. .
/
) , i.e., a transition between and
/
is either an action or delay transition;
. otoiic(:) = )o|:c, i.e., : is not included
into an atomic section; and
. otoiic(:
/
) = )o|:c, i.e., :
/
is not included
into an atomic section.
- Atomic transition: There exists an ordered
sequence of configurations
,
. . .
/
Q, such
that:
.
,
= = :. .. n. c. L
), i.e., is the starting

configuration of the sequence;
. otoiic(:) = false;
.
/
=
/
= :
/
. .
/
. n
/
. c
/
. L
/
), i.e.,
/
is the last
configuration of the sequence;
. otoiic(:
/
) = false;
. For any i [,. / 2[, an intermediate config-
uration
i1
= :
i1
. .
i1
. n
i1
. c
i1
. L
i1
)
is such that otoiic(:
i1
) = tinc, i.e., :
i1
is
included into an atomic section, and there
exists a support configuration
//
i1
= :
//
i1
.
.
//
i1
. n
//
i1
. c
//
i1
. L
//
i1
) Q such that:

i
.
//
i1
) , and, imperatively, the
configuration
//
i1
is reached from the
configuration
i
in one action transition
of the transition function ;
:
i1
= :
i1
, i.e., the state :
i1
in
i1
is
equal to the state :
//
i1
in
//
i1
;
.
i1
= .
//
i1
, i.e., the value of discrete
variables .
i1
in
i1
is equal to the
value of discrete variables .
//
i1
in
//
i1
.
This means that the value of variables in
1 may be updated in the intermediate
configurations of the sequence;
c
i1
= c
//
i1
, i.e., the value of continuous
variables c
i1
in
i1
is equal to the value
of continuous variables c
//
i1
in
//
i1
. This
means that the value of variables in c may
be updated in the intermediate config-
urations of the sequence;
n
i1
= n
i
, i.e., the value of variables in
is never updated in the intermediate
configurations of the sequence;
L
i1
= L
i
, i.e., in the intermediate
configurations of the sequence, the set
of active labels is neither updated nor
emptied. Only the labels that have been
active in the first configuration of the
sequence (i.e.,
,
) remain active;
. :
/
= :
//
/1
, i.e., the automaton state specified
in the last support configuration
//
/1
;
. .
/
= .
//
/1
, i.e., the set of values for discrete
variables specified in the last support config-
uration
//
/1
;
. c
/
= c
//
/1
, i.e., the set of values for continuous
variables specified in the last support config-
uration
//
/1
; and
. n
/
is such that \r , n
/
[
r
= )
r
(/), where
the function )
r
, used to define the value of
each single wire variable, is defined as
)
r
(i) =
n[
r
. i) i = ,
n
//
i
[
r
i) , < i _ /
oid t/c njdotc
nj
.oi
[
r
o) t/c octioi
tioi:itioi i: iot
t/c idcitity )nictioi
)
r
(i 1) ot/cini:c.
8
>
>
>
>
>
>
>
>
<
>
>
>
>
>
>
>
>
:
This means that the function )
r
analyzes the
support configurations in a backward fash-
ion, and for each wire variable r, the function
looks for the latest update nj
.oi
that changes
the value of r.
. L
/
= )
L
(/) |
niic
(n
,
. n
/
), where the func-
tion )
L
is such that:
)
L
(i) =
O. i) i = ,
)
L
(i 1) L
//
i
|
niic
(n
i
. n
//
i1
). i) , < i _ /.
8
<
:
This means that )
L
collects all the set L
//
i
of
labels stored into the several support config-
urations to compute the final set of active
labels (i.e., L
/
) that is being used for the

further automata synchronization. Notice
that the existence of nonempty L
//
i
sets is
due to the possible presence of |
|o/c|
functions
on the automaton edges belonging to the
atomic section.
3.6 Composition of Automata
The formal composition of UNIVERCM automata is the
following.
Definition 3. Given Q
1
.
TO`1
) and Q
2
.
TO`2
) timed
transition systems representing the semantics of UNIVERCM
automata /
1
and /
2
, respectively, the composition of /
1
and /
2
is a timed transition system /
1
/
2
=
Q.
TO`
) such that:
. Q is the set of configurations. A configuration is a
five-tuple :. .. n. c. L
), where:
- : = :
1
. :
2
) is the current state, representing the
current state :
1
of /
1
and :
2
of /
1
, : S
1
S
2
;
- . (AA
1
AA
2
)
[1
1
1
2
[
represents the value of
discrete variables of both 1
1
and 1
2
;
- n (AA
1
AA
2
)
[
1
2
[
represents the value of
wire variables of both
1
and
2
;
- c IR
[c
1
c
2
[
represents the value of continuous
variables of both c
1
and c
2
.
- L
= L
1
L
2
is the set of labels active in both
the automata.
. The initial configuration is a five-tuple :
0
. .
0
.
n
0
. c
0
. O) such that:
- :
0
= :
1
0
. :
2
0
) is the initial state, where :
1
0
is the
initial state of /
1
and :
2
0
is the initial state of
/
2
;
- .
0
is the vector of initial values of discrete
variables. In the following, .
i
0
represents the
vector of initial values assigned to discrete
variables by the automaton /
i
. Notice that
variables shared between the automata must be
assigned the same initial value by /
1
and /
2
.
As a consequence, .
0
must satisfy the following
constraints:
. \r (1
1
1
2
). .
0
[
r
= .
1
0
[
r
;
. \r (1
2
1
1
). .
0
[
r
= .
2
0
[
r
;
. \r (1
1
1
2
). .
0
[
r
= .
1
0
[
r
; and
.
1
0
[
r
= .
2
0
[
r
;
- n
0
is the vector of initial values of wire variables.
In the following, n
i
0
represents the vector of
initial values assigned to wire variables by the
automaton /
i
. Notice that variables shared
between the automata must be assigned the same
initial value by /
1
and /
2
. As a consequence,
n
0
must satisfy the following constraints:
. \r (
1

2
). n
0
[
r
= n
1
0
[
r
;
. \r (
2

1
). n
0
[
r
= n
2
0
[
r
;
. \r (
1

2
). n
0
[
r
= n
1
0
[
r
; and
n
1
0
[
r
= n
2
0
[
r
;
- c
0
is the vector of initial values of continuous
variables. In the following, c
i
0
represents the
vector of initial values assigned to continuous
variables by the automaton /
i
. Notice that
variables shared between the automata must be
assigned the same initial value by /
1
and /
2
.
As a consequence, c
0
must satisfy the following
constraints:
. \r (c
1
c
2
). c
0
[
r
= c
1
0
[
r
;
. \r (c
2
c
1
). c
0
[
r
= c
2
0
[
r
;
. \r (c
1
c
2
). c
0
[
r
= c
1
0
[
r
; and
c
1
0
[
r
= c
2
0
[
r
.
. Given two configurations :. .. n. c. L
). :
/
. .
/
.
n
/
. c
/
. L
/
) Q, the transition relation

TO`
is
such that :. .. n. c. L
), :
/
. .
/
. .
/
. c
/
. L
/
)) if
and only if:
- :
1
. .
1
. n
1
. c
1
. L
1
), :
/
1
. .
/
1
. n
/
1
. c
/
1
. L
/
1
) Q
1
;
- :
2
. .
2
. n
2
. c
2
. L
2
), :
/
2
. .
/
2
. n
/
2
. c
/
2
. L
/
2
) Q
2
;
and the following hold:
- : = :
1
. :
2
), i.e., the current state represents the
current state of /
1
(i.e., :
1
), and /
2
(i.e., :
2
);
-
:
1
. .
1
. n
1
. c
1
. L
1
). :
/
1
. .
/
1
. n
/
1
. c
/
1
. L
/
1
))

TO`1
such that:
. \r 1
1
, .[
r
= .
1
[
r
;
. \r
1
, n[
r
= n
1
[
r
;
. \r c
1
, c[
r
= c
1
[
r
; and
. L
1
= L
L
1
:
i.e., exists an active edge on /
1
between
configurations :
1
. .
1
. n
1
. c
1
. L
1
) and :
/
1
. .
/
1
.
n
/
1
. c
/
1
. L
/
1
) such that the value of variables in
/
1
is equal to the value of the same variables in
/
1
/
2
, and active labels in /
1
are equal to
the labels active in /
1
/
2
(restricted to the
labels declared in L
1
).
-
:
2
. .
2
. n
2
. c
2
. L
2
). :
/
2
. .
/
2
. n
/
2
. c
/
2
. L
/
2
))

TO`2
such that:
. \r 1
2
, .[
r
= .
2
[
r
;
. \r
2
, n[
r
= n
2
[
r
;
. \r c
2
, c[
r
= c
2
[
r
; and
. L
2 = L
L
2
:
i.e., exists an active edge on /
2
between
configurations :
2
. .
2
. n
2
. c
2
. L
2
) and :
/
2
. .
/
2
.
n
/
2
. c
/
2
. L
/
2
) such that the value of variables in
/
2
is equal to the value of the same variables in
/
1
/
2
, and active labels in /
2
are equal to
the labels active in /
1
/
2
(restricted to the
labels declared in L
2
).
- :
/
= :
/
1
. :
/
2
), i.e., the next state of /
1
/
2
represents the next state :
/
1
of /
1
and the next
state :
/
2
of /
2
;
- .
/
is a vector of values of discrete variables such
that the following hold:
. \r 1
1
1
2
, .
/
[
r
= .
/
1
[
r
;
. \r 1
2
1
1
, .
/
[
r
= .
/
2
[
r
; and
. \r 1
1
1
2
:
if .
1
[
r
= .
/
1
[
r
, then .
/
[
r
= .
/
2
[
r
;
else if .
2
[
r
= .
/
2
[
r
, then .
/
[
r
= .
/
1
[
r
; and
else .
/
[
r
.
/
1
[
r
. .
/
2
[
r
.
This means that, if a shared discrete variable is
assigned by only one of the automata /
i
, then its
new value depends on such an assignment. On the
contrary, if a shared variable is updated by both
automata at the same time, then the value is taken
nondeterministically among the values assigned
by each automaton. Thus, non determinism is
allowed;
- n
/
is a vector of values of wire variables such that
the following hold:
. \r
1

2
, n
/
[
r
= n
/
1
[
r
;
. \r
2

1
, n
/
[
r
= n
/
2
[
r
; and
. \r
1

2
:
if n
1
[
r
= n
/
1
[
r
, then n
/
[
r
= n
/
2
[
r
;
else if n
2
[
r
= n
/
2
[
r
, then n
/
[
r
= n
/
1
[
r
;
and
else n
/
1
[
r
= n
/
2
[
r
and n
/
[
r
= n
/
1
[
r
.
This means that the value of a shared wire variable
can be changed by the automata /
1
and /
2
one
at a time or, if they act on the variable at the same
time, /
1
and /
2
must assign the same value.
Thus, nondeterminism is not allowed on wire
variables;
- c
/
is a vector of values of continuous variables
such that the following hold:
. \r c
1
c
2
, c
/
[
r
= c
/
1
[
r
;
. \r c
2
c
1
, c
/
[
r
= c
/
2
[
r
; and
. \r c
1
c
2
:
if c
1
[
r
= c
/
1
[
r
, then c
/
[
r
= c
/
2
[
r
;
else if c
2
[
r
= c
/
2
[
r
, then c
/
[
r
= c
/
1
[
r
; and
else c
/
1
[
r
= c
/
2
[
r
and c
/
[
r
= c
/
1
[
r
.
This means that the value of a shared continuous
variable can be changed by the automata /
1
and
/
2
one at a time or, if they act on the variable at
the same time, /
1
and /
2
must assign the same
value. Thus, nondeterminism is not allowed on
continuous variables; and
- L
/
= L
/
1
L
/
2
, i.e., the set of labels available
for future synchronization is the union of labels
activated by /
1
and /
2
.
4 MAPPING TO AND FROM UNIVERCM
This section presents how HDL models, embedded SW and
analog components can be mapped onto UNIVERCM and
what solutions have been studied to overcome the
corresponding issues. It also outlines a prototype mapping
from HIF/UNIVERCM to SystemC.
4.1 From HDL Descriptions
HDLs provide mechanisms to reproduce HW execution,
in order to support design, refinement, and validation of
HW designs. Representation of the HDL semantics in
UNIVERCM introduces two main issues
. Scheduler representation. The HDL scheduler must be
represented in UNIVERCM so the HDL simulation
semantics is preserved.
. Atomicity. A HDL process is assured to run mutually
excluding other processes and no race condition
occurs when accessing shared data and variables.
This is a fundamental feature since it avoids
nondeterministic behaviors and thus it must be
preserved by UNIVERCM.
4.1.1 Scheduler Representation
In HDLs, processes are activated by events, such as
variations of an input signal value. If a process is activated
by a variation of a signal, it is said to be sensitive to that
signal. Thus, whenever a signal changes its value, processes
sensitive to it are ready for execution and they are inserted
in the queue of runnable processes.
The actual execution of a HDL model is managed by an
internal scheduler. Execution goes through a certain number
of simulation cycles, until simulation ends. Each cycle is
made of the following steps:
. update. The value of all signals is updated. If any
signal has changed its value or an event has been
fired, all sensitive processes are added to the
runnable queue.
. evaluation. Runnable processes are executed, one at a
time, until a synchronization point is reached.
. time update. Simulation time of the next cycle is
determined by setting it to the earliest of 1) the time
at which simulation ends, 2) the next time at which
an event occurs, or 3) the next time at which a
process resumes.
The main feature that must be preserved is the fact that
simulation time is advanced only when there is no event to
be processed in the system nor any signal to be updated.
In UNIVERCM time can be modeled as a continuous
variable, monotonically increasing as time passes. How-
ever, time must advance only when there is neither event
nor any update operation to process. Both events and
update operations are represented in UNIVERCM as labels,
thus it is necessary to model an automaton that advances a
continuous variable representing time only when there is no
active label in the system. The automaton will also manage
the clock variable, represented as a discrete variable in 1.
The resulting automaton is shown in Fig. 6.
. If there are active labels in the system, the automaton
remains in state S1 and thus time does not evolve.
. If no label is active, the automaton remains in state
S1 and it increases time (represented by the
continuous variable actual_time).
. As soon as actual_time reaches the end of a clock
period, then the automaton reaches state S2 with an
action transition that sets the clock variable to 1
(as a result, all synchronous processes will be
activated).
. Otherwise, if actual_time reaches the half of a
clock period (assuming to have a symmetric phase
Fig. 6. Representation of a HDL scheduler in UNIVERCM.
clock), then the automata reaches state S2 with an
action transition that sets the clock variable to 0.
. State S2 is used to force that, after an update of the
clock signal, time must evolve before updating the
clock signal once again. This mechanism avoids
deadlocks.
In this way, the HDL scheduling semantics is preserved.
. update. Signals are mapped onto variables of type .
Such variables automatically activate labels when-
ever they change value;
. evaluation. Processes sensitive to signals become
automata such that each action transition can be
traversed only if labels corresponding to signals in
the sensitivity list are active. All automata execute in
parallel, until there is at least one active label; and
. time update. When there is no active label, time is
increased linearly. If necessary, the clock variable is
updated.
An example of HDL model mapped to UNIVERCM is
depicted in Fig. 4. The original controller module was
implemented in VHDL, as a digital model containing one
asynchronous process. As a result, the UNIVERCM auto-
maton only implements its discrete evolution, represented
by action transitions. Delay transitions do not modify the
evolution of variables andthey are usedto remain in a state is
the conditions associated to the exiting action transitions are
not verified. Furthermore, the component is deterministic.
4.1.2 Atomicity
Atomicity is another major issue. In HDLs, parallel
processes are executed sequentially in a mutually exclusive
way. Furthermore, processes cannot be preempted they
reach a synchronization point. This semantics is called
cooperative multithreading.
In UNIVERCM, automata execute in parallel, i.e., all
automata take a transition simultaneously. Chunks of code
that were executed with no interruption by the original HDL
code may be divided into more transitions once that they are
representedin UNIVERCM(e.g., conditional branches). Thus,
a different interleaving of operations may occur, modifying
the execution flow. To overcome this issue, UNIVERCM
provides a function called atomic, that associates a boolean
to each state. If atomic calculated over a state returns true,
then the state is considered part of an atomic region.
. All transitions in the atomic region are considered as
a single transition, as all other automata will see only
the final configuration reached at the end of the
atomic region.
. Labels activated on the single transitions are
accumulated and they are activated only at the end
of the atomic region.
. Wires are updatedonlyat theendof the atomic region.
In this way, traversing many transitions inside of an
atomic region is considered to all intents as a single
transition when performing parallel composition with other
automata. This allows to reproduce the same semantics of
original HDLs in UNIVERCM and to preserve the same
synchronization points between processes.
An example of use of atomicity in HDL handling is
reported in Fig. 7, where the code between two consecutive
wait() must be executed without preemption.
4.2 From Embedded SW
Hardware dependent Software is SW that controls and
abstracts HW functionalities, to allow easy and standard
access to HW devices and to allow deployment of more
abstracted SW. HdS is in charge of managing communica-
tion with HW and it needs to be reactive to signals and
interrupts risen by HW devices.
HdS modeling in UNIVERCMimposes challenging issues.
. Function modeling.
. Communication with HW devices. Memory mapped
I/O (MMIO) communication between HW devices
and SW must be supported.
. Reactivity to HW interrupts.
. Atomicity to represent sections protected with mu-
tual exclusion resources.
An example of HdS mapped to UNIVERCM is depicted in
Fig. 5. The Figure shows the device driver communicating
with the HW controller depicted in Fig. 4. Such components
are usedto highlight the presentedissues onactual automata.
4.2.1 Function Modeling
A function can be easily represented as a UNIVERCM
automaton, evolving among a certain set of states via
transitions. SW does not allow continuous evolution, as its
execution is always made of a discrete set of instructions.
Thus, the automaton will evolve via action transitions and it
will contain discrete variables in 1, rather than providing
analog behaviors. Each function is provided with two special
labels: an activation label (representing function invocation
and activated by automata willing to execute the function)
and a return label (used to communicate to the caller that the
function has finished its execution). HdS usually do not use
recursion (indeed, only finite-length iteration loops are
enough), thus, recursion is not supported by UNIVERCM.
Fig. 5 shows how functions are modeled. The automaton
represents a function that is activated by the activation label
INVOKE and that notifies that its execution has finished by
activating the return label RETURN.
4.2.2 Communication with HW devices
Communication with HW devices based on the MMIO
approach is easily implemented in UNIVERCM. All variables
and registers are represented in UNIVERCM as variables
shared between automata. Thus, the MMIO memory
locations can be represented as variables of type 1 shared
between the SW automaton and the actual device represen-
tation. In this way, the automaton representing SW can read
andwrite the device status through variables sharedwith the
device automaton.
Fig. 7. Example of HDL code (left) and of corresponding UNIVERCM
representation with atomicity support.
The driver controls the configuration of the controller
device by accessing to the MMIO memory, in this case to set
the maximum number of errors accepted by the system
(ciioi t/ic:/o|d). The syntax of both the automata (outlined
in Section 3.4.1) highlights that the automata share the
ciioi t/ic:/o|d variable, written by the driver automaton
and read by the controller automaton. In this way, MMIO
communication is represented and HW-SW communication
is allowed between UNIVERCM automata.
4.2.3 Reactivity to HW Interrupts
In UNIVERCM both SW and HW are represented as parallel
automata. In detail, one automaton represents the execution
of the HW process firing the interrupt (see Fig. 8), while
another automaton is used to implement the interrupt
handling routine (see Fig. 9). Thus, the interrupt can be
mapped onto a UNIVERCM label (in S
|o/c|
). The interrupt
handling automaton is suspended until it receives the
interrupt label. This label activates the automaton, that
executes the corresponding interrupt handling operations.
Thus, interrupts and reactivity can easily be modeled in
UNIVERCM.
These solutions allow to easily represent HdS in UNI-
VERCM and to model in a formal way its interaction with
HW devices. However, changing type of target architecture
and extending the range of considered embedded SW
would add more issues (such as preemption), which will be
described in a future work.
In the water tank system, the controller device rises an
interrupt whenever the maximum number of errors is
reached by the system. The device driver manages this
interrupt, by halting and resetting the system. Fig. 4 shows
that the interrupt is represented, in UNIVERCM, as a label
ERROR, activated on the transition from state ACTIVE to
state DISABLED. Interrupt handling is shown in Fig. 5. The
transition from state ACTIVE to state HANDLE is activated
only when the ERROR label is active, and thus it starts all
actions to be performed to handle the interrupt.
4.2.4 Atomicity
Atomicity is a key issue also in SW, as it avoids race
conditions and unpredictable behaviors due to concurrency.
An example of atomicity is shown in Fig. 5 as an automaton
obtained starting from a SW model. Being part of a
interrupt handling routine, all transitions from state
HANDLE to state INIT must be executed atomically. In this
way, the different transitions are seen as one only step from
other automata and interference is avoided.
4.3 From Analog Models
The evolution of analog components can be defined by using
differential equation, e.g., Ordinary Differential Equation
(ODE) [17], which easily allow to specify continuous
behaviors. However, complex components can react to
changes of the surrounding environment by modifying their
behavior according to particular conditions. An easy way for
describing such complex components is hybrid automata. A
large variety of modeling languages have been proposed for
describing hybrid automata, e.g., Phaver [12], Matlab/
Simulink [30], and CIF (that is the most expressive one
1
).
Conversion from an automaton-based description to the
UNIVERCM Model of Computation (MoC) is straightfor-
ward. Fig. 3 shows a possible mapping of such a conversion
from the CIF model depicted in Fig. 10 into UNIVERCM.
However, if a CIF model does not contain a single
automaton, but a network of concurrent automata some
manipulations are still necessary for translating a CIF
description into UNIVERCM. These manipulations are
related to the semantics of particular syntactical constructs
provided with the CIF language. In particular, we identified
and solved two main issues.
. Synchronization semantics. CIF labels have a synchro-
nization semantics different w.r.t. UNIVERCM labels.
Thus, the derived UNIVERCM model have to take
into account such an aspect.
. Hierarchical models. CIF models allow hierarchical
representations. Thus, a flattening approach have to
be define to correctly represent CIF models into
UNIVERCM where hierarchy is not directly sup-
ported.
4.3.1 Synchronization Semantics
In the CIF language, as well as UNIVERCM, labels describe
common events on which the automata, modeling the
Fig. 8. Starting code and corresponding automaton for a HW component
firing an interrupt.
Fig. 9. Starting code and corresponding automaton for an interrupt
handling routine.
Fig. 10. CIF code modeling a single hybrid automaton.
1. Notice that Matlab/Simulink and Phaver descriptions can be
converted into CIF descriptions [29].
continuous component, have to synchronize. Notice that
whereas in UNIVERCM a label o can be issued whenever the
guard of the corresponding transition is satisfied, in CIF
models, it cannot be issued if all the automata that share
that label are not able to receive it. For preserving this
particular semantics during the translation of a CIF
description into UNIVERCM, for each synchronization label
o it is mandatory to introduce 1) a set of Boolean variables
B
o
= :yic/
(
i
.o)
, containing one variable for each auto-
maton
i
that shares the synchronization label o and 2) a
predicate
o
=
V
i
:yic/
(
i
.o)
, that is given by the conjunc-
tion of all the variables in B
o
.
Intuitively, a variable :yic/
(
i
.o)
states whether a UNI-
VERCM automaton
i
is able to synchronize on o. As a
consequence, the conjunction of all these variables, i.e.,
o
,
represents the predicate all the UNIVERCM automata
sharing o are able to synchronize on it. Notice that a
variable :yic/
(
i
.o)
must be set to true only when the
automaton
i
enters a state | and at least one of the
outgoing edges of | depends on o. Otherwise, if the
automaton reaches a state i whose outgoing edges do
not depend on o, the variable must be set to false. This can
be done by handling the edges of the different automata
i
as follows: the update functions of all the incoming edges of
the states | in
i
have to include the assignment
:yic/
(
i
.o)
:= tinc. Instead, the update functions of all the
incoming edges of the states i must include the assignment
:yic/
(
i
.o)
:= )o|:c. Finally, to guarantee that a label o is
issued only when all the automata
i
are willing to
synchronize on it, it is sufficient to define the guards of
the edges depending on o as the conjunction of the original
constraint (extracted from the CIF description) and the
predicate
o
=
V
i
:yic/
(
i
.o)
.
4.3.2 Hierarchical Models
The CIF modeling language supports the definition of
hierarchical models for simplifying the design of analog
components. In a hierarchical representation, different
functionalities are defined in different entities that evolve
concurrently. Each entity consists of an interface containing
the variables shared with the other entities (i.e., formal
variables), and a structure containing the definition of the
local variables and the continuous behaviors. These con-
tinuous behaviors may be described either by instantiating
other entities or by defining automata or both of them. An
entity instance is characterized by an identifier for the
instance and a binding between the variables (i.e., actual
variables) of the current entity andthe formal variables of the
entity to be instantiated. Notice that each entity can be
instantiated multiple times and in different levels of the
hierarchy. Thus, to obtain a flatten description it is necessary
to recursively replace, starting from the top-level entity, all
the entity instances with their corresponding structures. For
example, given an entity 1
1
containing two instances c
2
1
and
c
2
2
of another entity 1
2
, the flattened structure of 1
1
can be
obtained by replacing each instances c
2
i
with a copy c
2
i
of the
internal structure of 1
2
. However, this copy c
2
i
of 1
2
has to be
manipulated before the import. These manipulations regard
1) the substitution of the formal variables with the actual
variables specified by the instances and 2) the renaming of
the local variables for avoiding conflicts due to multiple
instantiations of the same entity structures.
To replace an instance c
2
i
of 1
2
with its corresponding
structure copy c
2
i
, all the occurrences of variables of c
2
i
corresponding to input/output port of 1
2
must be substi-
tuted with the actual variables specified in c
2
i
. Notice that, if
1
2
has a hierarchical structure, then each c
2
i
will contain one
or more entity instances. In such a case, the variable
substitution will effect also the actual parameters of these
instances present in c
2
i
. Thus, the variables of 1
1
will be
propagated deep in the hierarchy. During the flattening, also
the local variables have tobe manipulated. The local variables
of 1
2
will be imported in 1
1
multiple times, i.e., one for each
c
2
i
contained in 1
1
. Thus, for distinguish the local variables
belonging to the different instances and avoiding conflicts,
they must be renamed. The easiest way of renaming the local
variables and grouping them by instances, consists of
prefixing their current identifiers with the corresponding
instance identifier. In particular, in each c
2
i
every occurrence
of a local variable .oi
,
will be renamedas id
c
2
i
.oi
,
. It is worth
noting that the variable renaming will affect also the actual
parameters of any entity instances present in each structure
c
2
i
. This is necessary to correctly propagating the new local
variables of 1
1
deep in the hierarchy.
4.4 From UNIVERCM to SystemC
Code generation starting from UNIVERCM descriptions can
lead to the generation of a homogeneous system descrip-
tion. For the reasons reported in the introduction, the
chosen output language is C++, with the use of the SystemC
library as support framework for simulation. Output on
different languages can be considered, but this is not part of
this paper.
The formal semantics described in Section 3.5 states that
UNIVERCM automata execute in parallel, thus each auto-
maton is mapped to a SystemC process. The body of each
process is built as a unique switch statement, where each
case label represents one of the automaton states. The initial
state is associated to the default value of the variable on
which the switch statement is performed. States marked
as atomic are merged in a unique state in order to preserve
atomicity.
Wires are mapped to signals, and their type is assigned
by matching their allowed alphabet. Variables are mapped
to a couple of SystemC variables, representing the current
value and the future value, respectively, in order to respect
the UNIVERCM semantics. The type is determined by the
variable alphabet for discrete variables, while continuous
variables are mapped to doubles.
Labels are represented with boolean values, where true
states that the label is active. In detail, labels are mapped to
a couple of boolean values, representing the current value,
and the next simulation value, respectively. At the end of
each simulation step, a process will set the new current
value to the future one, and the future value to false. It is
not possible to map labels into sc_events, even if this
mapping may seem more straightforward, since in SystemC
events cannot be used into conditions, while UNIVERCM
transitions include conditions on labels.
Transitions are mapped into if statements, whose
condition are the logic and of transition predicates and
enabling labels (i.e., they are verified if both predicates and
conditions on labels are satisfied). The if statements are
nested as if else if constructs, sorted respecting their
priorities. Whenever two transitions have the same priority,
a pseudorandom number generator is used, so that the
choice of the transition to take is nondeterministic, in order
to follow the UNIVERCM semantics. In this way, nonde-
terminism is still preserved in SystemC, so that all the
possible behaviors of the UNIVERCM description can be
executed in the SystemC implementation.
State invariants are constraints on the value of variables
and wires, thus mapped to C asserts checked at runtime.
The flow predicate of each state, representing continuous
evolution, is not straightforwardly supported by SystemC,
since SystemC does not support analog components. Thus,
the flow predicate is calculated by using the Eulers
numerical integration algorithm, taking as input a time
discretization value chosen by the designer. The SystemC-
AMS library could be also used in this case.
5 EXPERIMENTAL RESULTS
Advantages and limitations of the proposed approach are
highlighted in this section through the analysis of two
heterogeneous systems.
5.1 The Water Tank System
The proposed framework has been applied to automatically
obtain a single homogeneous UNIVERCM model of the
water tank system, starting from the heterogeneous models
of its components: hybrid automata modeled by using CIF
for the analog components, VHDL code for the controller
and C code for the driver. In Table 1, the SystemC code
generated by our framework (last row) has been compared
with four modeling alternatives, concerning the simulation
speed and the accuracy of the model.
. A top-down approach combining different MoCs in
Ptolemy. This has been selected as reference model
for comparing accuracy, since in Ptolemy each
component is modeled by using the suited MoC.
. A top-down approach adopting a single MoC, i.e.,
hybrid automata, described by means of the CIF
language.
. a bottom-up approach setting up a cosimulation
framework between SystemC (for both analog com-
ponents and digital HW) and QEMU (for HdS) [13].
. A bottom-up approach setting up a cosimulation
framework between SystemC (for discrete HW and
HdS) and Matlab-Simulink (for analog components).
Simulations have been performed on an Intel Xeon
2.8 MHz with 8 GB of RAM and a Debian/Linux platform
with the 2.6.23 kernel version. Fig. 11 shows how different
approaches estimate the evolution of the water level during
simulation.
Concerning the simulation speed, the CIF simulation is
the fastest, since it takes advantage from the fact that, in
correspondence of an asymptotic growth of the water level,
the time step used for the approximation is relaxed without
loosing accuracy in the computation. On the contrary,
cosimulation approaches are the slowest. In particular the
SystemC/Simulink cosimulation suffers the overhead im-
posed to the SystemC kernel by the extremely frequent
synchronization steps caused by the fine-grain Simulink
computation.
Concerning the accuracy, the CIF model is as much as
accurate as the Ptolemy one. However, modeling the
discrete component (i.e., the controller) in CIF was not
trivial. In fact, it required to enrich the controller model
with a set of workarounds to represent its discrete evolution
(i.e., introduction of an automaton for modeling the clock
signal, an automaton to generate events on inputs, etc.).
Similar considerations apply for HdS. Differently from CIF,
cosimulation approaches highlighted a not negligible error
w.r.t the Ptolemy model. This is due to the lack of a uniform
time representation between the involved simulators, which
causes a not accurate opening of the valve. This problem is
implicit for all cosimulation schema where simulators
evolve without preserving a strict step-by-step simulation.
Thus, cosimulation is unsuited whenever timing is an
important parameter. On the contrary, the SystemC code
generated by our framework preserved a high degree of
accuracy w.r.t Ptolemy. A very small error (2 percent) is due
to the inaccuracy introduced by the discretization of analog
components. In fact, we simulated the model within
Ptolemy by using the O1145 (Dormand-Prince) solver
with a maximum step size of 1c 3 and an absolute
tolerance of 1c 8. As regards the generated SystemC
model, it adopts an Eulers numerical integration algorithm
to compute the model dynamics. In such a model, we used
the same accuracy (i.e., step size of 1c 3) for computing
the integration step. We are confident that such an error will
be removed when UNIVERCM automata related to analog
components will be mapped toward SystemC-AMS, instead
of SystemC.
TABLE 1
Water Tank: Modeling Alternatives
Fig. 11. Water tank: simulation traces.
In summary, these results show that the proposed
framework, generating a SystemC implementation with
simulation speed very closed to CIF and an high level of
accuracy, represents an effective environment for support-
ing component reuse and bottom-up design methodologies.
5.2 The Boiler System
This section presents another way of using the proposed
framework, that is, the evaluation of possible realizations of
high-level models obtained by combining manually defined
components and already existing IPs. In particular, lets
consider the bang-bang control-boiler model provided with
the Mathworks Simulink tool. Such a system is depicted in
Fig. 12. Its main components are 1) a discrete bang-bang
controller (i.e., Controller) and 2) a boiler plant. Intuitively,
the controller controls when the boiler is turned on and off,
i.e., when the boilers temperature is lower than the specified
set-point, the boiler is activated to warm up. Otherwise, the
boiler is switched off to reduce its temperature.
Apossible realization of such a systemis shown in Fig. 13.
It integrates the boiler components, coming from the
Simulink model, with reused components and manually
defined components. In particular, the Controller component
has been implemented in SystemC starting from the bang-
bang Stateflow model, while the behavior of the Boiler plant
has been formalized into a CIF description. To have a
concrete model of the system, we introduced an AMBA bus
(AHB) SystemC model, a simple generic RAM module and
an Analog-Digital Converter (ADC) both modeled by using
VHDL. Finally, we also added two software components
described in C (i.e., UI handler and UI). The UI handler is a
device driver that accesses the RAM memory to retrieve the
value of the digital temperature used by the controller for
turning on and off the boiler, while the UI software prints on
a file such values. Notice that none of these components has
been implemented ex novo, since they have been reused
starting from already existing implementations. For this
reason, the introduction of transducers has been required to
allow binding of different components (i.e., implementing
the protocol to communicate through the AMBA bus).
All the components have been automatically translated
into UNIVERCM automata, combined together and then
translated into a homogeneous SystemC description. In
particular, the first attempt was to check that the obtained
realization was equivalent to the original Simulink model.
In the first implementation, the controller, the ADC, bus,
and boiler plant have all the same sampling precision.
Moreover, only the controller acts as master on the bus.
Thus, no delays can happen on the bus, e.g., when sensing
the boiler temperature and turning on and off the boiler.
This represents the ideal case described by the Simulink
model but integrated in a complete system. Top of Fig. 14
shows a comparison between the temperature evolutions of
the high-level Simulink model and this ideal realization.
The figure clearly underlines that the behaviors coincide.
As a next step, in order to generate a more concrete test-
case, the manually defined components (i.e., controller and
boiler plant) have been changed by considering different
sampling times. In particular, the boiler plant is assigned the
finest sampling w.r.t. both the ADC and controller. Besides
the controller was assumed to have a sampling time coarser
than the ADC. Notice that these are realistic assumptions
that can be made on a realization of the control-boiler
system. Bottom of Fig. 14 depicts the new comparison of the
temperature evolutions of both the Simulink model and its
concrete SystemC realization. The two curves do not
coincide. The temperature of the SystemC realization tries
to follow its ideal evolution. However, due to the presence
of different sampling times, the operative modes of the
boiler (i.e., on/off) are switched with some delays. Notice
that this is not an erroneous implementation of the system.
On the contrary, it underlines how the proposed bottom-up
approach can speed up the identification of concrete
implementations which satisfy the user needs.
Fig. 12. Bang-bang control-boiler Simulink model.
Fig. 13. A realization of the Bang-bang control-boiler Simulink model.
Fig. 14. Comparison of Simulink simulation traces with ideal SystemC
traces (top) and concrete SystemC traces (bottom).
5.3 Applicability Analysis
The experimental analysis allows to compare the effective-
ness of UNIVERCM in modeling complex heterogeneous
embedded systems with respect to other formalisms, as
summarized in Table 2. Columns refer to the different kinds
of components required to model a typical heterogeneous
system: discrete (Digital HW), continuous (Analog HW),
software (SW), and physical environment (Env.), respec-
tively. A check mark in a cell states that the behavior is
supported by the corresponding formalism. If the check
mark is embraced into brackets, then the behavior is only
partially supported.
This round-up showed that only Metropolis is able to
capture the heterogeneity of components of modern
embedded systems. However, in Metropolis the commu-
nication semantics is not defined forcing the designer to
formalizing ad hoc interaction rules. On the contrary,
UNIVERCM allows to effectively model heterogeneous
embedded system and it does not suffer of Metropolis
limitation, thanks to a well-defined composition semantics
that establishes how interaction (i.e., communication)
between a set of UNIVERCM automata occurs. Moreover,
UNIVERCM is the only formalism defined to support a full
bottom-up approach where already existing heterogeneous
descriptions can be automatically converted and inte-
grated into UNIVERCM automata for being, subsequently,
remapped to a single simulable model.
Even if the formalism of UNIVERCM is stable, some
issues remain open. Digital and analog HW is fully
supported, but some work still needs to be done to allow
a complete mapping of SW to UNIVERCM. As an example,
recursion is not supported and operating system mechan-
isms are not completely reproduced. However, the focus of
UNIVERCM is on HdS, that is completely supported.
Furthermore, the mapping to SystemC may be further
investigated, to produce more optimized code and by
supporting SystemC-AMS.
5.4 Application to CMP Design
The most wide spread and promising type of heterogeneous
CMPs are architectures where the CPU is integrated with a
GPU-class multicore [34]. Porting one starting heteroge-
neous system to such architectures would be time-consum-
ing and complex, as the heterogeneous components must be
reconciled to a multithreaded environment and all syn-
chronization mechanisms that allow communication be-
tween components must be reproduced.
The methodology proposed in this paper allows to
automate this design step. Mapping all the starting
components to UNIVERCM allows to obtain an homoge-
neous SystemC implementation of the system, as described
in Section 4. Such a description can be used as a starting
point for automatic CPU-GPU code generation methodol-
ogies such as SAGA [33]. SAGA is a novel approach for
concurrent SystemC simulation that leverages the massive
parallelism available on GP-GPUs. The intrinsic parallelism
of the system is exploited in SAGA by dividing computa-
tion into different independent data-flows, mapped to
distinct processing units on the GPU. Each simulation step
is executed by a kernel on the GPGPU.
Application of SAGA to the homogeneous description
built for the boiler system in Section 5.2 brought to the
definition of 9 dataflows of starting SystemC processes.
Such dataflows have been converted to C code targeting
execution on the GPU, while the CPU has been used for
monitoring execution. As a result, generation of code for the
Pangaea architecture has been automatic, since both the
conversion to/from UNIVERCM and the SAGA methodol-
ogy are automated. The efficiency of such generated code is
highlighted also by the 3x speedup achieved with respect to
the homogeneous simulation (45.2 s versus 135 s).
6 CONCLUSIONS AND FUTURE WORKS
In the context of heterogeneous CMP design, the paper
presented a framework for efficiently supporting component
reuse and for generating a homogeneous representation of a
starting heterogeneous system. Such a representation can be
used as a starting point for heterogeneous CMP design and
optimization flows. The framework exploits an interchange
format and a set of related tools for automatically mapping
heterogeneous descriptions to a homogeneous representa-
tion with a precise semantics based on the UNIVERCM MoC.
Specific issues concerning mapping of HDL models, analog
models, and HdS code toward UNIVERCM have been
investigated. Experimental results showed that the SystemC
code generated from the UNIVERCM model preserves the
accuracy achieved by traditional top-down approaches
based on both the use of a single MoC (e.g., hybrid automata
modeled with the CIF language), and the integration of
different MoCs in a unique framework (e.g., Ptolemy).
Moreover, the simulation of such a code is more accurate and
faster w.r.t. bottom-up approaches based on cosimulation.
Future works will be devoted to support different C++ code
generators.
ACKNOWLEDGMENTS
This work has been partially supported by the European
project SMAC FP7-ICT-2011-7-288827.
REFERENCES
[1] Accellera, Verilog-AMS LRM, URL: http://www.verilog.org/
verilog-ams/htmlpages/public-docs/lrm/2.3.1/VAMS-LRM-2-3-
1.pdf, 2012.
[2] F. Balarin, Y. Watanabe, H. Hsieh, L. Lavagno, C. Passerone, and
A. Sangiovanni-Vincentelli, Metropolis: An Integrated Electronic
System Design Environment, Computer, vol. 36, no. 4, pp. 45-52,
Apr. 2003.
TABLE 2
Applicability of Different Languages, Formalisms, and MoCs
[3] K. Bertels, V.-M. Sima, Y. Yankova, G. Kuzmanov, W. Luk, G.
Coutinho, F. Ferrandi, C. Pilato, M. Lattuada, D. Sciuto, and A.
Michelotti, Hartes: Hardware-Software Codesign for Heteroge-
neous Multicore Platforms, IEEE Micro, vol. 30, no. 5, pp. 88 -97,
Sept./Oct. 2010.
[4] F. Bouchhima, M. Briere, G. Nicolescu, M. Abid, and E.
Aboulhamid, A SystemC/Simulink Co-Simulation Framework
for Continuous/Discrete-Events Simulation, Proc. IEEE Intl
Behavioral Modeling and Simulation Workshop (BMAS), pp. 1-6,
2007.
[5] C. Brandolese, W. Fornaciari, L. Pomante, F. Salice, and D. Sciuto,
Affinity-Driven System Design Exploration for Heterogeneous
Multiprocessor SoC, IEEE Trans. Computers, vol. 55, no. 5,
pp. 508-519, May 2006.
[6] D.D. Gajski, Z. Jianwen, R. Domer, A. Gerstlauer, and Z. Shuqing,
SpecC: Specification Language and Methodology. Springer, 2000.
[7] G. De Micheli, R. Ernst, and W. Wolf, Readings in Hardware/
Software Co-Design. Morgan Kaufmann Publishers, 2001.
[8] P. Diallo, J. Champeau, and V. Leilde, Model Based Engineering
for the Support of Models of Computation: The Cometa
Approach, Proc. Intl Workshop Multiparadigm Modeling (MPM),
pp. 1-13, 2011.
[9] EDALab s.r.l., HIFSuite, URL: http://www.hifsuite.com, 2012.
[10] J. Eker, J.W. Janneck, E.A. Lee, J. Liu, X. Liu, J. Ludvig, S.
Neuendorffer, S. Sachs, and Y. Xiong, Taming Heterogeneity -
The Ptolemy Approach, Proc. IEEE, vol. 91, no. 1, pp. 127-144,
Jan. 2003.
[11] M. Fernandez, Models of Computation - An Introduction to
Computability Theory. Springer, 2009.
[12] G. Frehse, PHAVer: Algorithmic Verification of Hybrid Systems
Past HyTech, Proc. Hybrid Systems: Computation and Control,
vol. 3414, pp. 258-273, 2005.
[13] F. Fummi, D. Quaglia, S. Vinco, G. Perbellini, and S. Saggin,
Mixing Simulated and Actual Hardware Devices to Validate
Device Drivers in a Complex Embedded Platform, Proc. 10th Intl
Workshop Microprocessor Test and Verification (MTV), pp. 63-68,
2009.
[14] D.D. Gajski, N.D. Dutt, A.C.-H. Wuand, and S.Y.-L. Lin, High-Level
Synthesis: Introduction to Chip and System Design. Kluwer Academic
Publishers, 1992.
[15] L.D. Guglielmo, F. Fummi, G. Pravadelli, F. Stefanni, and S. Vinco,
UNIVERCM: The UNIversal VERsatile Computational Model for
Heterogeneous Embedded System Design, Proc. IEEE Intl High
Level Design Validation and Test Workshop (HLDVT), 2011.
[16] W. Haid, K. Huang, I. Bacivarov, and L. Thiele, Multiprocessor
SoC Software Design Flows, IEEE Signal Processing Magazine,
vol. 26, no. 6, pp. 64-71, Nov. 2009.
[17] T. Henzinger, The Theory of Hybrid Automata, Proc. IEEE 11th
Ann. Symp. Logic in Computer Science (LICS), pp. 278-292, 1996.
[18] F. Herrera and E. Villar, A Framework for Embedded System
Specification under Different Models of Computation in Sys-
temC, Proc. ACM/IEEE 43rd Design Automation Conf. (DAC),
pp. 911-914, 2006.
[19] IEEE 1076.1 Working Group, IEEE Standard VHDL Analog and
Mixed-Signal Extensions, 1999.
[20] R. Kumar, D. Tullsen, N. Jouppi, and P. Ranganathan, Hetero-
geneous Chip Multiprocessors, Computer, vol. 38, no. 11, pp. 32-
38, Nov. 2005.
[21] E. Lee and A. Sangiovanni-Vincentelli, Component-Based Design
for the Future, Proc. ACM/IEEE Design Automation Test in Europe
Conf. and Exhibition (DATE), pp. 1-5, 2011.
[22] T. MathWorks, Stateflow: Design and Simulate State Machines
and Control Logic, URL: http://www.mathworks.com/
products/stateflow/, 2012.
[23] Open SystemC Initiative, SystemC, URL: http://www.systemc.
org, 2012.
[24] Open SystemC Initiative, SystemC-AMS 1.0 Standard, URL:
http://www.systemc.org/downloads/standards/ams10, 2012.
[25] H. Patel, S. Shukla, and R. Bergamaschi, Heterogeneous
Behavioral Hierarchy Extensions for SystemC, IEEE Trans.
Computer-Aided Design of Integrated Circuits and Systems, vol. 26,
no. 4, pp. 765-780, Apr. 2007.
[26] J. Paul, D. Thomas, and A. Bobrek, Scenario-Oriented Design for
Single-Chip Heterogeneous Multiprocessors, IEEE Trans. Very
Large Scale Integration Systems, vol. 14, no. 8, pp.868 -880, Aug.
2006.
[27] I. Sander and A. Jantsch, System Modeling and Transformational
Design Refinement in ForSyde, IEEE Trans. Computer-Aided
Design of Integrated Circuits and Systems, vol. 23, no. 1, pp. 17-32,
Jan. 2004.
[28] S. Shee and S. Parameswaran, Design Methodology for Pipelined
Heterogeneous Multiprocessor System, Proc. ACM/IEEE 44th
Design Automation Conf. (DAC), pp. 811-816, 2007.
[29] C. Sonntag, R. Schiffelers, D. van Beek, J. Rooda, and S. Engell,
Modeling and Simulation Using the Compositional Interchange
Format for Hybrid Systems, Proc. Sixth Intl Conf. Math. Modeling
(MATHMOD), pp. 640-650, 2009.
[30] The MathWorks, Inc. Simulink 7.6, http://www.mathworks.
com, 2010.
[31] S. Tudoret, S. Nadjm-Tehrani, A. Beneviste, and J.-E. Stro mberg,
Co-Simulation of Hybrid Systems: Signal-Simulink, Proc. Sixth
Intl Symp. Formal Techniques in Real-Time and Fault-Tolerant
Systems (FTRTFT), pp. 134-151, 2000.
[32] M. Vasilevski, F. Pecheux, N. Beilleau, H. Aboushady, and K.
Einwich, Modeling Refining Heterogeneous Systems with
SystemC-AMS: Application to WSN, Proc. ACM/IEEE Design,
Automation and Test in Europe (DATE), pp. 134-139, 2008.
[33] S. Vinco, D. Chatterjee, V. Bertacco, and F. Fummi, SAGA:
SystemC Acceleration on GPU Architectures, Proc. ACM/IEEE
49th Design Automation Conf. (DAC), 2012.
[34] H. Wong, A. Bracy, E. Schuchman, T.M. Aamodt, J.D. Collins, P.H.
Wang, G. Chinya, A.K. Groen, H. Jiang, and H. Wang, Pangaea:
A Tightly-Coupled IA32 Heterogeneous Chip Multiprocessor,
Proc. 17th Intl Conf. Parallel Architectures and Compilation Techni-
ques (PACT), pp. 52-61, 2008.
[35] H.woo Park, H. Oh, and S. Ha, Multiprocessor SoC Design
Methods and Tools, IEEE Signal Processing Magazine, vol. 26,
no. 6, pp. 72 -79, Nov. 2009.
Luigi Di Guglielmo received the masters
degree in computer science from the University
of Verona, in 2008. He is working toward the
PhD degree in the Department of Computer
Science at the University of Verona since 2009.
His main research interests include electronic
design automation methodologies for modeling
and verification of hardware/software discrete/
hybrid systems. In this context, he collaborated
in several national and international projects. He
is a member of the IEEE.
Franco Fummi received the laurea and PhD
degrees in electronic engineering, from Politec-
nico di Milano, in 1990 and 1995, respectively.
From 1995, he has been with the Dipartimento di
Elettronica e Informazione of Politecnico di
Milano with a position of an assistant professor.
In July 1998, he obtained the position of an
associate professor in computer architecture at
the Dipartimento di Informatica of Universita` di
Verona. He is a full professor at the Dipartimento
di Informatica of Universita` di Verona, since 2001. His main research
interests include electronic design automation methodologies for
modeling, verification, testing, and optimization of embedded systems.
He is a member of the IEEE and a member of the IEEE test technology
committee.
Graziano Pravadelli received the laurea degree
in computer science and PhD degree from the
University of Verona, in 2001 and 2004, respec-
tively. In January 2005, he obtained the position
of an assistant professor in the Department of
Computer Science at the University of Verona.
Since January 2011, he is an associate profes-
sor at the same University. He is the cofounder
of EDALab, a spin-off whose mission consists of
giving support for innovation and technology
adoption in traditional and emerging fields of networked embedded
systems. His main interests include hardware description languages,
methodologies to describe hardware and software systems, and
functional verification of embedded systems. In this context, he
collaborated in several national and international projects. He published
more than 80 papers in the electronic design automation field. He is a
member of the IEEE.
Francesco Stefanni received the master and
PhD degrees in computer science from the
University of Verona, Italy, in 2004, 2011,
respectively, where he is currently a postdoctor-
al student. His research interest encompasses
NES modeling and verification, formal modeling,
semantics mapping, efficient simulation. In
2011, he won the best paper award at Forum
on specification and Design Languages (FDL).
He has 13 publications and a book chapter
appeared on Languages for Embedded Systems and their Applications
(2009). He has been involved in many european projects.
Sara Vinco received the master degree in
computer science from the University of Verona,
in 2009. She is working toward the PhD degree
in the Department of Computer Science at the
University of Verona, since 2010. Her main
research interests include electronic design
automation methodologies for simulation and
validation of heterogeneous embedded sys-
tems. In this context, she collaborated in several
national and international projects. She is a
member of the IEEE.
> For more information on this or any other computing topic,
please visit our Digital Library at www.computer.org/publications/dlib.

UNIVERCM: The UNIversal VERsatile Computational Model For Heterogeneous System Integration

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

UNIVERCM: The UNIversal VERsatile Computational Model For Heterogeneous System Integration

Загружено:

Авторское право:

Доступные форматы

UNIVERCM: The UNIversal

VERsatile Computational Model for

is the set of currently active labels.

_ 11G the set of candidate edges for such

if and only if:

, i.e., the set of labels required to

). Wire variables behave like signals of an HDL,

for the configuration :. .. n. c.

= O, i.e., the active label set is emptied;

\t [0. c[ )|on(:)(.. )(t. .. n).

), i.e., is the starting

) that is being used for the

) Q, the transition relation

Вам также может понравиться