1 Gaspard Methodology The Y Model approach Models and UML profiles Arnaud CUCCURU, phd student ModEasy meeting, Lille, February 2005.

1

Gaspard MethodologyThe Y Model approach

Models and UML profiles

Arnaud CUCCURU, phd student

ModEasy meeting, Lille, February 2005

2

Outline

Y Model overview Common modeling paradigms Application modeling Hardware Architecture modeling Association modeling

3

“Y” model overview (1/2)

4

“Y” overview (2/2)

Common Modeling Paradigms

Application Hardware Architecture

AssociationY• Component Oriented Modeling• Factorization mechanisms

• Expression of data dependences • Data parallelism expression

• Resource dimensionning• Grid modeling

• Spatial and temporal mapping of an application on an architecture

5

Common modeling paradigms

Component oriented modeling

Components libraries Factorization

mechanisms



Association

6

Common modeling paradigms: Component Oriented Modeling (1/2)

Component<<Metaclass>>

Part<<Metaclass>>

1

*

Port<<Metaclass>>

*

Interface<<Metaclass>>

1

Connector<<Metaclass>>

*

ConnectorEnd<<Metaclass>>

1

1

*

*

+ports

+type

1

*+connectors1

+parts

*

+connectorEnds

*

+port1

+interface

1

Benefits:– Strong encapsulation

(to ease reuse)– Hierarchichal

description (to handle complexity)

7

Common modeling paradigms: Component Oriented Modeling (2/2)

ComponentA ComponentB

ComponentC

InterfaceB

InterfaceB InterfaceZ

InterfaceZ

InterfaceCInterfaceC

b : ComponentB

c : ComponentC

Component = Reusable design element

Port = Encapsulation point

Required interface = “Messages” that can be emitted

Provided Interface = “Messages” that can be received

Part = Component instance

Connector = Messages media

8

Common modeling paradigms: Components Libraries


Part<<Metaclass>>

1

*

Port<<Metaclass>>

*


1


*


1

1

*

*

+ports

+type

1

*+connectors1

+parts

*

+connectorEnds

*

+port1

+interface

1

«Metaclass» ElementaryComponent

Predefined components: ElementaryComponent

No internal structure description

Supposed to be implemented in a library

9

Common modeling paradigms: Factorization mechanisms (1/4)


Part<<Metaclass>>

1

*

Port<<Metaclass>>

*


1


*


1

1

*

*

+ports

+type

1

*+connectors1

+parts

*

+connectorEnds

*

+port1

+interface

1

«Metaclass» RepetitiveComponent

«Metaclass» RepetitiveConnector

Multidimentional Cardinalities

Definition of a “repetition space”: RepetitiveComponent

Use of multidimentional cardinalities on structural elements (parts and ports)

Use of “smart” connectors to interconnect factorized elements: RepetitiveConnector

Mechanisms inspired by the Array Oriented Language


10


Component

a3 : ComponentA

a2 : ComponentA

a1 : ComponentA

Ports Parts ConnectorsPotential factorization:

11


Component

a3 : ComponentA

a2 : ComponentA

a1 : ComponentA

PortsPotential factorization:

[6]

[2]

[2]

[2]

[3]

[ ]

[ ]

[ ]

=> Cardinalities

12


Component

Potential factorization:

[6] [3]

a3 : ComponentA

a2 : ComponentA

a1 : ComponentA

[2]

[2]

[2]

[ ]

[ ]

[ ]

Parts

a : ComponentA [3]

[2][ ]

=> Cardinalities

13


Component

Potential factorization:

[6] [3]

a : ComponentA [3]

[2][ ]

Connectors

«RepetitiveConnector» «RepetitiveConnector»

=> RepetitiveConnector

Several informations (vectors) are associated to Repetitive Connectors to describe connection patterns between ports: Origin, Paving, Fitting

14


Component

[6] [3]

a : ComponentA [3]

[2][ ]


RepetitiveComponent

Factorization expressed In the context of a repetitive component

Note: A repetitive component contains a repetition of a single part

15


Component

a3 : ComponentA

a2 : ComponentA

a1 : ComponentA0

1

2

3

4

5

0

1

2

0

1

0

1

0

1

• Basic idea: Handle ports with cardinalities as arrays of ports

• Dependences can be defined between patterns inside ports in the boundaries, and ports of the repeated parts

16


Component

a3 : ComponentA

a2 : ComponentA

a1 : ComponentA0

1

2

3

4

5

0

1

2

0

1

0

1

0

1

• Paving vector => identifies origin of each pattern inside the array of ports at the boundary, from a given Origin vector

• Paving limit is given by the cardinality associated to the repeated part (in this case 3)

Origin = {0}Paving = {2}


17


Component

a3 : ComponentA

a2 : ComponentA

a1 : ComponentA0

1

2

3

4

5

0

1

2

0

1

0

1

0

1

• An index vector is implicitely associated to each repetition of the part (Coordinates in the repetition space)

• Origin of the pattern associated to each part = origin + index x paving



{2}

{1}

{0}

18


Component

a3 : ComponentA

a2 : ComponentA

a1 : ComponentA0

1

2

3

4

5

0

1

2

0

1

0

1

0

1

• Fitting vector => determines the ports that belong to a given pattern inside of an array (from the origin of the pattern given by the Paving)

• Fitting limit is given by the cardinality associated to the ports of the repeated part



Fitting = {1}Fitting = {}

19


[6] [3]

a : ComponentA [3]

[2][ ]

«RepetitiveConnector»

Origin={0}Paving={2}Fitting={1}

«RepetitiveConnector»

Origin={0}Paving={1}Ftting={}

RepetitiveComponent

Final compact representation

20



Part<<Metaclass>>

1

*

Port<<Metaclass>>

*


1


*


1

1

*

*

+ports

+type

1

*+connectors1

+parts

*

+connectorEnds

*

+port1

+interface

1

«Metaclass» RepetitiveComponent

«Metaclass» RepetitiveConnector

Expression of connections between repeated instances: SelfConnector

= Connection between different points of the repetition space

«Metaclass» SelfConnector


21


Component

a3 : ComponentA

a2 : ComponentA

a1 : ComponentA

• Example: Ring topology

• Each instance is able to communicate with its neighbour

prov req

prov req

prov req

22


RepetitiveComponent

a : ComponentA [3]

• Factorization of parts in the context of a RepetitiveComponent

• Connection between points of the repetition space = Connection between different instances of the repeated part => SelfConnector

prov req

«SelfConnector»

RepetitionSpaceDependance = {1}

Modulo = true

23


RepetitiveComponent

• index of the “neighbour” = index + RepititionSpaceDependence mod RepetitionSpace size (i.e. Cardinality of the repeated part)

a3 : ComponentAa2 : ComponentAa1 : ComponentA

prov reqprov reqprov req{2}{1}{0}

{0} + {1} mod {3} {1} + {1} mod {3}

{2} + {1} mod {3}

24

Application modeling

Data Parallelism expression

Spatial and temporal dimensions unification

Inter-repetition dependences



Association

25

Application modeling

Component(from Common Modeling Paradigms)

<<Metaclass>>

AppComponent<<Metaclass>>

ElementaryComponent(from Common Modeling Paradigms)

<<Metaclass>>RepetitiveComponent

(from Common Modeling Paradigms)

<<Metaclass>>

AppElementaryComponent<<Metaclass>>

AppRepetitiveComponent<<Metaclass>>

• AppComponent ~= Function• Ports ~= Data handled (mainly multidimentional arrays)• Connectors ~= Data dependencies=> Expression of applications via expression of Data dependencies

26

Application modeling:Data parallelism expression (1/2)

• Example: Computations on a 4x4 array to produce a 2x2• Input and output arrays can be decomposed into patterns

arraypattern pattern

array

27

Application modeling: Data parallelism expression (1/2)

• Example: Computations on a 4x4 array to produce a 2x2• Input and output arrays can be decomposed into patterns• Each pattern can be computed independently: Potential Data Parallelism• => Represented with the common factorization mechanisms

array array

1,1

0,1

1,0

0,0Origin = {0,0}Paving = {{2,0},{0,2}}Fitting = {{1,0},{0,1}}

Origin = {0,0}Paving = {{1,0},{0,1}}Fitting = {{},{}}

28



array

29



array

RepetitiveComponent

30



array

RepetitiveComponent

p : Part

31


RepetitiveComponent

p : Part

[4,4] [2,2] [ ] [2,2]

32


RepetitiveComponent

p : Part [2,2]

[4,4] [2,2] [ ] [2,2]


33

Application modeling: Spatial and Temporal dimensions unification (1/2)

• Example: Signal processing application: Infinite stream of data consumed and produced• Idea: Infinite stream = Infinite dimension of an Array• Spatial and temporal dimension in an array• => Modeling of time and space dependences with the same formalism

Infinite vector Infinite vector

34

Application modeling:Spatial and Temporal dimensions unification (2/2)

RepetitiveComponent

p : Part [*]

[*] [*] [*] [*]


Origin = {0}Paving = {1}Fitting = {}


35

Application modeling: Inter repetition dependences (1/2)

• Inter repetition dependences

36

Application modeling:Inter repetition dependences (2/2)

RepetitiveComponent

p : Part [3]

[3] [1] [1] [3]




«SelfConnector»

RepetitionSpaceDependance = {1}

Modulo = false

37

Hardware Architecture modeling

Resources classification

Complex connection patterns expression

“Grid” topologies modeling



Association

38

Hardware Architecture modeling

Component(from Common Modeling Paradigms)

<<Metaclass>>

ElementaryComponent(from Common Modeling Paradigms)

<<Metaclass>>RepetitiveComponent

(from Common Modeling Paradigms)

<<Metaclass>>

HwComponent<<Metaclass>>

HwElementaryComponent<<Metaclass>>

HwRepetitiveComponent<<Metaclass>>

• HwComponent = Hardware resource

39

Hardware Architecture modeling: Resources classification

Passive: to support data. Example: RAM, ROM, SAM…

Active: able to read or write in passive resources, with or without modifications, and to sequence operations. Example: CPU, DMA.

Interconnect: interconnection between passive and active elements, or active and active. Example: Bus, static/dynamic interconnection networks,…

HwElementaryComponent<<Metaclass>>

HwActiveComponent<<Metaclass>>

HwPassiveComponent<<Metaclass>>

HwInterconnectComponent<<Metaclass>>

40

Hardware Architecture modeling: Complex connection patterns (1/2)

: Crossbar2x2

: Crossbar2x2

: Crossbar2x2

: Crossbar2x2

: Crossbar2x2

: Crossbar2x2

: Crossbar2x2

: Crossbar2x2

: Crossbar2x2

: Crossbar2x2

: Crossbar2x2

: Crossbar2x2

«CompoundHwComponent »

Omega8x8

41

Hardware Architecture modeling: Complex connection patterns (2/2)

«HwRepetitiveComponent »

OmegaStage

: Crossbar2x2 [2,2]

[8] [2] [2] [8]origin = {0}

paving = {{2},{2}}

fitting = {1}

origin = {0}

paving = {{4},{1}}

fitting = {2}


42

Hardware Architecture modeling: “Grid” topologies modeling (1/2)

• Example: 4x4 cyclic grid of communicating PEs

43

Hardware Architecture modeling: “Grid” topologies modeling (2/2)

• Example: 4x4 cyclic grid of communicating PEs

pe : PE [4,4]

« HwRepetitiveComponent »

CyclicGrid4x4

«SelfConnector»

RepetitionSpaceDependance = {1,0}

Modulo = true

«SelfConnector»

RepetitionSpaceDependance = {1,0}

Modulo = true

44

Association modeling



Association

In progress…

45

Association modeling

Association = distribution + scheduling– distribution = spatial mapping

code on active (and passive) data on passive communications on paths

– scheduling = temporal mapping for tasks memory allocation

1 Gaspard Methodology The Y Model approach Models and UML profiles Arnaud CUCCURU, phd student ModEasy meeting, Lille, February 2005.

Documents