System on Chip DEA 2002.

Présentation au sujet: "System on Chip DEA 2002."— Transcription de la présentation:

1 System on Chip DEA 2002

2 Evolution du marché Plus en plus présent dans le quotidien
Ordinateurs, PDA GSM,GPRS,UMTS, GPS TV numérique Electronique embarquée dans l’automobile Baladeurs CD/MP3 DVD

3 Standard Les standards facilitent cette évolution vers l’intégration de services : PDA + GSM GSM + MP3 UMTS + MPEG4 + MP3 + Hiperlan

4 Plus de performance GSM =>GPRS =>EDGE =>UMTS
Bluetooth 11 Mbits/s =>Hiperlan2 à 54 Mbits/s

5 Réduire le « time to market »
Les produits ont une durée de plus en plus faible Réduire le «time to market» Réutilisation pour concevoir d’autres produits (rentabiliser)

6 REUTILISATION Approche retenue pour limiter les coûts
Conception d’un SOC à partir de blocs prédéfinis : Intellectual Properties

7 Réduction des coûts Conséquences de la réduction des coûts de conception du matériel Réduire les coûts du matériel augmente en proportion les coûts du logiciel 80% du coût de développement d’un SOC est aujourd’hui dû au logiciel Le coût du test croît de façon exponentielle Equipes de vérification 2 fois plus nombreuses que celles de développement

8 La révolution Le nombre de SOC vendus croît de 30% par an
Prévision de répartition par secteur pour 2004 : Communication : 44% (croissance 24% par an) Electronique grand public : 28 % (croissance 43% par an) Le reste 28 %

9 Evolution des besoins Plus de fonctionnalités Plus de puissance
Consommation réduite Réduction de la taille Coût faible Réduire le time to market Réutisibalité

10 Evolution des outils Outils de conception évoluent moins vite que la technologies Réutiliser des éléments Bibliothèques, IP

11 Evolution de l’architecture

12 Techniques de conception
70-80 : full-custom Schéma Dessin des masques Simulation electronique 80-90 : Précaractérisé FPGA Réutilisation de briques élémentaires Modélisation, simulation 00-xx : SoC Réutlisation du matériel et logiciel Co-design, vérification

13 Principes de conception
Une architecture matérielle Blocs standards (CPU, mem) Blocs spécifiques Bus de communication Des ressources logicielles SoC = cohabitation de ces ressources sur un même chip, prise en compte globale pour la réalisation hard/soft

14 Approche traditionnelle de conception
Concevoir un SOC : Vaste Problème d’Optimisation Ensemble de choix suivant plusieurs critères Performances atteintes Coûts minimum Communications maîtrisées Time-to-market réduit Consommation minimisée

15 Quelle architecture? Architecture Généraliste ou Spécialisée?

16 Cycle classique de conception

17 Vérification par co-simulation

18 Techniques de vérification formelle
Vérification par équivalence de modèles Vérification par preuve formelle de propriétés Difficulté pour le concepteur : déterminer les propriétés qui font du sens

19 Limitations approche traditionnelle
La vérification par cosimulation de plus en plus limitée : couverture vs temps Vérification des contraintes de temps : test du système i.e. en fin de cycle Les remises en cause ont une portée importante dans le cycle Approche de conception “processor centric”. Tendre vers “communication centric” Augmenter l’effort sur les premières étapes : Méthodes et outils qui opèrent au niveau système Nécessité de modèles

20 Vers une Conception Système
Modélisation des applications Construction de l’architecture Le problème du partitionnement Le problème des communications Le problème de la consommation

21 Conception de SoC

22

23 Réalisation d’un SoC Réutiliser les blocs déjà conçus dans la société ; Utiliser les générateurs de macro-cellules (Ram, multiplieurs,…) Acheter des blocs conçus hors de l’entreprise.

24 PLATEFORM-BASED DESIGN
Poursuite de la réduction des coûts Concevoir un SOC réutilisable SOC pour une famille d’applications

25 Notion d’IP (Intellectual Property)
Blocs fonctionnels complexes réutilisables Hard: déjà implanté, dépendant de la technologies, fortement optimisé Soft: dans un langage de haut niveau (VHDL, Verilog, C++…), paramétrables Normalisation des interfaces Environnement de développement (co-design, co-specif, co-verif) Performances moyennes (peu optimisé)

26 Utilisation d’IP Bloc réutilisable (IP) connaître les fonctionnalités
estimer les performances dans un système être sûr du bon fonctionnement de l’IP intégrer cet IP dans le système valider le système

27 Commerce d ’IP « design & reuse »

28 Les Cœurs de Processeurs RISC
Grande variété de RISC disponibles sous forme d’IP : ARM, Hitachi, MIPS, LSI Logic Exemple : Processeurs RISC 32 bits ARM (Advanced Risc Machines)

29 Les DSP Architecture des DSP : ciblée par rapport aux besoins d’une (classe d’) applicaton Exemple : TMS320C54x pour GSM Pipeline faible : déterminisme, consommation, surface Parallélisme de calcul : performances, consommation Registres : spécialisés, juste suffisants Mémoire : parallèle multi-bancs, on-chip et off-chip : performances 1 à 3

30 IP DSP Nombreux constructeurs et nombreux DSP chez chacun d’eux

31 VSI alliance : Standardisation
Objectifs : Réutiliser, échanger, vendre des composants virtuels Principes : Spécification et recommandation sur : Interfaces logiciels et matériels Formats Directives de conception Modèles pour : Spécification à différents niveaux d ’abstraction Documentation Test Simulation

32 Alliance VSIA: Conception
Virtual Socket Interface Alliance

33 SoC vs SoPC SoC System on Programmable Chip Peu évolutif
Grandes productions Fabrication et test long et coûteux System on Programmable Chip Prototypage rapide sur FPGA Composant reconfigurable à volonté Moins de portes logiques dispo Consommation plus élevée Performances moins bonnes

34

35 SOPHOCLES System level develOpment Platform based on HeterOgeneous models and Concurrent LanguagEs for System applications implementation Thomson-CSF Communications, Thomson Marconi Sonar, LIFL, Esterel Technologies - France Philips - Pays-Bas ENEA, Ipitec - Italie

36 Présentation Générale
Avènement du “tout numérique” dans les applications Telecom et Multi-média accroissement des puissances de traitement nécessaires systématisation de l’usage de processeurs programmables systèmes hétérogènes - adéquation des unités de calcul aux besoins de traitement : structures SIMD pour le Traitement de signal systématique DSP pour le T.S. RISC pour la supervision intégration de Composants Virtuels (VC) multi-source Réduction permanente du “Time to Market”

37 Présentation Générale (2)
Les enjeux: Maîtriser la conception et le développement des applications Temps Réel complexes:  simulations systèmes globales,  mise en œuvre de simulations hétérogènes distribuées,  introduction des techniques formelles pour validations précoces,  utilisation d’environnements de programmation haut niveau,  constitution d’une “cyber entreprise” au travers d’Internet.

38 Présentation Générale (3)
Les techniques mises en œuvre : Introduction de nouveaux formalismes: SyncCharts / Esterel ArrayOL Evolving Grammars Made Utilisation de divers langages et techniques : UML, XML, VDM++ Java, Jini, RMI, Corba MPI, ZZ Design Patterns, Esterel ++, agents intelligents

39 Environnement SOPHOCLES

40 La “Cyber Entreprise”

41

42 Organisation du Partenariat et apports
SOPHOCLES est organisé sur une base coopérative: France (TCC, TMS, LIFL, Simulog) Pilotage (TCC) Techniques et environnement de simulation Italie (ENEA, Nergàl) Cyber Entreprise (MUI, WEB) et techniques de simulations Pays-Bas (Philips) Environnement pour l’analyse de performance

43 The Gaspard environment

44 Scientific area Two different domain intersection
Intensive Signal Processing (ISP) Huge quantity of data Real time constraints High performance computing Heterogeneity of tasks Large and infinite data flow

45 Gaspard overview Hiperf RT ISP Gaspard

46 Effective Goal To propose at the higher level, in a unique “standard” environment A formal model and an explicit specification model Validation, performance evaluation, verification All inputs are used at different levels Code analysis Mapping and scheduling Code production Feasible for a particular applicative domain

47 Modeling and specification
High level complete functional specification To reduce the time to market No new programming language Visual expression of data dependences Express all the potential parallelism Task and data parallelism paradigms Specify different levels of complexity Exchange network of cluster Data transfer on SMP board, on SoC Take into account the methods used by industrial partners Multiples Several levels of specification: functional, application, cycle-accurate… Separate specification and execution

48 « Y » model Visual specification ISP applications User applications
Target architectures Mapping of applications on architectures Model separation allows reuse Typical programming techniques in SP world User applications Algorithm Architecture Mapping Models Compilers  VC

49 Why three levels of formalism
Application: Complete formal description (a priori validation ) Hardware independent Simulation and compilation compatibility Architecture Functional description Iterative refinement Application independent Mapping Deployment of one application on one architecture Data allocations Data transfers Processing distribution

50 Modèle d’application

51 Data dependence expression
Specification of task applied on objects Express only which objects are needed to process an other object (seems like demand-driven model) Concurrency - partial order based on data dependences No Runtime control (no mapping, no scheduling) High level specification of the algorithm Common formalism Development of tools (Hierarchy, Modularity, GUI) Reduction of programming task effort Different type of dependences Array dependences Iterative dependences Recursive dependences Aletrnative dependences

52 Iterative dependences
Regular computational structure (Data Parallel) Allows a compact and parametric representation Local model of Array-OL Forall statements No or partial execution order (SPMD): explicit or automatic extraction Elementary Transform Pattern Input Array Output Examples Fitting Paving z2 z1 A(z1,z2) = f ( , ) (A(z1,z2-1) A(z2-1, z2-1)

53 Array (object) dependences
Graph of actions applied on objects Global model of Array-OL Kahn Process Networks - YAPI Time and space dependences should be similarly expressed user interface TS demux PES parser video mixer MPEG-2 decoder video resizer pes pid es1 es2 yuv1 yuv2 pip ts size position out

54 Recursive/alternative dependences
Irregular applications Reduce add, cyclic graph… Dynamic arrays Collections Functional language inheritance Fold operator of Caml… Unsystematic applications Switch Components End of recurrence Towards a model to specify types of dependences (Meta)

55 Array-OLTM Techniques
Thomson Marconi Sonar (TMS)

56 Some properties of Systematic Signal Processing (SSP)
Dedicated to Systematic Signal Processing, Array-OL takes advantage of some simple features of this domain: Data are naturally organized into arrays, Dimensions of the arrays have a static size (at least as long as the same mode is running), Access in the arrays are predefined and most of the time “regular”, There is no conditional branches inside the application (However, conditional operations - e.g.: if cond. then a+b, else a-b - are authorized. Sorting for instance may be considered to belong to SSP).

57 Specificity's of arrays in SSP
One dimension may be of infinite size (e.g. : time) Some dimensions may be wrapped-around (e.g : sensors). In fact some arrays may be cylindrical or even toroidal. Size of some dimensions may change during the application (e.g : undersampling, oversampling) Some dimensions may appear or vanish (e.g : frequency) Array-OL takes into account all those specificity's.

58 Graphical Array-OL With Graphical Array-OL, a SSP application is specified through the use of two models: the Global Model , to first give a complete view of dependencies between tasks at the Array level, then the Local Model , to give separately for each task dependencies between the output arrays and the input arrays at the Component level.

59 The Global Model Organization of the treatments for the complete application is defined by a graph in which: nodes are the tasks, and vertices carry arrays between tasks. In the Global model, one gives the name of the tasks and the name and the size of the arrays Array Task

60 The local Model makes the following assumptions:
Few elements of the input array(s) are consumed and few elements of the output array(s) are produced, each time an elementary transform (ET) is performed. The task is finished when its output arrays are completely filled The "Few elements" are called a pattern Fitting and paving examples define graphically sampling strides Input Array Output Array Elementary Transform Fitting Examples Paving Pattern

61 So far, what is defined with Array-OL?
So far, Array-OL just gives in fact an exhaustive view of dependencies in a SSP application. Among all the strong potential parallelism of SSP applications - data parallelism, task parallelism - the choice is left completely free for execution provided that dependencies are respected.

62 First literal formalism: Array-OL Q.D
Array-OL Q.D is restricted to a formal representation of the Local Model. It is centered on the “Q.D” Array which doesn’t order data but computation grains. The "Q.D" array is composed of: Q dimensions, which are the quotients (Q) obtained by dividing one of the Result arrays by a divider (D) being the corresponding Result pattern. Result patterns dimensions, Operand patterns dimensions, To define accesses among the data, each element (processing grain) of the Q.D array has to be projected on the Operand and Result arrays via matrices in which the coefficients define paving and fitting strides.

63 Array-OL Q.D: an example
128 6 Operand array 0  ope.0 < 64 0  ope.1 < 128 Result array 0  res.0 <8 0  res.1 < 6 Graph-ical view OPE.1 RES.1 OPE.0 RES.0 64 8 Q.D Array Projection Q.D => Operand Projection Q.D => Result For-mal view 0  q1 < 3 0  q0 < 8 0  d res. < 2 0  d ope. < 4 NB: the main lack with Array-OL Q.D is that it doesn’t establish a continuity between the Result space and the Operand space, thus forbidding dependence computation beyond one task.

64 Second literal formalism: Array Distribution Operators (ADO's)
ADO's permit to describe links between an Emitter space of type NxNx...: Ne of dimension e, and a Receiver space: Nr of dimension r. More precisely, an ADO describes for each element of Ne if it is connected to elements in Nr, and if true which elements in Nr.  E1  Nr R1 Ne   ADO E0 R0

65 ADO composition ADO’s may be seen as a multi-dimensional arithmetic with some non classic operations (e.g. : segmentation). An ADO is composed of a chain of "Elementary Operators" (EO) implicitly separated by Nd spaces. An EO may cut ( ), prolong ( ), multiply ( ), concentrate ( ), links received from its input space, but only for the components having been already reached by links coming from the previous EO. To describe dependencies, distributions or lay-out, 8 EO: 4 direct EO, 4 "mirror EO" are proved to be sufficient. DIRECT Gauge Modulo Shift Projection MIRROR Gauge -1 Modulo -1, or Blow-out Shift -1 Segmentation

66 ADO example : dependencies in an Array-OL task
General expression of the links between Operand space <= Result space q opé. . off . p f . d rés. . p f . rés. -set opé. opé. rés. rés. d opé. PRO. M S G SEG. G

67 Tasks composition computation M t .S tPRO tG t SEG t .G t}
The standard expression of an Array-OL task t is (R1): M t .S tPRO tG t SEG t .G t} where EO's contain only integer values. Links between results of this task t and operands of the task t-1 are expressed by (R2): M t-1 .S t -1PRO t -1G t -1 SEG t -1 .G t -1} M t .S tPRO tG t SEG t .G t} Patterns, fitting, paving of the macro-task obtained by composing t et t-1 will be defined when, by modifying EOs in (R2), one gets back to an expression of the same type as (R1). Modifications must respect the rule:cutting any link established in (R2) is forbidden; only adding new links is allowed. A (graphical) tool for tasks merging with automatic computation of pattern sizes, fitting and paving parameters has been realized in cooperation with "Laboratoire d'Informatique Fondamentale de Lille"

68 Transformations

69 Interface Visuelle Gaspard

70 Hierarchisation in Array-OL
Hierarchisation has been added to Array-OL mainly to give a way to define the lay-out of an application on a SSP machine. Starting from a flat view of the application, hierarchisation consists in: composing a segment of successive tasks into a single “macro-task”, considering that the relationship between the “macro-patterns” and the “macro-ET” of this macro-task may be seen as an application in a next lower level. Hierarchisation is done according to the architecture of the SSP target machine which in turn may be seen as a hierarchical organisation: several clusters, several nodes per cluster, several PEs in a node...

71 Hierarchisation example
Fix=>Float FFT Cx. MPY IFFT Beam Forming Composition Global Model Level ”L" A1 A2 A5 A6 Fix=>Float Pulse Compression Beam Forming TC T Local Model C C A'2 A'3 A'4 A'6 Global Model Level ”L-1" FFT Cx. MPY IFFT

72 UML language Standard used also in industrial development
Extension mechanisms (« stereotypes », « tagged values », « profils ») No method is imposed Used to validate our own “Y” model Visual as well as textual A lot of tools exit (Rational Rose, Objecteering...) Metamodel exits and is specified with MOF We propose our metamodel dedicated to ISP applications Interoperability in XMI/XML

73 UML ARRAY-OL for Signal Processing
Cédric Dumoulin LIFL

74 Goals Visual modeling of Intensive Signal Processing Application (ISP-A) Automatic exploitation of application models by tools Code generation, transformations, simulations, …

75 The ‘Y’ Model User applications Models Compilers  VC
This work is part of Sophocles project and DaRT project Propose the “Y” model: Separation of algorithm, architecture and mapping Allows reuse of algorithms and architectures Algorithm Architecture Mapping User applications Compilers  VC Models

76 Modeling Applications with UML
Restrict to Intensive Signal Processing (ISP) applications The framework clearly define what should be model and how  We can model a complete application and exploit it (transformation, code generation, …) Facultative, may be deleted

77 Basic Concepts to Model an ISP-A
Inspired from Array-OL (Array-Oriented Language) (TUS, Alain Demeure) Global model, task, array, local model, pattern, QD, elementary task, hierarchical description Our proposal: SP-Component (signal processing component): unit of computation Port: typed input/output of a sp-component Graph of dependencies: made of sp-components interconnected by their ports Represent the internal structure of a sp-component Tilers  UML classes

78 ISP UML et UML – Array-OL
TacheElementaire input T output Trois éléments clés : Composants Définit par une interface et un comportement Elémentaires, hiérarchiques, ou itératifs / data-parallèles Ports Symbolisent les données manipulées Points de connexion entre composants Connexions Entre les ports des composants « directes » ou « contrôlées » par un « Tiler »

79 Sp-Components and Ports in UML
Class stereotyped <<spComponent>> Port Class stereotyped <<port>> Specify a type description Add a port to a sp-component Component’s attribute stereotyped <<inPort>> or <<outPort>; with appropriate port type + UML association

80 Composants UML c2:C2 c3:C3 c1:C1 input1 input2 output

81 Composants en XML (aperçu)
<UML:Package xmi.id="a0" name="myPackage" isSpecification="false" isRoot="false" isLeaf="false" isAbstract="false"> <UML:Namespace.ownedElement> <UML:SpComponent xmi.id="a3" name="InputComponent" isSpecification="false" isRoot="false" isLeaf="false" isAbstract="false" isActive="false"> <UML:Classifier.feature> <UML:PortAttribute xmi.id="a4" type="a5" name="outStream" isSpecification="false" direction="out"></UML:PortAttribute> </UML:Classifier.feature> </UML:SpComponent> <UML:SpComponent xmi.id="a6" name="OutputComponent" isSpecification="false" isRoot="false" isLeaf="false" isAbstract="false" isActive="false"> <UML:PortAttribute xmi.id="a7" type="a5" name="inStream" isSpecification="false" direction="in"></UML:PortAttribute> <UML:SpComponent xmi.id="a8" name="CompoundComponent" isSpecification="false" isRoot="false" isLeaf="false" isAbstract="false" isActive="false"> <UML:PortAttribute xmi.id="a9" type="a5" name="input" isSpecification="false" direction="in"></UML:PortAttribute> <UML:PortAttribute xmi.id="a10" type="a5" name="output" isSpecification="false" direction="out"></UML:PortAttribute>

82 Graph of dependencies in UML
Collaboration diagram containing: Instances of sp-component’s ports Instances of sub sp-components with associated ports Links between instances Graph is associated to the sp-component it describes Possible improvement: structure diagram More adapted to our business Product DotProduct A B result Reduction

83 Application Creation Define port types Create sp-components
One top-level sp-component: the application No ports Structure represents the top level graph of dependencies

84 Component Creation Create a class stereotyped <<spComponent>> Add ports: attributes stereotyped <<inPort>> or <<outPort>> associations Associate collaboration diagram Draw sp-component internal structure

85 Ports Typed: only “compatible” ports can be connected
Ports and Array-OL Arrays: Arrays  typed port One port type for each kind of array Extend class AolPort Define a hierarchy of ports Compatible: same class or subclass

86 All is Sp-Component ? Application: Captors, data I/O:
top level sp-component Captors, data I/O: specialized sp-components Elementary tasks, calls to external functions, … Data-parallel components Modeled by classes stereotyped <<spComponent>> Some components use stereotypes extending <<spComponent>>: Ex: <<dataParallel>>

87 DataParallel Sp-Component (AOL local model)
Such component contains one and only one sub-component Ports represent arrays of data Tilers describe how arrays are divided in patterns and iterated Values are specified in tiler’ instances Sub-component is executed once for each set of patterns DotProduct MatrixProduct A B result

88 Advanced Concepts Ports can carry sp-components
Each sp-component has a special port named “thisComponent” As output: carry the sp-component itself As input: the instance is replaced by sp-component provided by the port Useful to build multiplexers, switches, build parameterized component CaseA this CaseB this multiplexer A B selected key ApplyCase this

89 Advanced Concepts (Con’t)
Recursive calls New kind of Array Tilers Enumerative: describe explicitly how an array is enumerated Irregular iteration: Ex: extract the first data and drop the rest, … input output E

90 Itérations non régulières
Exemple d’itération non régulière : input ReductionPattern output E E

91 Modélisation d’applications récursives :
Composants récursifs Modélisation d’applications récursives : Définition récursive de composants

92 Models Exploitation MOF ISP-UML metamodel MOF AOL metamodel
MOF UML metamodel extends OMG OMG OMG OMG JMI JMI JMI UML visual tools visual tools (netbeans) Ptolemy II UML XMI ISP XMI AOL XMI ISP Java interfaces and implementations AOL Java interfaces and implementations UML Java interfaces and implementations import/export import/export We have define a metamodel for our “language elements” It extends the UML one: - inherit UML feature - add our feature: structure, spComponent, ports We use standards: - metamodel in MOF - java interfaces defined by JMI, + implementations - corresponding XMI file format Tools builds around the XMI format and java interfaces Have define a metamodel for Array-OL - xmi file format, java interfaces and implementations Modules build around NetBeans -Core (metamodel classes) -Model Explorer -Structure diagram viewer -UML-XMI and AOL-XMI import/export -Transformations transformations simulations code generations

93 Works in Progress and Future Works
Provide similar framework for: Architecture modeling Mapping description Complete the “Y” model Simulator, code generator, transformations, …

94 Architecture specification
The same specification environment in UML Improve architecture modeling of UML Similar model than application specification Support the targets of applications : SoC, COTS, distributed simulators... Different levels of specification for different levels of simulation Hierarchical and iterative architecture building Two kind of components Active components to process data Passive components to store data To take account of industrial environments of Sophocles partners Array-OL architecture, mAgiSim, Vcc, SynDEx…

95 Mapping an application on an architecture
Last step before code generation : simulation or execution Specified explicitly by the programmer Integrate in UML new deployment elements Link between architecture and algorithm Same application on different architecture and reciprocally Express associations between components of application and active and passive elements of the architecture Same kind of iterators are use for iterative mapping on space and time

96 Possible SSP Architectures suggested by “Flat”Array-OL
“Flat” Array-OL may suggest that: : tasks in the Global Model could be executed in a pipeline fashion on different resources (if available), TEs in the Local Model could be executed in SIMD fashion if the resource considered in the Global Model is composed of several identical “Elementary Resources”. “Flat” Array-OL naturally calls for multi-SPMD architectures. Global Model A1 T1 A2 A3 T2 T.E. A1 A2 Local Model

97 Possible SSP Architectures suggested by Hierarchical Array-OL
With hierarchy, Array-OL may also suggest that an Elementary Resource in the Local Model could appear as composed of several heterogeneous resources n the Global Model of a next level. T C TC M1 A’1 A’3 A’4 Level L Level L+1 Global Model Local M2

98 Resources Classification
We consider that a SSP architecture may be seen as a set of only 2 types of resources : Passive Resources used as a medium for Arrays : memories to store the arrays, peripherals producing or consuming data outside the architecture. Active resources capable of reading or writing data in those passive resources : DMAs to move - without modification - data between passive resources, CPUs to read, modify, write, data in one or several memories.

99 Resources possible representation
Passive Resources Active Ressources Péripheral Memory DMA CPU

100 From Array-OL Appli to Array-OL Archi
From Array-OL (which we will call now “Array-OL Appli”) it is possible to derive a very close formalism (which we will call “Array-OL Archi”) to describe SSP architectures. Like Array-OL Appli, Array-OL Archi uses: a global model to define connexions between resources, a local model to show the (spatial or temporal) repetitive nature of each active resource and eventual constraints to its surrounding memories, and the hierarchy to gently detail the architecture. The general principle is to replace Arrays and Tasks in Array-OL Appli by respectively Passive and Active resources of Array-OL Archi.

101 The Global Model in Array-OL Archi
Like Array-OL Appli, the Global Model of Array-OL Archi uses a graph describing data paths between passive and active resources. FEC TD SDRAM1 SDRAM2 DMA1 CPU1 DMA2 CPU2 DMA3 E.g. : for a given level, a machine composed of 2 PPC G4 COTS boards

102 The Local Model in Array-OL Archi
The Local Model of Array-OL Archi defines for each Active Resource how its activity is distributed along a temporal or spatial (user’s choice) axis, on identical Elementary resources. Memory icons are used to define which dimension in a memory has to be paved or fitted in the last level of the hierarchy. x4 4 Node. @ 1 Mega x 64B. SDRAM1 Node. Width. 16B. Width. E.g. : CPU1 of the previous example being spatially distributed on 4 Elementary Processors (PE)

103 Compilation and simulation
Mapping/scheduling and code generation of ISP applications « Y » architecture allows Compilation techniques just after mapping specification Standard techniques of automatic parallelization is applied to ISP Code is produced for a particular architecture Diversity of targets (IP, COTS, simulator, VSIA...) asks for a lot of code generators A “generic” code generator Distributed simulator

104 Compilation Different type of optimizations
Unique assignment, recursive and first class citizen functions are similar to functional languages Data flow dependences are similar to forall loops Loop transformation de boucles, tiling… Signal processing allows other optimizations  Memory management, data transfers… Infinite arrays and memory management Time and space dimensions overlapping Multi optimization method integration in Gaspard Toward a formal model to express code transformations

105 Mapping/scheduling techniques
Unified time and space dimensions allows a joint optimization We propose automatic transformations of regular ISP applications to allow To choose the grain of the mapping to minimize communications To load balance memory occupation and performances Gaspard could already map regular ISP applications on heterogeneous SoC Extension to irregular ISP applications

106 Code generation Different levels of heterogeneity and communication
SoC are very heterogeneous, data transfers and execution time can be finely controlled (no OS) SMP are homogeneous but used OS and compilers (C, C++) Metacomputing insures interoperability and communication/synchronization between software components Generate code for different compilers according to the mapping Modularization et parameterization of Gaspard code generator

107 Distributed simulation
Sophocles cyber-entreprise for SoC simulation from distributed IP Runtime support, distributed component coupling with good performance characteristics Distributed process network Adequation between this runtime and our specification model Dynamic runtime support in Corba based on multithreaded component interconnexion via FIFO  Gaspard/Yapi gateway Integration of data-parallelism in PN Data-parallel CORBA VCI defined by Virtual Socket Interface Alliance could be supported by CORBA Wrapper integration

108 Compilation Gaspard environment

109 Architecture Overview of Gaspard
UML Tools Rose, Together, … Classes XML / XMI interfaces Code generation transformations visualization Gaspard files scheduling mapping SIMD Architecture Distributed simulation java others … runtime