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

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


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


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



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


Contribution et positionnement des travaux exploision en 3C Position de notre travail


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


Contribution et positionnement des travaux exploration en 3C Position de notre travail


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




Cible architecture



Cible architecture

Capabilité de reconfiguration39

Documents

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