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

2. 2 Outline Y Model overview Common modeling paradigms Application modeling Hardware Architecture modeling Association modeling

3. 3 “Y” model overview (1/2)

4. 4 “Y” overview (2/2) Y 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. 5 Common modeling paradigms Component oriented modeling Components libraries Factorization mechanisms

6. 6 Common modeling paradigms: Component Oriented Modeling (1/2) Benefits: – Strong encapsulation (to ease reuse) – Hierarchichal description (to handle complexity)

7. 7 Common modeling paradigms: Component Oriented Modeling (2/2) ComponentA ComponentB ComponentC InterfaceB InterfaceZ InterfaceC 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. 8 Common modeling paradigms: Components Libraries «Metaclass» ElementaryComponent Predefined components: ElementaryComponent No internal structure description Supposed to be implemented in a library

9. 9 Common modeling paradigms: Factorization mechanisms (1/4) «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 «Metaclass» ElementaryComponent

10. 10 Common modeling paradigms: Factorization mechanisms (2/4) Component a3 : ComponentAa2 : ComponentAa1 : ComponentA PortsPartsConnectorsPotential factorization:

11. 11 Common modeling paradigms: Factorization mechanisms (2/4) Component a3 : ComponentA a2 : ComponentA a1 : ComponentA PortsPotential factorization: [6] [2] [3] [ ] => Cardinalities

12. 12 Common modeling paradigms: Factorization mechanisms (2/4) Component Potential factorization: [6] [3] a3 : ComponentA a2 : ComponentA a1 : ComponentA [2] [ ] Parts a : ComponentA [3] [2] [ ] => Cardinalities

13. 13 Common modeling paradigms: Factorization mechanisms (2/4) Component Potential factorization: [6] [3] a : ComponentA [3] [2] [ ] Connectors «RepetitiveConnector» => RepetitiveConnector Several informations (vectors) are associated to Repetitive Connectors to describe connection patterns between ports: Origin, Paving, Fitting

14. 14 Common modeling paradigms: Factorization mechanisms (2/4) Component [6] [3] a : ComponentA [3] [2] [ ] «RepetitiveConnector» RepetitiveComponent Factorization expressed In the context of a repetitive component Note: A repetitive component contains a repetition of a single part

15. 15 Common modeling paradigms: Factorization mechanisms (3/4) Component a3 : ComponentA a2 : ComponentA a1 : ComponentA 0 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. 16 Common modeling paradigms: Factorization mechanisms (3/4) Component a3 : ComponentA a2 : ComponentA a1 : ComponentA 0 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} Origin = {0} Paving = {1}

17. 17 Common modeling paradigms: Factorization mechanisms (3/4) Component a3 : ComponentA a2 : ComponentA a1 : ComponentA 0 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 Origin = {0} Paving = {2} Origin = {0} Paving = {1} {2} {1} {0}

18. 18 Common modeling paradigms: Factorization mechanisms (3/4) Component a3 : ComponentA a2 : ComponentA a1 : ComponentA 0 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 Origin = {0} Paving = {2} Origin = {0} Paving = {1} Fitting = {1} Fitting = {}

19. 19 Common modeling paradigms: Factorization mechanisms (3/4) [6] [3] a : ComponentA [3] [2] [ ] «RepetitiveConnector» Origin={0} Paving={2} Fitting={1} «RepetitiveConnector» Origin={0} Paving={1} Ftting={} RepetitiveComponent Final compact representation

20. 20 Common modeling paradigms: Factorization mechanisms (4/4) «Metaclass» RepetitiveComponent «Metaclass» RepetitiveConnector Expression of connections between repeated instances: SelfConnector = Connection between different points of the repetition space «Metaclass» SelfConnector «Metaclass» ElementaryComponent

21. 21 Common modeling paradigms: Factorization mechanisms (4/4) Component a3 : ComponentA a2 : ComponentA a1 : ComponentA Example: Ring topology Each instance is able to communicate with its neighbour provreq provreq provreq

22. 22 Common modeling paradigms: Factorization mechanisms (4/4) 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 provreq «SelfConnector» RepetitionSpaceDependance = {1} Modulo = true

23. 23 Common modeling paradigms: Factorization mechanisms (4/4) RepetitiveComponent index of the “neighbour” = index + RepititionSpaceDependence mod RepetitionSpace size (i.e. Cardinality of the repeated part) a3 : ComponentAa2 : ComponentAa1 : ComponentA provreq provreq provreq {2} {1}{0} {0} + {1} mod {3} {1} + {1} mod {3} {2} + {1} mod {3}

24. 24 Application modeling Data Parallelism expression Spatial and temporal dimensions unification Inter-repetition dependences

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

26. 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 array pattern array

27. 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 1,1 0,1 1,0 0,0 Origin = {0,0} Paving = {{2,0},{0,2}} Fitting = {{1,0},{0,1}} Origin = {0,0} Paving = {{1,0},{0,1}} Fitting = {{},{}}

28. 28 Application modeling: Data parallelism expression (2/2) array pattern array

29. 29 Application modeling: Data parallelism expression (2/2) array pattern array RepetitiveComponent

30. 30 Application modeling: Data parallelism expression (2/2) array pattern array RepetitiveComponent p : Part

31. 31 Application modeling: Data parallelism expression (2/2) RepetitiveComponent p : Part [4,4][2,2] [ ] [2,2]

32. 32 Application modeling: Data parallelism expression (2/2) RepetitiveComponent p : Part [2,2] [4,4][2,2] [ ] [2,2] «RepetitiveConnector»

33. 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

34. 34 Application modeling: Spatial and Temporal dimensions unification (2/2) RepetitiveComponent p : Part [*] [*][*][*][*] [*][*] [*][*] «RepetitiveConnector» Origin = {0} Paving = {1} Fitting = {} Origin = {0} Paving = {1} Fitting = {}

35. 35 Application modeling: Inter repetition dependences (1/2) Inter repetition dependences

36. 36 Application modeling: Inter repetition dependences (2/2) RepetitiveComponent p : Part [3] [3][1] [3] «RepetitiveConnector» Origin = {0} Paving = {1} Fitting = {} Origin = {0} Paving = {1} Fitting = {} «SelfConnector» RepetitionSpaceDependance = {1} Modulo = false

37. 37 Hardware Architecture modeling Resources classification Complex connection patterns expression “Grid” topologies modeling

38. 38 Hardware Architecture modeling HwComponent = Hardware resource

39. 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,…

40. 40 Hardware Architecture modeling: Complex connection patterns (1/2) : Crossbar2x2 «CompoundHwComponent » Omega8x8

41. 41 Hardware Architecture modeling: Complex connection patterns (2/2) «HwRepetitiveComponent » OmegaStage : Crossbar2x2 [2,2] [8] [2] [8] origin = {0} paving = {{2},{2}} fitting = {1} origin = {0} paving = {{4},{1}} fitting = {2} «RepetitiveConnector»

42. 42 Hardware Architecture modeling: “Grid” topologies modeling (1/2) Example: 4x4 cyclic grid of communicating PEs

43. 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. 44 Association modeling In progress…

45. 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