View
33
Download
2
Category
Preview:
DESCRIPTION
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). sommaire. - PowerPoint PPT Presentation
Citation preview
Thésard : Xun zhangThèse en deuxième année
Directeur de thèse :Serge WEBERCo-directeur de thèse : Hassan RABAH
Université NancyLaboratoire d’Instrumentation d’Electronique de Nancy (LIEN) 1
sommaireIntroduction
Besoin de flexibilité Platform et flexibilité Solution matérielle reconfigurable
Contribution et positionnement des travaux Architecture hétérogène basé-cluster
Multiple cluster Contrôleur reconfiguration
ApplicationConclusion et Perspective
2
Introduction•Les différent applications ont besoin différent architecture pour le meilleurs performance.
• différent fonction
Besoin de flexibilité ?
•Différent comportements de l’application ont besoin différent architecture • l’état de batterie • command de client• qualité de réseau
Groups d’application
Différent architecture
Différent Traffic Patterns
Tous sont on même
puce!!
3
---Plateforme et flexibilité
•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
Microprocessors ReconfigurableComputing
ASICs
Highest flexibility
Performance?
High flexibility
High performance
Highest performance
Lowest flexibility
ReconfigurableComputing
Héterogeous reconfiguration
IntroductionSolution matérielle dédiée
ASIC 1 ASIC 2 ASIC 3
entrée 1 entrée 2entrée 1 entrée 2entrée 1 entrée 2
Solution logicielle
ALU
Banc de registres
µP
sortie
REGREGREGREG
mémoiresinstructionsdonnées
entrée 1 entrée 2
Solution flexible Solution performante
4
--Solution matérielle reconfigurable
architecture physiquereconfigurable
éléments configurables de calculs et mémoires
réseaux configurables de connexions
architecture logique 1
configuration 1
application 1
configuration
architecture logique 2
configuration 2
application 2
reconfiguration
Introduction
5
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ène basé-cluster Multiple cluster Contrôleur reconfiguration
ApplicationConclusion et Perspective
6
Les problème de design
Cible architecture (la granualité de configuration) Coût d’architecture(surface occupé sur puce) Coût de reconfiguration
Gros grain
LUT LUT LUT
LUT LUT LUT
LUT LUT LUT
LUT LUT LUT
LUT LUT LUT
LUT LUT LUT
LUT LUT LUT
LUT LUT LUT
LUT LUT LUT
LUT LUT LUT
LUT LUT LUT
LUT LUT LUT
C1 E1C2
E2
Reconfiguration sous programme
(ordonnancement en pipeline)
C3
C1E1
C2
Reconfiguration ordonnancement en séquence
E2 Cycle
opération
-positionnement de l’architecture en 3C
Cible architecture
Coût d’architecture
Coût de reconfiguration
7
Critère de l’architecture
Réduction du temps de reconfiguration par la méthode de programme, réutilisation de matériel on puce;
Augmente la flexibilité du système par les multiple modes reconfigurable;
Une topologie de module peut être changeable pour le system adapter facilement l’application correspondant;
Optimisation de nombre de module pour réduire la pression de communication;
8
9
Target architecture
Cible architecture
Coût de reconfiguraiton
Coût d’architecture
IP matériel Mixé GPP
System « on demande »2004
Grain fin(famille)
Reconfiguration on demande
YES NON NON
FiPRe2004
Gros grain(réseau up)
pipeline NON NON YES
Tornado2007
Mixe grain(basé-IP)
Mixé (inter- et intra-tâche)(non interchangeable)
YES YES YES
dyCORE2006
Gros grain et grain fin(famille)
Reconfiguration on demande (module interchangeable)
YES NON YES
1.M. Ullmann, M. Hnbner, B. Grimm, J. Becker, On-demand FPGA run-time system for dynamical reconfiguration withadaptive 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 enableself-reconfigurable applications, Lecture Notes in Computer Science 3203 (2004) 1042–1046.3.Armando Astarloa , et al. Tornado: A self-reconfiguration control system for core-based multiprocessor CSoPCs, Journal of Systems Architecture 53 (2007) 629–6434. 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)
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.
10
Introduction Besoin de flexibilité Platform et flexibilité Solution matérielle reconfigurable Choose d’architecture
Contribution et positionnement des travaux explosion en 3C Position de notre travail
Modélisation de l’Architecture hétérogène basé-cluster Modélisation hiérarchique Méthode exposition architecturale Les Éléments du système Estimation de l’application Organisation architecturale Flow de exploration architecturale
ApplicationConclusion et Perspective
11
SoPC auto-adaptif
• multiple module fonctionnelle et reconfigurable (en vue d’architecture)• GPP• DSP• IP matériel • IP reconfigurable
• SoPC architecture : Centric Architecture
• partition matériel et logiciel(en vue de fonction) •Tâche matériel•Tâche logiciel•Programme de configuration
12
L’idée actor
Global task
Local task
Lib.ProC
Lib.ProC
node Global Reconfigurable module
Local Reconfigurable Module HWHW
Application
Système opérationSystème opération
NoC Lib.Con
f.Lib.Con
f.Cluster
(HW platform
)
Cluster(HW
platform)
ClusterCluster ClusterCluster
1. Structure basé-cluster (scalabilité et extension du système) 2. Architecture hiérarchique( cluster -> RPM) (reconfiguration efficace)3. Topologie de cluster est flexibilité ( adaptation de l’application ou comportement
de l’application)
13
Modélisation possible d’architecture
Utilisation d’une vue fonctionnelle de l’architecture
les ressources sont décrites par les fonctions qu’elles réalisent.
Basé-cluster: (ID_cluster) Module Reconfigurable Partial (RPM): (ID_RPM) Interface hiérarque(Interface cluster-cluster, Interface
RPM-RPM)
Les éléments hiérarchiques: sont utilisés pour modéliser le routage et les ressources de traitements
•ID et nom de module •ID de l’interface
•ID et nom de fonction•Nombre et type de RPM
14
Les éléments hiérarchiques
N1
N2
N3
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
15
Méthode de exposition architectural
exposition
N1
N2
N3
Stratégie:Prospecter la nécessité d’adaptation de l’application en rapprochant hiérarchiquement les RPM avec les différentes critères de l’application;
Les critères de projection architectural•Complexité de calcul •Temps d’exécution•Consommation d’énergie•Consommation de communication(accès mémoire)
Solution moyennePlus de souplesse
Plus de performance
16
Organisation architectural de ressource
•Lib. Reconfiguration(DBRC)•ID_RPM•ID_module(global, local)•ID_interface(global, local)•Priority_Module
•Lib. Reconfigurable module & interface (bitstreams ou programmation)(DBMS & DBMR)•Resource Configuration
Graph of task
17
Flot d’exploration architecturale
Choix des fonctions critiques
Organisation architecturale
Choix d’une architecture
Estimation de l’architecture
communications & taux d’utilisation
F6F5
F4F3
F2
F1
Spécification DAG desfonctions de l’application
ESTIMATION de l’application
Fonctions critiques
de l’application
Architecture
Modélisée(DBRC)
n°1
Spécification des
architectures
Architecture choisie
18
Flot de reconfiguration partial
Architecture hétérogène basé-clustermulti-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 RPMIdentify type of RPM organisation de chaque RPM faire allocation ordonnancement
I/O
DBMS &
DBMR
RC
19
RPM
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;
Accèss vitess, flexibilité, énergie d’accèss
Densité de cellule
20
Minimum version:Intermédiaire version:Maximum version:
Règle :
Interface hiérachique Inter-module and Intra-module communication models support
Cluster-Cluster RPM-RPM
Contrôleurreconfiguratio
n
Interface section
Cluster
Standard busBus dock
ISM
ISM: Interface of Sub-Module
Mémoir
Interface section
Cluster
Description de Interface section 21
Interface programmable(M2IRE)
switch
DMA/mémoire externe
GRMLRMGPP
Mémoire &contrôle registre
Mémoire &contrôle registre
Mémoire &contrôle registre
Contextemanager
Contrôleurreconfigurati
on
context1
contex2
context3
Hardware bitstreams
Routage d’entré et sortie
Programme logicielleSection interface
Description de contrôleur reconfiguration
Multiple-Mode Interface for Reconfigurable Element
22
Contrôleur reconfiguration
External system
RC
Info._config.
en_info.
Ack_Reconf.
Activating RPM
answer of RPM
Environment Cluster
Reconfiguration library
bitrstreams library
Quel RPM?Quelle model de RPM?Est-ce que tous les RPM?Quand?
Identifier RPMIdentifier le type de RPM Identifier la reconfiguration mode L’allocation ordonnancement (mapping –schaduling )
non-prehentif (handshake) prehentif
23
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
24
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ène basé-cluster Multiple cluster Contrôleur reconfiguration
Flow de conception ApplicationConclusion et Perspective
25
Transformée en ondelette discrète une technique utilisée dans la compression de
données numériques avec ou sans pertes.(JPEG200)
Réalisation de l’auto-reconfiguration
Analyse de fonction critique
26
Le monde réel --Multiple modes d’énergieIdé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.
27
L’énergie critique P
: P
erfo
rman
ce (
qu
alit
é &
tem
ps
de
exéc
uti
on
)
C: consommation d’énergie
Mode d’énergie : le plus puissance le moyenne le moins puissance
28
RGB2YCbCr
DWT
Quantize
Huffman
Estimation de l’application
t1
t2
t4
t5
t3Le Plus
Le
moyen
Le moins
Système en sérieGPP
Système parelle
Mixé LRM
Système pipeline
HW GRM
29
Résultat de l’éstimation de consommation d’énergie (sous xpower)
exposition
N1N2
N3
30
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ène basé-cluster Multiple cluster Contrôleur reconfiguration
Flow de conception Application
DWT Experimental result
Conclusion et Perspective
31
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
32
Perspective Exploration architecturale hiérarchique Interface programmable-M2IRE
33
34
challengeIdentification de tâcheJugement de topologie puce en temps réelLa 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.
35
les problème
1. Topologie du système est fixé - La densité de système argumente à adapter les plus en plus d’application
1. Réduce le temps de reconfigurable par la méthode de programme, reutilisation de matériel on puce et
1. Augmente la flexibilité du système par les multiple mode reconfiugrable
36
Organisation hiérarchique
Global
Local
•Lib. Reconfiguration•ID_RPM•ID_module(global, local)•ID_interface(global, local)•Priority_Module
•Lib. Reconfigurable module & interface (bitstreams ou programmation)
•Configuration Resource •Configuration Resource
Lib.Re.module. Lib.Re.inter.
RC
Reconfiguration Lib.
Global Interface
Local Interface
RPM
Local module Example of RPM
Graph of task
37
RGB2YCbCr
DWT
Quantize
Huffman
Estimation de l’application 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)
t1
t2
t4
t5
t3 Le Plus
Le
moyen
Le moins
Système en sérieGPP
Système parelle
Mixé LRM
Système pipeline
HW GRM
38
System « on demande » 2004 Enzler 2000 Institut Technologique Fédéral de Suisse E.T.H.
MPSoC Nageldinger 1997 Université de Kaiserlautern Allemagne
Algorithme d’ordonnancement de reconfigurationRéduction de la contraint de reconfiguration
C1
C1
C2
cluster
famille
Topologie du
système
App1
App2
App3
E1
configuration configuration
Positionnement de notre architecture
départ
arrivé
clustercluster
Multiple reconfiguration modeBasé-cluster Tornado 2007
Cible architecture
Capabilité de reconfiguration
coût de reconfiguration
Cible architecture
coût de reconfiguration
Capabilité de reconfiguration
Capabilité de reconfiguration
Cible architecture
coût de reconfiguration
coût de reconfiguration
Cible architecture
Capabilité de reconfiguration39
Recommended