Exploration de l’Architecture hétérogène basé- cluser pour SoPC auto-adaptif

1. Exploration de l’Architecture hétérogène basé-cluser pour SoPC auto-adaptif Thésard : Xun zhang Thèse en deuxième année Directeur de thèse :Serge WEBER Co-directeur de thèse : Hassan RABAH Université Nancy Laboratoire d’Instrumentation d’Electronique de Nancy (LIEN)

2. sommaire • Introduction • Besoin de flexibilité • Platform et flexibilité • Solution matérielle reconfigurable • Contribution et positionnement des travaux • Architecture hétérogènebasé-cluster • Multiple cluster • Contrôleur reconfiguration • Application • Conclusion et Perspective

3. Introduction Besoin de flexibilité ? • Les différent applications ont besoin différent architecture pour le meilleurs performance. • différent fonction Tous sont on même puce!! • Différent comportements de l’application ont besoin différent architecture • l’état de batterie • command de client • qualité de réseau Différent Traffic Patterns Différent architecture Groups d’application

4. Introduction Solution matérielle dédiée entrée 1 entrée 2 entrée 1 entrée 2 ASIC 1 ASIC 2 ASIC 3 Solution flexible entrée 1 entrée 2 entrée 1 entrée 2 ---Plateforme et flexibilité Héterogeous reconfiguration Solution logicielle mémoires instructions données Reconfigurable Computing Banc de registres REG REG REG Microprocessors REG ASICs Reconfigurable Computing ALU Highest flexibility Performance? High flexibility High performance Highest performance Lowest flexibility Solution performante µP sortie • GPPs can execute any software, but performance can be slow • ASICs can execute only one application, but quickly • Reconfigurable computing seeks to bridge this gap • Reconfiguration allows same hardware to execute multiple applications • Executing application in hardware leads to higher performance than in software

5. Introduction application 2 application 1 architecture logique 1 architecture logique 2 configuration 1 configuration 2 configuration --Solution matérielle reconfigurable architecture physique reconfigurable éléments configurables de calculs et mémoires réseaux configurables de connexions reconfiguration

6. Introduction • Besoin de flexibilité • Platform et flexibilité • Solution matérielle reconfigurable • Contribution et positionnement des travaux • contribution en 3C • Position de notre travail • Architecture hétérogènebasé-cluster • Multiple cluster • Contrôleur reconfiguration • Application • Conclusion et Perspective

7. Les problème de design -positionnement de l’architecture en 3C • Cible architecture (la granualité de configuration) • Coût d’architecture(surface occupé sur puce) • Coût de reconfiguration ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU C1 E1 Cible architecture C2 ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU E2 Gros grain ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU ALU C3 Reconfiguration sous programme (ordonnancement en pipeline) opération Coût d’architecture C1 E1 C2 Coût de reconfiguration E2 Cycle Reconfiguration ordonnancement en séquence

8. Critère de l’architecture • Réduction du temps de reconfigurable par la méthode de programme, réutilisation de matériel on puce; • Augmente la flexibilité du système par les multiple mode reconfigurable; • Une topologie de module changeable fait le system adapter facilement l’application correspondant; • Optimisation de nombre de module pour réduire la pression de communication;

9. 1.M. Ullmann, M. Hnbner, B. Grimm, J. Becker, On-demandFPGA run-time system for dynamical reconfiguration with adaptive priorities, Lecture Notes in Computer Science 3203 (2004) 454–463. 2.L. Möller, N. Calazans, F. Moraes, E. Briao, E. Carvalho, D. Camozzato, FiPRe: an implementation model to enable self-reconfigurable applications, Lecture Notes in Computer Science 3203 (2004) 1042–1046. 3.Armando Astarloa, et al. Tornado: A self-reconfiguration control system for core-basedmultiprocessorCSoPCs, Journal of Systems Architecture 53 (2007) 629–643 4. Carsten Albrecht,et al. DynaCORE – A Dynamically Reconfigurable Coprocessor Architecture for Network Processors,14th Euromicro International Conference on Parallel, Distributed, and Network-Based Processing (PDP’06)

10. Contribution et positionnement des travaux • ----le but de travail est de balancer le performance de reconfigurable et la flexibilité du SoPC auto-adatif système. La réalisation de ce but est de mettre en œuvre une architecture hétérogène reconfigurable afin de répondre au besoins d’adaptabilité et de scalabilité dans ces applications complexes(Multimédia, télécom, système nomades …) • ---- • ----Les travaux s’appuient sur les technologies FPGAs reconfigurables partiellement et dynamiquement.

11. Introduction • Besoin de flexibilité • Platform et flexibilité • Solution matérielle reconfigurable • Choose d’architecture • Contribution et positionnement des travaux • exploision en 3C • Position de notre travail • Modélisation de l’Architecturehétérogènebasé-cluster • Modélisation hiérarchique • Méthodeexposition architecturale • Les Éléments du système • Estimation de l’application • Organisation architecturale • Flow de exploration architecturale • Application • Conclusion et Perspective

12. SoPC auto-adaptif • SoPC architecture : Centric Architecture • multiple module fonctionnelle et reconfigurable (en vue d’architecture) • GPP • DSP • IP matériel • IP reconfigurable • partition matériel et logiciel(en vue de fonction) • Tâche matériel • Tâche logiciel • Programme de configuration

13. L’idée Application node actor Global Reconfigurable module Global task Système opération Local Reconfigurable Module Local task Lib.ProC Cluster (HW platform) Cluster Cluster Lib.Conf. NoC HW • Structure basé-cluster (scalabilité et extension du système) • Architecture hiérarchique( cluster -> RPM) (reconfiguration efficace) • Topologie de cluster est flexibilité ( adaptation de l’application ou comportement de l’application)

14. Modélisation possible d’architecture • Les éléments hiérarchiques: sont utilisés pour modéliser le routage et les ressources de traitements • Basé-cluster: (ID_cluster) • Module Reconfigurable Partial (RPM): (ID_RPM) • Interface hiérarque(Interface cluster-cluster, Interface RPM-RPM) • ID et nom de module • ID de l’interface • Utilisation d’une vue fonctionnelle de l’architecture • les ressources sont décrites par les fonctions qu’elles réalisent. • ID et nom de fonction • Nombre et type de RPM

15. Les éléments hiérarchiques Cluster- N2 Global Reconfigurable module Local Reconfigurable Module 3 niveaux hiérarchiques N1={Cluster1,Cluster2,…,Clustern} N2={RPM1,RPM2,RPM3} N3=GRM or GPP or LRM N3 N2 N1

16. Méthode de exposition architectural Plus de performance Stratégie: exposition Prospecter la nécessité d’adaptation de l’application en rapprochant hiérarchiquement les RPM avec les différentes critères de l’application; Plus de souplesse Solution moyenne • Les critères de projection architectural • Complexité de calcul • Temps d’exécution • Consommation d’énergie • Consommation de communication(accès mémoire) N3 N2 N1

17. Organisation architectural de ressource Graph of task • Lib. Reconfiguration(DBRC) • ID_RPM • ID_module(global, local) • ID_interface(global, local) • Priority_Module • Lib. Reconfigurable module & interface (bitstreams ouprogrammation)(DBMS & DBMR) • Resource Configuration

18. Flot d’exploration architecturale ESTIMATION de l’application Spécification DAG des fonctions de l’application Fonctions critiques F6 F5 de l’application F4 Spécification des F3 architectures Organisation architecturale F2 Architecture F1 Modélisée(DBRC) n°1 Choix des fonctions critiques Choix d’une architecture Estimation de l’architecture communications & taux d’utilisation Architecture choisie Flot de reconfiguration partial

19. Architecture hétérogène basé-cluster DBMS & DBMR • multi-types Reconfigurable Pressing Module (RPM) • hardware IP Core /GPP • reconfigurable IP Core • mixed core • Interface programmable • Cluster-Cluster (Interface Cluster) • RPM-RPM (Interface RPM) • Reconfiguration controller • Identifier Cluster • Identifier RPM • Identify type of RPM • organisation de chaque RPM faire allocation ordonnancement I/O RC

20. RPM Accèssvitess, flexibilité, énergie d’accèss Règle : Minimum version: Intermédiaire version: Maximum version: Densité de cellule Caractéristique: • Trois niveaux granularités aident de contacter plusieurs de performance et flexibilité; • Interface reconfigurable permet de connecter avec différentes band passante de connexion; • Local Memory permet de réduire la fréquence de communication sur l’interface global;

21. Interface hiérachique • Inter-module and Intra-module communication modelssupport • Cluster-Cluster • RPM-RPM Mémoir Contrôleur reconfiguration Standard bus Bus dock Interface section Interface section ISM Cluster Cluster ISM: Interface of Sub-Module Description de Interface section

22. Interface programmable(M2IRE) Multiple-Mode Interface for Reconfigurable Element DMA/mémoire externe Hardware bitstreams context1 Routage d’entré et sortie switch Programme logicielle Section interface contex2 Contexte manager context3 Contrôleur reconfiguration Mémoire & contrôle registre Mémoire & contrôle registre Mémoire & contrôle registre GPP LRM GRM Description de contrôleur reconfiguration

23. Contrôleur reconfiguration External system • Quel RPM? • Quellemodel de RPM? • Est-cequetous les RPM? • Quand? Environment Cluster Info._config. RC Activating RPM en_info. answer of RPM Ack_Reconf. • Identifier RPM • Identifier le type de RPM • Identifier la reconfiguration mode • L’allocationordonnancement (mapping –schaduling ) • non-prehentif (handshake) • prehentif Reconfiguration library bitrstreams library

24. Flux de contrôle: Étape un(Idle): surveiller la demande vers système externe (fonction critique) ou commande de client; Étape deux(Identify): identifier la liste de tâche nécessaire pour la nouvelle fonction; Étape trois(Allocate): identifier la liste de donnée de configuration; Étape quatre(Error): error résilience Étape cinq(Config): chargement de donnée de configuration

25. Introduction • Besoin de flexibilité • Platform et flexibilité • Solution matérielle reconfigurable • Choose d’architecture • Contribution et positionnement des travaux • exploision en 3C • Position de notre travail • Architecture hétérogènebasé-cluster • Multiple cluster • Contrôleur reconfiguration • Flow de conception • Application • Conclusion et Perspective

26. Réalisation de l’auto-reconfiguration • Transformée en ondelette discrète • une technique utilisée dans la compression de données numériques avec ou sans pertes.(JPEG200) • Le but de l’expérimente • Vérifier la configurabilitéet analyser le contrainte de reconfiguration • Vérifier l’auto-adaptation sous contrôle et analyser • Analyse de fonction critique • Génération de énergie mode

27. Le monde réel --Multiple modes d’énergie • Idée est de créer sous-système pour présenter les différents mode d’énergie. Le sous-système peut être un basé-cluster module. • La choix est dépendant la command de utilisateur ou l’opération sensibilité , comme l’état de batterie, environnent de réseau, etc.

28. L’énergie critique Mode d’énergie : le plus puissance le moyenne le moins puissance T: Performance (qualité & temps de exécution) P: Performance (consommation d’énergie)

29. Estimation de l’application t1 t2 Système en série GPP RGB2YCbCr Le moyen t3 DWT Système parelle Mixé LRM Le Plus Le moins Quantize Système pipeline HW GRM t4 Huffman t5

30. Résultat de l’éstimation de consommation d’énergie (sous xpower) exposition N3 N2 N1

31. Introduction • Besoin de flexibilité • Platform et flexibilité • Solution matérielle reconfigurable • Choose d’architecture • Contribution et positionnement des travaux • exploration en 3C • Position de notre travail • Architecture hétérogènebasé-cluster • Multiple cluster • Contrôleur reconfiguration • Flow de conception • Application • DWT • Experimental result • Conclusion et Perspective

32. Prochaine étape …. • Vérifier le nombre de RPM dans chaque cluster par rapport notre suppose (trois RPM dans chaque cluster) • Test notre proposé avec plusieurs benchmark

33. Perspective • Exploration architecturale hiérarchique • Interface programmable-M2IRE

35. challenge • Identification de tâche • Jugement de topologie puce en temps réel • La création de communication Some basic assumptions: Techniques for constrained code partitioning and hw/sw co-design; Cluster-based structure is enough efficient to represent the flexibility and performance of system.

36. les problème • Réduce le temps de reconfigurable par la méthode de programme, reutilisation de matériel on puce et • Augmente la flexibilité du système par les multiple mode reconfiugrable • Topologie du système est fixé - La densité de système argumente à adapter les plus en plus d’application

37. Organisationhiérarchique Global Local Graph of task Reconfiguration Lib. Lib.Re.module. Lib.Re.inter. • Lib. Reconfiguration • ID_RPM • ID_module(global, local) • ID_interface(global, local) • Priority_Module • Lib. Reconfigurable module & interface (bitstreams ouprogrammation) • Configuration Resource • Configuration Resource RC Global Interface RPM Example of RPM Local module Local Interface

38. Estimation de l’application t1 • Les tâches fixé dans graph de tâche(DAG)– tâche fixé • Les tâches reconfigurable dans DAG – tâche reconfigurable • Les interconnexions • Tâche reconfigurable • Tâche global (t3) • Tâche Local (sub-module de t3) t2 Système en série GPP RGB2YCbCr Le moyen t3 DWT Système parelle Mixé LRM Le Plus Le moins Quantize Système pipeline HW GRM t4 Huffman t5

39. MPSoC Nageldinger 1997 Université de Kaiserlautern Allemagne Positionnement de notre architecture Cible architecture System « on demande » 2004 Enzler 2000 Institut Technologique Fédéral de Suisse E.T.H. Cible architecture configuration configuration coût de reconfiguration App1 coût de reconfiguration famille App2 Topologie du système App3 Capabilité de reconfiguration Capabilité de reconfiguration Cible architecture cluster cluster cluster Cible architecture Multiple reconfiguration mode Basé-cluster Tornado 2007 Algorithme d’ordonnancement de reconfiguration Réduction de la contraint de reconfiguration coût de reconfiguration arrivé C1 départ App1 E1 coût de reconfiguration C2 C1 Capabilité de reconfiguration App2 Capabilité de reconfiguration