42: The question of Components, Embedded Systems, and Everything 1 - - PowerPoint PPT Presentation

42 the question of components
SMART_READER_LITE
LIVE PREVIEW

42: The question of Components, Embedded Systems, and Everything 1 - - PowerPoint PPT Presentation

42: The question of Components, Embedded Systems, and Everything 1 Florence Maraninchi, Tayeb Bouhadiba www-verimag.imag.fr/ maraninx Verimag-Synchrone / Inst. Nat. Polytechnique de Grenoble November 28, 2006 1 Freely adapted from The


slide-1
SLIDE 1

42: The question of Components, Embedded Systems, and Everything1

Florence Maraninchi, Tayeb Bouhadiba www-verimag.imag.fr/˜maraninx Verimag-Synchrone / Inst. Nat. Polytechnique de Grenoble November 28, 2006

1Freely adapted from “The Hitchhiker’s Guide to the Galaxy”, D. Adams.

FM, TB (Verimag/INPG) 42 28/11/06 1 / 1

slide-2
SLIDE 2

Synchronous Languages, Component-Based Design and 42 FM, TB (Verimag/INPG) 42 28/11/06 2 / 1

slide-3
SLIDE 3

Synchronous Languages, Component-Based Design and 42

Synchronous Languages for the Component-Based Modeling of Heterogeneous (Embedded) Systems

Example in Lustre: sensor networks [InterSense’06, IWWAN’06]. Key points: Lustre allows to model hardware in details (necessary for modeling energy consumption) Lustre can be used as an ADL Lustre allows to write EXECUTABLE models Lustre allows to include a model of the physical environment Lustre is connected to testing and verification tools Asynchrony and other MoCCs can be encoded into Lustre

FM, TB (Verimag/INPG) 42 28/11/06 3 / 1

slide-4
SLIDE 4

Synchronous Languages, Component-Based Design and 42

Existing (successful) Component-Based Frameworks

Hardware (synchronous) components, called IPs, really exist. The sequential Boolean abstraction of the electric behavior is sufficient for component-based design. Software components really exist (at least in non concurrent frameworks). The OO paradigm works.

FM, TB (Verimag/INPG) 42 28/11/06 4 / 1

slide-5
SLIDE 5

Synchronous Languages, Component-Based Design and 42

What about concurrent embedded system design?

Observe current practise in: programming with Lustre/SCADE, SystemC/TLM for systems-on-a-chip, virtual prototypes of sensor networks, Ptolemy, the Architecture Analysis and Design Language (AADL), ...

FM, TB (Verimag/INPG) 42 28/11/06 5 / 1

slide-6
SLIDE 6

Synchronous Languages, Component-Based Design and 42

Lesson

Component-based design is about forgetting as much as possible, as soon as possible. But: what you can forget about the detailed behaviour depends on the kind of “soup” in which you put your components.

FM, TB (Verimag/INPG) 42 28/11/06 6 / 1

slide-7
SLIDE 7

Synchronous Languages, Component-Based Design and 42

Lesson

Component-based design is about forgetting as much as possible, as soon as possible. But: what you can forget about the detailed behaviour depends on the kind of “soup” in which you put your components. Such “soups” are often called MoCCs.

FM, TB (Verimag/INPG) 42 28/11/06 6 / 1

slide-8
SLIDE 8

Synchronous Languages, Component-Based Design and 42

42

Is meant to be: A simple framework to help identifying soups and forgetting things. Is not: – YAPMF (yet-another-parallel-modeling-formalism) – a high-level language – a tool similar to Ptolemy – ...

FM, TB (Verimag/INPG) 42 28/11/06 7 / 1

slide-9
SLIDE 9

Synchronous Languages, Component-Based Design and 42

42: Approach

Behaviors are in the components The oriented connections are nothing more than wires (no memory, no synchronisation). The way components (connected by wires) behave together is defined by a director that characterizes the MoC, as in Ptolemy The director is a small “program” in terms of more basic

  • perations

The director may be a model of a physical phenomenon (electricity in synchronous HW, an abstract non-deterministic model of the radio link for sensor networks, ...) or the code of an explicit scheduler in SW, or ...

FM, TB (Verimag/INPG) 42 28/11/06 8 / 1

slide-10
SLIDE 10

Synchronous Languages, Component-Based Design and 42

Additional (“language”) Questions in 42

encapsulation and component protocols (like in OO frameworks) and/or assume-guarantee data specifications Conditions for an assemblage of components to be correct (session types, ...) hierarchy: (components+wires+director) is a new component separate code generation

FM, TB (Verimag/INPG) 42 28/11/06 9 / 1

slide-11
SLIDE 11

42: Definition FM, TB (Verimag/INPG) 42 28/11/06 10 / 1

slide-12
SLIDE 12

42: Definition

A Basic Component with a Self-Defined Notion of Atomicity

Output Control Ports Data Ports Input Data Ports Output Control Ports Input

(not necessarily deterministic)

FM, TB (Verimag/INPG) 42 28/11/06 11 / 1

slide-13
SLIDE 13

42: Definition

A Basic Component with a Self-Defined Notion of Atomicity

  • c1
  • c2

id3 id2 id1

  • d3
  • d2
  • d1

ic1 ic2 Output Control Ports Data Ports Input Data Ports Output Control Ports Input

(not necessarily deterministic)

FM, TB (Verimag/INPG) 42 28/11/06 11 / 1

slide-14
SLIDE 14

42: Definition

A Basic Component with a Self-Defined Notion of Atomicity

atomic step internal memory

  • c1
  • c2

id3 id2 id1

  • d3
  • d2
  • d1

ic1 ic2 Output Control Ports Data Ports Input Data Ports Output Control Ports Input

(not necessarily deterministic)

FM, TB (Verimag/INPG) 42 28/11/06 11 / 1

slide-15
SLIDE 15

42: Definition

Compositions: The global picture

FM, TB (Verimag/INPG) 42 28/11/06 12 / 1

slide-16
SLIDE 16

42: Definition

Compositions: The global picture

  • utput port

input port ic, oc

Comp Comp Comp C Comp D B A

FM, TB (Verimag/INPG) 42 28/11/06 12 / 1

slide-17
SLIDE 17

42: Definition

Compositions: The global picture

a c e d b f

  • utput port

input port ic, oc

Comp Comp Comp C Comp D B A

FM, TB (Verimag/INPG) 42 28/11/06 12 / 1

slide-18
SLIDE 18

42: Definition

Compositions: The global picture

The controller:

a c e d b f

  • utput port

input port ic, oc

Comp Comp Comp C Comp D B A

FM, TB (Verimag/INPG) 42 28/11/06 12 / 1

slide-19
SLIDE 19

42: Definition

Compositions: The global picture

The controller: − dialogs with ABCD (ic, oc)

a c e d b f

  • utput port

input port ic, oc

Comp Comp Comp C Comp D B A

FM, TB (Verimag/INPG) 42 28/11/06 12 / 1

slide-20
SLIDE 20

42: Definition

Compositions: The global picture

The controller: − Manages memory for a, b, c, d, e, f − dialogs with ABCD (ic, oc)

a c e d b f

  • utput port

input port ic, oc

Comp Comp Comp C Comp D B A

FM, TB (Verimag/INPG) 42 28/11/06 12 / 1

slide-21
SLIDE 21

42: Definition

Compositions: The global picture

The controller: − defines glob. ic, oc, id, od

FM, TB (Verimag/INPG) 42 28/11/06 12 / 1

slide-22
SLIDE 22

42: Definition

42 Component Protocols, What For?

Define how components can be used Check that an assemblage of components is correct (e.g., in the synchronous MoC, it will enable the detection of instantaneous loops) Derive the code of the director from the protocols + other information Orthogonal to the notion of Assume/Guarantee data constraints

FM, TB (Verimag/INPG) 42 28/11/06 13 / 1

slide-23
SLIDE 23

42: Definition

42 Component Protocols, First Ideas

(inspired by multi-clocked synchronous languages)

Output Control Ports Data Ports Input Data Ports Output Control Ports Input

Instantaneous constraints to express e.g., the data output od is relevant only when the control input ic is true or, the data input id is required only when the control input ic is true Logical-time constraints: the data input id is required only if asked at the last activation (of this component) with the control

  • utput oc

FM, TB (Verimag/INPG) 42 28/11/06 14 / 1

slide-24
SLIDE 24

42: Definition

42 Component Protocols, First Ideas

(inspired by multi-clocked synchronous languages)

  • c1
  • c2

id3 id2 id1

  • d3
  • d2
  • d1

ic1 ic2 Output Control Ports Data Ports Input Data Ports Output Control Ports Input

Instantaneous constraints to express e.g., the data output od is relevant only when the control input ic is true or, the data input id is required only when the control input ic is true Logical-time constraints: the data input id is required only if asked at the last activation (of this component) with the control

  • utput oc

FM, TB (Verimag/INPG) 42 28/11/06 14 / 1

slide-25
SLIDE 25

42: Definition

42 Component Protocols, First Ideas

(inspired by multi-clocked synchronous languages)

atomic step internal memory

  • c1
  • c2

id3 id2 id1

  • d3
  • d2
  • d1

ic1 ic2 Output Control Ports Data Ports Input Data Ports Output Control Ports Input

Instantaneous constraints to express e.g., the data output od is relevant only when the control input ic is true or, the data input id is required only when the control input ic is true Logical-time constraints: the data input id is required only if asked at the last activation (of this component) with the control

  • utput oc

FM, TB (Verimag/INPG) 42 28/11/06 14 / 1

slide-26
SLIDE 26

42: Definition

42 Component Protocols, General Definition

An automaton structure like in OO protocols, specifying the language of correct sequences of method calls, used here for control inputs Accepting states specify what sequences of activations are “complete” w.r.t. the atomicity the component behaviour On each transition labeled by a control input, indicate what data inputs it requires and what data or control outputs it produces

FM, TB (Verimag/INPG) 42 28/11/06 15 / 1

slide-27
SLIDE 27

42: Definition

Example Object Protocol

package java.applet; public class Applet { //@ public call_sequence // init() : (start() : stop())* : destroy(); // member declarations ... } The specification init . (start . stop)∗ . destroy is meant for the whole life of the object.

http://opuntia.cs.utep.edu/utjml/callseq.html Specifying and Checking Method Call Sequences of Java Programs

FM, TB (Verimag/INPG) 42 28/11/06 16 / 1

slide-28
SLIDE 28

42: Definition

42 Component Protocols, General Definition

control inputs: init, start, stop, destroy destroy start stop init

FM, TB (Verimag/INPG) 42 28/11/06 17 / 1

slide-29
SLIDE 29

42: Definition

42 Component Protocols, General Definition

(y, c1) (x) data input : x control output : c1 data output : y control inputs: init, start, stop, destroy destroy start stop init

FM, TB (Verimag/INPG) 42 28/11/06 17 / 1

slide-30
SLIDE 30

42: Definition

42 Component Protocols, Intra-Step Sequential Constraints

b

(x)a(y,γ:=c) Idea: we ask the component what it wants to do with command a (that needs the data input x and produces the data output y) and it answers with the control output c, stored in variable γ). Later, depending on γ, we may need an input x or not.

FM, TB (Verimag/INPG) 42 28/11/06 18 / 1

slide-31
SLIDE 31

42: Definition

42 Component Protocols, Intra-Step Sequential Constraints

e (γ? x : ) d (...)

b

(x)a(y,γ:=c) Idea: we ask the component what it wants to do with command a (that needs the data input x and produces the data output y) and it answers with the control output c, stored in variable γ). Later, depending on γ, we may need an input x or not.

FM, TB (Verimag/INPG) 42 28/11/06 18 / 1

slide-32
SLIDE 32

42: Definition

42 Component Protocols, Inter-Step Sequential Constraints

The data input id is required for a step activation only if asked at the last activation (of this component) with the control output oc. (pre (oc)? id : ) step Remarks:

  • 1. pre : the needed memory

is managed by the director.

  • 2. Does not need a global

notion of time: pre means “last time” for this component.

FM, TB (Verimag/INPG) 42 28/11/06 19 / 1

slide-33
SLIDE 33

First Exercice: the Synchronous MoC FM, TB (Verimag/INPG) 42 28/11/06 20 / 1

slide-34
SLIDE 34

First Exercice: the Synchronous MoC

A Circuit Example (in Lustre)

node DoubleIntegr (i : int) returns (o : int) ; var x, y, z : int ; let x = Integr (i + (0->pre y)) ; y = Integr (x) ;

  • = y ;

tel. node Integr (i : int) returns (o : int) ; let

  • = i -> pre(o) + i ;

tel.

C2 C1 u t Counter Counter y z + x 0->PRE

FM, TB (Verimag/INPG) 42 28/11/06 21 / 1

slide-35
SLIDE 35

First Exercice: the Synchronous MoC

The Component View and the Director Algorithms

C2 C1 get0 step get0 get0 get0 step step step step getO u t Counter Counter y z + x 0->PRE

global get0: u.set ; pre.get0 ; z.set () ; plus.getO ; t.set (); c1.getO ; x.set () ; c2.getO ; y.set () ; global step :c1.step ; c2.step ; pre.step ; plus.step ;

FM, TB (Verimag/INPG) 42 28/11/06 22 / 1

slide-36
SLIDE 36

First Exercice: the Synchronous MoC

Protocols: All the Mealy Components

  • ne data input, one data output

no control outputs two control inputs: getOutput, step

(all inputs) (all inputs) (all outputs)

getO step

FM, TB (Verimag/INPG) 42 28/11/06 23 / 1

slide-37
SLIDE 37

First Exercice: the Synchronous MoC

Protocols: The (Moore) PRE component

  • ne data input, one data output

no control outputs two control inputs: getOutput, step

(all inputs) (all outputs)

getO step

FM, TB (Verimag/INPG) 42 28/11/06 24 / 1

slide-38
SLIDE 38

First Exercice: the Synchronous MoC

Observations on the Synchronous “MoC”

To be able to implement pure synchrony in a component-based manner, we need to distinguish between getO and step(s).

FM, TB (Verimag/INPG) 42 28/11/06 25 / 1

slide-39
SLIDE 39

First Exercice: the Synchronous MoC

Observations on the Synchronous “MoC”

To be able to implement pure synchrony in a component-based manner, we need to distinguish between getO and step(s). If we get a piece of code with this interface, it can be used as a black box in our component model.

FM, TB (Verimag/INPG) 42 28/11/06 25 / 1

slide-40
SLIDE 40

First Exercice: the Synchronous MoC

Observations on the Synchronous “MoC”

To be able to implement pure synchrony in a component-based manner, we need to distinguish between getO and step(s). If we get a piece of code with this interface, it can be used as a black box in our component model. The director needs only setting the values of the wires and activating the components.

FM, TB (Verimag/INPG) 42 28/11/06 25 / 1

slide-41
SLIDE 41

First Exercice: the Synchronous MoC

Observations on the Synchronous “MoC”

To be able to implement pure synchrony in a component-based manner, we need to distinguish between getO and step(s). If we get a piece of code with this interface, it can be used as a black box in our component model. The director needs only setting the values of the wires and activating the components. The values on the wires are not meant to be persistent: they are used only during the global step. This is the essence of synchronous communication.

FM, TB (Verimag/INPG) 42 28/11/06 25 / 1

slide-42
SLIDE 42

First Exercice: the Synchronous MoC

Observations on the Synchronous “MoC”

To be able to implement pure synchrony in a component-based manner, we need to distinguish between getO and step(s). If we get a piece of code with this interface, it can be used as a black box in our component model. The director needs only setting the values of the wires and activating the components. The values on the wires are not meant to be persistent: they are used only during the global step. This is the essence of synchronous communication. The director can be deduced from the dataflow graph and the components’ protocols (Lustre structural interpreter, electricity in synchronous circuits!)

FM, TB (Verimag/INPG) 42 28/11/06 25 / 1

slide-43
SLIDE 43

2nd Exercice: Something Asynchronous FM, TB (Verimag/INPG) 42 28/11/06 26 / 1

slide-44
SLIDE 44

2nd Exercice: Something Asynchronous

The Execution Platform

A monoprocessor computer, running multiple processes or threads thanks to a time-sharing scheduler. All processes (or threads) access the same memory. Reading or writing a word from/to memory is made atomic by the HW. Assume the processes are programmed in a language with an explicit yield instruction.

FM, TB (Verimag/INPG) 42 28/11/06 27 / 1

slide-45
SLIDE 45

2nd Exercice: Something Asynchronous

The Component Picture

Memory r w rv rv’ Process wv x a

  • ut

step pr pw a’ wv’ getWish y step

FM, TB (Verimag/INPG) 42 28/11/06 28 / 1

slide-46
SLIDE 46

2nd Exercice: Something Asynchronous

The global step, informally

If we encapsulate several processes, the shared memory, and a scheduler, we get a global component whose global step corresponds to: Either a step of process 1 and a step of the memory Or a step of process 2 and a step of the memory ... But never a step of process 1 and a step of process 2. More important: a step of process i that writes to memory, and the corresponding step of the memory, are no longer distinguishable. The director defines the atomicity of the global step.

FM, TB (Verimag/INPG) 42 28/11/06 29 / 1

slide-47
SLIDE 47

2nd Exercice: Something Asynchronous

A Remark on masters and slaves

The steps of the memory are not triggered by the global step directly. They are required by the processes. This leeds to the idea of a constraint between the control outputs of the processes (the masters), and the control inputs of the memories (the slaves).

  • c (process) =

⇒ ic (memory)

FM, TB (Verimag/INPG) 42 28/11/06 30 / 1

slide-48
SLIDE 48

2nd Exercice: Something Asynchronous

Component Protocols: a Process

(x) getWish (a, α:=pw, β:=pr) (y, β? rv’ : ) step (out, α? wv : )

FM, TB (Verimag/INPG) 42 28/11/06 31 / 1

slide-49
SLIDE 49

2nd Exercice: Something Asynchronous

Component Protocols: the Memory

(a’) r (rv) (a’,wv’) w Remark: such a memory may accept several writes and/or several reads “at the same time” provided they use distinct addresses. A “Test-and-Set” instruction may be described by a read-write activation of the memory, or by an unbreakable sequence of a read and a write at the same address.

FM, TB (Verimag/INPG) 42 28/11/06 32 / 1

slide-50
SLIDE 50

2nd Exercice: Something Asynchronous

The Master/Slave constraints

pw w pr r A write (resp. read) request should be followed (within the same global step) by a write (resp. read) activation of the memory.

FM, TB (Verimag/INPG) 42 28/11/06 33 / 1

slide-51
SLIDE 51

So What? FM, TB (Verimag/INPG) 42 28/11/06 34 / 1

slide-52
SLIDE 52

So What?

Constraints from which step could be defined

The processes’ protocols The connections (cannot consume the value on a wire before it has been produced) The master/slave constraints, if any A Global indication:

Synchronous MoC: a global step should be exactly one step of each component Asynchronous MoC: a global step should be one step of Process 1 (and its consequences) XOR one step of Process 2 (and its consequences)

Coordination language: connections + M/S constraints + global indication

FM, TB (Verimag/INPG) 42 28/11/06 35 / 1

slide-53
SLIDE 53

So What?

Ongoing Work

42’ization of the SystemC/TLM MoC Separating between control contracts (protocols) and data contracts... how, why? Relationship with TLM levels of abstraction (see talk by J. Cornet) MWCEC: Modular Worst-Case-Energy-Consumed

FM, TB (Verimag/INPG) 42 28/11/06 36 / 1

slide-54
SLIDE 54

So What?

Modular Worst-Case-Energy-Consumed

(Formal) Modeling and Analysis of ad-hoc sensor networks, with adaptable granularity and Precision. Energy Models M1, M2, ... representing parallel activities running on the same source of energy or not Parallel Composition × of these machines, yielding an energy model of the parallel system A partial order on machines: M1 < M2 if M1 is a more precise model than M2 A pre-congruence property: if M1 < M2 then, for any N, M1 ×N < M2 ×N.

FM, TB (Verimag/INPG) 42 28/11/06 37 / 1

slide-55
SLIDE 55

So What?

bla, bla...

because

FM, TB (Verimag/INPG) 42 28/11/06 38 / 1

slide-56
SLIDE 56

So What?

bla, bla...

I

FM, TB (Verimag/INPG) 42 28/11/06 39 / 1

slide-57
SLIDE 57

So What?

bla, bla...

need

FM, TB (Verimag/INPG) 42 28/11/06 40 / 1

slide-58
SLIDE 58

So What?

bla, bla...

42

FM, TB (Verimag/INPG) 42 28/11/06 41 / 1

slide-59
SLIDE 59

So What?

bla, bla...

slides

FM, TB (Verimag/INPG) 42 28/11/06 42 / 1