La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

System on Chip DEA 2002. Evolution du marché Plus en plus présent dans le quotidien –Ordinateurs, PDA –GSM,GPRS,UMTS, GPS –TV numérique –Electronique.

Présentations similaires


Présentation au sujet: "System on Chip DEA 2002. Evolution du marché Plus en plus présent dans le quotidien –Ordinateurs, PDA –GSM,GPRS,UMTS, GPS –TV numérique –Electronique."— 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 + Hiperlan2 +...

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 : full-custom –Schéma –Dessin des masques –Simulation electronique : 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 –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 SOPHOCLES S ystem level devel O pment P latform based on H eter O geneous models and C oncurrent L anguag E s for S ystem 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 Gaspard overview Hiperf RT ISP

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 –Target architectures –Mapping of applications on architectures Model separation allows reuse Typical programming techniques in SP world AlgorithmArchitecture Mapping User applications Compilers  VC Models

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 z2z2 z1z1 A(z 1,z 2 ) = f (, )(A(z 1,z 2 -1)A(z 2 -1, z 2 -1) Elementary Transform Pattern Input Array Output Array Examples Fitting Paving

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 yuv2pip 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 SOPHOCLES BSR/TBR/STN/ARC/ Array-OL TM Techniques Thomson Marconi Sonar (TMS)

56 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ 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 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ 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 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ 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 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ 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 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ The Local Model Elementary Transform Pattern Input Array Output Array Examples Fitting Paving  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

61 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ 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 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ 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 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ Array-OL Q.D: an example RES.0OPE.0 OPE.1 RES.1 Operand array 0  ope.0 < 64 0  ope.1 < 128 Result array 0  res.0 <8 0  res.1 < 6 Projection Q.D => Operand Projection Q.D => Result Q.D Array 0  q1 < 3 0  q0 < 8 0  d res. < 2 0  d ope. < 4 Graph- ical view For- mal view 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 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ Second literal formalism: Array Distribution Operators (ADO's)  ADO's permit to describe links between an Emitter space of type NxNx...: N e of dimension e, and a Receiver space: N r of dimension r.  More precisely, an ADO describes for each element of N e if it is connected to elements in N r, and if true which elements in N r. E0 E1   R0   NeNe R1 NrNr ADO

65 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/  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 ADO composition  An ADO is composed of a chain of "Elementary Operators" (EO) implicitly separated by N d 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. ADO’s may be seen as a multi-dimensional arithmetic with some non classic operations (e.g. : segmentation).

66 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ ADO example : dependencies in an Array-OL task  General expression of the links between Operand space <= Result space q opé..off -set.p opé. 0f.d rés..p rés. f 0. d opé. MSGG PRO. SEG.

67 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ Tasks composition computation  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 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ Transformations

69 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ Interface Visuelle Gaspard

70 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ 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 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ Hierarchisation example Cx. MPYIFFT Fix=>Float FFT A1A2A3A4A5A6 Beam Forming Fix=>Float Pulse Compression A1A2A5A6 Beam Forming Composition T C C TC Local Model Cx. MPY IFFTFFT A'2A'3A'4 A'6 Level ”L-1" Global Model Level ”L" Global Model

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 SOPHOCLES - UML ARRAY-OL for Signal Processing Cédric Dumoulin LIFL

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

75 SOPHOCLES 75 - The ‘Y’ Model 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 AlgorithmArchitecture Mapping User applications Compilers  VC Models

76 SOPHOCLES 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, …)

77 SOPHOCLES 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

78 SOPHOCLES 78 - ISP UML et UML – Array-OL 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 » output TacheElementaire input T T

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

80 SOPHOCLES 80 - c2:C2c3:C3 c1:C1 input1input2 output Composants UML

81 SOPHOCLES 81 - Composants en XML (aperçu)

82 SOPHOCLES 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 SOPHOCLES 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 SOPHOCLES 84 - Component Creation Create a class stereotyped > Add ports:  attributes stereotyped > or >  associations Associate collaboration diagram  Draw sp-component internal structure

85 SOPHOCLES 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

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

87 SOPHOCLES 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 DotPro duct MatrixProduct A B result

88 SOPHOCLES 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 ApplyCase this CaseB this multiplexer AB selected key

89 SOPHOCLES 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, … inputoutput E E

90 SOPHOCLES 90 - Itérations non régulières Exemple d’itération non régulière : inputoutput E E ReductionPattern

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

92 SOPHOCLES 92 - Models Exploitation MOF UML metamodel MOF AOL metamodel MOF ISP-UML metamodel UML Java interfaces and implementations UML XMI ISP XMI AOL XMI visual tools (netbeans) Ptolemy II UML visual tools ISP Java interfaces and implementations AOL Java interfaces and implementations transformations code generations simulations OMG JMI OMG JMI OMG JMI import/export extends

93 SOPHOCLES 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 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ 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. A1 A2 A3 T1 T2 Global Model Local Model

97 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/  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 C TC T M1 A’1 A’3 A’4 Level L Level L+1 Global Model Local Model M2 A’4 Possible SSP Architectures suggested by Hierarchical Array-OL

98 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ 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 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ Resources possible representation Péripheral Memory DMA CPU Passive Resources Active Ressources

100 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ 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 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ 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. E.g. : for a given level, a machine composed of 2 PPC G4 COTS boards TD DMA1 FEC SDRAM2 SDRAM1 DMA2 DMA3 CPU1 CPU2

102 SOPHOCLES : Array-OL TM Techniques (TMS) BSR/TBR/STN/ARC/ 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. 16B. Width. E.g. : CPU1 of the previous example being spatially distributed on 4 Elementary Processors (PE) x4 4 1 Mega x 64B. SDRAM1 SDRAM1 Width.

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 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 interfaces


Télécharger ppt "System on Chip DEA 2002. Evolution du marché Plus en plus présent dans le quotidien –Ordinateurs, PDA –GSM,GPRS,UMTS, GPS –TV numérique –Electronique."

Présentations similaires


Annonces Google