Model-driven design and ASM-based validation of Embedded Systems

sanatoriumdrumElectronics - Devices

Nov 25, 2013 (3 years and 8 months ago)

189 views

Model
-
driven design and

ASM
-
based
validation

of

E
mbedded

S
ystems



Angelo Gargantini


Dipartimento di Ingegneria Informatica e Modelli Matematici
,
Università di

B
ergamo
,

Italy

-

angelo.gargantini@unibg.it


Elvinia

Riccobene


Dipartimento di Tecnologie d
ell’I
nformazione,

Università di Milano
,
Italy


riccobene@dti.unimi.it


Patrizia Scandurra


Dipartimento di Tecnologie dell’Informazione
,
Università di Milano
,
Italy


scandurra@dti.unimi.it

KEY TERMS & DEFINITI
ONS

M
o
del
-
driven engineering,
E
mbedded
S
ystem

D
esign, System on Chip Design,
Abstract
State Machines,
UML profile, SystemC, Behavioral modeling,
System
Validation.

ABSTRACT

In the embedded system and
System
-
on
-
Chip (
SoC
)

design area, the increasing technological
complexity coupled with requests for mor
e performance and shorter time to market have caused a
high interest for new methods, languages and tools capable of operating at higher levels of
abstraction than the conventional system level. This chapter presents a model
-
driven and tool
-
assisted develo
pment process of SoCs, which is based on high
-
level UML design of system
components
, guarantees
SystemC code generation from graphical models, and
allows validation
of system behaviors

on
formal

models
automatic
ally derived

from UML models
. An environment
for
system
design and analysis is also p
resented, which is based on a UML profile for SystemC

and the Abstract State Machine formal method.

INTRODUCTION

In the
E
mbedded
S
ystem

(ES)

and
System
-
on
-
Chip (SoC)
design area, conventional system level
design flo
ws usually start by writing the system specification and developing a functional
executable model. The system is refined through a set of abstraction levels, toward a final
implementation in hardware and software. Nowadays it is an emerging practice to dev
elop the
functional model and refine it with the C/C++/SystemC languages

[
Gröetker et

al.
,
2002
]. The
hardware part of the system goes down to the Register Transfer Level (RTL) for the synthesis
flow, while the soft
ware part can be either simulated at high (functional or transactional) level or
compiled for an Instruction Set Simulator (ISS).


Recently, the increasing technological complexity coupled with requests for more
performance and shorter time to market have
caused a high interest for new methods, languages
and tools capable of operating at higher levels of abstraction

in the design process
.
Such an
improvement has been ach
ieved by exploiting visual
software
modeling

languages like
Unified
Modeling Language

(
U
M
L)
[
UML
, 2005
]
to describe system specifications and generate from
them executable models in C/C++/
SystemC.


In the embedded system domain, the

UML has been used
mainly for
documentation
purposes. There are, indeed, some criticisms t
hat are widely shared towards the use of
the
UML
as
modeling language.
T
he UML includes a rich set of modeling elements that can be used for a
wide range of applications, whereas
modeling specific applications, as
embedded systems

and SoCs,
would be easier

using a more specialized (domain
-
specific) notation representing the basic elements
and patterns of the target domain. Furthermore, the UML offers the possibility of
designing

the same
system from different

views (by different UML diagrams). Even if such
a feature can be used to
capture re
lated aspects of a design from

different prospective, it may result in inconsistencies between
diagrams, when the use of UML is not coupled with a rigorous design discipline [
Chen et al, 2003

]. There
fore, the use of
the
UML for
the

specific application domain
of
embedded system

and
SoC

design
requires:



a domain

specific language, called
profile
, built on the basic UML infrastructure and
including domain
-
specific building blocks (defined using stereoty
pes) to model common
design elements and patterns,



a methodology
defining

how and when the profile notation should be used.

According to these requirements, i
n
[
Riccobene et al.,

200
5a
,
Riccobene
et al.
, 2005b
,
Riccobene et al.
, 2007a
]

a

UML2 profile for Sy
stemC

is presented
, which lift
s

the SystemC
language
to the UML
modeling
level.

It represents a

set of structural and behavioral c
onstructs
for designing at
system
-
level with automatic encoding in
SystemC. With this approach, the
standard UML language is applied as high
-
level system modeling language

and operates in
synergy with a lower
-
level system language.

To foster the methodology in a systematic and
sea
mless way, in [
Riccobene et

al.
, 2007b
] a SoC design process, called UPSoC (Unified Process
for SoC), is presented as extension of the conventional Unified Process [
Arlow & Neustadt,
2002
]

for

the
SoC

refinement flow
. The UPSoC process
has been developed
following
the
principles of the
Object Management Group

(
OMG
) Model
-
driven

Architecture (MDA) [
Mellor
et al., 2003
]
--

a framework for Model
-
driven Engineering

(MDE) [
Bezivin, 2005
]
,
according to

which a
system development process
should rely

on
modeling, model transformations

and
automated

mapping of models to implementations.
Indeed, the UPSoC
is

based on
model
-
to
-
model

and
model
-
to
-
code

model tra
nsformations from abstract models towards refined (but
still
abstract) models and/or
SystemC code models.

Even if
modeling
methods based on the UML and UML profiles have receiving increasing
interest in the
embedded system

and SoC contexts as they allow
m
odeling at a higher level of
ab
straction than that of system
-
level languages
,

UML
-
based design methods

still suffer the lack
of

effective
formal analysis

(validation & verification) techniques. Formal methods and analysis
tools have been most often applied

to low level hardware design. But, these techniques are not
applicable to system descriptions given in terms of programs of system
-
level languages (like
SystemC, SpecC, etc.), since such languages are closer to concurrent software than to traditional
hard
ware description [
Vardi, 2007
], and the focus in the literature so far has been mainly on
traditional code
-
based simulation techniques. Moreover, classical analysis techniques are not
directly applicable to UML
-
based desig
n methods
that lack of a strong mathematical foundation
necessary for formal model analysis.



We
tackle
the problem of form
ally analyzing high
-
level UML

SoC

descriptions by joining
the
SystemC
UML

modeling language
with
a
formal
method,
capable of
elimina
ting ambiguities in
the UML semantics,

and using

analysis

techniques

applicable to formal models. Therefore, w
e
have

complement
ed

our

UP
SoC design process with a
formal analysis

process allowing

system
components
to

be functionally validated and verified e
arly at high levels of abstraction
, and even
in a
semi
-
transparent way (i.e. no strong skills and expertise on formal methods are required to
the user) by the use of the
Abstract State Machine (
ASM
)

formal method

[
Börger & Stärk, 2003
]
and its related tools

[
Asmeta,

20
07
]
.



In this chapter, we present a model
-
driven
methodology
for the SoC design, which involves
the
SystemC UML profile as major
system modeling
notation

and the
Abstract State Ma
chines

as
formal support for

validation of

system behavior
.
The
modeling activity can be performed at
different level
s

of abstraction,

from a high

functional

level
down to the Register Transfer

L
evel

(RTL)
.

Model
-
to
-
code transformations allow automatic map
ping of UML models to SystemC
code, while model
-
to
-
model transformations provide automatic mapping of SystemC UML
graphical model to formal models suitable for application of model analyses
standard techniques
.



A supporting
environment for both
processe
s
of
SoC
design and
validation

is also presented.
The
modeling
kit

of this environment

assists the designer
along
the
modeling
activity

and
provides
SystemC code generation/back
-
annotation from/to UML modes.
The
validation

process
is supported by an
analys
is kit

built upon the ASMETA toolset


a set of tools around ASMs
--
,
which operates on
the
formal specification

of the system.

As case study,
the
Counter

system
taken from the standard SystemC distribution will be
considered to illustrate
how to design an
d validate a SoC by our approach. The design model is
developed using the
SystemC UML profile.
We
then show

how the UML model of the
underlying system is automatically mapped into a corresponding ASM model
, and
h
ow to
validate the
system
functionality by
t
echniques based on
simulation

and scenario
s construction.

The remainder of this chapter is organized as follows. Sect.
Background

quotes some
related
work and

provides an overview of the SystemC UML profile
explaining

the rational
ity behind the
development of a UML profile

for

the

SoC design. It also briefly
summarizes
the application of
formal m
ethods to specify and analyze embedded systems,

and presents and justifies the choice
of the ASM
s

as formal support for our design methodo
logy
. Sect.
Model
-
driven SoC design and
analysis flow

describes the overall SoC design and
analyses
flow
, at the light of the MDA
principles
. It also
comments on

the advantages
of a

model
-
driven methodology
with respect to a
code
design
for the
development of
SoC
s.

Sect.
SoC
modeling

&
Validation

environment

describes the architecture and the tool components of the supporting design and validation
environment. Sect.
The Counter case study

presents the application of our design methodology to
the case study. Sect.
Industrial
application

discusses some industrial case studies. Sect.
Future
Trends

sketches some future directions. F
inally, Sect.
Conclusion

provides some concluding
remarks.


BACKGROUND

This section provides an overview of

existing work concerning model
-
driven approaches for
embedded system

and SoC modeling using UML and UML profiles
, and on

the
formal
analyses
of UML design models
. It also

introduces
the reader to the main notations used

in our approach,
namely the UML

profile of the
SystemC language and the Abstract State Machines.

It also
justifies
the choice of the formal method we use fo
r analyses purposes, in

relation to the
models
of computation
most commonly used
in the area of embedded system and SoC
modeling
.

Related work

The possibility to use UML 1.x for system design [
Martin, 1999
]

started since
1999, but the
general opinion at that time was that UML was not mature enough as a system design language.
Nevertheless significant industrial experiences using UML in a system design process soon
started leading to the first results in design methodology,

such as the one in [
Moore et al., 2002
]
that was applied to an internal project for the development of a OF
DM Wireless LAN chipset. In
that

project
,

SystemC was used to provide executable models.

M
ore integrated design met
hodologies were
later
developed. The
authors of

[
Zhu et al., 2004
]
propose a methodology using UML for the specification a
nd validation of SoC design. They
define

a flow, parallel to the implementation flow, which is focu
sed on high
-
level specs capture
and validation. In [
Lavagno et

al., 2003
], a UML profile for a
platform
-
based

approach to
embedded software development is presented. It includes stereotypes to represent platform
services and

resources that can be assembled together. The authors also present a design
methodology supported by a design environment, called Metropolis, where a set of UML
diagrams (use cases, classes, state machines, activity and sequence diagrams) can be used to
c
apture the functionality and then refine it by adding models of computation. Another approach
to the unification of UML and SoC design is the HASoC (Hardware and Software Objects on
Chip) [
Edwards & Green, 2003
] methodology.

It is based on the UML
-
RT profile [
Selic, 2003
]
and on the RUP process [
Kruchten, 1999
]. The design process starts with an
uncommitted model
,
then

a
committed model

is derived by partitio
ning the system
into software and hardware, which
is finally

mapped onto a system platform. From these models a SystemC skeleton code can be
also generated, but to provide a finer degree of
behavioral

validation, detailed C++ code must be
added by hand to
the skeleton code. All the works mentioned above could greatly benefit from
the use of UML2

[
UML
, 2005
]
.

In [
do

Nascimento et

al., 2007
], the authors present a model
-
driven framework
,

called Mod
ES
(Model
-
driven Design of
ES
)
, made of metamodels definition

and APIs to integrate, by model
transformations, several model
-
based design tools
. However, this framework is

more related to
the design space exploration at a high abstraction level than
to
mod
el refinement,
model
validation
, and

automatic
code generation

from models
, which are
,

instead
,

our main concerns.

SysML [
SysML
, 2007
] is a
n

extension of
the
UML2 for a domain
-
neutral representation of
system engineering

applications.

It can be involved at the beginning of the design process, in
place of the UML, for the requirements, analysis, and functional design workflows. So it is in
agreement with
the
SystemC

UML profile, which can be thought (and effectively made) as
customizati
on of SysML rather than UML.
Unluckily,
when we started the SysML specification
was not yet finalized and there
were
no tools yet

support
ing it
.

Similar considerations apply also
to
the recent MARTE (Modeling and Analysis of Real
-
Time
Embedded Systems
) pro
file
initiative [
Rioux et al., 2005
;

MARTE, 2008
]
.

The standardization proposal [
USoC, 2005
] by Fujitsu, in collaboration with IBM and NEC,
has evident similarities w
ith
the

SystemC UML profile, like the choice of SystemC as a target
implementation language. However, their profile does not provide building blocks for
behavior

modeling
, neither

any time model.

Some other proposals already exist about extensions of UML
towards C/
C++/
SystemC. All
have in common the use of UML stereotypes for SystemC constructs, but
do
not rely on a UML
profile definition. In this sense, it is appreciable the work in [
Bruschi & Sciuto, 2002
] attempting
t
o define a UML profile for SystemC; but, as all the other proposals, it is based on the previous
version of UML, UML 1.4. Moreover, in all the proposals we have seen, no code generation,
except in [
Nguyen et

al., 2005
], from
behavioral

diagrams is considered.

Concerning the analysis (i.e. the validation and verification)
of UML
-
based
embedded system

descriptions
, in [
Patel & Shukla, 2007
]

the authors present a model
-
driven develop
ment and
validation process which begins by creating (from a natural language specification of the system
requirements) a functional abstract model and (still manually) a SystemC implementation model.
The abstract model is described using the Abstract Stat
e Machine Language (AsmL)


another
implementation language for ASMs. Our methodology, instead, benefits from the use of the
UML as design entry
-
level and of model translators
that

provide automation and ensure
consistency among descriptions in different n
otations (such those in SystemC and ASMs). In
[
Patel & Shukla, 2007
], a designer can visually explore the actions of interest in the ASM model
using the Spec Explorer tool and generate tests. These tests are used to drive
the SystemC
implementation from the ASM model to check whether the implementation model conforms to
the abstract model (
conformance testing
). The test generation capability is limited and not
scalable. In order to generate tests, the internal algorithm of
Spec Explorer extracts a finite state
machine

(FSM)

from ASM specifications and then use test generation techniques for FSMs. The
effectiveness of their methodology is therefore severely constrained by the limits inherited from
the use of Spec Explorer. Th
e authors themselves say that the main difficulty is in using Spec
Explorer and its methods for state space pruning and exploration. The ASMETA ATGT
[
Asmeta,

20
07
]
tool that we intend to use for the same scope exploits, instead,

the method of model
checking to generate test sequences, and it is based on a direct encoding of ASMs in PROMELA,
the language of the model checker SPIN [
Holzmann, 1997
].

The work in [
Habibi & Tahar, 2006
] also uses AsmL and Spec Explorer to settle a
development and verification methodology for SystemC. They focus on assertion based
verification of SystemC designs using the Property Specification Language (PSL), and although
they mention tes
t case generation as a possibility, the validation aspect is largely ignored. We
were not able to investigate carefully their work as their tools are unavailable. Moreover, it
should be noted that approaches in [
Patel & Shukla, 2007
;

Habibi & Tahar, 2006
], although using
the Spec Explorer tool, do not exploit the scenario
-
based validation feature of Spec Explorer.

In [
Mathaikutty et

al., 2007
], a mod
el
-
driven methodology for development and validation of
system
-
level SystemC designs is presented. The
design
flow is entirely based on the specification
of a functional model (reference model) in the ESTEREL language, a state machine formalism,
and on the

use of the ESTEREL Studio development environment for the

purpose of test
generation. This
approach provid
es

coverage
-
directed test suite generation for system level
design validation.

Authors in [
Bruschi et

al., 2005
]
provide test case generation by performing
static analysis

on
SystemC designs. This approach is limited by the strength of the static analysis tools, and the lack
of flexibility in describing the reachable states of interest for directed test generation. M
oreover,
static analysis requires sophisticated syntactic analysis and the construction of a semantic model,
which for a language like SystemC (built on C++) is difficult due to the lack of formal semantics.

The SystemC Verification Library [
OpenSystemCInitiativ
e, 2008
]
is a standard for developing
test
-
benches for SoC designs. It
provides API for transaction
-
based verification, constrained and
weighted randomization, exception handling, and HDL
-
connection.
These techni
ques
are
applicable

at SystemC code level, while w
e aim at developing formal techniques
for validation of
SystemC
system designs

at model level
.

The Message Sequence Chart (MSC) notation [
MSC, 1999
], originally developed for
telecommunication

systems, can be adapted to
embedded systems

to allow validation. For
instance, in [
Kogel et

al., 2004
] MSC is adopted to
visualize

the simulation of SystemC models.
The traces are only displayed and

not validated, and the author
s

report the difficulties of adopting
a graphical notation like MSC. Our approach is similar to that presented in [
Haroud et

al., 2004
],
where the MSCs are validated against the SDL model, fr
om which a SystemC implementation is
derived. MSCs are also generated by the SDL model and replayed to cross validation and
regression testing.

The SystemC UML profile: an overview

The

UML has been used in areas for which it was not originally intended. Ma
ny proposals have
been arisen for extending the UML for specific domains as banking, telecommunications,
aerospace, real
-
time systems, etc. These extensions are called
profiles
. UML profiles provide a
standard and generic extension mechanism for customizin
g UML models for particular domains
and platforms. Since a complete coverage of the UML is beyond the scope of this chapter, we
suppose the reader familiar with UML2

[
UML
, 2005
]
. We here provide some background
information on the System
C standard and on the UML extension mechanism based on profiles,
and then present the SystemC UML profile.

SystemC

SystemC

[
OpenSystemCInitiativ
e, 2008
;

SystemC, 2006
] is an IEEE standard controlled by the
major companies in the
Electronic Design Automation
(
EDA
) industry. It is a system
-
level
design language intended to support the description and validation of complex systems in an
environment completely based

on the C++ programming language.

SystemC is defined in terms
of a C++ class library, organized according to a layered
-
architecture shown in

Figure
1

(
adapted

from [
Gröetker et

al.
,
2002
]).


The
Core Language

and
Data Types

are the so called
core layer

(or layer 0) of the standard
SystemC, and consists of the event
-
based and discrete
-
timed SystemC simulation kernel, the core
design primitives
(modules, ports, channels, etc.)
an
d data types. The
Primitive Channels

represents, instead, the layer 1 of SystemC; it comes with a predefined set of interfaces, ports and
channels for commonly used communication mechanisms such as signals and fifos. Finally, the
external libraries layer o
n top of the layer 1 are not considered as part of the standard SystemC
language.

A design of a system in SystemC is essentially given by a containment hierarchy of
modules
.
A
module

is a container class able to encapsulate
structure

and
functionality

of
hardware/software
blocks. Each module may contain
variables

as simple data members,
ports

for communication
with the surrounding environment and
processes

for performing module’s functionality and
expressing concurrency in the system. Two kinds of processe
s are available:
method

processes
and
thread

processes. They run concurrently in the design and may be sensitive to
events

which
are notified by other processes. A port of a module is a proxy object through which the process
accesses to a
channel

interface
. The
interface

defines the set of access functions for a channel,
while the channel provides the implementation of these functions to serve as a container to
encapsulate the
communication

of blocks. There are two kinds of channels:
primitive

channels

and
hierarchical

channels
. Primitive channels do not exhibit any visible structure, do not contain
processes, and cannot (directly) access other primitive channels. A hierarchical channel is a
module, i.e., it can have structure, it can contain processes, and
it can directly access other
channels.

UML profiles

A UML profile is a set of
stereotypes
. Each stereotype defines how the syntax and the semantics
of an existing UML construct (a class of the UML metamodel) is extended for a specific domain
terminology or

purpose. A stereotype can define additional semantic
constraints



the
well
-
formedness rules



expressed as OCL (Object Constraint Language)

formula over the base
metaclass to enforce a semantic restriction of the extended
modeling

element, as well as
tag
s

to
state additional properties.

Figure
2

shows an example of stereotype definition for the
concept of

port


in
SystemC
(
sc_port
)

together with an example of OCL constraint.

Methodology
-
Specific Libraries

Layered Libraries

Master/Slave Library, etc.

Verification Library

Stat
ic Dataflow, etc.

Primitive Channels

Signal, Mutex: Semaphore.
FIFO, etc.

Core Language

Data Types

Modules Ports

Processes Interfaces

Channels Events

Event
-
driven simulation

4
-
valued Logic type

4
-
valued Logic Vectors

Bits and Bit Vectors

Arbitrary Pr
ecision Integers

Fixed
-
point types

C++ user
-
defined types

C++ Language Standard

Figure
1

SystemC Language Architecture


Figure
2

sc_port

stereotype

At model level, when a stereotype is applied to a model element (an instance of a UML
metaclass), an instance of a stereotype is linked to the model element. From a notational point of
view, the name of the stereotype is shown within a pair of guillemets
above or before the name of
the model element and the eventual tagged values displayed inside or close as name
-
value pairs.
Examples of stereotypes application are provided in Sect.

The SystemC UML profile

(see

Figure
6
, e.g., for the
sc_port

stereotype).

The SystemC UML profile

The UML2 profile for SystemC

[
Riccobene
et al.
, 2005b
]

is a consistent set of
modeling

constructs designed to lift both structural a
nd
behavioral

constructs of

SystemC (including events
and time features) to the UML
modeling
level.


The profile is defined at two distinct levels, reflecting the layered
-
architecture of SystemC: the
basic SystemC profile

for the core layer (or layer 0) o
f SystemC, and the
extended SystemC
profile

for the SystemC layer of predefined channels, ports and interfaces (or layer 1). This last is
provided either as a UML class library,
model
l
ed

with the basic stereotypes of the basic SystemC
profile, or as a grou
p of
standalone

stereotypes




specializing the basic SystemC profile.

Figure
3

summarizes the essential UML diagrams used in the profile.



Diagram

Purpose

Class Diagram

To define modules, channels, interface, port types

Compo
site
Structure Diagram

To describe how parts of modules and channels are connected
to each other to form the internal structure of a container
module

State Diagram

Used as method state machine to describe the reactive behavior
of processes/operations of m
odules and channels

Object Diagram

Derived from a composite structure diagram by instantiating
parts and connectors, to describe a particular configuration (also
partial) of the system

Figure
3

UML diagrams in the SystemC profile

Below, we briefly pres
ent
the most significant
modeling

elements of the basic SystemC
profile. It is logically str
uctured in three

parts: structure and communication, behavior and
synchronization
, and data types.

The

Structure and Communica
tion

part defin
es stereoty
pes for the SystemC
basic structural
modeling elements
(modules, interfaces, ports and channels) for use in UML structural diagrams
like UML class diagrams and composite structure diagrams.

Figure
4

show
s

t
he stereotype
s
de
fi
nition using the standard notation of UML pro
fi
les
, while
Figure
5

show
s

the concrete
notation of the
se

s
tereotypes

when applied at model level
.



Figure
4

Structure

and Communication

Stereotypes


Figure
5

Structure Stereotypes Notation


The
sc_module

stereotype defi
nes a SystemC module as extension of a UML

structured
class. As structured class, a composite structure (diagram) can be further

associated to a module
to repr
esent its internal structure (if any) made of channel

and other module parts
1
. Furthermore,
modules contain
ing

reactive processes are considered
active

classes

(and hence
shown by a class
box with additional vertical bars
)
.


In SystemC, an interface de
fi
ne
s the set of access functions (methods) for a

channel. The
sc_interface

stereotype de
fi
nes a SystemC interface as a UML

interface, and uses its
(longhand/shorthand) notation.


A port of a module is a proxy object through which a process accesses to a chann
el

i
nterface.
The
sc_port

stereotype maps the notion of SystemC port directly to the

notion of UML port,
plus some constraints to capture the concepts of simple, multi

and behaviour port. The tag



1

A property (or part) denotes a set of instances (in case of a property multiplicity greater than

1) that are
owned by the structured module. These instances are instances (j
ust a subset of the

total set of instances)
of the classi
fi
er (a module or a channel) typing the property.

max_if

de
fi
ned for the port stereotype speci
fi
es

the maximum

number of channel interfaces that
may be attached to the port. The

type of a port, namely its required interface, is shown with the
socket icon attached

to the port.
Figure
6

shows an example of a SystemC module exposing a
multi
-
port, an array port, and a simple port, together with the port type and the interface
definitions of the simple port.


Since UML ports are linked by connectors, a SystemC connector (binding of

ports to
channels) is provided as extension of t
he UML connecto
r, by the
sc
_
connector

stereotype. A
relay connector
--

the
sc_relay_
connector

stereotype
--

is

also de
fi
ned to represent the
port
-
to
-
port binding

between parent and child ports
2
.

The
sc_prim_channel

stereotype defines a primate channel
as extension of a s
imple
UML class

that implements a certain number of interfaces (i.e. the provided interfaces of the

channel).

The
sc_channel

stereotype de
fi
ne
s

a SystemC hierarchical channel
as specialization
of the
sc_module

stereotype as it may
further have structure (i
ncluding ports)
and may
contain
processes

other than providing interfaces
.



Figure
6

Modules, ports and interfaces

UML class diagrams are used to define modules, port types, inter
faces and channels.
The
internal structure of comp
osite modules

(or of hierarchical channels)
, especially the one of the
topmost level module (
for

the structure of the overall system), is captured by UML composite
structure diagrams; then, from these diagrams several UML object diagrams can be created to
describe different configuration scenarios. This separation allows the specification (also partial)
of different HW platforms as instances of the same parametric model (i.e. the composite structure
diagram).

The

Behavior

and Sy
nchroniza
tion

part defines sp
ecial state and action stereotypes

(see

Figure
7
)

to model

the control flow and the reactive behavior of SystemC processes
.

The two
stereotype
s
sc_met
hod

and
sc_
th
-
read

extend the
Operation

and the
StateMachine

UML
metaclasses. Th
is double extension allows us to associ
ate an operation (i.e. a process of a
module) to its behavio
r speci
fi
ed in terms of a
UML
method

state machine
3
.

These stereotypes
lead to a

n
ew formalism, called
SystemC Process State Machines
, defined as
ext
ension o
f the
UML state machines.






2

A port
-
to
-
port connection is the binding of a module port (parent port) to a lower level module

port (child port)
.

3

In UML,
a
method

state machine

is a state machine associated to a behavioral feature (such as an
operation of a class)

t
o

specif
y

the algorithm or procedure for the behavioral feature.

Each kind of process has a slight different behavior, but basically all processes: run
concurrently, are sequential, and are activated (if terminated or simply suspended) on the base of
their own sensitivity, which consists of a
n initial list of zero, one or more events
--

the
static
sensitivity

of a process

(specified as a list attached to the process operation in the container
module
)

--

and can dynamically change at run time realizing the so called
dynamic sensitivity

mechanis
m.

Stereotypes
wait
,
static_wait
,
and
,
wait_next_trigger
,
next_trigger_action
, and
dont_initialize

model the
dynamic
sensitivity
mechanism of a process behavior (a thread or a method).

The
sc_event

stereotype models a SystemC event in terms of a UML signal

(instance of the
class
SignalEvent
). The
notify_action

stereotype can be applied to an UML action to model
the SystemC function notify used to notify events. The
cancel_action

stereotype can be
applied to an UML action to model the SystemC function cancel

used to eliminate a pending
notification of an event.

The
sc_time

type is used to specify concrete time values used for setting clocks objects, or
for the specification of UML time triggers.



Figure
7

Behavioral Stereotypes

In
addition to these stereotypes, a

finite number of
abstract
behavior

patterns

of
process
state
machines have been identified.

Figure
8

depicts one of these
behavior

patterns together with the
corresponding SystemC pseudo
-
code for a

thread that: (i) is not initialized, (ii) has both a static
(the event list

e
1s
,…,e
Ns
) and a dynamic sensitivity (the
wait

state), and (iii) runs continuously
(by the infinite
while

loop). Note that

activities
a
1

and
a
2

stand for blocks of sequential (or
not) code without
wait

statements
. Moreover,

the notation used for the
wait

state in the pattern
in

Figure
8

stands for a shortcut to
denote

a generic
wait(e*)

statement

where the event
e*

matches one of the cases reported in

Figure
9

(each arc is a
run to completion

step of UML state
machines)
.

It should be noted that the state machine pattern depicted in

Figure
8

can be more complex in
case of one or more
wait

statements are en
closed in the scope of one or more nested control
structures. In this case, as part of the UML profile for SystemC, the control structures
while
,
if
, etc. need to be explicitly represented in terms of special stereotyped junction or choice
pseudostates
4

co
mbined together in order to stand out the state
-
like representation of the
wait

calls. The infinite loop mechanism of the thread process in
Figure
8
,

for example, is model
l
ed
with a
while

stereotyped pseudostate with a true guard
on the outgoing transition. These control
stereotypes allow us to effectively generate code from state diagrams in a style that reflects the
nature of constructs of the target implementation language, despite to well know techniques (like
state pattern, st
able table pattern, etc.) existing to achieve this goal.



Figure
8

A thread process pattern


Figure
9

Dynamic Sensitivity of a Thread

The

Data types

part defines a UML class library to represent the set
of SystemC data types.




4

Choice pseudostates must be used in place of junction pseudostates whenever the head condition of t
he
while

loop is a function of the results of prior actions performed in the same run
-
to
-

completion step.

Formal
M
ethods for Embedded System Design

The embedded systems and SoCs design approach currently used in the industry
,

is still informal
and
system
requirements and fu
nctionality

are expressed in natural language.
The inherent
ambig
uities of an informal specification prevent a meaningful analysis of the system and may
result in misunderstandings with customers and in incorrect or inefficient decisions at the time
when the design is partitioned and the tasks are assigned to different
teams. Therefore, i
t

is
nowadays widely acknowledged that an abstract mathematical model

is an essential ingredient
for a sound system
-
level design methodology

[
Sgroi et al., 2000
]
.

Indeed, a formal model
permits

(a)
to
u
nambiguously captur
e

the required functionality and other nonfunctional constraints (e.g.,
performance, cost, power consumption, and quality of service);
(b)
to
verify

the correctness of the
functional specification with respect to its desired properties (
e.g., satisfaction of temporal logic
properties or expected simulation behavior)
;

(c) model refinement
to include stepwise design
decisions and implementation details to
synthesize part of the specification onto the chosen
architectural and communication r
esources
, and the possibility to
verify the correctness of the
refinement
; (d) the
use
of
different tools, all understanding (possibly different aspects of) the
model
. In literature, there exist different
Models of Computation (
MOCs
)

that have

been used fo
r
system design.

Among the main MOCs, we can cite
:

discrete event models, data flow process
networks, Petri nets, synchronous and asynchronous finite state machines
t
ogether with their
extensions
. For a complete and detailed presentation and comparison of
them, we refer the reader
to

[
Edwards at at., 1997
]
,
while in the rest of this section, we introduce the concept of
Abstract
State Machines
(ASMs)
[
Börger & Stärk, 2003
]
that represent
an extensio
n of Finite State
Machines

and have
been widely applied as high
-
level system design and analysis method in the
area of the
embedded systems
.

A complete mathematical definition of the ASM method can be
found in [
Börger & Stärk, 2003
], together with a presentation of the great variety of its
application
.


Certainly, ASMs could be themselves used as systems engineering method, and thanks to
the notion
of

model
refinement [
Börger, 20
03
]
,

which

allows mapping abstract
specifications

into
code through a sequence of refinement steps [
Beierle et

al., 1995
Beierle et

al., 1995
;

Börger et

al., 2000
]
, they are able to guide the development of embedded hardware/software systems
seamlessly from requirements capture to their implementation.

However,
this is not the view of
ASMs tha
t we prefer to give here. Indee
d,
we
like
to integrate this f
or
mal method into a
system
development process where design models
are

developed using a graphical front
-
end conforming
to the current industrial standard,
i.e. the UML targeted for the SoC application domain,
and the
ASMs can be adopted to provide formal in
termediate representations of the intended system,
which can be used for several goals (abstract representation, models refinement, behavioral
validation, properties verification, etc.) according to the designer needs.


The choice
of the ASM as formal supp
ort
for model analyses in intentional and due to the
following main reasons:

(a)

ASMs

capture the principal models of computation

and specification in the literature

[
Börger & Stärk, 2003

(cap 7)
]
,

and therefore, ASMs have the

potentiality to smoothly
integrate useful concepts and techniques which have been tailored and are successfully
applied for specific goals or application domains.


(b)

Although the ASM method comes with a rigorous scientific foundation, the practitioner
needs

no special training to use it since it can be understood correctly as pseudo
-
code or
Virtual Machines workin
g over abstract data structures.

(c)

ASM models are

executable specifications,
therefore
suitable for high
-
level model

v
alidation
, and they are support
ed by a set of tools for
model simulation, testing, and
verification.

(d)

It is endowed with a
metamodel

[
Asmeta,

20
07
]
defining the ASM

abstract syntax in
terms of an object
-
oriented
representation. The metamodel availabi
lity
allows
automatic
mapping
of
SystemC UML models into ASM models by exploiting
MDE
techniques

of
automatic
model
s

transformation

[
Zhang et at., 2008
]
.

Abstract State Machines and the ASMETA toolset

Abstract State Machines
[
Börger & Stärk, 2003
]
are an extension of Finite State Machines, where
unstructured “internal” control states are replaced by states comprising arbitrary complex data.
The
states

of an ASM are multi
-
sorted first
-
order structures,
i.e. domains of objects with
functions and predicates defined on them. The
transition relation

is specified by “rules”
describing the modification of the functions from one state to the next. The basic form of a
transition rule is the
guarded update

having

form
if

Condition

then

Updates
, where
Updates

are
a set of function updates of the form
f
(
t
1
, …t
n
):=

t

and are simultaneously executed
5

when
Condition

is true.

An ASM
M

is a finite set of rules for such guarded multiple function updates. State transitions

of
M

may be influenced in two ways:
internally
, through the transition rules, or
externally

through the modifications of the environment. A
computation

of
M

is a finite or infinite sequence
S
0
,
S
1
,…
S
n

of states of
M
, where
S
0

is an initial state and each
S
n
+1

is obtained from
S
n

by firing
simultaneously all of the transition rules which are enabled in
S
n
.

The notion of ASMs moves from a definition which formalizes simultaneous parallel actions
of a single agent, either in an atomic way,
Basic
ASMs
, and in a structured and recursive way,
Structured or Turbo ASMs
, to a generalization where multiple agents interact
Multi
-
agent ASMs
.
Appropriate rule constructors also allow non
-
determinism (existential quantification) and
unrestricted synchronous p
arallelism (universal quantification).


The
ASMETA

(ASM mETA
modeling
) toolset
6


[
Gargantini et al.
, 20
07
;

Asmeta,

20
07
]
is a
set of tools around ASMs developed according to the model
-
dr
iven development principles. At
the core of the toolset (see

Figure
10
), the
AsmM metamodel

is a complete meta
-
level
representation of ASMs concepts based on the OMG’s Meta
-
Object
-
Facility (MOF). AsmM is
also available in the meta
-
language EMF/Ecore

thanks to the ATL
-
KM3 plug
-
in which allows
model transformations both in the EMF and MOF
modeling

spaces.




5

f

is an arbitrary
n
-
ary function and
t
1
,..,
.t
n
,
t

are first
-
order terms. To fire this rule to a state
S
i
,
i

0,
evaluate all terms
t
1
,
..,
.t
n
,
t

at
S
i

and update the function
f

to
t

on parameters
t
1
,..,
.t
n
. This produces another
state
S
i
+1

which differs from
S
i

in the new interpretation of
f
.

6

http://asmeta.sourceforge.net


Figure
10

The ASMETA tool set


The ASMETA toolset includes, among other things,



a textual notation,
As
metaL
, to write ASM models (conforming to the AsmM) in a
textual

and human
-
comprehensible form;



a text
-
to
-
model compiler,
AsmetaLc
,

and

the
OCL Checker
, to parse respectively
AsmetaL models and check for their consistency w
.r.t. the AsmM OCL constraints;



a
n XMI (XML Metadata Interchange)

interchange format for ASM models, JMI (Java
Metadata Interfaces) APIs for the creation, storage, access
and manipulation of ASM
models
;



a simulator,
AsmetaS
, to execute ASM models,



the
Avalla

language

and
the
AsmetaV

vali
dator

for scenario
-
based validation of ASM
models



the
ATGT

tool
for automatic test case generation from ASM models, which is
based
upon the SPIN model checker [
Holzmann, 1997
];



an Eclipse plug
-
in called
ASMEE

(ASM Eclipse Env
ironment) which acts as graphical
front
-
end to edit, manipulate, and export ASM models by using all tools/artifacts listed
above.

More details on these tools and on how we have targeted them for our goal are provided in
Sect.
0
.

MODEL
-
DRIVEN SOC DESIGN AN
D ANALYSIS FLOW

The
model
-
driven design methodology

we are presenting, has been developed
[
Riccobene et
al.,

200
5a
;

Riccobene et al.
, 2007a
]

according to the
principles of the
MDA approach
,
namely (a)
high
-
level
modeling
,
(b)
automated mapping of models to implementations
, and (c
)
model

transformations
.

Our design
process

starts by
applying

the SystemC
UML profile
presented in Sec.
The
SystemC UML profile
, to
develop

a
high
-
level
UML
model
of the system

from its informal
requirements or
from
its
higher
-
level
description in terms of a platform independent model

(which can be developed by, for example, SysML or MARTE)
.


The modeling acti
vity can be performed at different levels of abstraction. It is possible to
create a pure
functional model
, or to add timing information in a
functional
-
timed model
.
A
transactional model

describes abstract communication by transactions, which are protocol
s
exchanging complex data with associated timing information. It is possible
modeling
the details
of the implementation platform with a
behavioural model

(which is pin and functionally
accurate), by a
Bus Cycle Accurate model

(which is also cycle accurate
at its boundaries), or by a
RTL model

(the model is described as transfer of information between registers). Each model is
an instance of the SystemC UML profile metamodel.

Model
-
to
-
code

transformations
allow automatic mapping of
SystemC UML model
s

into
S
ystemC
executable code, at a fixed abstraction level.

The SystemC UML profile provides in a graphical way all
modeling

elements for SoC design,
and exactly resembles the
modeling

primitives of SystemC.
Indeed, the intention of defining this
profile was to
lift SystemC at the UML level so to use the UML for platform
-
specific modeling
of SoCs.
Through different case studies

(see Sect.
Industrial
application
)
, we performed an
evaluation
of
modeling with our UML based methodology compa
red to coding
.
An immediate
benefit is a

significant reduction in the effort to produce the final code (there is
a big saving in the
number of lines that are
written by hand, especially
redundant lines of code

due to the C++
syntax are avoided),
but
the gr
eatest benefi
ts are
in
terms of

model
documentation,
maintenance
and
reuse.
Furthermore
,
high
-
level SystemC UML
modeling allows more

flexib
i
l
ity

than
coding
.

Indeed, well
-
established abstraction/refinement patterns coming from hardware/system
engineering a
nd till now only used at code level with great difficulty, can be easily managed
(possibly automatically by appropriate model transformation engines) as
model
-
to
-
model
transformation

steps
along the modeling process from a high functional level model down
to a
RTL model. Their application at the UML level, by the use of the SystemC UML profile,
guarantees
(possibly)
automatic and traceable evolution of the system.
Furthermore, proving
correctness of the refinement process and system properties is a

very har
d, and we can say
impo
ssible, activity at code level, whereas, it is feasible at model level

with the aid of

suitable
formal analysis
tools
.

A
utomatic

model
-
to
-
model

transformation
s

are at the base of the
formal analyses flow

that we
propose. The process
starts by automatically mapping a SystemC UML m
odel into an ASM
,
moving from a visual graphical view of the system to a formal view
.
Once the ASM
specification
of the system is generated, several analyses activities

can be performed, i.e.
validation
,
verif
ication
,
and
conformance testing
.

Validation is intended as the process of investigating a model (intended as formal
specification) with respect to its user perceptions, in order to ensure that the specification really
reflects the user needs and statement
s about the application, and to detect faults in the
specification as early as possible with limited effort.
Techniques for validation include
scenarios
generation
,

when the user builds scenarios describing

the behav
ior of a system
by looking at the
obser
vable interactions between the system and its environment in specific situations
;

simulation
,
when the user provides certain input and observe
s

if the output is the expected one or not (i
t is
similar to code
debugging
); model
-
based
testing
, when the specif
ication is used as oracle to
compute test cases for a given critical behavior of the system at the same level of the
specification.
These abstract test cases cannot be executed at code level since they are at a wrong
level of abstraction. Executable test c
ases must be derived from the abstract ones and executed at
code level to guarantee
conformance

between model and code.

In any case, v
alidation should
precede the application of more expensive and accurate methods, like requirements
formal
analysis and ver
ification of properties, which should be applied only when a designer has enough
confidence that the specification captures all informal requirements. Formal verification
has to be
intended as the mathematical proof of system properties, which can be carri
ed on by hand or by
the aid of model checkers (which are usable when the variable ranges are finite) or of theorem
provers (which require strong user skills to drive the proof).

Currently,
system validation is
fully supported

in our framework
, as described

in the next
section,
through simula
tion and scenario
s

construction. Future advanced analyses features
have
been planned, as

explained in Sect.
Future Trends
.

SOC
MODELING

&
VALIDATION

ENVIRONMENT

The
Modeling

&
Validation

environ
ment works as front
-
end for consolidated lower level co
-
design tools, and is intended to assist the designer across the refinement steps in the
modeling

activity, from a high
-
level functional UML model of the system down to the SystemC RTL level.
Figure
11

shows the general architecture of the proposed environment. It consists of two major
parts: a runtime environment (RE) that is the SystemC execution engine, and a development kit
(DK) consisting of a UML2
mod
eler

supporting the UML profile for SystemC and for multi
-
thread C,
translators

for for
ward/
re
verse engineering to/from C/C++/SystemC, and a
Validation

toolset

based on the ASM formal method. The modeler is based on the Enterprise Architect (EA)
U
ML too
l by Sparx Systems. The validation

toolset is built upon the ASMETA toolset [
Asmeta,

20
07
].



Figure
11

Modeling

and Analysis tool

Figure
11

also shows the phases (denoted wit
h a label) the designer undertakes in the overall SoC
modeling

and
validation

process. The
modeling

process starts by
developing a model

written with
the SystemC UML profile going through a sequence of refinement steps from a high
-
level
functional UML mode
l down to a UML model

at RTL level
, as already explained in
the previous
section
. At each abstraction level, by automatic
code generation
, a unique SystemC specification
(for both the structural and behavioural aspects) is obtained from the UML model. The
resulting
code can be executed in the SystemC simulation environment at suitable abstraction levels (from
transactional downto RTL). The code generation flow is complemented by a
reverse engineering

flow to transform SystemC programs into UML models.

The
validation

process starts by applying the
mapping

of the SystemC
-
UML model of the
system (exported from the EA
-
based modeler) into a corresponding ASM model (written in
AsmetaL). This transformation has been defined (once for all) by establishing a set of
semantic
mapping rules between the SystemC UML

profile and the AsmM metamodel
. The
UML2AsmM

transformation is completely
automatic

by means of the ATL engine developed within the
Eclipse Modeling Project as implementation of the OMG QVT [
QVT
,
2007
] standard.

T
wo different levels of model execution for analysis are supported by our environment: (i) the
simulation

based on AsmetaS; (ii) the SystemC simulation and debugging. The first one is more
abstract and aimed at high
-
level
functional validation to investigate a model with respect to the
desired system
behavior

to ensure that the specification really reflects the user needs and
statements about the system, and to detect faults in the specification as early as possible with
li
mited effort. The second one is low
-
level, based on SystemC code, and necessary to deliver
correct system
-
level designs. The joint use of these two simulation modes bring
s

the advantage of
having specification
-
based test oracles to be used to drive the Sys
temC implementation code for
conformance testing (and to test the
UML2AsmM

transformation).

It should be noted that as required skills and expertise the designer (or analyst) has to
familiarize

with the SystemC UML profile (embedded in the EA
-
based modeler
), with very few
commands of the Avalla textual notation to write pertinent ASM validation scenarios, and with
property specification notations like temporal logics.

A brief description of each tool component follows.

The Modeler

It is built upon
the Ente
rprise Architect (EA) tool by SparxSystems
,

but any other tool supporting
UML2 with the standard extension mechanism of UML profiles can be also used and easily
customized.

We decided to rely on tools supporting UML2.
T
he
SystemC UML profile

can be
importe
d into an EA design project for use in the UML
modeling

process. The available
stereotyped
modeling

elements will appear in the
Resource View

page of the
project
browser

of EA and can be dragged and dropped into UML diagrams. The EA tool attaches
automatic
ally all the extensions (tagged values, default values, etc.) provided by the related
profile.
Figure
12

shows a screenshot of EA while attaching a port to a module in a class
diagram. The SystemC data types and predefined channel
s, interfaces, and ports (the SystemC
layer 1) are modelled with the core stereotypes, and are also available in the
Project View

with the name
SystemC_Layer1
.


Figure
12
:

Using the SystemC UML profile in EA

Translators

The Code G
eneration Facility adopts a
full generation

approach
.
SystemC
is

used
as action
language

at
UML
level, so that the source code is fully generated
.


Figure
13

Generate SystemC code from EA


It is possible to generate code from the

whole model, at package level or even for single
diagrams. Starting from the selected element in the EA project view browser (project, package or
class diagram) the code generation analyzes the underlying hierarchy of views generating the
corresponding Sy
stemC code. For further details, see [
Riccobene at al.
, 2006
].
Figure
13

shows a
screenshot of EA while generating SystemC code from a UML
-
SystemC model.

The Reverse Engineering component is made of

three parts: a parser, a data structure and a
XMI writer. We developed a parser for SystemC using the JavaCC tool. The component accepts
SystemC code which is translated into a UML model conforming to the UML

profile
. The
internal data structure of this e
ngine captures t
he main structures of the
SystemC model and their
relations. The XMI writer finally produces a UML model that can be imported in the EA tool.

The reverse engineering facility allows us to import existing models into the
modeling

environment

and to achieve rapidly a high number of design cases. It is also indispensable to
allow round trip engineering, that is the synchronized cooperation with code generation (forward
engineering) to complete the description of a model working on both the UML
model and the
code. It is also useful in practice as a tool to inspect the structure of a source code graphically.
Currently, the reverse facility is limited to the generation of the design
skeleton
7

only, and some
open problems still exist in the layout o
f the resulting graphical UML model, that have been left
for further development.

Mapping from SystemC UML profile to AsmM

A

SystemC UML model provided in input from the EA tool is transformed into a corresponding
ASM model (an instance of the AsmM metamod
el). In order to provide a one
-
to
-
one mapping
(for both the structural and
behavioral

aspects), first we had to express in terms of ASMs the
SystemC discrete (absolute and integer
-
valued) and event
-
based simulation semantics. To this
goal, we
considered

th
e ASM
specification

of the SystemC 2.0 semantics in [
Müller et

al., 2003
]
to define a precise and executable semantics of the SystemC UML profile [
Gargantini et al.
,

2008a
;

Riccobene et al., 200
5c
] and, in particular, of the SystemC scheduler and the
SystemC
process state machines
. We then proceeded to model in ASMs the predefined set of interfaces,
ports and primitive channels (the layer 1 of Syst
emC), and SystemC
-
specific data types. The
resulting SystemC
-
ASM component library is therefore available as target of the
UML2AsmM

transformation process.

Since a complete coverage [
Gargantini et al.
,

2008a
] of the tra
nsformation rationale is beyond
the scope of this
chapter
, we limit to provide
below

an example of application of such mapping
by showing the UML notation, the corresponding SystemC code, and the resulting ASM (in
AsmetaL notation) for a module.





7
The skeleton describes

only the static structure of the system. For OO technologies, this means
generating classes, attributes, relations and operations, but not method bodies.


Figure

14
: A UML module (A), its SystemC implementation (B) and its corresponding ASM (C
)

Validation by
simulation

The AsmetaS simulator [
Gargantini et al.
, 20
07
] interprets ASM models
written in AsmetaL
.
It
can be used in a standalone way to provide basic simulation of the overall system
behavior
. As
key features for model validation, AsmetaS supports
axiom checking

to check whether axioms
expressed over the currently executed ASM model are satisfied or no
t,
consistent updates
checking

for revealing inconsistent updates,
random simulation

i.e. an environment provide
s

(when needed)
random values for

monitored
functions

8
,
interactive simulation


to validate
a

system component separately
(or even the entire
system)
by providing the required input to the
component interactively

during simulation
,

and configurable
logging

facilities to inspect the
machine state. Axiom checking and random simulation allow the user to perform a draft system
validation with minima
l effort
, while interactive simulation,
al
though more accurate, requires

the
user interaction
.

These simulation
modes
are
illustrated

in practice in Sect. 5
.2.1

for

the
Counter

system
.

Scenario
-
based functional validation

The AsmetaV validator is based on
the AsmetaS tool and on the Avalla language

[
Gargantini et
al.
,

2008b
]
. This last provides constructs to express execution scenarios in an algorithmic way as
interaction sequences consisting of
actions

committed by the
user actor

to
s
et

the environment
(i.e. the values of monitored/shared functions), to
check

the machine state, to ask for the
exec
ution of certain transition rules, and to enforce the machine itself to make one
step

(or a
sequence of steps by
step until
) as reaction of t
he actor actions.
An example of scenario
written in Avalla is given in Sect.

5.2.2 for t
he
Counter

case study.





8

Monitored

functions are dynamic functions of the ASM signature which provide input from the externa
l
environment. Monitored functions are also named
read
-
only

function
s

of the ASM program

since they

must not be updated by the ASM itself
.

asm
MyModule

signature
:


dynamic abstract domain M


//controlled functions


controlled myAttr: M
-
>T


contro
lled myPort: M
-
>C

definitions
:


// named transition rules


rule r_myOp(...) = ...


rule r_initM($m in M,..) = ...


class

MyModule:

public

sc modulef // an attribute of type T


T myAttr;


// a port


sc port<C> myPort;


// an operation


void myOp(..)
{…}



//constructor


M(...)
{…}

};

(B)

(C)

(A)

AsmetaV reads a user scen
ario written in Avalla (see
Figure
11
), it builds the scenario as instance
of the Avalla meta
model by means of a parser, it transforms the scenario and the AsmetaL
specification which the scenario refers to, to an executable AsmM model. Then, AsmetaV
invokes the AsmetaS interpreter to simulate the scenario. During simulation the user can pause
the

simulation and watch the current state and value of the update set at every step, through a
watching window. During simulation, AsmetaV captures any check violation and if none occurs
it finishes with a “PASS” verdict. Besides a “PASS”/“FAIL” verdict, dur
ing the scenario running
AsmetaV collects in a final report some information about the coverage of the original model;
this is useful to check which transition rules have been exercised.

THE COUNTER CASE STU
DY

To give an idea on how the UML profile for Sys
temC can be used in practice, we show here part
of the model of a simple
Counter

system consisting of: one module
count
, that represents an
integer counter of stimuli; one module
count_stim
, that provides stimuli to the counter; one
module
display
, that sh
ows simulation results; and one clock object which propagates
activities within the system.

Moreover, as part of the analysis process, we apply to the
Counter

system (relying on its
corresponding ASMs
-
based representation) two forms of validation technique
s: basic simulation
and scenario
-
based validation.

Note that, even if the proposed case study could seem a toy
example, it covers all the essential
communication
aspects
between

process
state machines
and it
is
didactic
to illustrate the
proposed
validatio
n techniques.

Major case studies
from industrial
design projects

have been taken in consideration (see Sect. 6

for a brief description
)
, but cannot
be reported in depth since protected by
confidential information
.



Modeling

The
count_stim

module is show
n in
Figure
15
.

This module contains one thread process
stimgen
, two input ports
dout

and
clock
, and two output ports
load

and
din
. In particular,
clock

is a
behavior

port since it provides events that trigger the
stimgen

thread p
rocess
within the module. The
stimgen

thread state machine is shown in

Figure
16
. It is a realist
example of the
beh
avior

pattern presented in

Figure
8
. The
stimgen

thread drives the
load

and
din

inputs o
f the
count

module. It can initialize the
count_val

of the
count

module by
setting the
load

port to true; the value loaded into the
count

module is the value of
din
. It can
set, instead, the counter to the counting mode putting
load

to false. It also recei
ves back the
value from the counter in the
dout

port, and may restart the counter when it reaches the value
specified by the local
_maxcount

attribute.


Figure
15
: The
count_stim

module



Figure
16
: The
stimgen

and the
count_up

process state machines

The
count

module (see
Figure
17
) has a private attribute
count_val

of type integer that
stores the actual value of the counter, and three input ports: one
clock

behaviour port to rec
eive
stimuli coming from the system’s clock; one boolean input port
load

that, when set to true at the
next rising edge of the clock, loads the data into the counter; one integer input port
din
; and one
integer output port
dout
, which gives out the actual
value of the counter. The
count

functionality is implemented inside the body of the
count_up

method process (see

Figure
16
),
which is sensitive to the positive edges of the clock. If the
load

input is true, the signal value
from p
ort
din

is loaded into the counter. Otherwise, the counter increments its value by 1.

Figure
17
: The
count

module

Finally, the
display

module (see

Figure
18
) prints out any new data from the counter. This

function is computed by its internal method process
display_count

which is activated at any
new value on the input port. The state machine for this process is straightforward.

The top level container is shown by the composite structure diag
ram in
Figure
19
. It represents
the internal structure of the module
top

used to assemble the whole system. This module
contains parts of instances of the inner modules
count
,
count_stim

and
display
, and of
the
clock

and
sc_signal

channels (pred
efined SystemC channels) used to connect the
modules’s parts.



Figure
18
: The
display

module



Figure
19
: The
Top

composite structure


Part of the SystemC code for the
Counter

sy
stem is reported
below. T
he C++ header files
(.h) for the definition of modules, channels and interfaces are automatically generated from the
UML class diagrams. The C++ body files (.cpp) are determined by the process state machines
that implement the
behavior

of SystemC processes
. The header file named
count_stim.h

(see
below on the
left
)
, for example, is generated from the
count_stim

module class in

Figure
15
,
while, the body section
(see
below on the right)
is determined by the process state machine in

Figure
16
, where the C++ notation is put on top of the UML action semantics and the control
structures are directly derived from the stereotyped pseudostates
while
,
if
-
then
, etc., of the
state machine diagram. Moreover, by an anal
ysis of the composite structure diagram it is possible
to discover the internal structure of the module to determine how internal parts are connected to
each other. The constructor body of the enclosing
top

module of the
Counter

system is
therefore derived

by the composite structure diagram in

Figure
19
.


#include ``systemc.h''

class count_stim: public sc_module {


public:


sc_port<sc_signal_inout
_if<
bool> > load;


sc_port<sc_signal_inout_if
<int> > din;


sc_port<sc_signal_in_if<
bool> > clock;


sc_port<sc_signal_in_if
<int> > dout;


void stimgen();


SC_HAS_PROCESS(count_stim);


count_stim(sc_module_name nm,int maxcount):


sc_module(nm), _maxcount(maxcount){


SC_THREAD(stimgen);


dont_initialize();


sensitive << clock.posedge_eve
nt();


}


private:

int _maxcount;

};

#include ``count_stim.h''

void count_stim::stimgen(){


load = true; din = 0;


while(true){


wait();


if(dout == _maxcount
-
1){



load =true;



din = 0; }


else

load = false;


}

}


Validation: simulation and scen
ario
-
based validation

According to the mapping from
SystemC UML
to ASM, the SystemC UML
model
of the
Counter

system
is
provided in input from the EA tool
to the
UML2AsmM

component and
therefore automatically
transformed into a corresponding ASM model
in te
xtual form in the
AsmetaL notation
.
Below we report the

ASM

r_count_up

rule of the
count

module
; it
corresponds to the
count_up

process state machine shown in

Figure
16
.



macro rule r_count_up =



seq




if read(load(self)) then





count_val(self) := readInt(din(self))




else





count_val(self) := count_val(self) + 1




endif




r_writeInt[dout(self), count_val(self)]




r_wait
_next_trigger
[self]



endseq


endlet

S
imulation

We started with the simulation of the entire system. I
n this case, the user executes the system and
observes the output produced by the
display

module and checks that
i
t
is

correct with respect
to the input provided by the
counter_stim

module.


Axiom checking

The user can increase and decrease the verbosity
of the output produced

during
simulation

either by modifying the logging configuration for the simulator or by inserting logging
messages directly in the ASM specifications. However, this activity can be time consuming and
several errors may pass unnoticed
. For this reason, the user should insert appropriate axioms
which will be automatically checked by the simulator. For example the following axiom:

axiom inv_count_val over count_val :





(
forall

$c in Count with count_val($c) !=
undef

implies count_val($
c) >= 0 )

was

added to the
C
ount

module
. I
t states that the value of the internal variable
count_val

is
always greater than or equal to zero.

The following axiom:


axiom inv_max over
dout
: (
forall

$c in Count_stim with



let

($out = readInt(
dout
($c))) in
($
out

!=
undef

implies $out <
maxcount
($c))
endlet
)


was

added
instead
to the
counter_stim

module and states that the value read from the
dout

channel from the counter is always less than
maxcount
.

By running the counter example again, this axiom is falsi
fied, and the simulator prints a trace
like:

<
UpdateSet>



INFO
-

axiom (name inv_max) violated

FATAL


UpdateSet:

value(dOUT)=8

</UpdateSet>

INFO


State:



maxcount(u_count_stim)=8


The right axiom states that the value

read

can be less or equal to
max
co
unt
.



Interactive simulation

T
he user
can

validate
a system component separately
by providing the
input

inter
actively.
The component must be connected with the external environment by means of
monitored variables. F
or example
,
the
counter_stim

module
, the

user

can
slightly
modify the
counter_stim

signature
as follows. First the following monitored variables can be added to the
count_stim

signature



monitored load_cmd: Count_stim_user
-
> Boolean
// the user wants to set the counter


monitored din_value: Co
unt_stim_user
-
> Integer
// the
desired
value


and then the rule
, which
transfers

the information to the counter ports
load

and
din
.








if load_cmd($d) then seq






r_
write[load($d), true]






r_writeInt[din($d), din_value($d)]





endsdeq


By running this example, the simulator will ask the user to provide the value of
load_cmd

and, if
needed, also for
din_value
. The user must type the value directly on the console an
d the simulator
will show the response of the system.


Random simulation

The random simulation is easy to
perform
, since it does not require any user
interaction.
The

simulator execut
es

the ASM specification with a random environment, i.e.
by
providing

ran
dom values
to

assign to
the
monitored
functions
.

During random simulation the
axioms are checked and possible violations are displayed. For example, the fact that the axiom
inv_count_val

is false, can be discovered by random simulation when the
din_value

b
ecomes less
than zero and the counter is set to that negative value. Random simulation is complementary with
user guided simulation: it is cheaper and it can discover faults in correspondence to input the user
forgets, possible because of implicit assumpti
ons he/she assumes.

Scenario validation

To be able to rerun scenarios, to avoid repeating the interactive simulation with the same inputs
over again, t
he user can write scenario in which specifies the input to system and the expected
outputs
. The correctne
ss of the output

is no longer of the user to judge, but it is formally specified
in the scenario. For example, the following scenario

written in Avalla

sets the value to write to
the counter to 10, it checks that the value read from the
dOut

chann
el is 10,

then it lets the counter
increment the value and it checks that the new value read from

the
dOut

channel is 11.


scenario test1

// set the counter to 10


load ./main_user.
asm


set load_cmd(u_count_stim) = true;

set din_value(u_count_stim) = 10;



step unt
il time = 30 and phase = TIMED_NOTIFICATION;

check readInt(dOUT) = 10;


set load_cmd(u_count_stim) = false;


step until time = 50 and phase = TIMED_NOTIFICATION;

check readInt(dOUT) = 11;


INDUSTRIAL
APPLICATION

The design methodology has been tested on se
veral different case studies, some taken from the
SystemC distribution like the Simple Bus design

[
Bocchio

et al.
, 2008a
]
, and some of industrial
interest.


The Simple Bus system was entirely developed in a forward engineeri
ng manner. The code
generator has been tested primarily on this example, and it produced an executable and complete
(i.e
.

including both structural and
behavioral

parts) SystemC code.

On this example we
performed also an evaluation about the benefits of mo
deling with our UML based methodology
compared to coding. Even if our methodology is oriented to the implementation and the modeling
style strictly resembles the structure of the target SystemC language, by analyzing the produced
SystemC code we find out t
hat 652 of the 1018 lines are automatically inferred from the
structural diagrams of the UML model, the remaining 366 lines of code are derived from the
behavioral description in the Process State Machines diagrams or
produced from
actions
introduced manua
lly

in the model
.

Therefore,
we unexpectedly concluded that there is a
significant reduction in the effort to produce the final code and there is also a benefit in
documentation, maintenance and reuse. For instance one benefit compared with SystemC is that

all the header files are completely and consistently generated from the UML structural diagrams.

The reverse engineering flow was tested by modeling
the
On Chip Communication Network
(OCCN) library

[
OCCN
]
.
This library is ma
de of about 14.000 lines of code and implements an
abstract communication pattern for connecting multiple processing elements and storage
elements on a single chip.
We understood that the reverse engineering component is useful in
practice as a tool to ins
pect the structure of a source SystemC code graphically, which is typically
hierarchical with modules containing sub
-
modules and so on. Starting from a bunch of source
code header files, it is therefore possible to obtain immediately a graphical representa
tion of the
most important design changes introduced at code level including
structure, relations, variables,
functions, etc.

In [
Bocchio et al.
, 2005a
], an application example related to an 802.11.a physical layer
trans
mitter and receiver system described at instruction level is presented. The hardware platform
is composed of a VLIW processor developed in STM, called LX, with a dedicated hardware
coprocessor that implements an FFT (Fast Fourier Transform) operation
.

We

t
ested also advantages and indispensability of a round trip engineering
--

based on a
synchronized cooperation between code generation (forward engineering) and reverse
engineering
--

in order to have a complete description of a system design on both the UM
L
abstract level and the code level. Finally, the adoption of formal analysis techniques at model
level helped to
discover errors or inconsistencies

early in the design process before producing a
more detailed implementation in SystemC code.

FUTURE TRENDS

Our

model
-
driven
methodology for the
design
and analysis
of
embedded systems
can be further
improved
.
As future aims,

we want to
provide

model
-
based testing, conformance testing and
property verificat
ion for the SystemC UML models.


By using the ATGT tool
[
Gargantini et al.
, 2003
] that automatically generates test cases from
the specification by exploiting the counter example generation of

the SPIN [
Holzmann, 1997
]
model checker, it is po
ssible to build functional tests on the same level of abstraction as the
model. These test cases are known as the
abstract test suite
.

We also plan to integrate AsmetaV
with the ATGT tool in order to be able to automatically generate some scenarios by usin
g ATGT
and ask for a certain type of coverage (rule coverage, fault detection, etc.). Test cases generated
by ATGT and the validation scenarios can be transformed in concrete SystemC test cases to test
the conformance of the implementations with respect to

their specification.

This requires the
implementation of
a SystemC code
instrumenter

which should
map the abstract test cases to
concrete test cases suitable for execution. Selected behavioural aspects of the system can be
studied, therefore, by
conforman
ce testing
, i.e. by instrumenting the SystemC implementation
code from the model
.

W
e plan to support system properties formal verification by model checking techniques.
Every
model
-
checking tool comes with its own
modeling

language. By model transformation
s,
appropriate links can be provided from AsmetaL to model checkers like the well
-
known
SPIN/Promela, and therefore encoding ASM models into Promela communicating automata. The
user has therefore to specify only the properties (linear temporal logic (LTL)
formulas, in the
case of SPIN) that the final system is expected to satisfy. The model checker then outputs yes if
the given ASM model satisfies the given properties, or generates a counterexample otherwise. By
studying the counterexample, you can pinpoint

the source of the error, correct the model, and try
again. The idea is that by ensuring that the model satisfies enough system properties, we increase
our confidence in the correctness of the model.

Beyond code generation, the MDA
-
style separation of mode
ls demands automatic model
transformations as support to
evolution activities

[
Mens et

al., 2005
] in general like
refinement/abstraction, model refactoring, model inconsistency management, etc. Refinement, in
particular, i
s a key issue in the model
-
driven engineering approach. Compared with the
refinement techniques available for formal methods like Z, B, and ASMs [
Börger & Stärk, 2003
],
few work has been carried out for
visual

model
l
ing

la
nguages like UML. At the time of writing,
very few proposals exist in literature. Some proposals that we are considering in our process can
be found in [
Catalysis
;

Pons & Kutsche
, 2004
;

Pons & Garcia, 2006
;

P
ons & Kutsche
, 2003
;

Paige et

al.,

2005
]. The general idea is to collect and reuse precise abstraction/refinement
transf
ormation patterns, coming from industry best practices. Once the transformation patterns
have been proved correct and complete, they may be used during the
modeling

activity for
guiding a refinement process or for pointing out missing elements in a
particu
lar

refinement
schema. By applying the model transformations defined for a given pattern, a UML system
design may automatically and correctly evolve to an abstract/refined model reflecting the
abstraction/refinement rules defined for the applied pattern.

T
o this purpose, in the future we aim at identifying characteristics of reusable transformations
and ways of achieving reuse by collecting in a library precise abstraction/refinement
transformation patterns according to the levels of abstraction: functional
, transactional,
behavioral
, BCA, and RTL. In particular, we are focusing on the
transactional
-
level modeling

to
model the communication aspects at a certain number of TLM sub
-
levels according to the
OSCI
TLM 1.0 library

[
OpenSystemCInitiativ
e, 2008
]. We believe the use of fine
-
grained
transformations that are being composed (chaining) would be beneficial, both increasing the
productivity and the quality of the developed systems.

CONCLUSION

This work is part o
f our ongoing effort to enact
design flows

that start with system descriptions
using UML
-
notations and produce C/C++/SystemC implementations of the SW and HW
components as well as their communication interfaces, and that are complemented by
formal
analysis

flows

for system validation and verification.

In this paper, we proposed a model
-
driven system
-
level design and analysis methodology by
the use of the SystemC UML profile (for the
modeling

part) and the ASM formal method and its
related ASMETA toolset (fo
r the analysis part). We have been testing our methodology on case
studies taken from the standard SystemC distribution and on some of industrial interest.

Thanks to the ease in raising the abstraction level using the UML and ASMs,
and considering
the res
ults obtained by applying our methodology to case studies,
we believe
that
our approach
scales effectively to industrial systems
.


REFERENCES

[
Arlow & Neustadt, 2002
]
Arlow, J.
&

Neustadt, I. (2002).
UML and the Unified Process
. Addison
Wesley.

[
Asmeta,

20
07
]

The ASMETA toolset.

(2007).

http://asmeta.sf.net/

[
Beierle et

al., 1995
]

Beierle, C., Börger, E., Durdanovic, I., Glässer, U.,
&

Riccobene, E. (1995).
Refining
abstract machine specifications of the steam boiler control to well documented executable c
ode. In Abrial,
J.
-
R., Börger, E., and Langmaack, H., editors,
Formal Methods for Industrial Applications
, volume 1165
of
Lecture Notes in Computer Science
, pages 52

78. Springer.

[
Bezivin, 2005
]

B
ezivin, J. (2005)

On the unification power of models
. Softw
are

and System Modeling
(SoSym), 4(2):171

188.

[
Bocchio et al.
, 2005a
]

Bocchio, S., Riccobene, E., Rosti, A., Scandurra, P. (2005) A SoC design

flow based on UML 2.0 and SystemC.
In
Proc. of the International DAC Workshop UML
-

SoC'05
. IEEE
press
.

[
Bocchio

et al.
, 2008a
]

Bocchio, S., Riccobene, E., Rosti, A., Scandurra, P. (2008).
An Enhanced
SystemC UML Profile for Modeling at Transaction
-
Level. In Villar, E., editor,
Embedded Systems
Specification and Design Languages
, pages 211
-
226. Springer
.

[
Börger, 20
03
]
Börger, E. (2003). The ASM refinement method.
Formal Asp.
Comput
, 15(2
-
3):237

257.

[
Börger et

al., 2000
]

Börger, E., Riccobene, E.,
&

Schmid, J. (2000b).
Capturing requirements by Abstract
State M
achines: The light control case study.
J.UCS: Journal of

Universal Computer Science
, 6(7):597

625.

[
Börger & Stärk, 2003
]

Börger, E.
&

Stärk, R. (2003).
Abstract State Machines: A Method for High
-
Level
System Design and Analysis
.
Springer Verlag.

[
Bruschi et

al., 2005
]
Bruschi, F., Ferrandi, F.,
&

Sciuto, D. (2
005).
A framework for the functional
verification of systemc models.
Int. J. Parallel Program.
, 33(6):667

695.

[
Bruschi & Sciuto, 2002
]
Bruschi, F. and Sciuto, D. (2002).
SystemC based Design Flow starting from
UML Model.
In
Proc. of European SystemC Users

Group Meeting
.

[
Carioni et al.
, 2008
]
Carioni, A., Gargantini, A., Riccobene, E., Scandurra, P. (2008).
A Model
-
driven
Technique for Embedded System Validation. In
FDL 08: Proceedings of Forum on Specification and
Design Languages
,

pp. 191
-
196
.

IEEE press
.

[Catalysis
]
Catalysis. The Catalys
is process:
www.catalysis.org

[
Chen et al, 2003
]

Ch
en,
R.,
Sgroi,
M.,
Martin,
G.,
Lavagno,
L.,
Sangiovanni
-
Vincentelli,
A.L.,
Rabaey,

J.
(2003).

Embedded System Design Using UML an
d Platforms
. In
System Spe
cification and Design
Languages

(Eugenio Villar and Jean Mermet,
eds.), CHDL Series, Kluwer
.



[
do

Nascimento et

al., 2007
]
do

Nascimento, F. A.

M., Oliveira, M. F.

S.,
&

Wagner, F.

R. (2007).
ModES:
ES

Design Methodology and Tool
s based on MDE. In
Fourth International workshop on Model
-
based Methodologies for Pervasive and Embedded Software (MOMPES’07)
. IEEE Press.

[Edwards at at., 1997] Edwards, S., Lavagno, L., Lee, E., Sangiovanni
-
Vincentelli, A. (1997). Design of
Embedded Syst
ems: Formal Models, Validation, and Synthesis.
Proc.
IEEE,
vo.
85,
n.
3, 1997,
pp
. 366

390
.


[
Edwards & Green, 2003
]
Edwards, M.
&

Green, P. (2003). UML for hardware and software object
modeling.
UML for real design of embedded real
-
time systems
, pp.

127

1
47.

[
Gargantini et al.
, 2003
]
Gargantini, A., Riccobene, E., Rinzivillo, S. (2003).
Using Spin to Generate Tests
from ASM Specifications. In
Proc. of the 10th Int. Workshop on Abstract State Machines
. LNCS 2589, p.
263
-
277. Springer
.

[
Gargantini et al.
, 20
07
]
Gargantini, A., Riccobene, E., Scandurra, P. (2007).
A metamodel
-
based

simulator for ASMs. In
Proc. of the 14th Int.
ASM Workshop
.

[
Gargantini et al.
,

2008a
]

Gargantini,
A.,
Riccobene,
E.,
Scandurra
, P. (2008)
.
A Language and a
Simulation Engine for Ab
stract State Machines based on Metamodelling. In
Journal of Universal
Computer Science
, Vol. 14, No. 12, p.1949
-
1983
.

Springer.

[
Gargantini et al.
,

2008b
]
Gargantini,
A.,
Riccobene,
E.,
Scandurra
, P. (2008)
.
A scenario
-
based validation
language for ASMs. I
n
Proc. of First International Conference on Abstract State Machines, B and Z (ABZ
2008)
.
LNCS 5238, pp. 71

84, Springer.

[Gröetker et

al.
,
2002
]
Gröetker, T., Liao, S., Martin, G.,
&

Swan, S. (2002).
System Design with SystemC
.
Kluwer Academic Publisher.

[
Habibi & Tahar, 2006
]

Habibi, A.
&

Tahar, S. (2006). Design and verification of systemc transaction
-
level models.
IEEE Transactions on VLSI Systems
, 14:57

68.

[
Haroud et

al., 2004
]
Haroud, M., Blazevic, L.
, &

Biere, A. (2004). HW

accelerated ultra wide ba
nd mac
protocol using sdl and systemc. In
IEEE Radio and Wireless Conference
, pp.

525

528.

[
Holzmann, 1997
]

Holzmann, G.

J. (1997). The Model Checker SPIN.
IEEE Trans.
Softw. Eng.
,
23(5):279

295.

[
Kogel et

al., 2004
]
Kogel, T., Doerper, M., Kempf, T., Wief
erink, A., Leupers, R., Ascheid, G.
, &

Meyr,
H. (2004).
Virtual architecture mapping: A systemc based methodology for architectural exploration of
system
-
on
-
chip designs. In Pimentel, A.

D. and Vassiliadis, S., editors,
Computer Systems: Architectures,
Mod
eling, and Simulation, Third and Fourth International Workshops, SAMOS
, volume 3133 of
Lecture
Notes in Computer Science
,
pp.

138

148.

[
Kruchten, 1999]

Kruchten, P. (1999).
The Rational Unified Process
.
Addison Wesley.

[
Lavagno et

al., 2003
]
Lavagno, L., M
artin, G., Vincentelli, A.

S., Rabaey, J., Chen, R.
, &

Sgroi, M.
(2003).
UML and Platform based Design.
UML for Real Design of Embedded Real
-
Time Systems
.

[MARTE, 2008]
. OMG, UML Profile for Modeling and Analysis of Real
-
time and Embedded Systems,
ptc/08
-
0
6
-
08.

[Martin, 1999] Martin, C. (1999). UML and VCC. White paper, Cadence Design Systems, Inc.

[
Mathaikutty et

al., 2007
]
Mathaikutty, D., Ahuja, S., Dingankar, A.
, &

Shukla, S. (2007). Model
-
driven
test generation for system level validation.
High Level D
esign Validation and Test Workshop, 2007.
HLVDT 2007. IEEE
, pp.

83

90.

[Mellor et al., 2003] Mellor, S., Scott, K., Uhl, A., Weise, D. (2004).
MDA Distilled, Principles of Model
Driven Architecture
. Addison
-
Wesley Professional.

[
Mens et

al., 2005
]
Mens, T.
, Wermelinger, M., Ducasse, S., Demeyer, S., Hirschfeld, R.
, &

Jazayeri, M.
(2005).
Challenges in Software Evolution. In
Proc. of the International Workshop on Software Evolution
.
IEEE.

[Moore et al., 2002] Moore, T., Vanderperren, Y., Sonck, G., van Ooste
nde, P., Pauwels, M., & Dehaene,
W. (2002).
A Design Methodology for the Development of a Complex System
-
On
-
Chip using UML and
Executable System Models. In
Forum on Specification and Design Languages, ECSL
.

[
MSC, 1999
]

MSC (1999). Message Sequence Charts (
MSC).

[
Müller et

al., 2003
]
Müller, W., Ruf, J.
, &

Rosenstiel, W. (2003).
SystemC Methodologies and
Applications
. Kluwer Academic Publishers.

[
Nguyen et

al., 2005
]
Nguyen, K., Sun, Z., Thiagarajan, P.
, &

Wong, W. (2005). Model
-
Driven SoC
Design: The UML
-
Sy
stemC Bridge.
UML for SOC Design
.

[OCCN
]
OCCN. OCCN Project: http://occn.sourceforge.net/

[OpenSystemCInitiativ
e, 2008
]
The Open SystemC Init
iative

(2008)
. http://www.systemc.org
.

[
Paige et

al., 2005]

Paige, R.

F., Kolovos, D.

S.
, &

Polack, F.

A.
. (2005).

Refinement via Consistency
Checking in MDA.

Electr. Notes Theor. Comput. Sci. 137(2): 151
-
161

[
Patel & Shukla, 2007
]

Patel, H.

D.
&

Shukla, S.

K. (2007). Model
-
driven validation of systemc designs.
In
DAC ’07: Proc. of the 44th annual conference on Design

automation
, pp.

29

34, New York, NY, USA.
ACM.

[
Pons & Garcia, 2006
]
Pons, C.
&

Garcia, D. (2006).
An OCL
-
Based Technique for Specifying and
Verifying Refinement
-
Oriented Transformations in MDE.
In
MoDELS
, pp.

646

660.

[
Pons & Kutsche
, 2004
]
Pons, C. and
Kutsche, R.
-
D.

(2004).
Traceability Across Refinement Steps in
UML Modeling.
In
Proc. of WiSME@UML 2004
.

[
P
ons & Kutsche
, 2003
]
Pons, C.
&

Kutsche, R.
-
D.
(2003).
Using UML
-
B and U2B for formal refinement
of digital components. In
Proc. of Forum on specific
ation and design languages, Frankfurt, 2003
.

[QVT
,
2007
]
QVT (2007). OMG, MOF Query/Views/Transformations, ptc/07
-
07
-
07.

[
Riccobene et al.,

200
5a
]
Riccobene, E., Scandurra, P., Rosti, A., Bocchio, S.
(
2005
)
.
A SoC Design
Methodology Based on a UML 2.0 Prof
ile for SystemC. In
Proc. of Design Automation and Test in
Europe

(DATE 05),

IEEE Computer Society
.

[
Riccobene
et al.
, 2005b]
Riccobene, E., Scandurra, P., Rosti, A., Bocchio, S. (2005).
A UML 2.0 Profile
for SystemC. STMicroelectronics Technical Report, A
ST
-
AGR
-
2005
-
3.

[Riccobene et al., 200
5c
] Riccobene, E., Scandurra, P., Rosti, A., and Bocchio, S.
(
2005
)
.
A UML 2.0
profile for SystemC: toward high
-
level SoC design. In
EMSOFT '05: Proceedings of the 5th ACM
international conference on Embedded

S
oftware

(
pp. 138
-
141).
ACM Press.

[
Riccobene at al.
, 2006
]


Riccobene, E., Scandurra, P., Rosti, A., Bocchio, S.
(2006)
.
A Model
-
driven
Design Environment for Embedded Systems. In
DAC'06: Proc. of the 43rd annual conference on Design
automation

(915
-
918).
ACM Press
.

[
Riccobene et al.
, 2007a
]
Riccobene, E., Scandurra, P., Rosti, A., Bocchio, S. (2007).
A Model
-
driven co
-
design flow for Embedded Systems. In (
Sorin A. Huss
ed.)
Advances in Design and Speci
fi
cation
Languages for Embedded

Systems
. Springer
.

[
Riccobene et

al.
, 2007b
]

Riccobene, E., Scandurra, P., Rosti, A., Bocchio, S.
(
2007
)
.
Designing a
U
nified
P
rocess for
E
mbedded
S
ystems. In
MOMPES ’07
:
Proceedings of Fourth international workshop on
model
-
based methodologies for pervasive and embedded software
.
IEEE P
ress
.


[Rioux et al., 2005] Rioux, L., Saunier, T., Gerard, S., Radermacher, A., de
Simone
, R., Gautier, T. ,
Sorel, Y. , & Andre, C.
(2005).
MARTE: A new Profile RFP for the Modeling and Analysis of Real
-
time
ES. In
UML for SoC Design workshop at DAC’05
.

[
Selic, 2003
]
Selic, B. (
2003).
A Generic Framework for Modeling Resources with UML. In
Proceedings
of the 16th Symposium on Integrated Circuits and Systems Design (SBCCI’03)
.

33:64

69, IEEE Computer
Society.

[Sgroi et al., 2000]
Sgroi, M., Lavagno, L. San
giovanni
-
Vincentelli, A.

(200
0
).

Formal Models for
Embedded System Design
.

IEEE Design & Test Magazine. Special Issue on System Design
. IEEE press
.

[SysML
, 2007
]
OMG, SysML, Version 1.0, formal/2007
-
09
-
01.
http://ww
w.omgsysml.org/
.

[SystemC, 2006] SystemC Language Reference Manual. IEEE Std 1666
-
2005, 31 March 2006.

[UML
, 2005
] Unified Modeling Language, Version 2.0, 2005. http://www.uml.org/

[
USoC, 2005
]
USoC, 2005
.
Fujitsu Limited, IBM, NEC. A UML Extension for So
C. Draft RFC to OMG,
2005
-
01
-
01.

[
Vardi, 2007
]
Vardi, M.

Y.

(2007). Formal techniques for SystemC
verification; position paper. In
DAC
’07: Proc. of the 43rd annual conference on Design automation
,
(pp.

188

192
)
. IEEE.

[Zhang et at., 2008] Zhang, T., Jouau
lt, F., Bézivin, J., Zhao, J. (2008). A MDE Based Approach for
Bridging Formal Models. In Proc. 2nd IFIP/IEEE
International Symposium on Theoretical Aspects of
Software Engineering
. IEEE Computer Society.

[Zhu et al., 2004]

Q. Zhu, R. Oishi, T. Hasegawa, T
. Nakata (2004).
System
-
on
-
Chip Validation using
UML and CWL. In
Proc. of CODES
.