Processes, interfaces and

workablejeansΚινητά – Ασύρματες Τεχνολογίες

21 Νοε 2013 (πριν από 3 χρόνια και 10 μήνες)

54 εμφανίσεις

Processes, interfaces and
platforms.

Embedded software modeling in
Metropolis.

Luciano Lavagno

Politecnico di Torino

EMSOFT 2002, CASES 2002

Grenoble, France

Metropolis Project: main participants


Cadence Berkeley Labs
(USA):
methodologies
,
modeling
,
formal
methods


UC Berkeley

(USA):
methodologies
,
modeling
,
formal methods


Politecnico di Torino

(Italy):
modeling
,
formal methods


Universitat Politecnica de Catalunya

(Spain):
modeling
,
formal methods


Philips Research

(Netherlands):
methodologies

(multi
-
media)


Nokia

(USA, Finland):
methodologies

(wireless communication)


BWRC

(USA):
methodologies

(wireless communication)


BMW

(USA):
methodologies

(fault
-
tolerant automotive controls)


Intel

(USA):
methodologies

(microprocessors)


STMicroelectronics

(France, Italy):
methodologies

(wireless platforms)

etropolis

Metropolis Framework

Infrastructure



Metropolis meta
-
model


-

language


-

modeling mechanisms



Meta
-
model compiler

Meta
-
model Library



Models of computation


Meta
-
model Library



Architecture platforms


Tools



Simulator

QSS

PIG

STARS

SPIN



Application
-
specific methodologies

Multi
-
media, wireless communication, mechanical controls, processors

Design Methodology

Balance between reusability and optimality



orthogonalize design concerns as much as possible



optimize the final implementation as much as necessary

Refine

Optimize

Implementation

of System

Functional

& Non
-
func.

Constraints

Function

Component

Library

MPEG

decode

PES

parser

VSRC

I$

D$

CPU

UART

RTOS

Architecture

Component

Library

demux

PES

parser

MPEG

decode

HSRC

VSRC

Image

Juggler

MPEG

decode

Control

System

Function

Model

System

Architecture

Model

BCU

HW

assist

MEM

I$

D$

CPU

UART

INT

RTOS

API

driver

Map

Metropolis meta
-
model



Computation


:
f : X


Z






Communication

:
state evaluation and manipulation






Coordination


:
constraints over concurrent actions



-

process
: generates a sequence of
events

-

medium
: defines
states

and
methods


-

quantity

: annotation of each event (time, energy, memory, …)


-


logic


: relates events and quantities, defines axioms on quantities


-

quantity
-
manager

: algorithm to realize annotation subject to


relational constraints

Concurrent specification with a formal execution semantics:

Key difference with respect to

Ptolemy, UML, SystemC, …!!!

Concurrent specification with a
formal execution semantics
:

Meta
-
model : function netlist

process P{


port reader X;


port writer Y;


thread(){


while(true){


...


z = f(X.read());


Y.write(z);


}}}

medium M
implements reader, writer
{


int storage;


int n, space;


void write(int z){


await(space>0; writer ; writer)


n=1; space=0; storage=z;


}


word read(){ ... }

}

interface reader extends Port{


update int read();


eval int n();

}

interface writer extends Port{


update void write(int i);


eval int space();

}

M

P1

X

Y

P2

X

Y

Env1

Env2

MyFncNetlist

R

I

F

A

M

Meta
-
model: execution semantics



Processes take
actions
.


statements and some expressions, e.g.

y = z+port.f(), port.f(), i < 10, …




An
execution

of a given netlist is a sequence of vectors of
events
.


event
: the beginning of an action, e.g.
B(
port.f()
)
,


the end of an action, e.g.
E(
port.f()
)
,


null (no
-
op)
N


the
i
-
th component of a vector is an event of the
i
-
th process


synchronous trace
-
based semantics


time and other quantities elapse and actions are executed in states


no assumption on atomicity whatsoever (unless explicitly modeled)



An execution is
feasible

if


it satisfies all coordination constraints, and


it is accepted by all action automata defining meta
-
model semantics

Meta
-
model: architecture components

An architecture component specifies
services
, i.e.



what it
can

do



how much it
costs

:

interfaces

:
quantities, annotation, logic of constraints

medium Bus
implements BusMasterService


{


port BusArbiterService Arb;


port MemService Mem; …


update void busRead(String dest, int size) {


if(dest== … ) Mem.memRead(size);


[[Arb.request(
B(
busRead
)
);


GTime.request(
B(
memRead
)
,


BUSCLKCYCLE +


GTime.annotation(
B(
busRead
)
));


]]


}




scheduler BusArbiter extends Quantity


implements BusArbiterService

{


update void request(event e){ … }


update void resolve() { //schedule }


}

interface BusMasterService extends Port {


update void busRead(String dest, int size);


update void busWrite(String dest, int size);

}

interface BusArbiterService extends Port {


update void request(event e);


update void resolve();

}

BusArbiter

Bus

R

I

F

A

M

Meta
-
model: architecture netlist

Bus

Arbiter

Bus

Mem

Cpu

OsSched

MyArchNetlist







Master

CPU +
OS

Slave

Mem

Arbiter

Architecture netlist specifies configurations of architecture components.

Each constructor


-

instantiates arch. components,


-

connects them,

-

takes as input
mapping processes
.

R

I

F

A

M

Meta
-
model: mapping processes

process P{


port reader X;


port writer Y;


thread(){


while(true){


...


z = f(X.read());


Y.write(z);


}}


int f (int n) {


int i;


for (i = 0; i < n; i++) {




}}

process MapP{


port CpuService Cpu;


void readCpu(){


Cpu.exec(2); Cpu.cpuRead();


}


void mapf(){Cpu.exec(12*n); }










}

thread(){


while(true){


await {


(true; ; ;) readCpu();


(true; ; ;) mapf();


(true; ; ;) readWrite();

}}}

B(
P, X.read
)

<=>
B(
MapP, readCpu
)
;
E(
P, X.read
)
<=>
E(
MapP, readCpu
)
;

B(
P, f
)

<=>
B(
MapP, mapf
)
;
E(
P, f
)
<=>
E(
MapP, mapf
)
;



Function process

Mapping process

R

I

F

A

M

Meta
-
model: mapping netlist

Bus

Arbiter

Bus

Mem

Cpu

OsSched

MyArchNetlist

mP1

mP2

mP1

mP2

MyFncNetlist

M

P1

P2

Env1

Env2

B(
P1, M.write
)

<=>
B(
mP1, mP1.writeCpu
)
;
E(
P1, M.write
)
<=>
E(
mP1, mP1.writeCpu
)
;

B(
P1, P1.f
)

<=>
B(
mP1, mP1.mapf
)
;
E(
P1, P1.f
)
<=>
E(
mP1, mP1.mapf
)
;

B(
P2, M.read
)

<=>
B(
P2, mP2.readCpu
)
;
E(
P2, M.read
)
<=>
E(
mP2, mP2.readCpu
)
;

B(
P2, P2.f
)

<=>
B(
mP2, mP2.mapf
)
;
E(
P2, P2.f
)
<=>
E(
mP2, mP2.mapf
)
;

MyMapNetlist

Bus

Arbiter

Bus

Mem

Cpu

OsSched

MyArchNetlist







R

I

F

A

M

Meta
-
model: platforms

interface MyService extends Port { int myService(int d); }

medium AbsM implements MyService{


int myService(int d) { … }

}

B(
thisthread, AbsM.myService
)

<=>
B(
P1, M.read
)
;

E(
thisthread, AbsM.myService
)

<=>
E(
P2, M.write
)
;

refine(AbsM, MyMapNetlist);

MyArchNetlist

MyFncNetlist

M

P1

P2

B(
P1, M.write
)

<=>
B(
mP1, mP1.writeCpu
)
;

B(
P1, P1.f
)

<=>
B(
mP1, mP1.mapf
)
;
E(
P1, P1.f
)
<=>
E(
mP1, )

B(
P2, M.read
)

<=>
B(
P2, mP2.readCpu
)
;

E(
P2, P2.f
)
<=>
E(
mP2, mP2.mapf
)
;

MyMapNetlist1

MyArchNetlist

MyFncNetlist

M

P1

P2

B(
P1, M.write
)

<=>
B(
mP1, mP1.writeCpu
)
;

B(
P1, P1.f
)

<=>
B(
mP1, mP1.mapf
)
;
E(
P1, P1.f
)
<=>
E(
mP1, )

B(
P2, M.read
)

<=>
B(
P2, mP2.readCpu
)
;

E(
P2, P2.f
)
<=>
E(
mP2, mP2.mapf
)
;

MyMapNetlist1

B(

)

<=>
B(

)
;

E(

)

<=>
E(

)
;

refine(AbsM, MyMapNetlist1)

MyArchNetlist

MyFncNetlis
t

M

P1

P2

B(
P1, M.write
)

<=>
B(
mP1, mP1.writeCpu
)
;

B(
P1, P1.f
)

<=>
B(
mP1, mP1.mapf
)
;
E(
P1, P1.f
)
<=>
E(
mP1, )

B(
P2, M.read
)

<=>
B(
P2, mP2.readCpu
)
;

E(
P2, P2.f
)
<=>
E(
mP2, mP2.mapf
)
;

MyMapNetlist2

M

B(

)

<=>
B(

)
;

E(

)

<=>
E(

)
;

refine(AbsM, MyMapNetlist2)

A set of mapping netlists, together with constraints on
event mappings, constitutes a
platform

(constrained set of
possible implementations) with a given interface.

R

I

F

A

M

R

I

F

A

M

Meta
-
model: recursive platforms

S

N

N'

B(
Q2, S.cdx
)

<=>
B(
Q2, mQ2.excCpu
)
;
E(
Q2, M.cdx
)
<=>
E(
mQ2, mQ2.excCpu
)
;

B(
Q2, Q2.f
)

<=>
B(
mQ2, mQ2.mapf
)
;
E(
Q2, P2.f
)
<=>
E(
mQ2, mQ2.mapf
)
;

MyArchNetlist

MyFncNetlist

M

P1

P2

B(
P1, M.write
)

<=>
B(
mP1, mP1.writeCpu
)
;

B(
P1, P1.f
)

<=>
B(
mP1, mP1.mapf
)
;
E(
P1, P1.f
)
<=>
E(
mP1, )

B(
P2, M.read
)

<=>
B(
P2, mP2.readCpu
)
;

E(
P2, P2.f
)
<=>
E(
mP2, mP2.mapf
)
;

RTOSNetlist

MyArchNetl
ist

MyFncNe
tlist

M

P1

P2


B(
P2, M.read
)

<=>
B(
P2,
mP2.readCpu
)
;

E(
P2, P2.f
)
<=>
E(
mP2, mP2.mapf
)
;

M

RTOS

Meta
-
model: summary



Concurrent specification with a formal execution semantics



Feasible executions of a netlist: sequences of event vectors



Quantities can be defined and annotated with events, e.g.

time, energy, memory, ...



Concurrent events can be coordinated in terms of quantities:


-

logic can be used to define the coordination,


-

algorithms can be used to implement the coordination.



The mechanism of event coordination wrt quantities plays a key role:


-

architecture modeling as service with cost,


-

mapping coordinates executions of functional and architecture netlists,


-

refinement with event coordination provides a platform.

Metropolis Framework

Infrastructure



Metropolis meta
-
model


-

language


-

modeling mechanisms



Meta
-
model compiler

Meta
-
model Library



Models of computation


Meta
-
model Library



Architecture platforms


Tools



Simulator

QSS

PIG

STARS

SPIN



Application
-
specific methodologies

Multi
-
media, wireless communication, mechanical controls, processors

Metropolis infrastructure architecture

Meta model

compiler

Verification
tool

Verification
tool

Front end

Meta model language

Simulator
tool

...

Back end
1

Abstract syntax trees

Back end
2

Back end
N

Back end
3

Synthesis
tool

Language
1

Language
2

Language
n

Translator
1

Translator
2

Translator
n

...

Metropolis infrastructure status

Meta model

compiler

Spin

Prometheus

Front end

Meta model language

SystemC

Simulator

...

Back end
1

Abstract syntax trees

Back end
2

Back end
N

Back end
3

Symbolic
HW

scheduler

Simulink

Esterel/Lustre

UML

Translator
1

Translator
2

Translator
n

...

Deriving other formal models from the meta
-
model

Example:

Petri nets

await(
X.n()>=2
; X.reader; X.reader)


for(i=0; i<2; i++) x[i]=X.read();

reader_unlock

reader_lock

X.n()

2

2

i=0;

i<2?

x[i]=X.read();

i++;

end of await


Formal methods on Petri nets:



analyze the schedulability



analyze upper bounds of storage sizes



synthesize schedules

Restrictions:


condition

inside await is conjunctive


specific medium type (FIFO) is used

Example: quasi
-
static scheduling

1
Specify a network of processes



2
Translate to the Petri net model



3
Find a “schedule” on the Petri net


4
Translate the schedule to a set of tasks
(processes)

Metropolis Summary



Metropolis meta
-
model:


-

concurrent specification for functions, architecture, and mappings


-

libraries of models of computation, libraries of platforms




Metropolis design environment:


-

meta
-
model compiler to provide an API to browse designs,


-

backend tools to analyze designs and produce appropriate models,


-

easy to incorporate simulation, verification, and synthesis tools

Backup slides: Execution semantics


A sequence of vectors of events is a legal behavior
if it


satisfies all constraints


is accepted by all
action automata


one for each action of each process

B

y=x+1

Action automata


y=x+1;

B

y=x+1

B

x+1

E

x+1

E

y=x+1

y:=V
x+1

B

x+1

E

x+1

E

y=x+1

y:=any

c

c

c

c

* =

write
y

*

*

*

B

x+1

E

x+1

V
x+1
:=x+1

E

x+1

V
x+1
:=any

c

c

write

x

y=x+1


x+1



V
x+1

y

x


0

0

0

N

Action automata


y=x+1;

y=x+1


x+1



V
x+1

y

x


B

y=x+1

B

x+1

E

x+1

E

y=x+1

y:=V
x+1

B

x+1

E

x+1

E

y=x+1

y:=any

c

c

c

c

* =

write
y

*

*

*

B

x+1

E

x+1

V
x+1
:=x+1

E

x+1

V
x+1
:=any

c

c

write

x

0

0

0

B

y=x+1

B

x+1

N

N

N

E

x+1

1

0

0

Action automata


y=x+1;

y=x+1


x+1



V
x+1

y

x


B

y=x+1

B

x+1

E

x+1

E

y=x+1

y:=V
x+1

B

x+1

E

x+1

E

y=x+1

y:=any

c

c

c

c

* =

write
y

*

*

*

B

x+1

E

x+1

V
x+1
:=x+1

E

x+1

V
x+1
:=any

c

c

write

x

0

0

0

B

y=x+1

B

x+1

N

N

N

Action automata


y=x+1;

y=x+1


x+1



V
x+1

y

x


B

y=x+1

B

x+1

E

x+1

E

y=x+1

y:=V
x+1

B

x+1

E

x+1

E

y=x+1

y:=any

c

c

c

c

* =

write
y

*

*

*

B

x+1

E

x+1

V
x+1
:=x+1

E

x+1

V
x+1
:=any

c

c

write

x

0

0

0

B

y=x+1

B

x+1

E

x+1

N

N

N

E

y=x+1

1

0

0

1

1

0

B

y=x+1

Action automata


y=x+1;

y=x+1


x+1



V
x+1

y

x


B

y=x+1

B

x+1

E

x+1

E

y=x+1

y:=V
x+1

B

x+1

E

x+1

E

y=x+1

y:=any

c

c

c

c

* =
write
y

*

*

*

B

x+1

E

x+1

V
x+1
:=x+1

E

x+1

V
x+1
:=any

c

c

write

x

0

0

0

N

Action automata


y=x+1;

y=x+1


x+1



V
x+1

y

x


B

y=x+1

B

x+1

E

x+1

E

y=x+1

y:=V
x+1

B

x+1

E

x+1

E

y=x+1

y:=any

c

c

c

c

* =

write
y

*

*

*

B

x+1

E

x+1

V
x+1
:=x+1

E

x+1

V
x+1
:=any

c

c

write

x

0

0

0

B

y=x+1

B

x+1

N

N

Action automata


y=x+1;

y=x+1


x+1



V
x+1

y

x


B

y=x+1

B

x+1

E

x+1

E

y=x+1

y:=V
x+1

B

x+1

E

x+1

E

y=x+1

y:=any

c

c

c

c

* =

write
y

*

*

*

B

x+1

E

x+1

V
x+1
:=x+1

E

x+1

V
x+1
:=any

c

c

write

x

0

0

0

B

y=x+1

B

x+1

N

N

N

E

x+1

5

0

0

Action automata


y=x+1;

y=x+1


x+1



V
x+1

y

x


B

y=x+1

B

x+1

E

x+1

E

y=x+1

y:=V
x+1

B

x+1

E

x+1

E

y=x+1

y:=any

c

c

c

c

* =
write
y

*

*

*

B

x+1

E

x+1

V
x+1
:=x+1

E

x+1

V
x+1
:=any

c

c

write

x

0

0

0

B

y=x+1

B

x+1

N

N

N

Action automata


y=x+1;

y=x+1


x+1



V
x+1

y

x


B

y=x+1

B

x+1

E

x+1

E

y=x+1

y:=V
x+1

B

x+1

E

x+1

E

y=x+1

y:=any

c

c

c

c

* =
write
y

*

*

*

B

x+1

E

x+1

V
x+1
:=x+1

E

x+1

V
x+1
:=any

c

c

write

x

0

0

0

B

y=x+1

B

x+1

E

x+1

N

N

N

E

y=x+1

5

0

0

5

5

0

Semantics of await

await {


(X.n()>0;X.writer; X.writer) comp: z = f(X.read());


(Y.space()>0;Y.reader;Y.reader) Y.write(z);

}

B

await...

c



start

Y.reader

E

comp:...

(
true

X.n()>0




active

X.writer)/


B

comp:...

(
true

Y.space()>0




active

Y.reader) /

B

Y.write(z)

E
Y.write(z)



s瑡牴

堮睲楴敲

c

E

await...

Semantics summary


Processes run sequential code concurrently, each at its
own arbitrary pace


Read
-
Write and Write
-
Write hazards may cause
unpredictable results


atomicity has to be explicitly specified


Progress may block at synchronization points


awaits


function calls and labels to which awaits or LTL
constraints refer