Thèse

REPUBLIQUE
ALGERIENNE
DEMOCRATIQUE
ET POPULAIRE
Universit
e dOran-Es-Senia
Facult
e des Sciences
D
epartement dInformatique
Ordonnancement Hi
erarchique
Multi-Objectif DApplication
Embarqu
ees Intensives
`
THESE
presente et soutenu publiquement le
pour lobtention du
Dipl
ome De Doctorat DEtat
(CAO/IAO&Simulation)
par
BENYAMINA Abou Elhassen
Encadreur : Mr B.BELJILALI.
Mr P.BOULET
Devant les membres du jury

President :
Mr. K.RAHMOUNI
Examinateurs :
Mr. M.BENYETTOU
Mr. B.YAGOUBI
Promotion 2008-2009
Table des mati`

eres
Table des figures
vi
Liste des tableaux
Introduction g
en
erale
Chapitre 1
Introduction aux syst`
emes embarqu
es
1.1
Motivation et objectifs des systèmes embarques
. . . . . . . . . . . . . . . . . .
10
1.1.1
Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.1.2
Les types de systèmes embarques
. . . . . . . . . . . . . . . . . . . . . .
10
1.1.3
Caracteristiques principales dun système embarque . . . . . . . . . . . .
11
1.2
Informatique embarquee
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.3
Les differentes architectures des differents systèmes embarques . . . . . . . . . .
14
1.3.1
Mono-puce ( SOC)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
1.3.2
Les multiprocesseurs on SOC (MPSOC) . . . . . . . . . . . . . . . . . . .
16
1.3.3
Les NOC (Network On Chip) . . . . . . . . . . . . . . . . . . . . . . . . .
18
1.3.4
Architecture regulière à base de tableau de processeurs identiques . . . .
19
Linterconnexion dans les SOC . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
1.4.1
Du SOC au NOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
1.4.2
Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
1.4.3
Le Bus centralise ou partage : . . . . . . . . . . . . . . . . . . . . . . . . .
23
1.4.4
Les reseaux en etoile et en anneau : . . . . . . . . . . . . . . . . . . . . .
25
1.4.5
Les reseaux Crossbar
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
1.4.6
Les reseaux commutes ou à maille : . . . . . . . . . . . . . . . . . . . . . .
25
1.4
Chapitre 2
Flots de conception dans les SOC
2.1
La notion de modèle
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
30
2.2
2.3
2.4
2.5
2.6
LIngenierie Dirigee par les Modèles (IDM)
. . . . . . . . . . . . . . . . . . . .
31
Model Driven Architecture MDA . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
2.3.1
Modelisation UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
2.3.2
Extensibilite dUML : la notion de profil . . . . . . . . . . . . . . . . . . .
34
GASPARD : Flot de conception pour les SOC . . . . . . . . . . . . . . . . . . . .
37
2.4.1
Modelisation des applications DSP . . . . . . . . . . . . . . . . . . . . . .
39
2.4.2
Principe de modelisation dans Gaspard2 . . . . . . . . . . . . . . . . . . .
40
2.4.3
Nud Direct Acyclique : . . . . . . . . . . . . . . . . . . . . . . . . .
41
2.4.4
Nud r
ep
etitif : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
Lenvironnement GASPARD 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
2.5.1
Le paquetage Component . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
2.5.2
Le paquetage factorisation . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
2.5.3
Paquetage Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
2.5.4
Le paquetage HardwareArchitecture . . . . . . . . . . . . . . . . . . . . .
50
2.5.5
Le paquetage association . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
Chapitre 3
Calcul intensif et applications DSP
3.1
Calcul intensif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
3.2
Exemples dapplications (hautement regulières) . . . . . . . . . . . . . . . . . . .
56
3.3
Exemples dapplication DSP à t

aches irregulières . . . . . . . . . . . . . . . . . .
57
3.4
Specification multidimensionnelle et modèles de calcul pour le TSI . . . . . . . .
58
3.4.1
MATLAB/SIMULINK . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
3.4.2
ALPHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
3.4.3
MDSDF : Multidimensional Synchronous Dataflox . . . . . . . . . . . . .
61
3.4.4
ARRAY-OL (Array Oriented Language) . . . . . . . . . . . . . . . . . . .
63
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
3.5
Chapitre 4
Placement et Ordonnancement (ou AAS)
4.1
Objectifs de conception des NoC . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
4.2
Problematique du placement et ordonnancement . . . . . . . . . . . . . . . . . .
73
4.2.1
Le modèle darchitecture et le modèle dapplication . . . . . . . . . . . . .
73
4.2.2
Problèmes et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
Etat de lart des approches existantes . . . . . . . . . . . . . . . . . . . . . . . .
77
4.3.1
77
4.3
Approches pour les NoC . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ii
4.3.2
4.4
4.5
Approches pour les systèmes embarques multiprocesseur (MPES ou MPSoC) 85
Comparaison entre les techniques de placement et dordonnancement . . . . . . .
91
4.4.1
Verification des contraintes de temps reel . . . . . . . . . . . . . . . . . .
91
4.4.2
La minimisation de la consommation denergie . . . . . . . . . . . . . . .
95
4.4.3
Contraintes materielles et memoire . . . . . . . . . . . . . . . . . . . . . .
97
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
Chapitre 5
Optimisation multi-objectif
5.1
Loptimisation combinatoire
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2
Loptimisation combinatoire multi-objectif . . . . . . . . . . . . . . . . . . . . . . 101

5.2.1
Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.2.2
Les solutions dun problème multi-objectif . . . . . . . . . . . . . . . . . . 101
5.2.3
Caracteristique du front Pareto . . . . . . . . . . . . . . . . . . . . . . . . 103
5.2.4
Choix de la methode daide à la decision . . . . . . . . . . . . . . . . . . . 104
5.3
Problèmes doptimisation multi-objectif . . . . . . . . . . . . . . . . . . . . . . . 105
5.4
Classification des methodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.5
Approches de resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

5.5.1
5.6
Les methodes bi-objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Chapitre 6
Contribution
6.1
Modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.2
Formulation mathematique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.3
Première phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.4
Seconde phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
6.5
Algorithmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.6
Mapping des taches repetitives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.7
Routage et optimisation des communications . . . . . . . . . . . . . . . . . . . . 130

6.7.1
6.8
Generation de chemin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.7.2
Problème de generation du chemin
. . . . . . . . . . . . . . . . . . . . . 133
6.7.3
Routage statique des paquets . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.7.4
Problème du routage des paquets . . . . . . . . . . . . . . . . . . . . . . 135
6.7.5
Temps dexecution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
mapping Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

6.8.1
Demarche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
iii
6.9
Le choix dune methode à base de GA pour le placement irregulier . . . . . . . . 137

6.9.1
paramètres de lalgorithme genetique . . . . . . . . . . . . . . . . . . . . . 137
6.9.2
Choix des operateurs genetiques . . . . . . . . . . . . . . . . . . . . . . . 139
6.9.3
Transformation de la fonction objectif en fonction Fitness . . . . . . . . . 140
6.9.4
Fonction devaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.9.5
Formalisation du problème de placement : . . . . . . . . . . . . . . . . . . 142
6.9.6
Bande passante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.9.7
M
emoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
6.9.8
File dattente
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
6.10 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Chapitre 7
Mise en uvre et validation
7.1
Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
7.2
Specification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
7.3
Choix du language de programmation . . . . . . . . . . . . . . . . . . . . . . . . 146
7.4
Justification du choix de la methode pour le placement irregulier de grande taille 147
7.5
Description du logiciel (Aspect general) . . . . . . . . . . . . . . . . . . . . . . . 148
7.6
Presentation des organigrammes du logiciel . . . . . . . . . . . . . . . . . . . . . 149

7.6.1
Organigramme representant les principales etapes du logiciel . . . . . . . 149
7.6.2
Organigramme representant le fonctionnement de lalgorithme genetique

(A.G) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
7.6.3
Organigramme representant le processus devaluation des individus dune

population . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
7.6.4
7.7
7.8
Experimentations pour determiner les valeurs des paramètres de lalgorithme . . 151

7.7.1
Evolution du temps dexecution en fonction de la taille du problème . . . 151
7.7.2
Effet du nombre de generations . . . . . . . . . . . . . . . . . . . . . . . . 152
7.7.3
Effet de la population . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
7.7.4
Influence de la probabilite de croisement
7.7.5
Influence de la probabilite de mutation . . . . . . . . . . . . . . . . . . . . 154
7.7.6
Influence de larchitecture sur le co

ut
7.7.7
Mapping multiobjectif dune application reel . . . . . . . . . . . . . . . . 155
. . . . . . . . . . . . . . . . . . 153
. . . . . . . . . . . . . . . . . . . . 154
Lalgorithme exact pour les applications DSP (LR) . . . . . . . . . . . . . . . . . 160

7.8.1
7.9
Diagramme de classe de lapplication pour Le GI à base du genetique . . 151
Resultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
La methode pour le hierarchique (ou le GILR) . . . . . . . . . . . . . . . . . . . 163

7.9.1
Descriptif de lapplication . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

iv
7.9.2
Etude de cas et validation experimentale . . . . . . . . . . . . . . . . . . . 164
7.9.3
Application encodeur H.263 sur MPSoC . . . . . . . . . . . . . . . . . . . 164
7.9.4
Architecture materielle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
7.10 conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Conclusion g
en
erale et perspectives
Bibliographie
Table des figures

1.1
1.2
1.3
1.4
1.5
. . . . . .
. . . . . .
. . . . . .
. . . . . .
la maille
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
11
12
15
16
Architecture en 4 couches employee par IDM . . . . . . . . . . . . . . . . . . . .

Classification des 13 diagrammes du langage UML . . . . . . . . . . . . . . . . .
Specialisation dUML par le mecanisme de profil . . . . . . . . . . . . . . . . . .
Exemple de metamodèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple de profile pour le meta-modèle de lexemple de la figure precedente . . .
Flot de conception en Y de GASPARD 2 . . . . . . . . . . . . . . . . . . . . . .
Vue densemble des differents paquetages constituants le profil Gaspard . . . . .
Un exemple de composant gaspard, processing Unit compose de trois sous composants instancies sous les noms cb, mem et mips. Les ports et les connecteurs
indiquent les relations entre les instances . . . . . . . . . . . . . . . . . . . . . . .
2.9 Representation dun composant Gaspard2 avec une multiplicite bidimensionnelle
(sur la gauche) et son equivalent en UML2 (sur la droite) . . . . . . . . . . . . .
2.10 Illustration de la notion de Tiler . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.11 Un exemple de Reshape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.12 Reshape exprime à laide dune t
ache fant
ome . . . . . . . . . . . . . . . . . . . .
32
34
35
36
36
38
43
1.6
1.7
1.8
1.9
1.10
1.11
1.12
1.13
1.14
1.15
La loi de Gordon Moore . . . . . . . . . . . . . . . . . . . . . . .

Système embarque typique . . . . . . . . . . . . . . . . . . . . . .
Un exemple de système mono-puce (SOC) . . . . . . . . . . . . .
Un exemple darchitecture monoprocesseur (p/co-processeurs) .
Un NOC de structure de maille avec 9 nuds o`
u chaque noeud
contient un commutateur et une ressource. . . . . . . . . . . . .
trois types dinterconnexions utilisees dans les MPSOC . . . . .
Liaison point à point. . . . . . . . . . . . . . . . . . . . . . . . .
Anneau simple . . . . . . . . . . . . . . . . . . . . . . . . . . . .
maille complètement connecte . . . . . . . . . . . . . . . . . . .
Crossbar complet . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bus centralise . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anneau decouple & Bus Etoile

. . . . . . . . . . . . . . . . . . .
Interconnexions totales . . . . . . . . . . . . . . . . . . . . . . . .
Topologie hybride bus . . . . . . . . . . . . . . . . . . . . . . . .
Liaison des nuds à des commutateurs . . . . . . . . . . . . . . .
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
vi
. . .
. . .
. . .
. . .
dans
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
19
21
22
22
23
24
24
25
26
26
26
44
45
46
47
47
2.13 Illustration des liens Inter -Repetition, à gauche le composant Gaspard representant une grille à droite son equivalent en UML . . . . . . . . . . . . . . . . . . .
2.14 Exemple dune tache composee dans Gaspard, elle est constituee de 4 sous t
aches,
p, c1 , c2 et a. La tache a possède deux dependances sur c1 et c2 , possedant ellememe chacune une dependance sur p. Les t
aches c1 et c2 peuvent etre executee
en parallèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.15 Parallelisme de donnees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.16 Un exemple de composant gaspard, processing Unit compose de trois sous composants instancies sous les noms cb, mem et mips correspondant respectivement
a un crossbar, une memoire et un processeur . . . . . . . . . . . . . . . . . . . .
`
2.17 Composant materiel Gaspard representant une grille de 16 unites de calcul reparties sur deux dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.18 Allocation de la tache appli sur le processeur proc . . . . . . . . . . . . . . . . .
2.19 ADistribution dune tache repetee sur une grille de 4x4 unites de calcul . . . . .
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
4.1
4.2
4.3
4.4
48
50
51
51
52
53
53
Positionnement du TSS dans le domaine TS. . . . . . . . . . . . . . . . . . . . .

Representation de lapplication Radar anti-collision. La phase du traitement du
signal systematique precède celle du traitement de donnees intensif. . . . . . . . .
Phases dun Transcoder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Application CSLC (Coherent Side Love Cancellation). . . . . . . . . . . . . . . .
Exemple dun graphe dune application en SDF. . . . . . . . . . . . . . . . . . .
Exemple dun graphe dune application en MDSDF. . . . . . . . . . . . . . . . .
Une application MDSDF non representable en SDF. . . . . . . . . . . . . . . . .
Exemple de composant : reduction à partir dune haute definition vers une definition TV standard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modèle global. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Un exemple du modèle local en Array-ol. . . . . . . . . . . . . . . . . . . . . . .
Exemple de repetition dans un filtre horizontal. . . . . . . . . . . . . . . . . . . .
Un exemple simple dajustage des elements dun tableau par leurs indexes dans
le motif (i), illustrant la formule i, 0 i < Spattern , ei = ref + F xi. . . . . . . .
Un exemple complexe dajustage illustrant la relation i, 0 i < Spattern , ei =
(ref + F xi)modSarray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple de pavage illustrant la formule ; r, 0 r < Srepetition , ref r = (0 +
P xr)modSarray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple dun produit de matrices . . . . . . . . . . . . . . . . . . . . . . . . . . .
Quelques repetitions du filtre horizontal pour illustrer les dependances entre les
entrees/sorties dune repetition. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
Illustration dun problème de placement et ordonnancement

: Scheduling de TGs sur une platefome NoC . . . . . . . .
: Methogologie de G.Varatkar et al. . . . . . . . . . . . . .
: La methodologie de Lei et al. . . . . . . . . . . . . . . . .
74
74
78
79
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
56
58
58
61
62
62
65
66
67
68
68
68
69
69
70
vii
4.5
4.6
4.7
: Methodologie de J.Hu et al . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
: Methodologie de D.Shin et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
: Exemple de placement du CTG sur le NOC. Les lignes flechees dans le NOC
representent les chemins de communications reservees par lalgorithme de placement.
4.8 : Methodologie de M.T.Schmitz et al. . . . . . . . . . . . . . . . . . . . . . . . .
4.9 : Methodologie de F.Gruain et al. . . . . . . . . . . . . . . . . . . . . . . . . . .
4.10 : Methodologie de L.A.Cortes et al. . . . . . . . . . . . . . . . . . . . . . . . . .
4.11 : R.Szymanek et al.Methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
79
81
83
86
87
87
89
101
102
102
103
104
104
105
105
107
108
109
5.13
5.14
5.15
5.16
Exemple de problème doptimisation combinatoire multi-objectif . . . . . . . . .

Notion de dominance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple de front Pareto optimale . . . . . . . . . . . . . . . . . . . . . . . . . .
Points particulier de front de Pareto . . . . . . . . . . . . . . . . . . . . . . . . .
Front Pareto concave/convexe . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple de front Pareto Bi-objectif . . . . . . . . . . . . . . . . . . . . . . . . .
Approche interactive : cooperation progressive entre le solveur et le decideur . . .
Optimum Pareto local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Classification des methodes doptimisation multi-objectif . . . . . . . . . . . . . .
Exemple de recherche lixicographique . . . . . . . . . . . . . . . . . . . . . . . .
Direction de recherche (Gauche) , et Nouvelles recherches (Droite) . . . . . . . .
Recherche entre le point Ideal et le point Nadir (Gauche), et Division en deux
sous recherches (Droite) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple de recherche pour la Methode des e-contraintes . . . . . . . . . . . . . .
Nouvelle recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Methode des e-contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
La methode deux phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
Exemple de problème doptimisation combinatoiremulti-objectif .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple de problème doptimisation combinatoire multi-objectif
Illustre lapplication detection de contour . . . . . . . . . . . . .
modèle darchitecture regulière . . . . . . . . . . . . . . . . . . .
Illustre lapplication detection de contour . . . . . . . . . . . . .
Repetition de motifs pour generer lordonnancement de N t
aches
Exemple de problème doptimisation combinatoire multi-objectif
114
114
115
115
115
121
121
123
124
124
124
125
7.1
7.2
Les principales etapes de letude . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Fonctionnement de lalgorithme genetique. . . . . . . . . . . . . . . . . . . . . . . 150
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
110
111
111
111
111
viii
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
7.11
7.12
7.13
7.14
7.15
7.16
7.17
7.18
7.19
7.20
7.21
7.22
7.23
7.24
7.25
7.26
7.27
7.28
7.29
7.30
7.31
7.32
Evaluation dun individu appartenant à une population. . . . . . . . . . . . . . . 150

Evolution de la fitnesse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Influence de la taille du problème sur le temps dexecution. . . . . . . . . . . . . 152
Evolution des solutions en fonctions du nombre de generations. . . . . . . . . . . 152
Suivi dune population de 10 chromosomes. . . . . . . . . . . . . . . . . . . . . . 152
Suivi dune population de 60 chromosomes. . . . . . . . . . . . . . . . . . . . . . 153
Influence des probabilites de croisement . . . . . . . . . . . . . . . . . . . . . . . 153
Influence des probabilites de mutation . . . . . . . . . . . . . . . . . . . . . . . . 154
Influence de larchitecture sur le temps de recherche . . . . . . . . . . . . . . . . 154
Diagramme de bloc de lapplication . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Le graphe de tache de lapplication figure 7.12 . . . . . . . . . . . . . . . . . . . . 155
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
explicitant le placement et lordonnancement des differentes t
aches . . . . . . . . 156
Front Pareto des solutions de ce problème . . . . . . . . . . . . . . . . . . . . . . 159
Recherche du meilleur motif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Recherche du meilleur motif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
la fenetre principale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Saisie dun graphe hierarchique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
saisie dune architecture hierarchique . . . . . . . . . . . . . . . . . . . . . . . . . 164
saisie dune architecture hierarchique . . . . . . . . . . . . . . . . . . . . . . . . . 164
Vue principale de limplementation de lencodeur H.263 en mode Gaspard. . . . . 166
Vue partielle du tableau des elements de chrominance. Chaque lecteur de motif
correspond à une tuile compacte de 8x8 elements du tableau. Ici sont representes
les elements lus pour trois repetitions de t
ache differentes. . . . . . . . . . . . . . 166
vue du deploiement des taches elementaires Quan2Block et QCIFReader. En bas
a droite est presente le type des donnees traitees par les fonctions : unsigned char.167
`
Vue principale de larchitecture materielle du MPSoC en modèle Gaspard . . . . 169
: Vue du deploiement des composants Cache et MIPS . . . . . . . . . . . . . . . 169
Graphe de tache hierarchique de lencodeur H.263 . . . . . . . . . . . . . . . . . 169
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
evolution des temps de recherche du GILR en fonction de la taille des application
et du nombre de niveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
ix
Liste des tableaux

4.1
4.2
4.3
4.4
4.5
4.6
4.7
Methodologies pour les NOC . . . . . . . . . . . .

Objectifs specifies pour les NOC . . . . . . . . . .
Methodologies pour MPSOC à base de Bus . . . .
Les objectifs des MPSOC à bus . . . . . . . . . . .
Les delais de communication dans les NOC . . . .
Delais de traitement dans les NOC . . . . . . . . .
Placement de taches avec optimisation de lenergie
6.1
Tableau 2 : Implementation de lalgorithme de Dijkstra avec des structures de

donnees differentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Complexite des algorithmes de routage direct . . . . . . . . . . . . . . . . . . . . 136
6.2
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Sommaire des resultats comparatifs obtenus par recuit simule et AG . . . . .

matrice des communications inter-t
aches . . . . . . . . . . . . . . . . . . . . .
matrcice des carateristiques de la machine . . . . . . . . . . . . . . . . . . . .
Les tailles des taches selon le type du processeur . . . . . . . . . . . . . . . .
Les meilleurs placements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Placement et ordonnancement . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resultats comparatifs entre notre approche, Syndex et Menna . . . . . . . . .
R : Les evolutions des temps de recherche selon les tailles des applications et
nombre de niveaux du HTG . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
. .
. .
. .
. .
. .
le
. .
84
84
90
90
93
93
96
147
155
157
157
158
162
162
170
Remerciements
C e document reflète laboutissement de plusieurs annees de travaux de thèse entames entre
les universites dORAN et Lille1. Ce resultat nest quune etape dans le processus de recherche
quon a reellement lance depuis trois ans avec P.BOULET et B.Beljilali dans lequipe DaRT de
Lille. Mon plus grand espoir est que les propositions presentees ici pourront etre utiles en se
servant de base à nos futur travaux et à dautres propositions scientifiques plus avancees.
Je tiens à remercier vivement le professeur P.BOULET de mavoir fait confiance et de mavoir
encadre dans ce thème. Sa generosite scientifique et sa disponibilite pour la recherche mont
permis davancer dans mes travaux et de surmonter avec lui toutes les difficultes.
Mes remerciements vont aussi à B.Bouziane qui na jamais cesse de croire en moi. Merci à ses
encouragements, ses conseils judicieux et son aide dans la redaction de ce manuscrit.
Merci au professeur K.Rahmouni qui nous a fait lhonneur daccepter de presider le jury de
soutenance.
Merci aux professeurs B.Yagoubi et M.Benyattou davoir accepte dexaminer ce travail.
Je tiens à exprimer ma profonde gratitude à lequipe DaRT/West de lINRIA futur et de son
directeur Jean-Luc DEKEYSER, qui avec P.BOULET mont accueilli au sein de leur equipe en
mettant à ma disposition tous les moyens de lequipe. Sans le financement quils mont accorde,
pour mes travaux et conferences, il maurait ete très difficile de finaliser ma thèse.
Un grand merci pour mes collègues de DaRT, en particulier les permanents P.Marquet, Sami,
Anne, Abdoulaye, Cedric, Fred ainsi que tous les autres thesards et stagiaires.
A la memoire de mon père

A ma mère qui nous a toujours encourage
A ma femme qui a souffert de mes absences et qui a assume toutes mes
responsabilite durant mes absences pour atteindre cet objectif
A mes enfants Amina, Fadia et mohamed toufik
Introduction g
en
erale
Context
Au debut des annees 70, lhumanite a pris connaissance de la conception par Marcian Hoff
du premier microprocesseur commercial Intel 4004. Meme si depuis de nombreuses technologies
ont ete proposees, les microprocesseurs reposent presque tous sur le meme principe dexecution
dit Von Newman. La complexite de ces dispositifs est passee de 2250 transistors, pour lIntel
4004, à des centaines de milliers pour les microprocesseurs actuels. La puissance de traitement
elle, a augmente pendant la meme periode de 6000 instructions executees par seconde à plusieurs
milliards pour les processeurs les plus performants. Cette evolution rapide de la technologie informatique represente lun des plus importants phenomènes techniques depuis plusieurs decennies.
Cest elle qui a declenche cette course, que nous vivons maintenant, à la miniaturisation de tout
appareil electronique.
Lexemple le plus illustrant de ce phenomène est la telephonie mobile. Les premiers systèmes
offrant le service de telephonie mobile ont ete introduits au debut des annees cinquante. A cette
epoque ils etaient souvent assez gros et avaient une antenne assez importante. Ils etaient limites
par une mobilite assez restreinte, une capacite basse, un service reduit et une mauvaise qualite
du son en plus de leur prix qui etait souvent très eleve. Actuellement, le monde, avec la revolution numerique, est transforme par la creation des telephones mobiles numeriques plus petits,
plus legers et plus performants. Ces telephones sont egalement, de plus en plus multimedia et
fournissent une meilleure qualite et un grand nombre de service. Ce qui a permis leur utilisation dans des domaines très varies : pour passer des appels bien s
ur, pour prendre des photos,
pour ecouter la musique, et meme pour visualiser des videos. De plus, de nos jours, ils offrent
des fonctions de traitement dimages impressionnantes qui demandent des puissances de calcul
similaire à celle des ordinateurs.
Ce rythme devolution effrene provient des avances technologiques des circuits integres et de
leurs architectures qui ont permis de developper des systèmes informatiques plus petits, plus
compacts et plus rapides, grace en grande partie à la capacite dintegration de plus en plus elevee. Un type de ces systèmes qui a profite largement de cette evolution est le système embarque.
Les techniques de conception de ces systèmes permettent maintenant de regrouper des systèmes
heterogènes sur la meme puce electronique, donnant ainsi naissance à un nouveau paradigme
dans les systèmes embarques : les systèmes sur puce (SoC : System on Chip).
De part leur forte capacite dintegration, les SoCs offrent des grandes economies en consommation denergie et en espace ainsi quun gain important en performance. Du fait de ces avantages,
les SoCs sont donc souvent integres dans des systèmes embarques afin de remplacer certaines
ressources informatiques. Mais on ne peut pas parler uniquement davantage sans citer des inconvenients, dont le plus important est la complexite de leur conception. Le risque que le produit
final ne corresponde pas à la specification et les delais de production qui les rend obsolètes avant
meme leur mise sur le marche, sans oublier la demande toujours croissante en puissance de calcul
complique enormement leur conception.
Cet inconvenient, qui est de taille, ne devait pas freiner les industriels et les chercheurs. Ils
doivent suivre cette revolution technologique au prix denormes efforts en recherche et develop4
pement. Cest dans cette optique que plusieurs equipes de chercheur se sont constituees afin de
proposer une methodologie de conception et de developpement facile de ces systèmes. Le projet
INRIA DaRT en fait partie. Cest dans ce projet que notre travail, quon presentera par la suite,
sinscrit. Lun des principaux objectifs de cette equipe est la mise en uvre dune methodologie et
dun environnement de developpement pour les systèmes sur puce à hautes performances. Cestà-dire, un cadre unifie pour le developpement de ces systèmes en partant de leur modelisation
au plus haut niveau dabstraction jusqu`
a la generalisation du code.
DaRT vise comme domaine dapplication le traitement systematique à parallelisme massif
dont la caracteristique principale est quil effectue une grande quantite de calculs reguliers sur des
donnees multidimensionnelles. Les applications de ce domaine opèrent dans des conditions temps
reel, elles sont generalement critiques et presentent un degre eleve de parallelisme de donnees de
calcul. Le projet DaRT a donc pour objectif de fournir un environnement de developpement pour
ces applications de traitement parallèles en se basant sur le modèle de specification ARRAY-OL.
P robl
ematique
Comme on la presente auparavant, notre travail sinscrit dans le cadre dun projet global supporte par toute lequipe DaRT de lINRIA. Ce projet consiste à realiser un flot de conception
et de developpement de SoC. Ce flot de conception est connu sous le nom GASPARD2 et qui
fait partie des methodes classiques en Y pour les SoC. Dans ce flot de conception la phase de
placement (mapping) ou association application/materielle constitue une etape très importante,
car elle participe dune facon critique dans latteinte des objectifs arretes lors de la specification
du SoC.
Ce mapping a une particularite, dans ce contexte, car il ne sagit pas uniquement dun placement classique quon a lhabitude de rencontrer dans les systèmes parallèles mais il englobe trois
phases : Assignation, Affectation et Scheduling (AAS). De plus, du fait que Gaspard2 vise à
traiter aussi des applications de traitement intensif, on est amene à prendre en considerations
dans le mapping la nature repetitive de certaines taches qui traitent des donnees multidimensionnelles.
Ce dernier problème nous permet de caracteriser le placement par deux categories : le placement
des calculs (taches) et le placement de donnees. Le premier type de placement nous permet de
trouver sur quel processeur doit sexecuter quelle t
ache et à quel moment. Le deuxième type
de placement doit determiner un accès efficace et rapide aux donnees avec si cest possible des
chemins daccès le plus court possible en prenant en consideration les caracteristiques de la topologie cible telle la bande passante.
Donc on ne peut faire un bon placement si on ne prend pas en consideration tous les aspects
o`
u on a des taches qui ne sont pas repetitives et dautres qui le sont. Ce type de placement ou
mapping est connu comme etant un placement GILR (Globally Irregular Locally Regular), il
consiste à exploiter le parallelisme de t
aches et de donnees dans une architecture multiproces-
seurs [11,166]. Les benefices et utilites des GILR ont ete prouve dans [39,167] et bien entendu
dans [17] pour les deux types darchitectures heterogènes et homogène.
Adopter directement des solutions proposees dans les systèmes distribues classiques nest pas
conseille pour les architectures MPSoC. Ces dernières sont globalement heterogènes et ont
quelques elements reguliers homogènes (Tableau de PE. Ce qui doit nous amener à extraire
les parties regulières et irregulières de darchitecture pour exploiter au maximum la correspondance dans lapplication. Le graphe suivant illustre un GILR o`
u les couleurs representent les
etapes suivies.
En generalisant cet exemple par une modelisation graphique on obtiendra des graphes hierarchiques. Et là on parlera dun placement hierarchique multi-niveaux, o`
u les nuds peuvent
etre de trois types : elementaire, compose ou repetitif. Donc un placement GILR nous amène
à trouver le meilleur mapping dun graphe hierarchique de lapplication (HTG) sur le graphe
hierarchique de larchitecture.
Contribution
Afin de traiter le problème dans sa globalite (GILR) on la decompose en sous problèmes complementaires :
1. Pour le mapping des taches irregulières sur larchitecture correspondante on a propose un
algorithme hybride. Ce dernier cherche loptimisation multi-objectif du placement dun
DAG application sur un DAG architecture. En effet, pour prendre en consideration les
specificites et les exigences des SoCs(NoC), on ne cherche pas la meilleure solutions selon un
seul objectif (temps, consommation denergie, taille memoire,..) mais plusieurs. Dans notre
cas on a fait du bi-objectif (temps et energie), car ils sont les plus importants. Cependant, le
co
ut global du placement ne depend pas uniquement des co
uts des unites de traitements,
il depend aussi des co
uts des communications. Do`
u une autre methode permettant de
chercher le meilleur mapping des communications sur la topologie cible, ce qui fat de
lalgorithme, propose pour ce sous problème, un algorithme hybride doptimisation multiobjectif.
2. Pour le mapping des taches repetitives et des donnees regulières, exprimees par le langage
Array-Ol, une autre approche est utilisee. Si pour le premier cas on a utilise une metaheuristique qui se justifie par la taille des DAG en entree, dans ce cas cest plutot une
methode exacte qui est utilisee. On justifie ce choix par le fait que les donnees, sur lesquelles
le traitement repetitif se fait, sont infinies. Le mapping de ces donnees ne les prends pas
toutes en meme temps mais par des paquets ayant le meme profil et la meme taille, appeles
Motifs. La taille de ces Motifs est petite, fixe et connue, et de meme pour larchitecture
regulière cible. Donc pour ce problème un algorithme hybride exact est propose pour
trouver le meilleur placement dune application DSP (chapitre 3) sur une architecture
6
regulière.
3. En fin le troisième sous problème consiste à prendre le GILR en entier avec son aspect
hierarchique. Ainsi pour placer une application hierarchique presentee par le graphe suivant
(Figure II) on doit balayer les deux graphes (HTG et HAG) de bas vers le haut en cherchant
à chaque niveau loptimalite en y faisant appel aux algorithmes proposes pour les phases
1 et 2. Lexplication de la demarche se fera dans le chapitre 6.
Enfin, pour valider les resultats (ce qui nest pas très evident du fait de loriginalite de la
demarche), on a essaye de comparer les resultats obtenus selon les deux critères temporel et
qualitatif. Pour le premier critère on a fait la comparaison des temps de convergence de la methode par rapport à ceux obtenus par des methodes exactes denumeration en ayant en entree
des benchmarks de graphes. Pour le deuxième critère on a compare les resultats obtenus par
rapport à ceux dun exemple reel (le HS69) modelisant une application DSP.
P lan du document
Le reste du document est structure en 7 parties selon un ordre quon a pense quil permet
tra au lecteur de suivre et comprendre la demarche. Evidemment,
les premiers chapitres sont
relatifs au contexte et letat de lart. Toute fois un lecteur initie aux concepts presentes peut les
eviter et passer directement aux parties qui linteressent.
Chapitre 1 : Dans cette partie on commence par introduire le concept des systèmes embarques
et les domaines de leurs utilisations. On y abordera aussi avec plus de details les SoC et leurs
sous familles NoC et MPSoC.
Chapitre 2 : Les methodologies de conception et developpement des SoCs sont très complexes
et delles dependra leur reussite. Cest ce quon essayera de presenter dans cette partie par
lenumeration de certains flots de conception, en insistant sur le flot GASPARD2 developpe par
lequipe DaRT INRIA. Ce flot avec tous les packages constituant son profil sont bien presentes
dans cette partie afin de permettre au lecteur de sy familiariser ou au moins de pouvoir y situer
notre contribution.
Chapitre 3 : Dans la partie precedente en parlant des differents flots de modelisation on a
aborde la modelisation des applications DSP. Afin de ne pas encombrer le chapitre precedent on
a prefere les presenter et les detailler dans ce chapitre.
Chapitre 4 : On ne peut parler de notre apport et du travail doptimisation dans les SoCs,
quon doit faire dans lequipe DaRT, sans aborder la problematique de lAAS en general. Dans
ce chapitre on etudiera les differentes methodes et approches les plus connues layant aborde.
Chapitre 5 : Ce chapitre sera consacre complètement à loptimisation combinatoire multiobjectif. Les concepts qui y sont introduits sont necessaire au non initie à loptimisation pour
comprendre le chapitre 6 en faisant le lien avec lui qui la precede.
Chapitre 6 : Dans cet avant dernier chapitre on presentera notre demarche pour lAAS du
GILR. Les differentes demarches ainsi que les formalismes qui les entourent seront presentes
avec details afin de clarifier au maximum notre contribution et mettre en evidence loriginalite
de la proposition.
7
Chapitre 7 : Les demarches et contributions, presentees dans le chapitre 6, doivent etre validees par des implementations et experimentations. Cest lobjet de ce dernier chapitre quon
consacrera à la presentation de lenvironnement dexperimentation et discussion des resultats.
Chapitre 1
Introduction aux syst`

emes
embarqu
es
Sommaire
1.1
Motivation et objectifs des syst`

emes embarqu
es
. . . . . . . . . . .
10
1.1.1
Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.1.2
Les types de systèmes embarques
. . . . . . . . . . . . . . . . . . . . .
10
1.1.3
Caracteristiques principales dun système embarque . . . . . . . . . . .
11
1.2
Informatique embarqu
ee . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.3
Les diff
erentes architectures des diff
erents syst`
emes embarqu
es
14
1.4
. .
1.3.1
Mono-puce ( SOC)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
1.3.2
Les multiprocesseurs on SOC (MPSOC) . . . . . . . . . . . . . . . . . .
16
1.3.3
Les NOC (Network On Chip) . . . . . . . . . . . . . . . . . . . . . . . .
18
1.3.4
Architecture regulière à base de tableau de processeurs identiques
19
. . .
Linterconnexion dans les SOC . . . . . . . . . . . . . . . . . . . . . .
19
1.4.1
Du SOC au NOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
1.4.2
Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
1.4.3
Le Bus centralise ou partage : . . . . . . . . . . . . . . . . . . . . . . . .
23
1.4.4
Les reseaux en etoile et en anneau : . . . . . . . . . . . . . . . . . . . .
25
1.4.5
Les reseaux Crossbar
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
1.4.6
Les reseaux commutes ou à maille : . . . . . . . . . . . . . . . . . . . . .
25
1.1. Motivation et objectifs des systèmes embarques
Les Systèmes On Chip (SOC) sont le resultat de levolution technologique qui

a permet lint
egration de plateforme complexe sur une seule puce. Les derniers permettent lint
egration de plusieurs CPU avec des sous syst`
emes pour ex
ecuter le Soft
et connecter entre eux selon les meilleures topologies connues dans les r
eseaux. Ces
syst`
emes sont appel
es Multiprocessors System on Chip (MPSOC). Pour g
erer
et exploiter ce haut degr
e de parall
elisme obtenu au niveau hardware et software
nous devons utiliser des constructeurs r
eguliers pour larchitecture et le software `
a
la fois. A travers ce chapitre, nous ferons un bref survol sur la probl
ematique de
lembarqu
e, en parlant bri`
evement des diff
erentes architectures et topologies.
1.1
Motivation et objectifs des syst`

emes embarqu
es
On peu affirmer que les syst`

emes embarqu`
es nous entourent et nous sommes
litt
eralement envahis par eux, fid`
eles au poste et pr
ets `
a nous rendre service. Pour
cela, il suffit de regarder autour de soi au quotidien pour voir et avoir la r
eponse sous
ses yeux. Vous
etes r
eveill
e le matin par votre radio-r
eveil ; cest un syst`
eme embarqu
e vous programmez votre machine `
a caf
e pour avoir un bon petit serr
e ; cest
un syst`
eme embarqu
e vous allumez la t
el
evision et utilisez votre t
el
ecommande ; ce
sont des syst`
emes embarqu
es vous allumez la t
el
evision et utilisez votre t
el
ecommande ; ce sont des syst`
emes embarqu
es vous prenez votre voiture et la voix suave
du calculateur vous dit que vous navez pas mis votre ceinture ; cest un syst`
eme
embarqu
e vous appelez votre patron avec votre t
el
ephone portable pour signaler
que vous serez en retard ; cest un syst`
eme embarqu
e. La liste est encore longue des
domaines de notre vie quotidienne o`
u on fait appel `
a ce type de syst`
eme.
1.1.1
D
efinition
Un syst`
eme embarqu
e peut
etre d
efini comme un syst`
eme
electronique et informatique autonome, qui est d
edi
e `
a une t
ache bien pr
ecise. Il ne poss`
ede g
en
eralement pas des entr
ees/sorties standards et classiques comme un clavier ou un
ecran
dordinateur. Le syst`
eme mat
eriel et lapplication sont intimement li
es, le logiciel
embarqu
e
etant enfoui, noy
e dans le mat
eriel. Ce dernier et le logiciel ne sont pas
aussi facilement discernables comme dans un environnement de travail classique de
type ordinateur P.C [75].
1.1.2
Les types de syst`

emes embarqu
es
Calcul g
en
eral (G
en
eral computing)
Application similaire `
a une application de bureau mais empaquet
ee dans un
syst`
eme embarqu
e.
Jeu video, Set top box.
Contr
ole de syst`
eme
10

Contr
ole de syst`
eme en temps r
eel : Moteur dautomobile, processus chimique,
processus nucl
eaire, syst`
eme de navigation a
erien.
Traitement de signal : Signal processing .
1.1.3
Caract
eristiques principales dun syst`
eme embarqu
e
Pour les syst`

emes embarqu
es on
enum`
ere les caract
eristiques principales suivantes :
Cest un syst`
eme principalement num
erique.
Il met en uvre g
en
eralement un ou plusieurs processeurs.
Il ex
ecute une application logicielle d
edi
ee pour r
ealiser une fonctionnalit
e
pr
ecise et nex
ecute donc pas une application scientifique ou grand public
traditionnelle.
Il na pas r
eellement de clavier standard (bouton poussoir, clavier matriciel
. . .). Laffichage est limit

e (Ecran
LCD) ou nexiste pas du tout.
Ce nest pas un PC en g
en
eral mais des architectures similaires basse consommation sont de plus en plus utilis
ees pour certaines applications embarqu
ees.
De ce fait on constate que :
1. Les ressources (
energie, surface) sont limit
ees.
2. Linterface IHM peut
etre aussi simple quune LED qui clignote ou aussi complexe quun cockpit davion en ligne.
3. Des circuits num
eriques ou des circuits analogiques sont utilis
es en plus pour
augmenter les performances du syst`
eme embarqu
es ou sa fiabilit
e.
La r
evolution num
erique datant des ann
ees 1970 avec lav`
enement des processeurs
qui sont devenus de plus en plus rapide, puissants et bon march
e a rendu les syst`
emes embarqu
es omnipr
esent dans notre vie. Ceci se confirme au travers de la loi
de Gordon Moore, cofondateur dIntel, qui stipule que pour une surface de silicium
donn
ee, on double le nombre de transistors int
egr
es tous les 18 mois.[figure 1.1]
Fig. 1.1 La loi de Gordon Moore
11

La figure suivante illustre un syst`
eme embarqu
e typique.1.2
Fig. 1.2 Système embarque typique
On retrouve en entr
ee des capteurs g
en
eralement analogiques coupl
es `
a des
convertisseurs A/N. On retrouve en sortie des actionneurs g
en
eralement analogiques
coupl
es `
a des convertisseurs N/A. Au milieu, on trouve le calculateur mettant en
uvre un processeur embarqu
e et ses p
eriph
eriques dE/S. Il est `
a noter quil est
compl
et
e g
en
eralement dun circuit FPGA jouant le r
ole de coprocesseur afin de
proposer des acc
el
erations mat
erielles au processeur. Sur ce sch
ema th
eorique se
greffe un param`
etre important : le r
ole de lenvironnement ext
erieur. Contrairement
au PC, un syst`
eme embarqu
e doit faire face `
a des environnements plus hostiles en
faisant face `
a un ensemble de param`
etres agressifs :
Variations de la temp
erature.
Vibrations, choc.
Variations des alimentations.
Interf
erences RF.
Corrosion.
Eau, feu, radiations.
(Etc).
Lenvironnement dans lequel op`
ere le syst`
eme embarqu
e nest pas contr
ol
e ou
contr
olable. Il doit
etre pris en consid
eration lors de la conception du syst`
eme. On
doit par exemple prendre en compte les
evolutions des caract
eristiques
electriques
des composants en fonction de la temp
erature, des radiations. Les syst`
emes embarqu
es, actuellement, sont fortement communicants. Cela est possible gr
ace aux puissances de calcul offertes par les processeurs pour lembarqu
e (32 bits en particulier)
et gr
ace aussi `
a lexplosion de lusage de la connectivit
e Internet ou connectivit
e IP
(Intellectual Property). La connectivit
e IP permet fondamentalement de contr
oler
`
a distance un syst`
eme embarqu
e par internet. Cde nest en fait que laboutissement
du contr
ole `
a distance dun syst`
eme
electronique par des liaisons de tous types :
liaison RS232, RS485, bus de terrain. Cela permet lemploi des technologies modernes du web pour ce contr
ole `
a distance par lutilisateur : Il suffit dembarquer
un serveur web dans son
equipement
electronique pour pouvoir le contr
oler ensuite
`
a distance, de nimporte o`
u, `
a laide dun simple navigateur ; il ny a plus dIHM
(Interface Homme Machine) sp
ecifique `
a concevoir pour cela, ce r
ole
etant rempli
par le navigateur Web. Cela est une r
ealit
e : Les chauffagistes proposent maintenant
des chaudi`
eres pouvant
etre pilot
ees par le Web. On note aussi que les communications sans fil sont plus utilis
ees dans lembarqu
e que les communications filaires
pour limiter le c
ablage et faciliter la mise en place du syst`
eme embarqu
e. Le WIFI
et toutes les normes de r
eseaux sans fil IEEE 802.15 comme Zig b
ee ont le vent
en poupe dans lembarqu
e et surtout en domotique (r
eseau de capteurs sans fil par
exemple). Mais, cela a bien s
ur un revers : la s
ecurit
e du syst`
eme embarqu
e puisque
12

connect
e`
a Internet.
Les syst`
emes embarqu
es et les contraintes de temps
On lie souvent les syst`
emes embarqu
es au temps r
eel : Un syst`
eme embarqu
e
doit g
en
eralement respecter des contraintes temporelles fortes (Hard real time) et
lon y trouve enfoui un syst`
eme dexploitation ou un noyau temps R
eel (Real Time
Operating System, RTOS). Le concept du temps r
eel est un peu vague et chacun
a sa propre id
ee sur la question, mais on pourrait le d
efinir comme : ( un syst`
eme
est dit temps r
eel lorsque linformation apr`
es acquisition et traitement reste encore
pertinente ). Cela veut dire que dans le cas dune information arrivant de fa
con
p
eriodique (sous forme dune interruption p
eriodique du syst`
eme), les temps dacquisition et de traitement doivent rester inf
erieurs `
a la p
eriode de rafrachissement
de cette information. Un temps maximum dex
ecution est garanti (pire cas) et non
un temps moyen ; [75] Pour cela, il faut que le noyau ou le syst`
eme temps r
eel :
Soit d
eterministe : les m
emes effets sont produits suite aux m
emes causes et
avec les m
emes temps dex
ecution.
Soit pr
eemptif : la t
ache de plus forte priorit
e pr
ete `
a
etre ex
ecut
ee doit
toujours avoir acc`
es au processeur.
Donc pour un syst`
eme embarqu
e ces conditions sont n
ecessaires mais pas suffisantes pour dire quil est temps r
eel par d
efinition, sans quon ait `
a m
elanger temps
r
eel et puissance de calcul. On entend souvent : Etre temps r
eel, cest avoir beaucoup
de puissance : des MIPS et MFLOPS. Ceci nest pas toujours v
erifi
e. Dune fa
con
plus pr
ecise,
etre temps r
eel dans lexemple donn
e pr
ec
edemment, cest
etre capable
dacquitter linterruption p
eriodique (moyennant un temps de latence de traitement
dinterruption impos
ee par le mat
eriel), traiter linformation et le signaler au niveau utilisateur (r
eveil dune t
ache, lib
eration dun s
emaphore . . .) dans un temps
inf
erieur au temps entre deux interruptions p
eriodiques cons
ecutives. Puisquon est
li
e`
a la contrainte dur
ee entre deux interruptions. Cest donc le processus ext
erieur
`
a contr
oler qui impose ses contraintes temporelles au syst`
eme embarqu
e et non le
contraire. Si cette dur
ee est de lordre de la seconde (pour le contr
ole dune r
eaction
chimique par exemple), il ne sert `
a rien davoir un syst`
eme `
a base de processeur 32
bits performant. Un simple processeur 8 bits voire m
eme un processeur 4 bits fera
amplement laffaire, ce qui permettra de minimiser les co
uts sur des quantit
es `
a
produire. Dans le cas dun temps de quelques dizaines de microsecondes il est alors
n
ecessaire de choisir un processeur nettement plus performant. Dans le pire cas, le
traitement en temps r
eel sera r
ealis
e en logique c
abl
ee tout simplement. Il convient
donc avant de concevoir le syst`
eme embarqu
e de connatre la dur
ee minimale entre
deux interruption ; ce qui est assez difficile `
a estimer voire m
eme impossible. Cest
pour cela que lon a tendance `
a concevoir dans ce cas des syst`
emes performants et
souvent surdimensionn
es pour respecter des contraintes temps r
eel mal cern
ees `
a
priori. Ceci induit en cas de surdimensionnement un surco
ut non n
egligeable.
13
1.2. Informatique embarquee
1.2
Informatique embarqu
ee
Par le terme informatique embarqu

e on d
esigne les aspects logiciels se trouvant `
a
lint
erieur des
equipements nayant pas une vocation purement informatique. Lensemble logiciel, mat
eriel int
egr
e dans un
equipement constitue un syst`
eme embarqu
e
[25]. Comme toute informatique, celle-ci a ses propres imp
eratifs qui la distingue,
on peut la caract
eriser principalement par :
La criticit
e : Les syst`
emes embarqu
es sont souvent critiques, et les syst`
emes critiques sont presque toujours embarqu
es. En effet, comme un tel syst`
eme agit sur
un environnement physique, les actions quil effectue sont irr
em
ediables. Le degr
e
de criticit
e est fonction des cons
equences des d
eviations par rapport `
a un comportement normal, cons
equences qui peuvent concerner la s
uret
e des personnes et des
biens, la s
ecurit
e, laccomplissement des missions, la rentabilit
e
economique.
La r
eactivit
e : Ces syst`
emes doivent interagir avec leur environnement `
a une
vitesse qui est impos
ee par ce dernier. Ceci induit donc des imp
eratifs de temps de
r
eponse. Cest pour cette raison que linformatique embarqu
ee est souvent bas
ee
sur un syst`
eme r
eel.
Lautonomie : Les syst`
emes embarqu
es doivent en g
en
eral
etre autonomes, cest`
a-dire remplir leur mission pendant de longues p
eriodes sans intervention humaine.
Cette autonomie est n
ecessaire lorsque lintervention humaine est impossible, mais
aussi lorsque la r
eaction humaine est trop lente ou insuffisamment fiable.
La robustesse, s
ecurit
e et fiabilit
e : Lenvironnement est souvent hostile, pour
des raisons physiques (chocs, variation de temp
erature, impact dions lourds dans
les syst`
emes spatiaux,. . .) ou humaines (malveillance). Cest pour cela que la s
ecurit
e au sens de la r
esistance aux malveillances, et la fiabilit
e, au sens continuit
e de
service, sont souvent rattach
ees `
a la probl
ematique des syst`
emes embarqu
es.
Et enfin des contraintes non fonctionnelles, comme par exemple loccupation
m
emoire, la consommation d
energie,. . ..
1.3
Les diff
erentes architectures des diff
erents syst`
emes embarqu
es
La technologie de fabrication de circuits int

egr
es, qui a permis lint
egration de
plusieurs composants sur une seule puce, a permis lapparition des syst`
emes sur
puce qui ont rapidement pris une place importante dans le domaine de la micro
electronique en int
egrant dans le m
eme circuit plusieurs processeurs, de nombreux
14
1.3. Les differentes architectures des differents systèmes embarques

composants num
eriques sp
ecialis
es et h
et
erog`
enes (m
emoire, p
eriph
eriques et unit
e
de calcul sp
ecifiques), du logiciel et souvent des circuits mixtes pour fournir un
syst`
eme int
egr
e complet. Les syst`
emes mono puce multiprocesseurs sont g
en
eralement d
edi
es aux applications sp
ecifiques dans des domaines diff
erents comme par
exemple dans le domaine de lautomobile, des t
el
ecommunications, du multim
edia
et leurs diversit
es ne cessent pas daccrotre [75].
1.3.1
Mono-puce ( SOC)
Un syst`
eme mono-puce appel
e encore SOC (Syst`
eme On Chip) ou syst`
eme sur
puce, d
esigne lint
egration dun syst`
eme complet sur une seule pi`
ece de silicium.
Ce terme est devenu tr`
es populaire dans le milieu industriel malgr
e labsence dune
d
efinition standard [23]. Certains consid`
erent quun circuit complexe en fait automatiquement un SOC, ce qui est faux. Une d
efinition plus appropri
ee de syst`
eme
mono-puce serait : un syst`
eme complet sur une seule pi`
ece de silicium, r
esultant de
la cohabitation sur silicium de nombreuses fonctions d
ej`
a complexes en elles m
eme,
processeurs, convertisseurs, m
emoire, bus..Etc. Il doit comporter au minimum une
unit
e de traitement de logiciel (un CPU) et ne doit d
ependre daucun (ou de tr`
es
peu) de composants externes pour ex
ecuter sa t
ache. En cons
equence, il n
ecessite
`
a la fois du mat
eriel et du logiciel. Dans la figure 1.3 est pr
esent
e un exemple de
syst`
eme mono-puce typique. Il se compose dun cur de processeur (CPU), dun
processeur de signal num
erique (DSP), de la m
emoire embarqu
ee, et de quelques
p
eriph
eriques tels quun DMA (Direct Memory Access) et un contr
oleur dE/S.
Le CPU peut ex
ecuter plusieurs t
aches via lint
egration dun OS, le DSP est habituellement responsable de d
echarger le CPU en faisant le calcul num
erique sur les
signaux de provenance du convertisseur A/N.[figure 1.3]
Fig. 1.3 Un exemple de système mono-puce (SOC)
Le syst`
eme pourrait
etre construit exclusivement de composants existants et
de solutions faites sur mesure. Plus r
ecemment, il y a eu beaucoup defforts pour
impl
ementer des syst`
emes multiprocesseurs sur puce [52].
La solution mono puce, pour diverses raisons,repr
esente une mani`
ere attrayante
pour impl
ementer un syst`
eme. Les processus de fabrication (de plus en plus fins)
daujourdhui permettent de combiner la logique et la m
emoire sur une seule puce,
r
eduisant le temps global des acc`
es m
emoires,
etant donn
e que le besoin en m
emoire
de lapplication ne d
epasse pas la taille de la m
emoire embarqu
ee sur puce, la
latence de la m
emoire sera r
eduite gr
ace `
a l
elimination de trafic de donn
ees entre
des puces s
epar
ees. Le nombre de broches peut
etre r
eduit puisquil ny a y plus
besoin dacc
eder `
a la m
emoire sur des puces externes et lutilisation de bus sur carte
devient inutile. Le co
ut total de fabrication est r
eduit `
a cause de la r
eduction du
co
ut de lencapsulation qui repr
esente en moyenne 50% du co
ut global du processus
15

de fabrication de puce. Ces caract
eristiques aussi bien que la faible consommation et
la courte dur
ee de conception permettent une mise sur le march
e rapide de produits
plus
economiques et plus performants.
1.3.2
Les multiprocesseurs on SOC (MPSOC)
Les progr`
es technologiques et la capacit
e dint
egration de centaines de millions
de transistors sur une seule puce ont fait
emerger deux tendances pour relever ce
d
efi. La premi`
ere tendance consiste `
a utiliser une architecture monoprocesseur tout
en am
eliorant consid
erablement les performances du CPU utilis
e et lutilisation de
coprocesseurs. Un tel CPU utilis
e se distingue par une fr
equence de fonctionnement
tr`
es
elev
ee, des structures mat
erielles sp
ecialis
ees, un ensemble dinstructions sophistiqu
ees, plusieurs niveaux de hi
erarchie m
emoire (plusieurs niveaux de cache),
et des techniques sp
ecialis
ees doptimisation logicielle (nombre dacc`
es m
emoire,
taille, etc.).
La figure 1.4 pr
esente un exemple darchitecture /coprocesseurs. Dans de telles
architectures la communication est bas
ee sur le principe matre/esclave. Le CPU
est le matre et les p
eriph
eriques sont des esclaves.(figure 1.4)
Fig. 1.4 Un exemple darchitecture monoprocesseur (p/co-processeurs)

La deuxi`
eme tendance consiste `
a utiliser des architectures multiprocesseurs (multimatres) qui
etaient r
eserv
ees jusqu`
a maintenant aux machines de calculs scientifiques. Lid
ee derri`
ere cette tendance se base sur les avancements en technologie et
architectures sous jacentes, car il sav`
ere quil est peut
etre de plus en plus difficile
davoir des architectures monoprocesseurs assez rapide alors que les multiprocesseurs sur puce sont d
ej`
a r
ealisables. Dautres raisons peuvent conforter ceux qui
sont derri`
ere cette tendance et qui sont [4] :
Le parall
elisme : Les transistors suppl
ementaires disponibles sur la puce sont
utilis
es par les concepteurs principalement pour extraire le parall
elisme `
a partir
des programmes afin deffectuer plus de travail par cycle dhorloge, la majorit
e
16

des transistors sont employ
es pour construire les processeurs super scalaires. Ces
processeurs visent `
a exploiter une quantit
e plus
elev
ee de parall
elisme au niveau
instruction, malheureusement, comme les instructions sont, en g
en
eral, fortement
interd
ependantes, les processeurs qui exploitent cette technique voient leur rendement diminuer malgr
e laugmentation quadratique de la logique n
ecessaire au
traitement de multiple instructions par cycle dhorloge, une architecture multiprocesseurs
evite cette limitation en employant un type compl`
etement diff
erent de
parall
elisme : le parall
elisme au niveau t
ache. Ce type de parall
elisme est obtenu en
ex
ecutant simultan
ement des s
equences dinstructions compl`
etement s
epar
ees sur
chacun des processeurs.
Les retards caus
es par les interconnections : Ils sont devenus plus significatifs `
a
cause de la rapidit
e croissante des portes Cmos et des tailles devenues physiquement
plus grande des puces. Ainsi, les fils, dans les ann
ees prochaines, pourront seulement acheminer les signaux sur une petite partie de la puce durant chaque cycle
dhorloge ce qui diminue drastiquement la performance dans le cas de large puce
monoprocesseur. Cependant, une puce multiprocesseur peut
etre con
cue de telle
fa
con que chacun de ses petits processeurs occupe un secteur relativement petit
r
eduisant, ainsi, au minimum la largeur de ses fils et simplifiant la conception de
chemins critiques. Seulement les fils, connectant les processeurs, les plus rarement
employ
es et donc les moins critiques peuvent
etre longs.
Le temps de conception : Il est d
ej`
a difficile de concevoir des processeurs. Le
nombre croissant de transistors, les m
ethodes de plus en plus complexes dextraction de parall
elisme au niveau instruction et le probl`
eme des retards caus
es par
les interconnections rendront ceci encore plus difficile. Une architecture multiprocesseurs mono-puce, cependant, permet de r
eduire ce temps de conception car il
permet linstanciation de plusieurs composants pr
e-valid
es qui peuvent
etre r
eutilis
es dans plusieurs applications de diff
erentes tailles (en changeant le nombre de
composants). Seulement la logique dinterconnexion entre composants nest pas enti`
erement reproduite.
Puisquune architecture multiprocesseurs mono-puce traite tous ces probl`
emes
potentiels dune fa
con directe et extensible, pourquoi ne sont ils pas d
ej`
a r
epondu ?
Une raison est que les densit
es dint
egration viennent juste datteindre les niveaux
ou ces probl`
emes deviennent assez significatifs pour consid
erer un changement de
paradigme dans la conception des syst`
emes. Une autre raison, cependant, est que le
probl`
eme de synchronisation et de communication entre les diff
erents processeurs
survient. Ceci rappelle encore une fois limportance de larchitecture de communication dans les syst`
emes multiprocesseurs.
17
1.3.3
Les NOC (Network On Chip)
Les premiers travaux universitaires cons

equents sur le th`
eme des r
eseaux int
egr
es furent publi
es d`
es la fin du pr
ec
edent mill
enaire. Ils portaient tous sur la
r
ealisation de r
eseaux de communication complets. Citons entre autre le routeur
`
a commutation de paquets RS P IN d
evelopp
e `
a luniversit
e PARIS VI [76], le bus
centralis
e asynchrone `
a mailles du processeur ultra faible consommation Maia d
evelopp
e par luniversit
e de Berkeley [58].
A travers ces travaux on cherchait `
a d
eterminer une architecture performante de
r
eseau sur silicium la plus g
en
erique possible, ce qui leur a permet tous, `
a l
epoque,
de parvenir `
a cette conclusion : lutilisation traditionnelle dun bus centralis
e est
obsol`
ete et doit
etre remplac
ee par des topologies de r
eseaux distribu
es sur le mod`
ele des r
eseaux utilis
es en t
el
ecommunications et pour les calculateurs parall`
eles
hautes performances [51].
En outre, la topologie efficace de ces r
eseaux est fortement d
ependante de lapplication et des contraintes de performances. Ces travaux et dautres plus r
ecents [20]
mirent
egalement en
evidence l
emergence des probl`
emes nouveaux li
es `
a la r
ealisation de larges syst`
emes complexes h
et
erog`
enes multi-horloges et aux contraintes de
performance
elev
ees : tr`
es faible consommation ou tr`
es haut d
ebit ou tr`
es haute h
et
erog
en
eit
e des modules int
egr
es au sein dun m
eme syst`
eme, impliquant une tr`
es
grande flexibilit
e. Ces nouveaux d
efis ne dispensant
evidemment pas le syst`
eme
de communication de respecter les contraintes dimpl
ementation physique que lon
exige de lui.
Apr`
es la loi de Moore qui a soutenu dans lindustrie de semi conducteur pendant
plus de 35 ann
ees, une puce simple est pr
evue pour pouvoir int
egrer quatre milliards
de transistors 50nm fonctionnant en dessous dun volt et fonctionnant `
a 10 gigahertz
vers la fin de la d
ecennie. D
u`
a sa capacit
e
enorme, la puce de milliard de transistors
peut prendre sur des fonctionnalit
es tr`
es complexes avec des centaines de microprocesseurs reli
ees `
a un ensemble de ressources informatiques. De telles ressources
peuvent
etre programmables comme CPUs, d
edi
ees comme ASICs, configurable
comme FPGAs, ou passif comme les m
emoires . . .etc, les ressources h
et
erog`
enes
impliquent de divers interfaces ou protocoles, logiciels dexploitation, etc.. . ., qui
est difficile de les int
egrer sur une puce simple.
Une plateforme de NOC est une structure de maille compos
ee de passages avec
chaque commutateur connect
e `
a une ressource, comme il est montr
e sur la figure
1.5. Les ressources sont plac
ees sur les fentes constitu
ees par les commutateurs. Le
commutateur de r
eseau offre une communication pour des ressources. Les ressources
ex
ecutent leurs propres fonctionnalit
es informatiques et fournissent le Ressource18
1.4. Linterconnexion dans les SOC

R
eseau-Interface (RNI).
1.3.4
Architecture r
eguli`
ere `
a base de tableau de processeurs identiques
M.C Herbord [59] dans sa th`

ese intitul
e The evaluation of Massively parallel
Array Architecture a surtout insist
e sur l
evaluation du gain, du mod`
ele et des
param`
etres techniques dun tel syst`
eme et leur application. Dapr`
es notre point de
vue les architectures r
eguli`
eres pour les syst`
emes embarqu
es seront tr`
es utilis
ees
dans le future, sp
ecialement pour les MPSOC.(figure 1.5)
Fig. 1.5 Un NOC de structure de maille avec 9 nuds o`

u chaque noeud dans la maille contient
un commutateur et une ressource.
1.4
Linterconnexion dans les SOC
Dans le future des SOC multi-

el
ements, la technologie dinterconnexion va jouer
un r
ole important dans les performances par lint
egration de centaines peut
etre plus
d
el
ements composants (PE, FPGE, ASIC, DSP, M
emoire, contr
oleurs. . .etc). Dans
ce qui suit on pr
esentera et discutera quelques topologies dinterconnexion, leur
extensibilit
e`
a travers les param`
etres de communication (latence et bande passante),
les exigences des applications DSP et leurs perspectives [56].
1.4.1
Du SOC au NOC
Lavanc
ee technologique des semi conducteurs va accrotre lexistence des SOC
dans les futurs syst`
emes. Ils seront capables dans la prochaine d
ecade dint
egrer
des centaines si cest des milliers de composants PE et/ou d
el
ements de stockage
dans une m
eme puce. La conception des SOC `
a ce stade ne va pas d
emarrer de z
ero
mais ils seront con
cus en r
eutilisant des composants existants tels les processeurs,
les contr
oleurs et les tableaux de m
emoires.
19

Donc les m
ethodologies de conception des futures SOC se baseront sur la r
eutilisation de composants dans plug and play dont lobjectif est de diminuer les
temps de conception et r
epondre aux exigences de fabrication. Ainsi dans ces futurs
syst`
emes le facteur le plus critique sera la communication entre les composants. La
fiabilit
e, consommation de peu d
energie et laugmentation de puissance de communication darchitecture sur puce vont devenir la nouvelle contrainte pour atteindre
les objectifs op
erationnels. N
eanmoins, les concepteurs pr
evoient une vue centr
ee
sur les communications dans les nouvelles m
ethodologies de conception dans les
edominance des technologies 50-100nm dans
ann
ees `
a venir [39], du fait de la pr
la deuxi`
eme partie de cette d
ecade. Les structures de communication sur puce
traditionnel ou contourner plusieurs limitations dans la conception des VLSI daujourdhui. Mais plusieurs de ces limitations vont devenir probl
ematiques quand les
semi-conducteurs progresseront dans les nouvelles g
en
erations. Ces limitations ont
un lien direct avec la taille (nombre de composants) des SoC [54]. Si la taille augmente on risque de se retrouver avec un goulot d
etranglement des communications
dans les SoC.
Contrainte de Bande passante (Throughput limitation) : Les structures de communication (bus) des SOC traditionnels ne peuvent pas augmenter quand le nombre
de composants augmente. Quand plusieurs flots de donn
ees sont transmis en m
eme
temps ils vont se partager la m
eme ressource, ce qui pose dautres probl`
emes de
congestion et de conflits dacc`
es.
Consommation d
energie : du fait de la diminution de lapport des composants
VLSI, les liens de connexion sont devenus lune des majeures contributions pour
la consommation d
energie du syst`
eme. Lutilisation des Bus dans les SOC actuels
nest pas tr`
es int
eressante sur le plan consommation d
energie car lenvoie dun bit
est propag
e`
a travers le bus `
a chaque terminal.
Dans la perspective de contourner ses limitations et dans lordre dint
egrer plus
de composants, lavenir des intercommunications des syst`
emes sur puce va devenir plus complexe et va h
eriter de plusieurs th
eories et techniques des topologies
dinterconnexion des multicomputers traditionnels pour r
epondre aux exigences de
fiabilit
e,
energie et performance.
Comparaison entre lutilisation des NOC et Bus par Les MPSOC [56]
Depuis lintroduction du concept des SOC dans les ann
ees 90, la solution pour les
communications
etait bas
ee g
en
eralement sur les bus ou les liens point `
a point [?]
figure 1.6. Lutilisation des bus est matris
ee et facile mais il peut facilement cr
eer
des goulots d
etranglement quand le nombre de composants accrot. Le probl`
eme se
pose aussi pour la consommation d
energie et sans oublier lautre probl`
eme impor-
20

tant qui est le probl`
eme darbitrage et des conflits dacc`
es du fait de la ressource
partag
ee qui est le Bus.(figure 1.6)
Fig. 1.6 trois types dinterconnexions utilisees dans les MPSOC

Dun certain point de vue, le bus lemporte dans les syst`
emes `
a moins de 20
composants. Mais quand la taille du syst`
eme augmente il pose plus de probl`
emes
et devient une contrainte insurmontable dans lattente dobjectifs tels le temps
dex
ecution total. Pour plus de flexibilit
e et dextensibilit
e une solution plus g
en
erale simpose en utilisant une structure de communication globale segment
ee et
partag
ee. Ceci nous am`
ene `
a penser `
a un r
eseau constitu
e de liens et des nuds
routeurs impl
ement
es sur puce. A la diff
erence des structures de communication
traditionnelles vue auparavant, ces nouvelles structures de communication distribu
ee se comporte mieux avec lextension, la taille de la puce et la complexit
e. Un
concept commun de ces structures de communication dans les SOC est bas
e sur les
r
eseaux, il est connu sous le nom Network on Chip (NOC) [[76] [90],[86],[47]]
Dans la communaut
e des chercheurs, certains voient les NOC comme un sous
ensemble des SOC et pour dautres les NOC sont une extension de SoC. Mais g
en
eralement pour simplifier la hi
erarchie des concepts on adopte la vue suivante :
1.4.2
Syst`
eme embarqu
e daujourdhui (NOC)
SOC
MPSOC
Bus
Topologies
Laugmentation constante du nombre de fonctions int

egr
ees dans une seule puce
a fortement augment
e les contraintes et les exigences sur les r
eseaux de communication. Les concepteurs de ces r
eseaux et les int
egrateurs syst`
emes se sont tourn
es
21

vers les techniques
eprouv
ees des r
eseaux `
a grande
echelle utilis
es dans le monde
des t
el
ecommunications et des calculateurs parall`
eles haute performance.
Les r
eseaux de communication pr
esentent donc aujourdhui une grande vari
et
e dimpl
ementations physiques. Ce paragraphe pr
esente donc les principes des familles de
topologies les plus utilis
ees, sachant que de nombreuses solutions sp
ecifiques sont
d
evelopp
ees `
a partir de ces familles pour adapter le r
eseau de communication `
a
lapplication cible. Les Figures suivantes pr
esentent ainsi le sch
ema de principe de
quelques unes des topologies les plus couramment employ
ees [51].
Ces r
eseaux int
egr
es sont compos
es de ressources de routage et de transport de
linformation. Ces ressources doivent permettre l
echange de donn
ees entre p
eriph
eriques.
Chemins de communication point `

a point :
Il sagit de lutilisation de ressources de transmission sp
ecifiques et d
edi
ees `
a
limpl
ementation dun lien entre deux
el
ements.
Fig. 1.7 Liaison point à point.
Fig. 1.8 Anneau simple

La ressource de transmission
etant d
edi
ee `
a une unique communication, elle est
toujours disponible pour cette derni`
ere et peut ainsi lui offrir sa pleine bande passante. De plus, du fait de la simplicit
e du contr
ole de telles connexions, les d
ebits y
sont
elev
es et les latences d
ependent principalement de la longueur du chemin. Par
contre la surface de ces connexions sera proportionnelle au nombre de liens.(figure
1.7,1.8)
22

Les topologies multipoints :
Dans lensemble des topologies pr
esent
ees, les besoins gourmands en performance ont conduit de mani`
ere universelle au d
eveloppement de r
eseaux dinterconnexion.
Le bus centralis
e est en abandon progressif en tant que m
edium principal de communication par lensemble des acteurs qui se veulent `
a la pointe des solutions syst`
eme
sur silicium. Le march
e se d
eplace, de plus en plus rapidement, vers des solutions
globales de transport et de management du trafic au sein des syst`
emes sur silicium,
sinspirant fortement des r
eseaux de calculateurs parall`
eles [10].
Les syst`
emes sur silicium pr
esentant une forte h
et
erog
en
eit
e de composants et poss`
edent rarement un seul type de r
eseau embarqu
e. Ils privil
egient davantage lutilisation conjugu
ee :
Dun r
eseau dinterconnexions point `
a point, de type maille ou crossbar (figures 1.91.10) pour les besoins de parall
elisme
elev
es entre sous-ensembles de
composants du syst`
eme
Avec un ou plusieurs bus partag
es pour les communications entre les composants de chaque sous-ensemble du syst`
eme, ces communications n
ecessitant
beaucoup de contr
ole et une
economie de surface.
Fig. 1.9 maille complètement connecte
1.4.3
Le Bus centralis
e ou partag
e:
Il sagit dimpl
ementer plusieurs liens logiques de communication par un unique
m
edium de communication `
a acc`
es partag
e : le bus. Ce m
edium permet la mise en
place de liens uni ou multidirectionnels entre un matre et un ou plusieurs esclaves.
Les bus Ethernet et USB sont deux exemples c
el`
ebres de bus partag
es. Tous les
el
ements sont susceptibles de piloter les lignes du bus de donn
ees, mais seuls un ou
certains dentre eux peuvent piloter le bus dAdresse.(figure 1.11)
Ces
el
ements sont appel
es matres du bus, les autres esclaves. Les matres ini23
Fig. 1.10 Crossbar complet
Fig. 1.11 Bus centralise

tient des transactions sur le bus avec des esclaves. Les matres peuvent aussi se
comporter en esclaves.
Le bus est allou
e dynamiquement `
a une communication, plus pr
ecis
ement `
a un
matre. Les
echanges peuvent
etre cadenc
es par :
Une horloge globale (syst`
eme) : bus globalement synchrone ;
Une horloge sp
ecifique au bus : bus de s
equencement local synchrone. Le syst`
eme devient Globalement Asynchrone et Localement Synchrone (GALS) ;
L
etat du matre et des esclaves : bus asynchrone. Le syst`
eme est toujours de
type GALS, sauf si lensemble des p
eriph
eriques est
egalement asynchrone. On
obtient alors un syst`
eme Globalement Asynchrone et Localement Asynchrone
(GALA).
Les deux derni`
eres cat
egories permettent de faire communiquer des
el
ements de
larchitecture ayant des horloges ind
ependantes, alors que la premi`
ere n
ecessite
lutilisation de la m
eme horloge pour tous les composants connect
es au bus. Ces bus
sont g
en
eralement utilis
es pour des syst`
emes ne n
ecessitant pas de larges bandes
passantes.
Le bus Advanced Multi-masters Bus Architecture (AMBA) et le bus CoreConnect
sont des exemples de bus partag
es.
24
1.4.4
Les r
eseaux en
etoile et en anneau :
Une premi`
ere alternative int
eressante au bus partag
e est les r
eseaux en
etoile,
de type Ethernet avec un serveur central, et en anneau. LOctagon a r
ecemment su
tirer parti des avantages conjugu
es de ces deux architectures.
Ces syst`
emes contiennent des commutateurs de paquets, au centre de l
etoile ou
sur chaque nud de lanneau .Elles peuvent offrir une grande bande passante dans
le r
eseau et une bande passante r
eduite moins co
uteuse avec le composant p
eriph
erique.
Fig. 1.12 Anneau decouple & Bus Etoile
1.4.5
Les r
eseaux Crossbar
Il sagit de la mise en parall`

ele de n lignes de transmission concurrentes [51].Le
r
eseau de p
eriph
eriques sarticule autour dune matrice (appel
ee FPIC ou Switch
Fabric) permettant la mise en oeuvre concurrente de plusieurs canaux de communication. La configuration de cette matrice peut
etre :
Statique par programmation de la matrice lors de la fabrication, compliquant
ainsi la r
eutilisation de la plateforme.
Dynamique par reconfiguration des interconnexions `
a chaque d
emarrage de
lapplication.
1.4.6
Les r
eseaux commut
es ou `
a maille :
Ce type de r
eseau comporte plusieurs
etages, dont le franchissement sop`
ere au
travers dun commutateur qui se charge de router le message.
Limpl
ementation de chaque commutateur peut
etre `
a base de multiplexeurs voire
`
a base de petits bus crossbar. La propagation de linformation peut suivre lun des
deux sch
emas suivants :
25

Une connexion source-destination (aussi appel
ee session) permettant le transport continue et transparent de linformation au travers des
etages ;
Une propagation de linformation d
etage en
etage o`
u elle est temporairement
buff
eris
ee dans une unit
e de routage. Ce mode de transmission est appel
e
wormhole.
Fig. 1.13 Interconnexions totales
Fig. 1.14 Topologie hybride bus
Fig. 1.15 Liaison des nuds à des commutateurs

Si deux paquets entrants doivent
etre rout
es vers la m
eme sortie, on parle alors
de collision, et un paquet doit
etre
elu et transmis tandis que lautre est buff
eris
e
pour ne pas
etre perdu.
Les exigences de conception dun r
eseau sur silicium :
Ces nouvelles contraintes tr`
es fortes qui p`
esent sur les r
eseaux de communication
int
egr
es d
eterminent un ensemble dexigences de conception que les concepteurs de
ces r
eseaux et les int
egrateurs de syst`
eme vont devoir sp
ecifier, impl
ementer et
evaluer pour concevoir des r
eseaux sur silicium performants. Ces exigences, ou crit`
eres,
26

sont les suivants :
1. La performance en termes de latence et d
ebit que peut garantir le syst`
eme
de communication : les syst`
emes sur silicium actuels int`
egrent plusieurs p
eriph
eriques capables chacun de r
ealiser des traitements `
a plusieurs gigabits par
seconde. Tous ces p
eriph
eriques op
erant simultan
ement, le r
eseau dinterconnexion doit leur offrir une bande passante suffisante pour
etablir entre eux des
communications.
2. Le placement et le routage des r
eseaux sur silicium qui pr
esentent le risque
doccuper une surface de silicium plus grande que les p
eriph
eriques int
egr
es.
3. Les temps de communication qui deviennent plus co
uteux que les temps de
calcul.
4. Les contraintes dordre syst`
eme deviennent pr
epond
erantes, en particulier la
v
erification et linterfa
cage du syst`
eme de communication avec les couches
logicielles basses de lapplication.
5. La testabilit
e. Les plus complexes des r
eseaux de communication peuvent embarquer de la logique de tests permettant despionner leurs
etats internes.
6. Laptitude du syst`
eme de communication `
a synchroniser des blocs cadenc
es
par des horloges diff
erentes (asynchronisme).
7. La flexibilit
e dans la d
efinition des protocoles de communication. Cest une
n
ecessit
e pour permettre la connexion au bus de blocs fonctionnels de nature
et dorigine tr`
es diverses.
8. La flexibilit
e dans la d
efinition des services offerts par le syst`
eme de communication. On peut citer : la gestion de priorit
es, lacc`
es parall`
ele aux ressources,
la m
emorisation de message. . .
9. La fiabilit
e des m
ecanismes de communication est une propri
et
e tr`
es importante. Il faut prendre en compte la fiabilit
e des protocoles de synchronisations
au niveau le plus bas.
Lensemble de ces exigences ou crit`
eres d
etermine le choix dune topologie du
r
eseau sur silicium synchrone ou asynchrone.
Ainsi les performances du r
eseau de communication vont d
ependre de la topologie
de ses composants et de leur bande passante, du nombre de liens logiques se partageant les m
emes ressources et n
ecessitant donc une latence dacc`
es `
a une ressource
partag
ee, mais aussi du protocole d
echange. La consommation du r
eseau de communication doit
etre soigneusement r
eduite car le r
eseau repr
esente une part tr`
es
importante de la charge de fonctionnement dun syst`
eme sur silicium. En outre, le
r
eseau dinterconnexion est `
a la fois un
emetteur puissant et un r
ecepteur sensible
dondes
electromagn
etiques, pouvant parasiter lensemble du syst`
eme.
Enfin, la surface occup
ee sur le circuit par le r
eseau doit rester la plus faible possible
par rapport `
a la surface attribuable sur ce m
eme circuit aux unit
es de calcul.
27

Tous ces crit`
eres ne se retrouvent pas de mani`
ere critique dans toutes les applications.Cependant une infrastructure de communication se doit aujourdhui d
etre
con
cue performante bien s
ur, mais
egalement flexible afin d
etre r
eutilisable pour
le plus grand nombre possible dapplications.
Conclusion
Cette br`
eve introduction aux concepts qui composent les syst`
emes embarqu
es
nous permet de constater que pour concevoir des applications pour ce type de
plateformes on doit prendre en consid
eration leurs sp
ecificit
es. Larchitecture doit
r
epondre aux besoins de lapplication et cette derni`
ere prends en consid
eration leurs
caract
eristiques. Cest-`
a-dire qu`
a un moment de la conception du syst`
eme on ne
peut concevoir lapplication sans le mat
erielle sur lequel elle va
etre ex
ecut
ee et on
ne peut arr
eter le mat
eriel sans connatre le type dapplication quil va supporter.
Do`
u la m
ethodologie ou flot de co-conception quon va introduire dans le chapitre
suivant.
28
Chapitre 2
Flots de conception dans les SOC

Sommaire
2.1
La notion de mod`
ele . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
2.2
LIng
enierie Dirig
ee par les Mod`
eles (IDM)
. . . . . . . . . . . . .
31
Model Driven Architecture MDA . . . . . . . . . . . . . . . . . . . . .
32
2.3
2.4
2.5
2.6
2.3.1
Modelisation UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
2.3.2
Extensibilite dUML : la notion de profil . . . . . . . . . . . . . . . . . .
34
GASPARD : Flot de conception pour les SOC . . . . . . . . . . . . .
37
2.4.1
Modelisation des applications DSP . . . . . . . . . . . . . . . . . . . . .
39
2.4.2
Principe de modelisation dans Gaspard2 . . . . . . . . . . . . . . . . . .
40
2.4.3
Nud Direct Acyclique : . . . . . . . . . . . . . . . . . . . . . . . .
41
2.4.4
Nud r
ep
etitif : . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
Lenvironnement GASPARD 2 . . . . . . . . . . . . . . . . . . . . . .
42
2.5.1
Le paquetage Component . . . . . . . . . . . . . . . . . . . . . . . . . .
42
2.5.2
Le paquetage factorisation . . . . . . . . . . . . . . . . . . . . . . . . . .
44
2.5.3
Paquetage Application . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
2.5.4
Le paquetage HardwareArchitecture . . . . . . . . . . . . . . . . . . . .
50
2.5.5
Le paquetage association . . . . . . . . . . . . . . . . . . . . . . . . . .
52
Conclusion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
53
2.1.
La notion de modèle
Dans ce chapitre, nous presentons la deuxième partie du contexte de notre
etude concernant la mod

elisation `
a haut niveau et la conception des syst`
emes sur
puce. Cette approche est bas
ee sur la m
ethode dIng
enierie Dirig
ee par les Mod`
eles
(IDM ou MDE en anglais) qui permet de faciliter l
etude et le d
eveloppement de
ces syst`
emes. LIDM, apparue vers la fin des ann
ees 1990, sest particuli`
erement d
evelopp
ee lors de la parution de linitiative Model Architecture [62] de lObjet management Groupe. Comme son nom lindique, lIDM est une approche dont l
el
ement
cl
e est la notion de mod`
ele. Apr`
es avoir introduit les principes de base de cette
d
emarche, nous allons pr
esenter lenvironnement de d
eveloppement GASPARD2,
principalement con
cu pour la conception des syst`
emes sur puce d
efini autour des
applications et darchitectures bas
ees sur Array-OL.
2.1
La notion de mod`
ele
Le but dun mod`

ele est de proposer une abstraction simplifier dune certaine
r
ealit
e ou de l
el
ement mod
elis
e en omettant certains d
etails et en ne laissant apparatre que les informations qui seront utiles `
a lutilisateur du mod`
ele. Dans [40],
BEZIVIN fournit une pr
esentation tr`
es d
etaill
ee des principaux concepts de lIDM.
Il se sert de la carte g
eographique pour expliquer le r
ole de mod`
ele. En effet, la carte
est un mod`
ele de la r
ealit
e, une simplification du monde r
eel dans lequel on ne va
laisser apparatre de mani`
ere compr
ehensible quun nombre limit
e dinformations.
On peut aussi repr
esenter une r
ealit
e par plusieurs mod`
eles. Chacun mod
elisant un
domaine pr
ecis. Ainsi une personne d
esirant obtenir des informations sur un terrain
va alors utiliser diff
erents types de cartes suivant quelle sint
eresse `
a la g
eopolitique,
l
economie, la g
eologie ou encore la circulation routi`
ere.
Dans le cas des syst`
emes sur puce, les d
etails dimpl
ementation seraient par
exemple abstraits. Merise [38], SSADM [31] et UML [14] sont des exemples de
m
ethodes de mod
elisation. Ces m
ethodes permettent de manipuler le concept de
mod`
ele appliqu
e`
a linformation en proposant des concepts et une notation permettant de d
ecrire le syst`
eme `
a concevoir. Chaque
etape du cycle de d
eveloppement
du syst`
eme produit un ensemble de documents le plus souvent constitu
es de diagrammes permettant aux diff
erents acteurs du projet de partager leurs points de
vue sur le syst`
eme.
Leur lourdeur et leur d
eficit de souplesse en r
eaction `
a l
evolution rapide des logiciels ont parfois
et
e`
a lorigine de critiques qui ont conduit `
a la notion de mod`
eles
contemplatifs essentiellement destin
es `
a la communication et `
a la compr
ehension.
Ces mod`
eles restent toutefois passifs `
a la production, contribuant `
a laisser, comme
cest le cas depuis plus de cinquante ans, le code au cur du processus de production
logicielle. LIDM tente de combler ce manque au niveau des m
ethodes tradition30
2.2.
LIngenierie Dirigee par les Modèles (IDM)
nelles de mod
elisation en fournissant un cadre de d
eveloppement logiciel au sein
duquel les mod`
eles passent de l
etat contemplatif (passif ) `
a l
etat productif (actif ),
cest-`
a-dire compr
ehensibles et interpr
etables par les machines.
2.2
LIng
enierie Dirig
ee par les Mod`
eles (IDM)
Les syst`
emes
etudi
es peuvent
etre mod
elis
es selon diff
erentes approches adapt
ees
`
a la nature de ces syst`
emes et au contexte dapplication dans lequel ils sont d
efinis.
Parmi ces approches, lIng
enierie Dirig
ee par Les Mod`
eles pr
esente une contribution importante dans le domaine de la conception de syst`
emes logiciels [84]. Elle
repr
esente une forme ding
enierie g
en
erative, par laquelle tout ou partie dune application est g
en
er
ee `
a partir des mod`
eles.
On peut voir lIDM comme une famille dapproches qui se d
eveloppent `
a la fois dans
les laboratoires de recherche et chez les industriels impliqu
es dans les projets de
d
eveloppement logiciels. Cette approche offre un cadre m
ethodologique et technologique qui permet dunifier diff
erentes fa
cons de faire dans un processus homog`
ene.
Il est aussi possible dutiliser la technologie la mieux adapt
ee pour chacune des
etapes du d
eveloppement, tout en ayant un processus de d
eveloppement global unifi
e. Le code source, dans lIDM, nest plus consid
er
e comme l
el
ement central dun
syst`
eme, mais comme un
el
ement d
eriv
e de la fusion d
el
ements de mod
elisation.
L
etude est bas
ee sur la construction de mod`
eles qui occupent la place principale
dans le cycle de d
eveloppement du syst`
eme, et doivent en contrepartie
etre suffisamment pr
ecis afin de pouvoir
etre interpr
et
es ou transform
es par des machines
vues comme un ensemble de transformation de mod`
eles. G
en
eralement, lIDM peut
etre d
efini autour de trois concepts de base : les mod`
eles, les m
eta- mod`
eles et les
transformations [figure 2.1].
Pour borner le nombre de couches superposables, on d
etermine un type de m
etamod`
ele particulier appel
e m
eta-m
eta-mod`
ele. La particularit
e de celui-ci est quil
est capable de sauto d
ecrire : Il est donc conforme `
a lui-m
eme. En effet, un m
etam
eta-mod`
ele est un m
eta-mod`
ele introduisant des notions permettant de d
efinir
des m
eta-mod`
eles : On va donc pouvoir utiliser ces notions pour d
efinir le m
etam
eta-mod`
ele.
Un des apports essentiels de lapproche IDM, consiste `
a automatiser la transformation de mod`
eles. Il sagit de transformer le code dun langage en un autre, ou une
mod
elisation abstraite en une structure de classe, ou m
eme un mod`
ele de donn
ees
en un autre mod`
ele tout en assurant que les propri
et
es des donn
ees sont conserv
ees
lors de la transformation. Dans ce contexte, la v
erification de mod`
eles bas
ee sur des
approches formelles donnant de sp
ecifications rigoureuses a pour objectif de garantir que les mod`
eles poss`
edent toutes les qualit
es attendues, en particulier lorsquils
31
2.3. Model Driven Architecture MDA
Fig. 2.1 Architecture en 4 couches employee par IDM
ont en charge de mod

eliser la fabrication de syst`
emes critiques d
evelopp
es dans des
secteurs comme les transports ferroviaires, lavionique, le spatial, les t
el
ecommunications ou l
energie. Lapproche IDM ouvre ainsi de nouvelles perspectives dans le
cadre de la conception des syst`
emes embarqu
es critiques. De plus, une caract
eristique principale de lapproche IDM consiste `
a favoriser l
etude s
epar
ee des diff
erents
aspects du syst`
eme. Cette s
eparation augmente la r
eutilisation et aide les membres
de l
equipe de conception `
a partager et s
echanger leurs travaux ind
ependamment
de leur domaine dexpertise. Ce concept est particuli`
erement int
eressant dans le
domaine de conception des syst`
emes sur puce o`
u les deux technologies logicielle et
mat
erielle vont interagir pour la d
efinition du comportement global du syst`
eme.
2.3
Model Driven Architecture MDA
Le MDA est une variantedynamiques1 de lIDM d

efinie par lOMGdynamiques2 (Object
Management Groupe). Cette approche fournit un ensemble de directives permettant de s
eparer les contraintes fonctionnelles des contraintes techniques, elle est
bas
ee sur lutilisation de mod`
eles pour la description des syst`
emes logiciels `
a d
evelopper.
Le MDA est bas
e sur la description du syst`
eme `
a plusieurs niveaux dabstractions
en s
eparant sa sp
ecification fonctionnelle des d
etails de sa plateforme dex
ecution
1
2
Historiquement, lapproche MDA a ete proposee avant lapproche IDM

http ://www.omg.org
32

et des contraintes techniques.
Ainsi ce concept fournit une approche et des outils pour :
Sp
ecifier les fonctionnalit
es du syst`
eme ind
ependamment de sa plateforme
dex
ecution (niveau PIM : Platform Independent Model),
Sp
ecifier les plateformes dex
ecution,
Choisir une plateforme particuli`
ere pour le syst`
eme, et
Transformer la sp
ecification du syst`
eme vers une sp
ecification plus adapt
ee `
a
la plateforme choisie (niveau PSM : Platform Specific Model).
Dans la premi`
ere
etape du MDA (PIM) on r
ealise un mod`
ele ind
ependamment
de toutes plateformes dex
ecution. Le PIM repr
esente uniquement les caract
eristiques fonctionnelles et le comportement du syst`
eme sous forme dun mod`
ele simple
et claire. La clart
e de ce mod`
ele permet aux concepteurs de mieux comprendre les
fonctionnalit
es du syst`
eme, et donc de pouvoir v
erifier ses caract
eristiques et sa
coh
erence. La deuxi`
eme phase dans le processus MDA consiste `
a transformer le
PIM vers un PSM. Le PSM permet dobtenir un mod`
ele sp
ecifique `
a la plateforme
dex
ecution utilis
ee pour la mise en uvre du syst`
eme. A ce niveau, les caract
eristiques dex
ecution et les informations technologiques sont prises en compte dans la
description du mod`
ele [71].
Les transformations entre les niveaux PIM e PSM sont g
en
eralement effectu
ees
via des outils automatis
es tel que QVT (Queries/Views/Transformations) [32], le
langage de transformation de mod`
eles standardis
e par lOMG. Lapproche MDA
se pr
esente sous la forme dun ensemble de standards utilis
es pour cr
eer un mod`
ele et laffiner jusqu`
a obtenir, id
ealement, un produit fini, comme du code source.
Cette approche fait g
en
eralement appel `
a lutilisation de langages de mod
elisation
et doutils de d
eveloppement commun standardis
es.
2.3.1
Mod
elisation UML
LUML (Unified Modeling Langage)[61] est des plus r

epandu M
eta-mod`
ele. Il a
et
e standardis
e par lOMG et vise la mod
elisation de syst`
eme informatique de tout
type. Son principal atout en plus d
etre r
epandu et connu de beaucoup dutilisateurs
est son caract`
ere g
en
eraliste. Cependant, dans sa forme livr
ee, il ne permet pas
une utilisation directe dans un processus ding
enierie dirig
ee par les mod`
eles du
fait de sa s
emantique g
en
eraliste qui manque de pr
ecision et ne permet pas de
produire directement un syst`
eme. Plus pr
ecis
ement, de nombreux points laissent
apparatre une s
emantique ambigu
e, laissant lutilisateur comme seul d
ecideur de
la signification `
a leur apporter [figure2.2].
De nos jours, lutilisation dUML dans un cadre ding
enierie dirig
ee par les mod`
eles se fait par linterm
ediaire de son m
ecanisme interne de m
eta-mod
elisation que
33
Fig. 2.2 Classification des 13 diagrammes du langage UML
lon appelle profil. Un profil est un ensemble dextensions et de restrictions permettant la sp

ecialisation et la description dun domaine particulier. Les extensions sont
appel
ees st
er
eotypes, elles permettent de sp
ecialiser une ou plusieurs classes UML
et peuvent contenir de nouveaux attributs appel
es tagged values.
Lutilisation des profils permet dobtenir un pouvoir dexpression quasiment identique au pouvoir dexpression du mod`
ele tout en ayant acc`
es aux concepts existants
propos
es par UML.
2.3.2
Extensibilit
e dUML : la notion de profil
Tel quon la avanc

e dans le paragraphe pr
ec
edent, lUML est un langage de
mod
elisation g
en
eraliste. Son m
eta-mod`
ele vise `
a couvrir tous les aspects de la mod
elisation logicielle. Cependant, il arrive quen pratique son utilisation, telle quelle,
ne soit pas adapt
ee pour mod
eliser les concepts dun domaine bien particulier.
Conscients de ce probl`
eme, les auteurs de ce langage y ont introduit la possibilit
e
de le sp
ecialiser par le m
ecanisme Profil lui permettant de passer dun langage g
en
eraliste `
a un DSL (Domaine Specific Language).
Pour sp
ecialiser UML un profil joue sur diff
erents points :
Extension du m
eta-mod`
ele : Le m
ecanisme offre un moyen d
etendre le m
etamod`
ele dUML par lutilisation de st
er
eotypes. Un st
er
eotype permet d
etendre
toute m
eta-classe du langage UML (sauf la M
eta-classe st
er
eotyp
ee elle-m
eme dy34
Fig. 2.3 Specialisation dUML par le mecanisme de profil
namiques 3 ) et de cr
eer ainsi une nouvelle m
eta-classe h
eritant de toutes les propri
et
es de la m
eta-classe
etendue. Il devient aussi possible dajouter des nouvelles
propri
et
es `
a cette nouvelle m
eta-classe `
a laide de Tagged values. Il est `
a noter quil
est possible dobliger lutilisation de st
er
eotypes sur la m
eta-classe, de telle sorte
que lutilisateur ne soit plus autoris
e `
a employer le m
eta classe original dans un
mod`
ele.
Fermeture de points de variation s
emantique : En vue de pouvoir sadapter dans
diff
erents domaines, la norme UML laisse d
elib
er
ement certains points de s
emantique ouverts. Lextension dune m
eta-classe cause lh
eritage de sa s
emantique, ce
qui oblige `
a fixer les points de variation s
emantique pour le langage cr
ee en fonction
de la sp
ecialisation que lon en fait.
Ajout de contraintes OCL : La nouvelle m
eta-classe que lon cr
ee `
a laide dun
st
er
eotype sutilise `
a priori en respectant les contraintes appliqu
ees `
a la m
eta-classe
etendue. Cependant, il est possible dajouter des contraintes suppl

ementaires en
associant des contraintes OCL au st
er
eotype. Un
editeur UML suffisamment
evolu
e
sera capable dinterpr
eter ces contraintes et de signaler une erreur de mod
elisation.
Sp
ecialisation de la syntaxe graphique : Le profil permet dassocier une forme
visuelle particuli`
ere au st
er
eotype que lon d
efinit. Ce qui nous permet de sp
ecialiser la syntaxe graphique en sp
ecialisant les diagrammes. Un
editeur
evolu
e permet
de charger dynamiquement ces images et d
editer directement ce nouveau type de
diagramme.
D
efinition dune m
ethodologie de mod
elisation : Le profil une fois d
efini, il est n
ecessaire de bien le documenter, notamment en identifiant clairement les diagrammes
avec lesquels ce profil est fait pour
etre utilis
e. En effet, un st
er
eotype ne pr
ecise
pas par lui-m
eme dans quel diagramme il doit
etre utilis
e. Lorsquun
el
ement dun
3
En empechant la specialisation de la notion de stereotype, UML sempeche de modifier son mecanisme de

specialisation, ce qui permet de pouvoir interpreter un profil de manière systematique, mais qui a aussi pour effet
de limiter les possibilites de specialisation
35

m
eta-mod`
ele peut apparatre dans diff
erents diagrammes, le st
er
eotype qui l
etend
le peut aussi. Or la transformation dUML en un DSL cherche `
a choisir les repr
esentations les plus expressives pour le domaine que lon vise. Pour illustrer le
m
ecanisme de profil, imaginons que lon veuille exprimer avec UML les concepts du
m
eta-mod`
ele de la figure II-4 dont la d
efinition du profil correspondant est donn
ee
par la figure II-5.
Fig. 2.4 Exemple de metamodèle
Fig. 2.5 Exemple de profile pour le meta-modèle de lexemple de la figure precedente
On voit que le st
er
eotype <dsl-Systeme> sp
ecialise la notion de classe servira `
a
36
2.4. GASPARD : Flot de conception pour les SOC

repr
esenter la notion de syst`
eme introduite dans notre m
eta-mod`
ele. Le st
er
eotype
<dsl-composant>
etend la notion de property dUML et st
er
eotype <dsl-port>
la notion de port. On voit de plus quune tagged value est ajout
ee `
a ce dernier afin
de sp
ecifier la direction de notre <dsl-Systeme>, notion qui nexiste pas dans
le meta-mod`
ele original dUML. Enfin le st
er
eotype <dsl-connection>
etend la
notion de connector dUML.
En effet, la norme UML laisse un point de s
emantique ouvert pour les connecteurs : il est dit que ce qui rend des
el
ements connectables compatibles est un point
de variation. Dans notre cas, nous pouvons le pr
eciser en disant que les
el
ements
connectables doivent
etre des <dsl-Systeme>, et quils ne peuvent
etre connect
es
que si leurs directions exprim
ees par les tagged values sont compl
ementaires. Ceci
pourrait de plus se d
ecrire `
a laide dune contrainte OCL afin quelle soit
evalu
ee et
que loutil UML puisse v
erifier quelle est respect
ee.
2.4
GASPARD : Flot de conception pour les SOC
Gaspard [53] est un environnement de d

eveloppement permettant la co-conception
de syst`
eme sur puce dans un cadre ding
enierie dirig
ee par les mod`
eles (IDM). Il est
d
evelopp
e au sein de l
equipe DaRT et est orient
e vers les applications de traitement
de signal intensif. Ces applications sont rencontr
ees souvent dans les SOC et sont
caract
eris
ees par leur gourmandise en termes de puissance de calcul ce qui n
ecessite
la parall
elisation des traitements. Gaspard permet donc dexploiter les principes de
ling
enierie dirig
ee par les mod`
eles pour Co-mod
eliser des MPSOC ou massivement
parall`
ele qui sera utilis
e dans une application de traitement de signal intensif.
Il adopte un flot de conception en Y, ce qui permet aux concepteurs du syst`
eme
de mod
eliser de mani`
ere ind
ependante lapplication et larchitecture mat
erielle du
syst`
eme, ensuite l
etape dassociation permet de les r
eunir en pla
cant lapplication
sur larchitecture. Ces trois mod`
eles permettent, par linterm
ediaire de transformations, de g
en
erer des simulations `
a des niveaux de pr
ecision de plus en plus
importants. La v
erification formelle de la mod
elisation de lapplication est rendue
possible par la g
en
eration de langages synchrones d
eclaratifs [2] comme lustre [74]
ou Signal [34].
Lex
ecution concurrente de diff
erents processus sur une architecture multiprocesseurs est rendue possible par la g
en
eration de langages proc
eduraux comme
Fortran/Open MP. La finalit
e
etant de g
en
erer un code de simulation, avec System
C par exemple, prenant en consid
eration `
a la fois les parties mat
erielles et logicielles
du syst`
eme sur puce complet. La figure 2.6 illustre le flot de conception en Y.
37
Fig. 2.6 Flot de conception en Y de GASPARD 2
Ce m
eta-mod`
ele sinspire de standard de lOMG comme SPT [33] pour la repr
esentation de larchitecture mat
erielle, SysML pour les m
ecanismes dassociation
et UML pour lapproche de mod
elisation par composants. Gaspard offre
egalement
la possibilit
e de mod
eliser sous une forme factoris
ee des applications et des architectures r
eguli`
eres ayant un caract`
ere r
ep
etitif ; cette expression est bas
ee sur le
langage Array-Ol (que nous pr
esenterons par la suite). Un m
ecanisme de factorisation permettant de repr
esenter de mani`
ere compacte les syst`
emes r
ep
etitifs r
eguliers
bas
e sur le langage Array-Ol est pr
esent. Pr
ecisons aussi que ce m
eta-mod`
ele est
en partie `
a la base du r
ecent standard MARTE.
Il faut noter aussi que le contexte de d
eveloppement, ce nest pas le m
eta-mod`
ele
Gaspard qui est directement manipul
e mais le profil UML associ
e, ceci afin de permettre lutilisation des outils standards de mod
elisation graphiques bas
es sur UML.
Une fois mod
elis
e, le mod`
ele conforme au profil UML Gaspard est transform
e vers
un mod`
ele conforme au m
eta-mod`
ele gaspard `
a laide dune transformation de mod`
eles [70].
38
2.4.1
Mod
elisation des applications DSP
Quel est le b
en
efice que lon peut tirer par lutilisation des approches IDM
(MDE) pour faire des applications DSP (Digital Signal Processing). Il ny a pas un
seul avantage mais plusieurs, des avantages techniques `
a la convivialit
e. Ceux cit
es
ci-apr`
es constituent les plus en vue.
Interop
erabilit
e : IDM est devenu de plus en plus utilis
e comme approche pour
d
evelopper le software. Ainsi plusieurs outils sont devenus disponibles pour manipuler des mod`
eles, m
eta-mod`
eles et les transformations de mod`
eles. Ces outils souvent
attach
es `
a des standards permettent une certaine interop
erabilit
e entre eux. En utilisant les outils de transformation de mod`
ele, il est facile dextraire `
a partir dun
mod`
ele connu les formats de fichiers dentr
ee pour lallocation, lassignation et le
Scheduling.
Abstraction : Lautre point fort des MDE est labstraction. G
en
eralement les
mod`
eles sont construits pour
etre facilement lus et compris par les humains. Lutilisateur peut mod
eliser son application, le hardware et leur association comme une
seule pi`
ece en utilisant une approche descendante, ascendante ou hybride comme il
le souhaite, et r
eutiliser des parties de ce mod`
ele facilement. Labstraction devrait
aussi permettre lint
egration des heuristiques diff
erentes de placement et dordonnancement, partager des mod`
eles communs de lapplication, du mat
eriel et leurs
associations. Ces mod`
eles devraient
etre extensibles pour permettre ladaptation
de futures techniques. LIDM aide dans cet aspect en permettant une facile extension de mod`
ele.
Caract
erisation : Dans le but de d
efinir compl`
etement lapplication et les param`
etres de larchitecture mat
erielle, le graphe mod`
ele doit
etre caract
eris
e. Ces caract
eristiques sont les attributs des nuds et arcs. Certaines de ces caract
eristiques
sont sp
ecifiques `
a lapplication telles les contraintes de temps r
eel et la consommation d
energie. Dautres sont relatives `
a larchitecture tel lensemble dinstructions du processeur, fr
equence dhorloge, consommation d
energie, taille m
emoire,
largeur de bande . . .etc. Sans oublier ceux qui caract
erisent lassociation des composants dapplication aux composants de larchitecture telles les temps estim
es ou
les contraintes de placement. Ces dernieres sont repr
esent
es par des liens entre le
graphe dapplication et le graphe darchitecture.
39
2.4.2
Principe de mod
elisation dans Gaspard2
Graphe de t
ache hi
erarchique (`
a reformuler)
Un programme peut
etre d
ecompos
e en structure de boucle et un graphe de
t
aches de d
ependance acyclique (ADTG) repr
esentant le corps de chaque boucle
ou sub-routine. Le parall
elisme inh
erent dans ces graphes acycliques augmente le
parall
elisme au niveau boucle disponible dans le programme. Ainsi Un graphe repr
esentant un tel programme, avec ces boucles localement encapsul
ees comme un
seul nud de t
ache et globalement vu comme un ADTG, est appel
e graphe de t
ache
hi
erarchique (HATG Hierarchical Application Task Graph). Pour plus de simplification dans la lecture on lappellera par la suite HTG (Hierarchical Task Graph).
Le probl`
eme dordonnancement dun tel graphe avec des crit`
eres doptimisation est
tr`
es complexe, car la construction dun tel graphe n
ecessite la mod
elisation des communications inter-t
aches et inter-processeurs. Traiter ce graphe comme un ADTG
pendant lordonnancement nous fait perdre le parall
elisme pr
esent dans les nuds
locaux encapsul
es ce qui a des cons
equences sur le potentiel doptimisation.
La plupart des heuristiques de placement utilisent des graphes bas
es sur la description de lapplication et de larchitecture. Dans le but de traiter des syst`
emes
plus complexes on doit avoir une description hi
erarchique dau moins lapplication.
Il est aussi important davoir une description hi
erarchique de larchitecture afin
daccommoder les granularit
es. Avec
ca on peut commencer par une optimisation
grossi`
ere quon essaye de raffiner par la suite. Une autre exigence dans ces repr
esentations est la mod
elisation des r
ep
etitions telles les boucles dans les applications ou
les unit
es SIMD dans le Hardware. Car de cette repr
esentation d
epend le gain de
la parall
elisation des traitements et des donn
ees. Puisque nous d
ependons de lalgorithme doptimisation utilis
e pour placer et ordonnancer ces structures r
ep
etitives
on doit les voir comme des entit
es indivisibles ou comme une r
ep
etition de structure
(r
eguli`
eres) ou m
eme comme de non structure (irr
eguli`
ere) densemble de t
aches.
On a propos
e des mod`
eles de graphe hi
erarchique pour d
ecrire le calcul intensif
des applications embarqu
ees et les plateformes de SOC [[73],[5]]. Ces mod`
eles sont
bas
es sur le profil UML2 et sont incorpor
es dans loutil de co-modeling Gaspard2
[53].
Une application Gaspard2 est un ensemble de composants connect
es entre eux
par des d
ependances de donn
ees. Ces composants doivent
etre construits `
a partir dun bas niveau (visuel ou textuel) composant. Les donn
ees
echang
ees entre
ces composants sont des donn
ees parall`
eles (tableaux multidimensionnelles dobjets
el
ementaires). Le composant graphe introduit le parall
elisme de t
ache et les
composants peuvent
etre utilis
es dans des it
erateurs parall`
eles de donn
ees. Sil y a
utilisation de ces it
erateurs parall`
eles de donn
ees, le composant donn
e est ex
ecut
e
40

en parall`
ele sur des
el
ements dun tableau dobjets.
Lid
ee fondamentale, ici, est que les composants de base doivent
etre parall`
eles,
le programmeur na pas `
a apprendre une librairie de programmation parall`
ele ou un
langage lui permettant intuitivement de les composer en parall`
ele, tout est donn
e
au niveau visuel, ce qui permet un d
eveloppement rapide.
Pour construire une application r
eguli`
ere distribu
ee, Gaspard 2 impl
emente le
mod`
ele Array-Ol [[17],[18]]. Il propose une approche `
a deux niveaux. Le premier
est le niveau graphe de t
ache qui permet lordonnancement de t
aches comme une
fonction de d
ependance entre t
aches et tableaux. Le deuxi`
eme niveau permet de
d
efinir les r
ep
etitions parall`
eles de composants.
Le mod`
ele math
ematique impl
ement
e dans Gaspard 2 est un HTG avec deux
types de nuds.
Nud Acyclique Direct (DAN Directed Acylique Node) qui est d
efini comme
un de DAG.
Nud R
ep
etitif (RN) qui repr
esente la r
ep
etition parall`
ele de donn
ees dun
nud.
La seule structure de donn
ee qui est autoris
ee dans GASPARD 2 (et Array-ol)
concerne les tableaux multidimensionnels. Cette structure de donn
ees est adapt
ee
au traitement de signal dont limportance dans les SOC a
et
e soulign
ee pr
ec
edemment. Les applications de traitement de signal sont habituellement organis
ees autour
dun flot infini de donn
ees r
eguli`
eres. Ce flot est captur
e dans des tableaux avec si
cest possible une dimension infinie. Certaines dimensions spatiales de tableaux utilis
es dans le traitement de signal correspondent `
a des capteurs.
2.4.3
Nud Direct Acyclique :
Ces nuds sont des DAG de nud connect

es entre eux par des arcs repr
esentant
la d
ependance de donn
ees entre ces nuds. Les donn
ees repr
esent
ees par ces arcs
sont des tableaux. Ainsi ce graphe est un graphe de d
ependance et non un flot de
donn
ees.
2.4.4
Nud r
ep
etitif :
Ces nuds permettent de repr

esenter les r
ep
etitions de donn
ees parall`
eles des
sous nuds. Ces r
ep
etitions prennent comme entr
ees/sorties des parties de tableaux
en entr
ee et en sortie du nud r
ep
etitif. Ces parties de tableaux ont toutes la m
eme
41
2.5. Lenvironnement GASPARD 2

forme et sont appel
es Motifs (patterns). Les Motifs en sortie sont produits en appliquant le sous-nud sur le Motif du tableau en entr
ee.
Toutes les r
ep
etitions des sous-nuds sont ind
ependantes et d
efinies dans un
espace de r
ep
etition Q. Pour chaque entr
ee/sortie du nud r
ep
et
e, on a les informations n
ecessaires. Dans le Chapitre 3, on d
ecrira comment on obtient ces
informations gr
ace `
a Array-Ol.
2.5
Lenvironnement GASPARD 2
Comme on la avanc
e pr
ec
edemment, dans le contexte de d
eveloppement, ce
nest pas le m
eta-mod`
ele Gaspard qui est directement manipul
e mais le profil UML
associ
e, ceci afin de permettre lutilisation des outils standards de mod
elisation graphiques bas
es sur UML. Une fois mod
elis
e, le mod`
ele conforme au profil UML gaspard est transform
e vers un mod`
ele conforme au m
eta-mod`
ele gaspard `
a laide dune
transformation de mod`
ele. Les principaux paquetages composants le m
eta-mod`
ele
permettent de mod
eliser les notions de composants, de factorisation, dapplication,
darchitecture et dassociation. La figure 2.7 illustre lorganisation des diff
erents
el
ements constitutifs du profil, agenc
es de mani`
ere `
a bien illustrer le Y form
e par
les paquetages application, hardware architecture et association.
2.5.1
Le paquetage Component
Lun des concepts de base du m

eta-mod`
ele Gaspard est le paquetage Component
qui permet de d
efinir lapproche orient
ee composant qui sera utilis
ee pour la mod
elisation. Ce paquetage `
a travers les outils quil apporte permet de construire dune
fa
con structur
ee des applications et des architectures mat
erielles. En adoptant les
concepts apport
es par UML, il permet de mettre en uvre diff
erents m
ecanismes.
Le m
ecanisme dencapsulation permet de rendre la d
efinition dun composant ind
ependante de lenvironnement dans lequel il est utilis
e. Cette s
eparation est trac
ee
entre lint
erieur du composant (son impl
ementation) et la fa
con dont il per
coit son
environnement, ou la fa
con dont il est per
cu par son environnement. La couche hi
erarchique est apport
ee par un m
ecanisme de composition et dassemblage pour organiser lint
erieur du composant. Cette couche permet dexprimer la structure dun
composant car il peut
etre compos
e de plusieurs composants. Afin, par exemple, de
simplifier les fonctionnalit
es, lassemblage de ces composants permet alors dimpl
ementer des comportements plus complexes. Le component est l
el
ement r
eutilisable
manipul
e au sein dun mod`
ele GASPARD. IL est d
efini par un ensemble dinterfaces propos
ees par linterm
ediaire de Ports et par sa structure compos
ee par un
assemblage dinstances reli
ees par des connecteurs. Si un composant A contient
42
Fig. 2.7 Vue densemble des differents paquetages constituants le profil Gaspard
une instance dun composant B, cela signifie que le composant A utilise B dans son
impl
ementation. Elementery component est un composant ne contenant aucune instance ce qui nous permet de le rapprocher dune boite noire , d
esignant un niveau
de pr
ecision `
a partir duquel le mod`
ele napporte plus dinformations.
La figure 2.8 illustre ces diff
erents concepts avec un exemple dunit
e de calcul
Processing Unit d
efinie `
a laide de trois composants
el
ementaires : un processeur
MIPS, une m
emoire Memory et un crossbar Crossbar4.
Selon le cas o`
u linterface, re
coit ou
emet des donn
ees, les ports utilis
es peuvent
etre qualifi
es de In ou out. En labsence de qualificatif, linterface est capable
d
emettre et de recevoir. Ces qualificatifs sont tr`
es importants vis-`
a-vis des connexions,
en effet les connecteurs de d
el
egation, reliant un composant `
a une instance, ne
peuvent connecter que des ports ayant la m
eme orientation tandis que les connecteurs dassemblage, reliant deux instances, ne peuvent connecter que des ports ayant
des orientations oppos
ees.
43
Fig. 2.8 Un exemple de composant gaspard, processing Unit compose de trois sous composants
instancies sous les noms cb, mem et mips. Les ports et les connecteurs indiquent les relations
entre les instances
2.5.2
Le paquetage factorisation
Ce paquetage est tr`

es important dans GASPARD, car cest `
a travers ces concepts
quon rend le m
eta-mod`
ele tr`
es adapt
e aux syst`
emes massivement parall`
eles r
eguliers. Des concepts permettent de repr
esenter sous une forme tr`
es compacte la
r
ep
etition dun ensemble de composants identiques. Il propose au d
eveloppeur de
syst`
emes sur puce multiprocesseurs les concepts apport
es par Array-Ol, mais g
en
eralis
es afin den permettre lutilisation pour mod
eliser les applications mais
egalement les architectures mat
erielles et les associations.
La notion de Shape
Ce concept permet dindiquer quun
el
ement poss`
ede une multiplicit
e, il peut
etre appliqu
e `
a une instance ou `
a un port. Shape est appliqu
e sur un
el
ement vu
comme une collection compos
ee dun nombre d
el
ements quil d
etermine. Cette collection est structur
ee avec un tableau multidimensionnel et son expression se fait
par linterm
ediaire dun vecteur de nombres entiers strictement positifs, chaque
composante du vecteur d
eterminant la taille, cest-`
a-dire le nombre d
el
ements, de
la dimension du tableau associ
e. La figure 2.9 illustre ce concept avec un exemple
repr
esentant 4 instances dun composant organis
ees sous la forme dun tableau bidimensionnel de 2x2 instances.
A noter quune dimension peut
etre d
eclar
ee comme infinie en sp
ecifiant le symbole `
a la place dun entier, cette sp
ecificit
e ne sapplique
evidemment qu`
a lapplication pour repr
esenter un traitement r
ep
et
e de mani`
ere infinie dans le temps,
d
efinir un composant mat
eriel aux ressources physiques illimit
ees nayant bien s
ur
pas de sens [70].
44
Fig. 2.9 Representation dun composant Gaspard2 avec une multiplicite bidimensionnelle (sur
la gauche) et son equivalent en UML2 (sur la droite)
Notion de Tiler
Le concept de Tiler a
et
e cr
ee pour acc
eder aux
el
ements des tableaux multidimensionnels caract
eris
es par un Shape dune fa
con simple et compact. On commence
par identifier au sein de ces tableaux des ensembles de points quon appelle Motifs
, appel
es aussi tuile (Tile en anglais), ils sont caract
eris
es par un espacement r
egulier des diff
erents points cest ce quon appelle lajustage (fitting en anglais). Avec
un ensemble de Motifs il est donc possible de parcourir tout le tableau afin den
r
ecup
erer tous les
el
ements. Comme les
el
ements des motifs, les diff
erentes tuiles
sont caract
eris
ees par un espacement entre elles, cest le pavage (paving en anglais).
La couverture compl`
ete dun tableau n
ecessite trois informations suppl
ementaires :
Une origine, point faisant office de r
ef
erence, un espace de r
ep
etition d
elivrant une
information concernant le nombre de tuiles `
a utiliser afin de parcourir tout le tableau et la taille du motif (le nombre de points `
a consid
erer pour chaque dimension
du tableau). Ce sont l`
a les notions de base du mod`
ele de calcul Array-ol quon
introduira dans le chapitre suivant. Pour un motif donn
e, la tuile correspondante
est identifi
ee `
a partir dun
el
ement de r
ef
erence dans le tableau, nous lappellerons
ref. Lespacement des diff
erents
el
ements au sein de la tuile est d
etermin
e par linterm
ediaire de la matrice dajustage et en rapport avec le point de r
ef
erence. Le
nombre de lignes de la matrice correspond au nombre de dimensions du tableau et
le nombre de colonnes correspond au nombre de dimensions du motif que lon veut
r
ecup
erer. Chaque
el
ement ei de la tuile est d
etermin
e par la somme des coordonn
ees du point de r
ef
erence et de la multiplication de la matrice dajustage par les
coordonn
ees i de l
el
ement du motif, comme exprim
e dans la formule suivante :
i0 i < S pattern , ei = ref + F.imodSarray
45

Spattern repr
esentant la forme du motif, Sarray repr
esentant la forme du tableau et F
etant la matrice dajustage.

Dans la figure 2.10 on pr
esente un exemple de Tiler dans une application. Le
connecteur situ
e entre les ports m1 et A, par exemple, le port m1 a une dimension
128x128 et le port A a une dimension de 8x8, le Tiler permet de d
ecomposer le
tableau situ
e sur m1 par bloc de 8x8
el
ements contigus.
Fig. 2.10 Illustration de la notion de Tiler
La notion de Reshape
Le concept de Reshape a
et
e introduit afin de permettre la liaison
el
ement par
el
ement de deux tableaux ayant des formes diff
erentes [70]. Au niveau conceptuel, un
reshape se contente simplement dassocier deux Tilers lun apr`
es lautre, le premier
Tiler ayant pour t
ache de rassembler par motif les
el
ements du premier tableau
vers un motif interm
ediaire et le second Tiler ayant pour fonction de r
epartir les
el
ements du motif interm
ediaire sous une nouvelle forme dans le tableau de sortie.
En plus des deux Tilers, , le Reshape apporte les notions de Pattern Shape et
de Repetition Space, le PatternShap permettant de repr
esenter la forme du motif
interm
ediaire et le Repetition-Space permettant dexprimer lespace de r
ep
etition
parcouru afin de compl`
etement remplir le tableau de sortie. La figure 2.11 illustre
un exemple de Reshape. Dans cet exemple, il y a deux t
aches t1 et t2 , chaque ligne
du tableau de sortie t1 est rang
ee dans une colonne du tableau dentr
ee t2 . On passe
donc dun tableau de dimension 3x2 `
a un tableau de dimension 2x3.
Figure 2.11 : Un exemple de Reshape
Ce concept permet une repr
esentation plus compacte permettant d
eviter lintroduction dune t
ache f antme ne faisant que consommer les motifs dun tableau
dentr
ee pour ensuite les ranger dans un tableau de sortie par linterm
ediaire de
46
Fig. 2.11 Un exemple de Reshape
Tiler comme le montre la figure 2.12.
Fig. 2.12 Reshape exprime à laide dune tache fant

ome
Les notions dInterRepetition et de DefaultLink

Ces deux concepts sont dans le paquetage Factorization. Le concept InterRepetition permet de qualifier les liens existant entre plusieurs
el
ements membres du
m
eme tableau, il permet aussi de d
efinir des d
ependances de donn
ees entre les diff
erentes it
erations ou des liens de communication en ce qui concerne les
el
ements
dune grille, figure 2.13.
Le concept DefaultLink permet dexprimer les connexions irr
eguli`
eres pouvant
se situer sur les bords dun tableau d
el
ements.
47
Fig. 2.13 Illustration des liens Inter -Repetition, à gauche le composant Gaspard representant
une grille à droite son equivalent en UML
2.5.3
Paquetage Application
Ce paquetage `
a travers les notions quil apporte permet dassocier une s
emantique propre `
a tout composant repr
esentant une partie de lapplication. Avec cette
s
emantique, les applications peuvent
etre repr
esent
ees par langage de flot de donn
ees sappuyant sur les concepts d
efinis dans les paquetages Component et Factorization. Ce langage est tr`
es fortement inspir
e de Array-Ol que nous allons voir par
la suite. Par application on d
efinit le comportement du syst`
eme en fonction des
entr
ees quon lui fournit, tout ou partie de lapplication peut donc
etre sous forme
logicielle ou mat
erielle.
Lobjectif est de permettre lexpression dapplications de traitement de signal
intensif travaillant avec des tableaux multidimensionnels. La mise au point de telles
applications nest pas complexe `
a cause des fonctions
el
ementaires les constituant
mais de leur association ainsi que de la mani`
ere dacc
eder aux tableaux utilis
es. La
finalit
e de tels syst`
emes
etant den ressortir des performances, il est indispensable
dutiliser le parall
elisme potentiel offert par lapplication de mani`
ere `
a lassocier au
parall
elisme disponible offert par larchitecture mat
erielle.
Pour constituer ce langage un certain nombre de principes de base ont
et
e choisis :
1. Expression de tout le parall
elisme potentiel ;
2. Expliciter toutes les d
ependances de donn
ees ;
3. Les tableaux sont `
a assignation unique, chaque
el
ement peut
etre lu plusieurs
fois mais ne peut
etre
ecrit quune seule fois ;
4. Il ny a pas de diff
erentiation dans le traitement des dimensions spatiale et
48

temporelle dans les tableaux
Ainsi lapplication est vue comme un graphe de d
ependance o`
u les nuds repr
esentent des t
aches et les ar
etes les d
ependances entre elles. En plus le graphe
poss`
ede un caract`
ere hi
erarchique, de telle fa
con que chaque nud peut contenir
lui-m
eme un graphe de d
ependance. Ce qui rend lapplication vue comme un ensemble de t
aches connect
ees par linterm
ediaire de ports. Au niveau de Gaspard les
t
aches sont repr
esent
ees par des instances de ApplicationComponents et les ports
par des Ports.
Trois types de t
aches ont
et
e recens
ees :
Les t
aches
el
ementaires, repr
esent
ees par des instances dElementComponent
et qui correspondent `
a des fonctions cach
ees `
a lint
erieur de boites noires ;
Les t
aches compos
ees, repr
esent
ees par linstance dun Component contenant
plusieurs instances, de telles t
aches correspondent `
a des graphes de d
ependances ;
Les t
aches r
ep
et
ees, repr
esent
ees par des instances de Component sur lesquelles des Shape ont
et
e sp
ecifi
ees.
Des tableaux multidimensionnels pouvant avoir une dimension infinie assurent la
communication entre les t
aches. Chaque tableau
etant sp
ecifi
e par une Shape pour
pr
eciser sa taille. Les ports sont
egalement sp
ecifi
es avec une Shape et avec le type
des
el
ements du tableau auquel il acc`
ede.
Parall
elisme de t
aches
La notion de parall
elisme de t
aches na de sens que dans le contexte de t
aches
compos
ees. Dans ce cas, la composition interne dun composant correspond `
a un
graphe acyclique orient
e, chaque nud du graphe correspond `
a une t
ache et chaque
arr
ete correspond `
a une d
ependance reliant deux ports de m
eme taille et de m
eme
type, un nud repr
esentant une instance et une arr
ete connecteur reliant port de
sortie et port dentr
ee [70]. On na pas de contrainte sur le type et la taille des
ports dentr
ee et de sortie dune t
ache. Cette derni`
ere peut lire deux tableaux `
a
une dimension pour ne produire quun tableau `
a deux dimensions. La figure 2.14
pr
esente un parall
elisme de t
aches avec un exemple contenant 4 t
aches : un producteur, deux consommateurs et un agr
egateur. Celui ci poss`
ede une d
ependance sur
les consommateurs C1 et C2 . Les ports de chaque composant sont orient
es, imposant
lex
ecution du producteur p avant les autres t
aches. Les deux consommateurs C1 et
C1 peuvent
etre ex
ecut
es en parall`
ele.
49
Fig. 2.14 Exemple dune tache composee dans Gaspard, elle est constituee de 4 sous taches,
p, c1 , c2 et a. La tache a possède deux dependances sur c1 et c2 , possedant elle-meme chacune
une dependance sur p. Les taches c1 et c2 peuvent etre executee en parallèle
Parall
elisme de donn
ees
Il est toujours li
e`
a lexpression des r
ep
etitions de t
aches, lid
ee
etant que chaque
r
ep
etition de la t
ache est ind
ependante : il ny a pas dordre impos
e pour lex
ecution,
les t
aches peuvent donc
etre ex
ecut
ees en parall`
ele. Les connectors qui interviennent
ne peuvent
etre sp
ecifi
es quavec des Tilers. Ils vont permettre de d
ecouper les tableaux pr
esents sur les ports du composant p`
ere, pour en faire des motifs qui seront
pr
esents sur les ports du composant lui-m
eme [70].
Ainsi chaque r
ep
etition de t
ache na le droit dacc
eder quaux sous ensembles des
tableaux du composant. La figure 2.15 pr
esente un exemple dapplication mettant
en uvre le parall
elisme de donn
ees. E composant A plus B contient une t
ache Sum
r
ep
et
ees 16x16 fois et prenant en entr
ee les donn
ees de deux matrices pour en sortir
un r
esultat. Chaque r
ep
etition de la t
ache va soccuper de traiter deux motifs des
tableaux dentr
ee.
Le paquetage Application apporte des notions de s
emantique permettant de repr
esenter les d
ependances entre les t
aches et les r
ep
etitions de t
aches. Il est
egalement possible de d
eterminer les d
ependances entre un
el
ement du tableau de sortie
et les
el
ements du tableau dentr
ee. Toutes ces informations permettent `
a la fin, de
d
eduire un ordre dex
ecution des t
aches.
2.5.4
Le paquetage HardwareArchitecture
La d
efinition de la composition de larchitecture mat
erielle du syst`
eme sur puce
se fait `
a laide des
el
ements apport
es par ce paquetage. Les notions du paquetage
Component permettent de repr
esenter la structure et la hi
erarchie du mat
eriel `
a
50
Fig. 2.15 Parallelisme de donnees
un haut niveau. Les liaisons directes entre composants sont repr

esent
ees par les
ports et les connecteurs, un connecteur
etant
equivalent `
a une connexion de transaction cest-`
a-dire quil repr
esente un ensemble de fils. Les diff
erents
el
ements de
larchitecture mat
erielle ont
et
e classifi
es dans quatre cat
egories : Processor, Memory, Communication et I/O. Chaque cat
egorie
etant elle-m
eme d
ecompos
ee en
un ensemble de sous types plus pr
ecis assurant un niveau de d
etails suffisant pour
repr
esenter de mani`
ere globale larchitecture du syst`
eme afin dy associer une application. Le comportement de larchitecture se situe au niveau des boites noires
repr
esentant des composants mat
eriels
el
ementaires. La figure 2.16 en illustre un
exemple.
Fig. 2.16 Un exemple de composant gaspard, processing Unit compose de trois sous composants
instancies sous les noms cb, mem et mips correspondant respectivement à un crossbar, une
memoire et un processeur
Il faut noter aussi que les concepts introduits par le paquetage Factorization
concernant les multiplicit
es peuvent
etre appliqu
es aux composants mat
eriels, la
ecification dune grille de processeurs et ce dune mani`
ere
figure 2.17 illustre la sp
51

tr`
es compacte.
Fig. 2.17 Composant materiel Gaspard representant une grille de 16 unites de calcul reparties
sur deux dimensions
2.5.5
Le paquetage association
Ce paquetage est le dernier du m

eta-mod`
ele MARTE, il a permis de compl
eter
le mod`
ele Y gr
ace aux notions quil a apport
e. Gr
ace `
a lui on peut faire un lien
entre une application et une architecture mat
erielle servant de support dex
ecution.
Lassociation consiste donc `
a placer les
el
ements de lapplication sur des
el
ements
de larchitecture mat
erielle. Les allocations peuvent
etre de plusieurs types :
TaskAllocation permet de d
ecrire lassociation dune t
ache sur une ressource
de calcul (processeur, acc
el
erateur mat
eriel),
DataAllocation permet dindiquer comment synchroniser deux m
emoires, son
utilisation est indiqu
ee lorsque plusieurs t
aches partagent des donn
ees allou
ees
sur diff
erentes m
emoires de la plateforme dex
ecution et dans ce cas,
Les donn
ees sont copi
ees en suivant linformation concernant la route donn
ee
pour lallocation. Ces diff
erentes notions dallocation ne permettent n
eanmoins de
ne sp
ecifier que des placements spaciaux dapplication. La gestion du caract`
ere temporel du placement est confi
ee au compilateur qui la charge de prendre ces d
ecisions.
ache sur un processeur
La figure 2.18 donne un exemple dallocation simple dune t
[70].
Il faut noter que ces notions dallocations ne concernent que des
el
ements simples.
Pour prendre en compte les aspects introduits par le paquetage Factorization et leur
utilisation pour les
el
ements dune application et dune architecture mat
erielles, la
notion de Distribution a
et
e introduite. Elle permet de distribuer une t
ache r
ep
et
ee sur un ensemble de processeur mais
egalement de sp
ecifier le placement dun
52
2.6. Conclusion
tableau de donn
ees sur un ensemble de m
emoires. La figure 2.19 suivante illustre
cette notion `
a laide dun exemple de distribution de t
aches sur un
el
ement dune
architecture mat
erielle.
Fig. 2.18 Allocation de la t

ache appli sur le processeur proc
Fig. 2.19 ADistribution dune t

ache repetee sur une grille de 4x4 unites de calcul
2.6
Conclusion
Dans la plupart des outils de mod

elisation que nous avons explicit
es, le Flot
GASPARD se pr
ete le mieux `
a la mod
elisation et `
a la sp
ecification des
el
ements
dun syst`
eme embarqu
e. Il prend en consid
eration en m
eme temps les aspects li
es
`
a lapplication, `
a larchitecture et `
a leur association. En plus de
ca son point le
plus fort cest quil permet de prendre en consid
eration les taches r
ep
etitives et les
donn
ees intensives r
eguli`
eres. Cest ce qui caract
erise les applications de traitement
de signal intensif que nous verrons dans le chapitre suivant.
53
Chapitre 3
Calcul intensif et applications DSP

Sommaire
3.1
Calcul intensif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
3.2
Exemples dapplications (hautement r

eguli`
eres) . . . . . . . . . . . .
56
3.3
Exemples dapplication DSP `

a t
aches irr
eguli`
eres . . . . . . . . . . .
57
Sp
ecification multidimensionnelle et mod`
eles de calcul pour le TSI
58
3.4
3.5
3.4.1
MATLAB/SIMULINK . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
3.4.2
ALPHA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
3.4.3
MDSDF : Multidimensional Synchronous Dataflox . . . . . . . . . . . .
61
3.4.4
ARRAY-OL (Array Oriented Language) . . . . . . . . . . . . . . . . . .
63
Conclusion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
70
3.1. Calcul intensif
Afin de pouvoir presenter le placement dans sa globalite (le graphe HTG), nous
devons commencer par pr
esenter une de ses parties importantes qui est le traitement intensif. Dans ce chapitre on introduira le principe g
en
eral des applications de
traitement de signal intensif, les domaines faisant appel `
a ce type de traitement et
les principaux mod`
eles de calcul existants pour leur sp
ecification. Par la suite, nous
etudierons le principe du mod`

ele Array-Ol, principalement con
cu pour lexpression
du parall
elisme de donn
ees et des d
ependances de t
aches pour ce type dapplications.
3.1
Calcul intensif
Les applications de traitement syst

ematique et intensif sont de plus en plus pr
esentes dans plusieurs domaines. Elles se trouvent aussi bien dans le domaine de
calcul scientifique que dans le domaine de traitement de signal intensif (t
el
ecommunications, traitement multim
edia, traitement dimages et de la vid
eo, etc.. . .).
Le d
eveloppement des syst`
emes logiciels se base
enorm
ement sur ces applications
qui occupent une place importante dans le milieu de la recherche scientifique. Les
caract
eristiques principales de ces applications sont quelles effectuent une grande
quantit
e de calculs r
eguliers, elles op`
erent dans des conditions temps r
eel, et sont
g
en
eralement complexes et critiques.
Un signal est assimil
e `
a un support v
ehiculant de linformation. Le traitement du
signal (TS) est lart de manipuler un signal afin den extraire cette information.
Le traitement du signal intensif (TSI) est le sous-ensemble du traitement du signal
le plus gourmand en calcul, dont la partie la plus r
eguli`
ere est le traitement du
signal syst
ematique (TSS). Il consiste `
a r
ealiser des calculs sur les signaux ind
ependamment de leur valeur dans le but den extraire des propri
et
es int
eressantes
(par exemple pour d
etecter la pr
esence dun obstacle dans le contexte dun radar
anti-collision ou de chercher une forme bien pr
ecis
ee dans une image). La deuxi`
eme
etape dans le traitement du signal est le TDI (traitement de donn

ees intensif ), cest
une
etape plus irr
eguli`
ere et d
ependante de la valeur des donn
ees. Cette
etape suit
celle de TSS dans le temps. Elle analyse le signal issu du traitement syst
ematique
et prend
eventuellement des d
ecisions (freinage durgence lors de la d
etection dun
obstacle ou analyse de fa
con plus d
etaill
ee une forme d
etect
ee dans une image).
Dans ces travaux, nous nous int
eressons au traitement de donn
ees intensif dont le
positionnement dans le traitement du signal est repr
esent
e par la figure 3.1.
Fig. 3.1 Positionnement du TSS dans le domaine TS.
Une application est dite intensive si elle op`

ere sur une grande masse de donn
ees,
55
3.2. Exemples dapplications (hautement regulières)

et sil faut fortement loptimiser pour obtenir la puissance de calcul requise et r
epondre aux contraintes dex
ecution du syst`
eme [11].
G
en
eralement, les applications de traitement syst
ematique et intensif n
ecessitent de
grandes capacit
es de traitement de donn
ees faisant souvent appel `
a des techniques
de calcul parall`
ele et distribu
e. Les difficult
es de d
eveloppement de ces applications
sont donc principalement lexploitation du parall
elisme de donn
ees et de calcul, et
le respect des contraintes de temps et de ressources du parall
elisme [71].
Le caract`
ere critique de ces applications exige des environnements de programmation sp
ecialis
es pour leur sp
ecification, simulation, v
erification et ex
ecution, afin de
r
eduire les temps de d
eveloppement et donc de mise sur le march
e. Leur principal objectif est dassurer le traitement de grandes quantit
es dinformations tout en
exploitant au mieux le parall
elisme pr
esent dans lapplication. Nous rencontrons
les applications complexes de traitement syst
ematique et intensif dans plusieurs
domaines dapplication tels que les r
eseaux de communication, le trafic a
erien, lautomobile et les syst`
emes multim
edias.
3.2
Exemples dapplications (hautement r

eguli`
eres)
De nombreuses applications permettent la d

ecomposition du TSI en TSS et TDI :
Radar anti-collisions : la pr
evention des collisions dans un syst`
eme n
ecessite lutilisation dune antenne qui renvoie le signal sous la forme dun flux de donn
ees
contenant des informations relatives `
a la pr
esence dobstacles, un
echo. Ces informations sont masqu
ees pare du bruit (des parasites) et sont
etal
ees sur le flux de
donn
ees temporel. Une phase de pr
etraitement qui rel`
eve du traitement du signal
syst
ematique, filtre ce signal de mani`
ere `
a en faire ressortir les caract
eristiques int
eressantes (la pr
esence dobstacles). La r
egularit
e se trouve dans l
etape suivante
qui consiste `
a analyser ce nouveau flux de donn
ees de mani`
ere `
a valider la pr
esence
dun obstacle, `
a d
eclencher un freinage durgence o`
u `
a le poursuivre si n
ecessaire
[?]. Cette application est illustr
ee par la figure 3.2
Fig. 3.2 Representation de lapplication Radar anti-collision. La phase du traitement du signal

systematique precède celle du traitement de donnees intensif.
Traitement sonar : une vision plus large de la sc`

ene est n
ecessaire dans lanalyse dun environnement maritime (qui est similaire `
a celui dun routier). Dans le
cas dun sous-marin, ce nest pas une antenne qui est utilis
ee mais plusieurs hydrophones r
epartis autour de ce sous-marin. La premi`
ere phase de traitement est
syst
ematique et est compos
ee dune FFT (Transformations de fourrier). Le traite56
3.3. Exemples dapplication DSP `

a t
aches irregulières
ment est d
edi
e`
a la d
etection dobjets et `
a leur poursuite au cours du temps.
Convertisseur 16/9-4/3 : Souvent devant notre t
el
evision et en utilisant une t
el
ecommande on peut passer dun format `
a un autre avec une certaine facilit
e. En
pratique ce processus se d
ecompose en deux phases. La premi`
ere consiste `
a cr
eer
des pixels `
a partir du signal vid
eo au format 16/9 via une interpolation, il en r
esulte
un nouveau signal vid
eo. La seconde phase supprime certains pixels de ce signal de
mani`
ere `
a ne conserver quune partie de linformation, cela permet le passage au
format 4/3. Cette application ne consid`
ere `
a aucun moment la valeur des pixels, il
sagit de traitement de signal. Dautres exemples encore illustrent lutilisation du
TSI : encodeur/d
ecodeur.
JPEG 2000, r
ecepteur de radio num
erique, etc. Chacune de ces applications r
ealise des traitements r
eguliers sur les donn
ees, certaines exploitent le r
esultat de
ces traitements pour prendre des d
ecisions. Nous pouvons par ailleurs remarquer
la diversit
e de la s
emantique port
ee par les dimensions des tableaux de donn
ees
manipul
ees par ces applications (temporel, spatial et fr
equentiel) et leur nombre.
Il sagit l`
a dune caract
eristique tr`
es sp
ecifique aux applications de traitement du
signal intensif quest la manipulation de tableaux multidimensionnels.
3.3
Exemples dapplication DSP `

a t
aches irr
eguli`
eres
Si on consid`
ere des domaines dapplication courants tels lintelligence artificielle,
surveillance, maintenance, m
edecine `
a distance, gestion des catastrophes, etc. avec
des plateformes de calcul `
a files ou sans o`
u il y a diff
erents types de nud (laptops,
palmtop, mobile, PDA, etc.) on a ici un sc
enario commun typique de la transmission
vid
eo et audio (one to one, one to many, many to many). Le probl`
eme ici, en plus
des vitesses de calcul diff
erentes des diff
erentes unit
es de traitement, se situe aussi
au niveau des communications. Cette particularit
e est due aux bandes passantes
diff
erentes, aux p
eriph
eriques h
et
erog`
enes, `
a la latence etc. Dans ce type dapplication le transcoder, quon pr
esentera juste apr`
es, joue tout son r
ole.
Transcoder : Il peut
etre mobile ou reli
e`
a un r
eseau fixe. Le transcoder convertit
un format vid
eo en dautres en consid
erant la compatibilit
e avec des bandes passantes du r
eseau, puissance de calcul et lutilisation des p
eriph
eriques utilisateurs
eo se fait en deux phases :
[15]. Transcoder un flot vid
a D
ecoder X-Format.
b Encoder dans Y-Format, figure 3.3.
57
3.4. Specification multidimensionnelle et modèles de calcul pour le TSI

Fig. 3.3 Phases dun Transcoder.
La phase encoder n
ecessite plus de puissance de calcul que lautre phase (en
g
en
eral 3 `
a 4 fois plus de temps pour le m
eme encodage) et elle est tr`
es d
ependante
des param`
etres (tels la taille des frames).
La fonction de base pour les deux
etapes est :
1. D
ecoder, le flot MPEG dans un format ligne (YUV, YU12, PPM, etc.).
2. Encoder, transforme la ligne dans la vid
eo MPEG avec les nouveaux param`
etres.
Eliminateur de parasites (CSLC Coherent Side Love Cancellation) : est un autre
exemple de traitement technique. Cette application a pour but de r
eduire les parasites avec coh
erence sur les antennes. Dans la figure 3.4, nous donnons le graphe
global de lapplication CSLC o`
u on voit que la FFT est appel
ee deux fois et lIFFT
une seule. Ceux-ci constituent les blocs majeurs dune application CSLC. Les autres
blocs constituent des nuds r
eguliers mais sont moins gourmand en termes de calcul par rapport au FFT et lIFFT. Un tel domaine dapplication est hautement `
a
donn
ees intensives et donne plus de chance de faire du parall
elisme de donn
ees que
celui de t
aches.
Fig. 3.4 Application CSLC (Coherent Side Love Cancellation).
3.4
Sp
ecification multidimensionnelle et mod`
eles de calcul pour
le TSI
Beaucoup de mod`
eles de calcul ont
et
e propos
es pour la mod
elisation et la
mise en uvre des applications de traitement du signal intensif. On peut citer
MATLAB/SIMULINK, ALPHA [?], MDSDF (MultiDimensional Synchronous Data
Flow) [67], GMDSDF ( Generalized MultiDimensional Synchronous Data Flow) [66]
et le langage Array-Ol (Array Oriented Langage). Malgr
e la diversit
e, de ces mod`
eles, leur occupation principale consistant `
a mieux mod
eliser les grandes quantit
es
de donn
ees multidimensionnelles dont le but est de faciliter la description et l
etude
des applications de traitement intensif `
a parall
elisme de donn
ees massif.
58
3.4.1
MATLAB/SIMULINK
Le logiciel de calcul MATLAB peut

etre vu comme un syst`
eme interactif et
convivial de calcul num
erique et de visualisation graphique o`
u beaucoup des ces
interactions (fonctions) sont bas
ees sur un calcul matriciel simplifi
e. Il permet de
distinguer plusieurs types de matrices : monodimensionnelles (vecteurs), bidimensionnelles (matrices), tridimensionnelles . . . etc. Gr
ace `
a ses fonction sp
ecialis
ees
(analyse num
erique, calcul matriciel, traitement du signal, etc.), MATLAB est consid
er
e comme un langage de programmation adapt
e pour les divers probl`
emes ding
enierie. La m
ethodologie de conception bas
ee sur MATLAB permet de r
eduire le
temps de mise sur le march
e en offrant le moyen pour la sp
ecification des syst`
emes
au plus haut niveau dabstraction.
Lextension graphique de MATLAB est SIMULINK qui permet de repr
esenter les
fonctions math
ematiques et les syst`
emes sous forme de diagramme de blocs (ou
diagrammes structurels) facilitant par l`
a la mod
elisation, lanalyse et la simulation
dune large vari
et
e de syst`
emes physiques et math
ematiques, y compris ceux avec
des
el
ements non lin
eaires et ceux qui se servent du temps continu discret. Le diagramme structurel dans SIMULINK met en
evidence la structure du syst`
eme et permet de visualiser les interactions entre les diff
erentes grandeurs internes et externes.
Le diagramme structurel est compos
e des
el
ements repr
esentants des op
erations math
ematiques (addition, soustraction, multiplication, int
egration et diff
erenciation).
Cet environnement fournit aussi des outils pour la mod
elisation hi
erarchique et la
gestion des donn
ees qui permettent une repr
esentation pr
ecise et concise de lapplication ind
ependamment de la complexit
e du syst`
eme
etudi
e.
Pour beaucoup des logiciels, MATLAB/SIMULINK sont devenus des standards
pour la conception de syst`
emes. Cependant, ils sont une pure cr
eation de num
ericiens et dautomaticiens, et na aucune des qualit
es informatiques requises pour
la g
en
eration du code pour des syst`
emes embarqu
es critiques. Ce sont des logiciels
principalement con
cus pour la simulation des applications de traitement num
erique
et ne prennent pas en consid
eration lexpression et lexploitation du parall
elisme de
donn
ees pr
esent dans ces applications.
3.4.2
ALPHA
Cest un langage `
a parall
elisme de donn
ees [[16],[79] et fonctionnel cr
ee par
l
equipe API `
a lIRISA de Rennes. La premi`
ere d
efinition de ce langage a
et
e proee sur le formalisme des syst`
emes d
equapos
e par Mauras en 1989 [57] et est fond
tions r
ecurrentes [44], mais depuis il a
evolu
e. Cest un langage `
a parall
elisme de
donn
ees permettant la description de haut niveau dalgorithmes de calcul r
eguliers.
Le formalisme qui est derri`
ere le langage est appel
e le mod`
ele poly
edrique, et se
trouve aujourdhui, `
a la base de plusieurs m
ethodes de parall
elisation automatique
59

des boucles et de la synth`
ese de r
eseaux systoliques. Un algorithme, dans ce langage,
est d
ecrit par des
equations sur des variables d
efinies dans des domaines multidimensionnels. Par des transformations successives, telle que la parall
elisation des
instances, ces descriptions peuvent
etre raffin
ees jusqu`
a leur interpr
etation par des
outils de synth`
ese logique dans le but de g
en
erer des architectures VLSI. Ce langage est donc propos
e pour faciliter la synth`
ese darchitectures parall`
eles int
egr
ees
pour ces algorithmes afin de les ex
ecuter en temps raisonnable (temps r
eel pour les
applications de traitement de signal). Les transformations du langage ALPHA sont
impl
ement
ees dans lenvironnement MMALPHA qui est une interface, principalement bas
ee sur MATHEMATICA, pour la manipulation de ce langage.
La notion de temps, ou m
eme dex
ecution, nexiste pas en ALPHA : un programme
d
ecrit un ensemble de calculs dont les d
ependances de donn
ees expriment lordre
dans lequel ces calculs peuvent
etre r
ealis
es. Cela implique quALPHA soit un langage `
a assignation unique et quil existe potentiellement plusieurs ordonnancements
pour lex
ecution dun programme.
Un programme ALPHA est un syst`
eme dont les variables sont d
efinies `
a laide des
fonctions de lensemble de points entiers dun espace vectoriel vers un ensemble
ees manipul
ees par ALPHA sont multidimensionde valeursdynamiques4 . Les donn
nelles : Elles correspondent `
a des unions de poly`
edres convexes. Leurs formes ne
sont donc pas restreintes `
a de simples tableaux rectangulaires. Par exemple le code
suivant :
V : i, j|1 i j; j 3of real
D
eclare une variable V de type r
eel. Le domaine de cette variable est lensemble de
points (i,j) dans le triangle 1 i j, j 3, et qui repr
esente la collection de valeurs
suivantes :
V1,1
V1,2
V2,2
V1,3
V2,3
V3,3
Le langage ALPHA est en mesure dexprimer de fa

con compacte des formes de
donn
ees complexes (un triangle par exemple). Cependant, en traitement du signal,
les donn
ees sont souvent manipul
ees sous la forme de tableaux simples, la puissance
de lexpression des formes de donn
ees dans ALPHA est donc rarement n
ecessaire.
En plus, ce langage ne g`
ere pas les acc`
es cycliques dans les tableaux de donn
ees,
acc`
es pourtant indispensables, par exemple, pour lapplication du traitement Sonar vu pr
ec
edemment. En outre, les programmes ALPHA manipulent des indices
pour les acc`
es aux donn
ees, ce qui implique que le programmeur calcule ces indices.
Cela augmente consid
erablement le risque derreurs quand `
a lexpression des d
ependances de donn
ees sur des tableaux multidimensionnels.
4
Le type des valeurs peut etre entier, reel ou booleen
60
3.4.3
MDSDF : Multidimensional Synchronous Dataflox
IL a
et
e propos
e par Edward Lee en 2002 [67]. Il
etend le concept du mod`
ele SDF
(Synchronous DataFlow) [[49],[50]] pour lappliquer dans un contexte multidimensionnel. Lobjectif est de permettre la sp
ecification des applications de traitement du
signal manipulant des donn
ees multidimensionnelles tels que le traitement dimage
et de la vid
eo.
Le mod`
ele SDF repr
esente un cas sp
ecial des mod`
eles flot de donn
ees qui sont
g
en
eralement utilis
es pour d
ecrire des applications de traitement du signal par des
graphes, en repr
esentant les fonctions par des nuds et les donn
ees par les arr
etes
du graphe. Lajout du terme synchrone implique que le nombre de donn
ees
consomm
ees et produites soit connu d`
es la conception de lapplication, cest-`
a-dire
qui permet de r
ealiser des ordonnancements statiques. Ce mod`
ele est int
egr
e `
a
5
elisation et de simulation dapPTOLEMYdynamiques , lenvironnement de mod
plications pour les syst`
emes embarqu
es.
Une application, dans SDF, est d
ecrite par un graphe orient
e acyclique o`
u chaque
nud consomme des donn
ees en entr
ee et produit des r
esultats en sortie. Donc les
calculs sont repr
esent
es par des nuds [Actor] et les donn
ees [Tokens] par des arcs
(figure 3.5). Les symboles associ
es aux entr
ees et aux sorties de chaque acteur dans
un graphe SDF sp
ecifient le nombre de jetons consomm
es ou produits par lacteur
en question. Ainsi, la relation entre les acteurs dans un graphe SDF doit satisfaire
la relation suivante :
ri Oi = ri+1 Ii+1 o`
u ri repr
esente le nombre de r
ep
etition dun acteur i et Oi (resIi )
est le nombre de jetons produits (resp consomm
es) par lacteur i. Le vecteur r =
[r1 r2 . . . rn ] peut regrouper les r
ep
etitions des acteurs. Dans lexemple de la figure
40,
r = [11010010] qui signifie que pour chaque ex
ecution de lacteur A, il y aura 10
ex
ecutions de lacteur B, 100 de lacteur C et 10 de lacteur D.
Fig. 3.5 Exemple dun graphe dune application en SDF.
Les applications bas

ees sur des flots de donn
ees synchrones peuvent
etre facilement mod
elis
ees par ce mod`
ele en sp
ecifiant les d
ependances entre t
aches. Cependant, ce mod`
ele est r
eserv
e`
a lexpression des applications monodimensionnelle
limitant ainsi le domaine des syst`
emes
etudi
es `
a celui manipulant des flots de donn
ees monodimensionnelles. Ce qui a justifi
e lintroduction du mod`
ele MDSDF pour
r
esoudre ce probl`
eme et permettre la prise en compte des applications `
a flot de
donn
ees multidimensionnelles.
5
http ://ptolemy.eecs.berkeley.edu
61

Lobjectif de ce mod`
ele est de donner un moyen pour la mod
elisation des traitements de donn
ees parall`
eles, et davoir une meilleure expression des d
ependances
de donn
ees entre les t
aches.
Le fonctionnement de MDSDF est similaire `
a celui de SDF. Ainsi, il suffit juste
de pr
eciser pour chaque acteur le nombre de jetons consomm
es et produits sur
chacune des dimensions du flot, sachant que ce nombre est repr
esent
e par un nuplet. Dans ce cas, le nombre de r
ep
etitions de deux acteurs A et B dun graphe
MDSDF manipulant un flot de donn
ees de n dimensions est calcul
e comme suit :
rA,i OA,i = rB,i OB,i , i = [1, n].
La figure 3.6 donne un exemple dune application en MDSDF qui prend en entr
ee
une image de 40x48 pixels et la divise en des blocs de 8x8. Dans cet exemple, le flot
repr
esent
e est de forme bidimensionnelle, le premier acteur A produit un rectangle
de jetons de taille 40 sur la premi`
ere dimension, et de taille 48 sur la deuxi`
eme
pour chaque it
eration. Ensuite lacteur B consomme sur les deux dimensions un
rectangle de jetons de taille 8. Pour cet exemple,rA,1 = rA,2 = 1, rB,1 = 5, rB,2 = 6 [41].
Fig. 3.6 Exemple dun graphe dune application en MDSDF.
Avec MDSDF on rend plus exacte lexpression dune application multidimensionnelle et possible la mod
elisation dapplication qui ne pouvait
etre d
ecrite en SDF. La
figure ?? illustre un exemple dune application non repr
esentable en SDF. On a un
acteur A qui produit une colonne de deux jetons et un acteur B qui consomme une
ligne de trois jetons. Les deux jetons de la colonne ne seront donc pas consomm
es
par la m
eme it
eration du deuxi`
eme acteur comme le montre le graphe de d
ependances. La mod
elisation de cette application en SDF nest pas possible puisque ce
dernier ne permet pas de sp
ecifier le mode de construction du graphe de d
ependance [65].
Fig. 3.7 Une application MDSDF non representable en SDF.
En fin, on peut dire que m

eme si ce mod`
ele rend possible lutilisation de flot
de donn
ees multidimensionnelles, il est contraignant sur le nombre de dimensions
du flot de donn
ees qui n
evolue jamais et il nest pas possible den cr
eer ou supprimer. Or pour cette application de traitement de signal, telle la FFT , la cr
eation
de dimension est utile. Une autre limitation dans le mod`
ele MDSDF est que la
consommation et la production des donn
ees doivent
etre parall`
eles aux axes. Ce
que Murphy et L
ee ont essay
e de combler en proposant une extension `
a ce mod`
ele
62

appel
e GMDSF (Generalized MultiDimensional Synchronous DataFlow).
3.4.4
ARRAY-OL (Array Oriented Language)
Cest un langage sp
ecialis
e dans la description dapplications de traitement du
signal intensif. Comme on la pr
esent
e pr
ec
edemment, ce type dapplication est
caract
eris
e par une manipulation de grande quantit
e de donn
ees qui sont trait
ees
par un ensemble de t
aches de fa
con r
eguli`
ere. Le langage Array-Ol est bas
e sur la
constatation que la complexit
e de telles applications vient des acc`
es aux donn
ees
(toujours des tableaux) et non des fonctions de calcul. Cest un langage `
a assignation
unique o`
u seules les d
ependances de donn
ees sont exprim
ees et o`
u les dimensions
spatiales et temporelles des tableaux sont banalis
ees. Donc le mod`
ele Array-Ol est
multidimensionnel et permet dexprimer un parall
elisme potentiel complet sur des
applications, que ce soit un parall
elisme de donn
ees ou un parall
elisme de t
aches.
Avant de comprendre lapport de ce langage, on doit comprendre le contexte dans
lequel est utilis
e le Array-Ol, en commen
cant par ces applications qui pr
esentent
plusieurs difficult
es [30].
Peu de mod`
eles de calcul sont multidimensionnels,
Les profils dacc`
es aux tableaux de donn
ees sont diverses et complexes,
Ordonnancer ces applications avec un temps et des ressources limit
es est un
chalenge sp
ecialement dans les contextes distribu
es.
A ce jour uniquement deux mod`
eles de calcul ont tent
e de proposer un formalisme
pour mod
eliser et ordonnancer de telles applications de traitement de signal multidimensionnel : MDSDF (vu pr
ec
edemment), son suivant GMDSDF et Array-Ol
[[17],[18]]. Ce dernier est introduit par Thomas Marconi Sonar et dont la compilation a
et
e
etudi
ee par Demeure, Soula, Dumont et al [[17],[18],[8],[87].
Ces deux langages propos
es ont les m
emes objectifs et m
eme sils sont diff
erents
dans la forme, ils partagent un certain nombre de principes tels que :
1. La structure de donn
ees doit avoir des dimensions multiples visibles.
2. Placement statique doit
etre possible avec des ressources limit
ees.
3. Domaine dapplication est le m
eme : application de traitement de signal intensif
multidimensionnel.
Comme une premi`
ere remarque on doit attirer lattention sur le fait que ArrayOl est uniquement un langage de sp
ecification. Il ny a pas de r`
egles sp
ecifi
ees pour
lex
ecution dapplication d
ecrite avec ce langage. Toute fois un ordonnancement
peut
etre facilement obtenu en utilisant la description.
63

Principes
Lobjectif initial de Array-ol est de fournir un langage textuel et graphique permettant lexpression dapplication de traitement de signal intensif et multidimensionnel. La difficult
e de ce type dapplications ne vient pas des fonctions
el
ementaires quelle combine (somme, produit, FFT) mais de la mani`
ere dont ces fonctions
acc`
edent `
a leurs donn
ees en entr
ee et sortie comme tableau multidimensionnel.
Lacc`
es complexe aux parties du tableau augmente encore plus les difficult
es de
placement de ces applications sur des plateformes dex
ecution parall`
eles et distribu
ees. Et puisque ces application traitent une quantit
e importante de donn
ees en
temps r
eduit (contrainte temporelle), lutilisation efficace du potentiel parall`
ele de
lapplication sur une architecture parall`
ele est n
ecessaire.
A partir de ces exigences, on peut expliciter les principes de base qui supportent
ce langage [30].
Array-Ol est un langage dexpression de d
ependance de donn
ees. Uniquement
les vraies d
ependances de donn
ees sont exprim
ees dans le but dexprimer le
parall
elisme total de lapplication en d
efinissant un ordre minimal de t
aches.
Lacc`
es aux donn
ees se fait `
a travers de sous tableaux appel
es Motifs (pattern
en anglais).
Le langage est hi
erarchique permettant la description des diff
erents niveaux
de granularit
e et de traiter la complexit
e de lapplication. Les d
ependances
de donn
ees exprim
ees `
a un niveau (entre tableau) sont des approximations de
d
ependances pr
ecises des niveaux interm
ediaires (entre Motifs).
Tout le potentiel de parall
elisme dans lapplication doit
etre explicit
e dans
la sp
ecification selon les deux axes parall
elisme de t
aches et parall
elisme de
donn
ees.
Cest un formalisme `
a assignation unique. Une donn
ee
el
ementaire m
eme si
elle peut
etre lue plusieurs fois elle nest jamais
ecrite deux fois.
Les dimensions spatiales et temporelles sont trait
ees
equitablement dans le
tableau. En particulier le temps est consid
er
e comme une des dimensions des
tableaux.
Les tableaux sont toriques. Ce qui veut dire que certaines dimensions spatiales
repr
esentent des concepts toriques physiques (tels les hydrophones autour dun
sous marin) et certains domaines de fr
equences obtenues par les FFT qui sont
aussi toriques.
Le mod`
ele usuel de description de d
ependance est un graphe de d
ependance o`
u
les nuds repr
esentent les t
aches et les arcs les d
ependances. Plusieurs types de
ces graphes sont propos
es mais les plus utilis
es, quon va adopter comme mod`
eles,
sont les graphes de t
aches. Dans lordre de repr
esenter des applications complexes,
une extension commune `
a ces graphes est la hi
erarchie.
Ainsi un nud peut lui-m
eme
etre un graphe. Array-Ol permet la construction de
64

tels graphes hi
erarchiques de d
ependance en ajoutant un nouveau type de nud
qui repr
esente le parall
elisme de donn
ees de lapplication : nuds r
ep
etitifs.
Dune fa
con formelle, une application Array-Ol est un ensemble de composants
connect
es `
a travers des ports. Les composants sont
equivalents aux fonctions math
ematiques lisant les donn
ees `
a travers les ports dentr
ee et
ecrivant les autres `
a
travers leurs ports de sortie. On a trois types de composants :
El
ementaire : se sont des composants atomiques (boite noire).
Compos
e : cest un graphe de d
ependance o`
u les nuds sont des composants
connect
es `
a travers leurs ports.
R
ep
etitif : cest un composant exprimant comment un sous compos
e est r
ep
et
e.
Toutes les donn
ees
echang
ees entre les composants sont des tableaux qui sont
multidimensionnels caract
eris
es par leurs profils Shape et le nombre d
el
ements sur
chacune des dimensions. Chaque port est caract
eris
e par le profil et le type des
el
ements des tableaux `
a partir du quel il lit ou dans lequel il
ecrit.
Tel quon la avanc
e pr
ec
edemment, Array-Ol est `
a assignation unique. Le temps
est donc repr
esent
e par une (ou plusieurs) dimensions des tableaux de donn
ees. Par
exemple un tableau repr
esentant une vid
eo a des motifs `
a trois dimensions (largeur
de frame, hauteur de frame, nombre de frame).
Toute description dune application en Array-ol fait successivement appel `
a deux
niveaux. Le premier niveau, appel
e mod`
ele global, d
efinit lenchanement des diff
erentes parties de lapplication dans son ensemble alors que le deuxi`
eme niveau
appel
e mod`
ele local pr
ecise les actions
el
ementaires `
a effectuer sur les
el
ements de
tableaux et le parall
elisme de donn
ees sur les diff
erentes t
aches.
Mod`
ele global (parall
elisme de t
aches)
Ce mod`
ele permet de nommer et de d
efinir les tableaux et les t
aches de calcul
dune application (figure 3.8).
Fig. 3.8 Exemple de composant : reduction à partir dune haute definition vers une definition
TV standard.
Ce mod`
ele est repr
esent
e par un graphe dirig
e acyclique o`
u chaque nud repr
esente une t
ache, et chaque arc repr
esente un tableau multidimensionnel (figure 3.9).
Le nombre de tableaux en entr
ee et en sortie est illimit
e. Il ny a pas non plus
de corr
elation entre les nombres de dimensions de ces tableaux. Dans ce cas il est
65

Fig. 3.9 Modèle global.
possible pour une t

ache de consommer deux tableaux bidimensionnels et de produire un tableau tridimensionnel.
La cr
eation de dimension est tr`
es utile, par exemple dans le cas dune FFT qui
cr
ee une dimension fr
equentielle. Cependant, la seule limitation sur les dimensions
des tableaux est quil doit y avoir une seule dimension infinie par tableau qui repr
esente g
en
eralement le temps. En plus, les tableaux utilis
es dans Array-Ol sont
consid
er
es comme toriques dans le sens o`
u la consommation ou la production de
leurs
el
ements peut se faire modulo `
a leur taille.
Chaque t
ache, au moment de lex
ecution, consomme un ou plusieurs tableaux,
effectue un traitement quelconque sur leurs
el
ements et produit un ou plusieurs tableaux r
esultats. Le nombre darcs en entr
ee ou en sortie de la t
ache correspond au
nombre de tableaux consomm
es ou produits. Ainsi le graphe obtenu est un graphe
de d
ependance et non un graphe de flots de donn
ees.
Il est aussi possible dordonnancer lex
ecution des diff
erentes t
aches dune application `
a partir du mod`
ele global. Cependant, il est impossible dexprimer le
parall
elisme de donn
ees pr
esent dans cette application puisque aucun d
etail sur les
calculs r
ealis
es nest donn
e`
a ce niveau de sp
ecification. Cest ce qui justifie lintroduction du mod`
ele local (ou parall
elisme de donn
ees)
Mod`
ele Local (parall
elisme de donn
ees)
La r
ep
etition de donn
ees parall`
eles dune t
ache est sp
ecifi
ee dans le composant
r
ep
etitif. Lhypoth`
ese de base est que toutes les r
ep
etitions de cette t
ache sont
ind
ependantes. Elles peuvent
etre ordonnanc
ees dans nimporte quel ordre m
eme
en parall`
ele. La seconde hypoth`
ese est que chaque sous t
ache op`
ere avec les sous
tableaux des entr
ees/sorties de la r
ep
etition.
Donc le mod`
ele local permet dexprimer tout le parall
elisme potentiel dans une
t
ache, et de d
efinir linteraction entre une t
ache et ses tableaux op
erandes et r
esultats. Cest un graphe dans lequel chaque tableau op
erande et r
esultat est reli
e
`
a la t
ache de ce mod`
ele en sp
ecifiant comment les donn
ees sont consomm
ees et
produites par cette t
ache. Une t
ache, dans ce mod`
ele, est toujours compos
ee dun
constructeur de r
ep
etition, o`
u chaque r
ep
etition est ind
ependante et appliqu
ee sur
un sous ensemble fini de points des diff
erents tableaux en entr
ee et en sortie (fi66

gure 3.10). Pour chaque r
ep
etition le r
ole dune t
ache consiste `
a extraire des motifs
(morceaux de tableaux ayant la m
eme forme) `
a partir de chaque tableau en entr
ee,
`
a appliquer une fonction de calcul qui produit des valeurs associ
ees aux motifs en
sortie, et `
a ranger ces derni`
eres dans les tableaux r
esultats.
La taille et la forme des motifs pour les diff
erents tableaux en entr
ee ou en sortie
peuvent
etre diff
erentes. Cependant, pour les diff
erentes r
ep
etitions sur un m
eme
tableau, les motifs doivent
etre r
eguliers (ajustage de tableau) et r
epartis r
eguli`
erement sur les tableaux (pavage du tableau). Cette hypoth`
ese permet une repr
esentation compacte de la r
ep
etition et sa coh
erence avec le domaine dapplication
dArray-Ol qui permet de d
ecrire des algorithmes tr`
es r
eguliers.
Afin de donner toutes les informations n
ecessaires `
a la construction des motifs,
un Tiler est associ
e `
a chaque tableau (cest-`
a-dire arc). Un Tiler est capable de
construire un motif `
a partir dun tableau ou le stocker. Il contient les informations
suivantes :
Fig. 3.10 Un exemple du modèle local en Array-ol.
F Une matrice appel

ee matrice dajustage (fitting matrix) qui d
ecrit comment remplir le motif par les
el
ements du tableau.
O lorigine du motif r
ef
erence (pour la r
ef
erence r
ep
etition).
P Une matrice appel
ee matrice de pavage (paving matrix) qui permet de d
ecrire
comment les motifs couvrent le tableau.
Les profils des tableaux et des motifs sont not
es sur les ports (comme dans le
composant de description). Lespace de r
ep
etition indique le nombre de r
ep
etitions
il est d
efini lui-m
eme comme un tableau multidimensionnel avec un profil. Chaque
dimension de cet espace de r
ep
etition peut
etre vue comme une boucle parall`
ele et
le profil de lespace de r
ep
etition donne les limites des indices (figure 3.10).
A partir dun
el
ement r
ef
erence (ref ) dans le tableau on peut extraire un motif
par l
enum
eration de ses
el
ements par rapport `
a l
el
ement r
ef
erence. En utilisant
la matrice dajustage, les coordonn
ees des
el
ements dun motif (ei) sont obtenues
en faisant la somme des coordonn
ees de l
el
ement r
ef
erence avec une combinaison
lin
eaire du vecteur dajustage comme suit :
i, 0 i < Spattern , ei = (ref + F xi)modSarray
O`
u Spattern est le profil dun motif, modSarray est le profil du tableau et F la matrice
dajustage.
La figure 3.12 [53] en donne plusieurs exemples de matrices dajustage et Motifs.
Dans ces exemples, les motifs sont dessin
es `
a partir dun
el
ement r
ef
erence dans un
67

Fig. 3.11 Exemple de repetition dans un filtre horizontal.
tableau 2D.
Fig. 3.12 Un exemple simple dajustage des elements dun tableau par leurs indexes dans le
motif (i), illustrant la formule i, 0 i < Spattern , ei = ref + F xi.
Du fait que dans Array-Ol toutes les dimensions de tableaux sont torodales, il
faut que toutes les coordonn
ees des
el
ements du motif soient calcul
ees modulo la
taille des dimensions du tableau. La figure 3.12 fournit plus dexemples complexes
de motifs obtenus `
a partir d
el
ements r
ef
erence fixe (O comme origine dans la figure
3.13)dans des tableaux `
a taille fixe.
Fig. 3.13 Un exemple complexe dajustage illustrant la relation i, 0 i < Spattern , ei =

(ref + F xi)modSarray .
Pour chaque r
ep
etition on doit sp
ecifier les
el
ements r
ef
erence des entr
ees et
sortie. Les
el
ements r
ef
erence de la r
ep
etition r
ef
erence sont donn
e par le vecteur
origine O de chaque Tiler. Les
el
ements r
ef
erence des autres r
ep
etitions sont obtenus `
a partir du vecteur o. comme vu pr
ec
edemment, les coordonn
ees sont obtenues
par combinaison lin
eaire de la matrice de pavage :
r, 0 r < Srepetition , ref r = (0 + P xr)modSarray
O`
u Srepetition est le profil de lespace r
ep
etition, P
etant la matrice de pavage et Sarray
le profil du tableau (figure 3.13).
Ainsi on peut r
esumer toutes ces explications par les deux formules suivantes :
r, 0 r < Srepetition , ref r = (0 + P xr)modSarray , donne les
el
ements de r
ef
erence
des
i, 0 i < Spattern , ei = (ref + F xi)modSarray , Enum

er
e tous les
el
ements dun
motif dune r
ep
etition r.
O`
u Sarray est le profil du tableau, Spattern le profil du motif, Srepetition est le profil
de lespace de r
ep
etition, o est les coordonn
ees de l
el
ement r
ef
erence du motif r
ef
erence appel
e aussi lorigine, P est la matrice de pavage dont les vecteurs colonnes
68

sont appel
es vecteurs de pavage, et qui repr
esentent lespacement r
egulier entre
les motifs, F est la matrice dajustage dont les vecteurs colonnes appel
es vecteurs
dajustage, repr
esentent lespacement r
egulier entre les
el
ements dun motif du tableau.
Fig. 3.14 Exemple de pavage illustrant la formule ; r, 0 r < Srepetition , ref r = (0 +

P xr)modSarray .
Les formules pr
ec
edentes explicitent quel
el
ement en entr
ee ou sortie dun tableau va
etre consomm
e ou produit par une r
ep
etition. Le lien entre les entr
ees et
sorties est donn
e par lindex de r
ep
etition r.
Pour une r
ep
etition donn
ee, les motifs de sortie (pour un index r) sont produits par
la t
ache r
ep
etitive `
a partir des motifs en entr
ee (pour lindex r). Ainsi lensemble
des Tilers, des profils des motifs et lespace de r
ep
etition d
etermine les d
ependances
entre les
el
ements des tableaux en sorties et les
el
ements des tableaux en entr
ees
dune r
ep
etition.
Pour illustrer lutilisation de ce langage, nous allons
etudier la sp
ecification dun
exemple classique et acad
emique dun produit de matrices. Cet exemple permet de
montrer la puissance du mod`
ele local pour lexpression du parall
elisme de donn
ees
dans un algorithme. A1
etant une matrice de taille 3x2 et A2 une matrice de taille 5x2,
nous calculons le produit A1 xA2 = A3 avec A3 de taille 3x2. Le calcul dun produit
de matrice revient au calcul du produit scalaire de chaque ligne A1 par chaque
colonne de A2 . Les diff
erents produits scalaires sont ind
ependants et peuvent
etre
alors effectu
es en parall`
ele.
Le langage Array-Ol permet dexprimer tout ce parall
elisme en identifiant les
motifs n
ecessaires en entr
ee pour produire les motifs r
esultats. Soit la t
ache
el
ementaire Produit Scalaire qui prend en entr
ee deux vecteurs de taille 5, et produit
en sortie un scalaire correspondant au Produit scalaire de ces deux vecteurs. Dans
le mod`
ele local, illustr
e par la figure 3.16, lespace de r
ep
etition de la t
ache Proache pour la production de
duit Scalaire est d
efini par le vecteur [[71],[?]] (Une t
chaque point du tableau de sortie). A travers cet exemple on montre la possibilit
e
dexprimer tout le parall
elisme potentiel dans une application, ce qui facilite son
interpr
etation par des outils doptimisation et de compilation.
Fig. 3.15 Exemple dun produit de matrices .
69
3.5. Conclusion
Dans lordre de simplifier la figure, et puisque le traitement est fait frame par
frame, uniquement les deux premi`
eres dimensions sont repr
esent
ees. La troisi`
eme
dimension de lespace de r
ep
etition est aussi infinie. La troisi`
eme dimension de lespace de r
ep
etition est aussi infinie. Les motifs ne rencontrent pas cette dimension
et uniquement le vecteur de pavage a un
el
ement non nul comme troisi`
eme
el
ement
t
(001) comme dimension infinie de lespace de r
ep
etition. Les tailles des tableaux
ont aussi
et
e r
eduites par un facteur de 60 dans chaque dimension pour des raisons
de lecture.
Fig. 3.16 Quelques repetitions du filtre horizontal pour illustrer les dependances entre les
entrees/sorties dune repetition.
3.5
Conclusion
Dans ce chapitre on a pr
esent
e les applications et les domaines o`
u on fait du
calcul intensif. Pour ce domaine, le DSP, plusieurs langages de sp
ecification existent
et on a cit
e les plus connus. Lobjectif essentiel de ces langages est de permettre
avec une relative simplicit
e de mettre en
evidence le parall
elisme de t
aches ou de
donn
ees inh
erent `
a ces applications. Notre choix sest port
e sur Array-Ol pour
expliciter le parall
elisme des t
aches r
ep
etitives quon va placer sur des architectures
r
eguli`
eres. Mais avant daborder ce probl`
eme qui constitue une partie de notre
approche globale, nous devons pr
esenter la probl
ematique g
en
erale du placement
sur les SoC. Le chapitre suivant va nous permettre de cerner ce probl`
eme et davoir
une id
ee sur les diff
erentes approches utilis
ees pour le solutionner.
70
Chapitre 4
Placement et Ordonnancement (ou

AAS)
Sommaire
4.1
Objectifs de conception des NoC . . . . . . . . . . . . . . . . . . . . .
72
4.2
Probl
ematique du placement et ordonnancement . . . . . . . . . . .
73
4.3
4.4
4.5
4.2.1
Le modèle darchitecture et le modèle dapplication . . . . . . . . . . . .
73
4.2.2
Problèmes et objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
Etat de lart des approches existantes . . . . . . . . . . . . . . . . . .
77
4.3.1
Approches pour les NoC . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
4.3.2
Approches pour les systèmes embarques multiprocesseur (MPES ou MPSoC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
Comparaison entre les techniques de placement et dordonnancement 91

4.4.1
Verification des contraintes de temps reel . . . . . . . . . . . . . . . . .
91
4.4.2
La minimisation de la consommation denergie . . . . . . . . . . . . . .
95
4.4.3
Contraintes materielles et memoire . . . . . . . . . . . . . . . . . . . . .
97
Conclusion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
97
4.1. Objectifs de conception des NoC
Le placement et ordonnancement (Mapping and Scheduling) appele aussi AAS

(Assignation Affectation and Scheduling) sont des
etapes qui suivent l
etape de
sp
ecialisation du NoC. Leur r
ole est dimpl
ementer lapplication sur larchitecture
s
electionn
ee. Ceci consiste principalement `
a assigner et ordonnancer les t
aches et
communications de lapplication sur les ressources darchitecture cible de telle fa
con
que les objectifs sp
ecifi
es soient atteints. Le placement des communications (CM :
Mapping Communication) et ordonnancement des communications (CS : Scheduling Communication) posent plus de probl`
emes dans les NoC que dans les SoC,
car dans les premiers cest le probl`
eme du plus court chemin qui se pose lors du
routage des communications. Dans ce cas, lusage exclusif des ressources doit
etre
r
egl
e sans arbitre tout en
evitant les probl`
emes de deadlock et de congestion. De
plus dans la plupart des NoC la distance des communications a un impact direct
sur les d
elais des communications. Dans ce chapitre on va
etudier et comparer
diverses techniques de mapping et scheduling dapplications sur des architectures
NoC. Mais du fait de la nouveaut
e, de ces syst`
emes, uniquement quelques approches
seront pr
esent
ees bas
ees sur une
etude comparative avec les syst`
emes `
a bus partag
e.
4.1
Objectifs de conception des NoC
Les m
ethodologies de conception des NoC partagent les m
emes objectifs avec
les m
ethodologies de conception des SoC, tels la r
eduction de la consommation
d
energie, la minimisation de la surface de la puce et la maximisation des temps de
performance. La pr
eservation de l
energie est tr`
es importante sp
ecialement dans la
conception des syst`
emes embarqu
es portables o`
u le fonctionnement du syst`
eme d
epend de la dur
ee de vie de la batterie et de la chaleur des circuits. Dans les NoC, les
switchs et les m
emoires occupent jusqu`
a 80% de la surface de la puce, en r
eduisant
la complexit
e fonctionnelle des switchs (algorithmes de routage) et en maximisant
lutilisation des m
emoires on peut r
eduire la surface de la puce. Les contraintes de
temps r
ef`
erent aux hard et soft deadlines dont le non respect peut causer la panne
(ou larr
et) du syst`
eme. Dans la r
ealit
e ces objectifs sont contradictoires, car en minimisant la consommation d
energie on ralentit la vitesse des calculs ce qui affecte
les performances du syst`
eme.
Ainsi lors de la conception des SoC on doit trouver un compromis entre ces diff
erents objectifs, ce qui va nous amener `
a faire du multi-objectifs qui constitue la
partie centrale de notre travail. Durant le placement (mapping) des t
aches, celles
qui consomment le plus d
energie sont affect
ees aux processeurs consommant le
moins d
energie pour
equilibrer la consommation totale d
energie. En fin, on peut
dire que le placement est responsable de lexploitations de la concurrence dans
lapplication, d
ependant du parall
elisme de larchitecture cible en prenant en consi72
4.2. Problematique du placement et ordonnancement

d
eration les objectifs de temps, surface et
energie. Lordonnancement a pour but
de v
erifier les contraintes de temps, mais un ordonnancement de voltage peut aussi
etre utilis
e pour minimiser la consommation d
energie du syst`
eme. Ceci sobtient
en faisant ex
ecuter certaines t
aches sur certains processeurs `
a niveau de voltage bas.
Le placement et ordonnancement sont parmi les t
aches les plus difficiles lors de
la conception, de bons algorithmes de placement et ordonnancement sont cruciaux
pour avoir un maximum de performance pour une application sur une plateforme
donn
ee. Les syst`
emes NOC sont `
a la base des syst`
emes multiprocesseurs h
et
erog`
enes faiblement coupl
es utilisant un routage par paquets pour les communications
inter-processeurs. Une des plus importante particularit
e des NoC par rapport aux
multiprocesseurs, cest que les NoC contiennent certains
el
ements sp
ecialis
es quon
ne peut pas utiliser pour des calculs g
en
eraux mais pour uniquement certaines
fonctions sp
ecialis
ees. Cette diff
erence doit
etre pris en consid
eration lors de la
conception et surtout dans la phase de placement.
4.2
Probl
ematique du placement et ordonnancement
Dans le flot de conception, l

etape de placement et ordonnancement est directement li
ee `
a limpl
ementation de lapplication sur une architecture sp
ecialis
ee. Les
entr
ees de cette phase sont [77] :
Un mod`
ele dapplication,
Un mod`
ele darchitecture cible,
Des contraintes de performance et d
energie,
Des fonctions objectifs `
a optimiser.
La sortie de cette phase est une affectation des diff
erentes t
aches et communications aux ressources physiques, plus un ordonnancement dex
ecution des diff
erentes
t
aches sur ces ressources.
4.2.1
Le mod`
ele darchitecture et le mod`
ele dapplication
Le mod`
ele darchitecture est g
en
eralement un graphe orient
e avec deux types
de nuds repr
esentant les processeurs (PE) et les switchs qui sont interconnect
es par des arcs repr
esentant les liens de communication (CL) dans la plateforme.
Puisque le NoC peut
etre un syst`
eme multiprocesseur alors les PE peuvent
etre
des processeurs g
en
eraux ou sp
ecialis
es tels les ASIC, FPGA, etc. CL peut
etre une
connexion point `
a point ou bus. PE et CL peuvent avoir plusieurs types de voltage
permettant leur utilisation dynamique. Les techniques de gestion d
energie peuvent
etre utilis
ees pour carr
ement arr
eter les
el
ements non utilis
es et diminuer par l`
a
73

la consommation d
energie. Dautres param`
etres sont n
ecessaires pour sp
ecifier la
plateforme mat
erielle, on peut citer : le nombre, type et position des PE. Vitesse
(fr
equence) et niveau de voltage des PE et CL. Contraintes taille m
emoire et surface
des PE sans oublier la topologie dinterconnexion des PE.
Lapplication est, g
en
eralement, donn
ee par un graphe de t
ache (TG) dont les
nuds repr
esentent les t
aches et les arcs les communications. Plusieurs applications
concurrentes peuvent
etre repr
esent
ees comme un ensemble de TG qui peuvent
etre
ex
ecut
es en parall`
ele sur la plateforme de calcul. On a quelques param`
etres pour caract
eriser ce graphe, on cite : le temps dex
ecution de t
ache (ET) sur chaque PE, les
deadlines hard et soft des t
aches, volume de communication sur chaque arc, consommation d
energie par cycle `
a chaque voltage,
energie consomm
ee pour le transfert
dune unit
e de donn
ee (bit/byte) en ignorant les distances des communications. La
figure 4.1 illustre un exemple dun probl`
eme de placement et ordonnancement sur
un NoC 2D o`
u la topologie est `
a maillage complet avec 3x3 ressources. Dans cet
exemple, il y a deux applications concurrentes repr
esent
ees par deux TG.
Fig. 4.1 Illustration dun problème de placement et ordonnancement

Le placement est d
efini comme lassignation des t
aches (communications) sur les
el
ements de calcul (routage). Le placement pour les NoC peut aussi inclure lassignation des composants IP aux tuiles du NoC et en m
eme temps lassignation
des chemins de routage (communication mapping r
ef
er
ee dans la litt
erature par
lassignation r
eseau ). Ce dernier est souvent trait
e apr`
es le placement des t
aches
et tends `
a r
eduire les distances des communications sur la puce.
Le scheduling est lordonnancement des temps des t
aches et communications sur
leurs ressources auxquelles elles sont assign
ees. Il doit assurer lexclusion mutuelle
entre lex
ecution de t
aches sur la m
eme ressource. Dans la figure 4.2 on illustre le
scheduling de lexemple 1. Le graphe de Gantt est utilis
e pour une repr
esentation
graphique des r
esultats du placement et ordonnancement.
Fig. 4.2 : Scheduling de TGs sur une platefome NoC

La sortie de cette phase est le mod`
ele plac
e et ordonnanc
e qui montre les temps
de d
ebut et les dur
ees dex
ecution des t
aches sur les diff
erentes ressources auxquelles
elles sont assign
ees. Les contraintes de temps peuvent facilement
etre v
erifi
ees en
comparant la dur
ee de lordonnancement avec les deadlines donn
ees. Le diagramme
de Gantt permet aussi dinclure de la m
eme mani`
ere le placement des communications. La seule diff
erence cest que dans ce cas les arcs des NoC vont apparatre sur
74

certains liens de communication correspondant aux chemins de routage. Ce placement peut
etre suivi par lordonnancement du voltage et les techniques de gestion
d
energie pour minimiser la consommation d
energie.
Lordonnancement voltage, implique la s
election voltage (VS), il tend `
a minimiser la consommation d
energie dynamique des t
aches et communications plac
ees sur
des ressources `
a voltage graduel. Adaptive Body Biasin (ABB) est un cas sp
ecial
dordonnancement voltage qui minimise la consommation d
energie statique en ralentissant certaines t
aches et les ex
ecutant `
a des seuils
elev
e du niveau voltage.
Les techniques de gestion d
energie (PM) tendent `
a r
eduire la consommation d
energie statique en arr
etant totalement, partiellement ou mettre au repos (idle) certaines
ressources. La gestion de l
energie peut
etre appliqu
ee en m
eme temps aux
el
ements
de calcul et aux liens de communication.
4.2.2
Probl`
emes et objectifs
Contraintes et fonctions objectifs

Un placement et ordonnancement r
ealisable est celui qui satisfait les contraintes
sp
ecifi
ees telles que les contraintes de temps, contraintes de pr
ec
edence de donn
ees, contraintes taille m
emoire etc. Un placement et ordonnancement de qualit
e
est celui qui, en plus de satisfaire les contraintes, il doit optimiser les fonctions objectifs sp
ecifi
ees telles que la minimisation de la consommation d
energie, maximiser
les temps de performance ou
equilibrage de charges des m
emoires. Le Placement
et ordonnancement doit, parfois, trouver un compromis entre plusieurs objectifs
contradictoires tels la minimisation de la consommation d
energie et satisfaire les
contraintes temps r
eel, etc.
S
epar
es ou int
egr
es
Les probl`
emes de placement et ordonnancement peuvent
etre trait
es s
epar
ement,
ou ensemble int
egr
es dans un m
eme probl`
eme. Dans ce dernier cas la solution optimale correspondra `
a la meilleure solution. Mais les deux probl`
emes sont NP.hard,
les solutionner s
epar
ement est moins co
uteux que de les traiter ensemble comme
un seul probl`
eme cest-`
a-dire simultan
ement.
Placement et ordonnancement statique et dynamique

Le placement et ordonnancement peuvent
etre trait
es en on-line ou en off-line.
En Off-line (ou statique) le placement et ordonnancement sont ex
ecut
es avant lex
ecution de lapplication. Un tableau enregistrant, les temps de d
ebut dex
ecution des
75

t
aches sur les ressources dassignation avec les niveaux de voltage correspondants
et les temps de leurs switching est donn
e avant le d
ebut de lex
ecution. Donc, d`
es
que le placement et ordonnancement est ex
ecut
e, au moment de la compilation, il
naura aucune influence sur lapplication pendant lex
ecution.
Le On-line ou dynamique mapping et scheduling donne les affectations et les
ordonnancements pendant lex
ecution de lapplication. Ceci permet une meilleure
solution, mais les temps de traitements, pendant lex
ecution de lapplication, vont
augmenter la dur
ee dex
ecution et la consommation totale d
energie de lapplication. En plus ce type dordonnancement est tr`
es difficile `
a tester.
Comme cons
equence le placement et ordonnancement statique est conseill
e pour
les syst`
emes embarqu
es et sp
ecialement pour les NoC o`
u le placement dynamique
des communications est tr`
es contraignant. Cest ce qui justifie notre choix, dans
cette
etude, de ne traiter que le placement statique.
Pour le voltage, la notion de statique et dynamique na pas la m
eme signification que off-line et on-line. Statique Voltage S
election (SVS) est daffecter plusieurs
niveaux de voltage `
a l
echelle des voltages dune ressource selon lutilisation de la
ressource durant lex
ecution dune application. SVS est souvent appliqu
e en off-line
ou quand le temps dordonnancement de t
aches sur l
echelle des voltages des ressources est n
egligeable. Donc dans le SVS les temps de basculement (switching)
sont ignor
es.
Dynamique Voltage Scheduling (DVS) correspond `
a lallocation dun ou plusieurs niveaux de voltage pour lex
ecution des t
aches sur des ressources `
a
echelle de
voltage. Les niveaux multi-voltages ont des valeurs discr`
etes o`
u le temps et l
energie
relatifs au switching entre les voltages ne sont pas toujours n
eglig
es. DVS peut
etre
appliqu
e en off-line ou on-line et ils est toujours appliqu
e apr`
es lordonnancement
des t
aches selon l
echelle des voltages des ressources.
La m
eme observation peut aussi
etre faite pour la gestion d
energie. La d
ecision
darr
eter les ressources inutilisables peut
etre prise en off-line ou On-line, mais la
mani`
ere dappliquer le PM aux ressources de larchitecture ou aux t
aches de lapplication donne la signification statique ou dynamique au PM.
Algorithmes de placement et dordonnancement

Placement et ordonnancement sont des probl`
emes NP-hard, donc la solution
des probl`
emes `
a tailles r
eelles ne peut
etre envisag
ee quavec des heuristiques de
construction ou transformation. N
eanmoins les probl`
emes `
a petites tailles peuvent
76
4.3. Etat de lart des approches existantes
etre solutionn
es avec des m
ethodes qui d
eterminent loptimum dune fa
con d
eterministe. Ces m
ethodes (d
eterministes) explorent dune fa
con exhaustive tout
le domaine des solutions et retournent loptimum th
eorique cest-`
a-dire exact ; Le
Branch-and-Bound (BB) en est une.
Les heuristiques sont des m
ethodes de recherches pseudo al
eatoires et des techniques doptimisation qui explorent et exploitent lespace des solutions en se basant
sur lexp
erience apprise. Elles sont utilis
ees quand une recherche d
eterministe ou
exhaustive est tr`
es hard ou impossible et quand le temps de recherche augmente
dune fa
con exponentielle avec la taille du probl`
eme. Les heuristiques permettent
dobtenir des solutions de qualit
e raisonnable en un temps tr`
es court. Les heuristiques constructives permettent de construire graduellement des solutions partielles
valides jusqu`
a atteindre loptimum. Les heuristiques de transformation alternent
des solutions existantes en cherchant `
a
elargir lespace dexploration de lespace des
solutions. LS (List Scheduling) et GA (Genetic Algorithms) sont des exemples, respectivement, dheuristiques constructives et transformatives.
Ce quon vient de dire ne doit pas nous fait oublier dautres approches utilis
ees
m
eme si elles le sont rarement dans notre domaine. La programmation math
ematique [85] en est la premi`
ere avec ces diff
erentes variantes : programmation lin
eaire
en nombre entier (ILP), Programmation non lin
eaire (NLP) et programmation en
nombre entier mix
e (MILP). On cite aussi la programmation par contrainte dont
la classe englobe celles de ILP et MILP.
4.3
Etat de lart des approches existantes
Dans cette section on va d

ecrire les m
ethodes de placement et ordonnancement
les plus repr
esentatives pour les NoC et MPSOC `
a base de bus.
4.3.1
Approches pour les NoC
Les NOC constituent un domaine de recherche nouveau o`

u seulement quelques
m
ethodologies de placement ont
et
e d
evelopp
ees. La plupart ne prennent pas en
consid
eration le placement des communications alors que pour lordonnancement
encore moins. Le plus court chemin dans le NoC est souvent d
etermin
e au moment
du placement des communications.
On va pr
esenter quatre approches pour les NoC, group
ees selon le crit`
ere dassignation r
eseau. Deux parmi elles, G.Varatkar et al [35] et T.lei et al [91], traite
dune fa
con tr`
es restreinte le probl`
eme des communications en laissant de cot
e le
77

placement et ordonnancement. J.Hu et al [41] proposent une approche qui est la
seule qui traite du placement et de lordonnancement des communications en foures sur
nissant des mesures exactes des
echanges. D.Shin et al. [21] se sont concentr
les communications dans les NoC en traitant assignation r
eseau et les vitesses des
liens mais en laissant de cot
e lordonnancement.
Approches sans assignation r

eseau
G.Varatkar et al.[35] ont d
evelopp
e une m
ethodologie en deux
etapes pour minimiser la consommation d
energie totale dans le NoC (figure 4.3). L
etape communication traite simultan
ement le maping et le scheduling des taches en cherchant
`
a r
energie par minimisation du volume des communications inter processeurs. Ca
facilite aussi la minimisation d
energie des t
aches dans
l
etape de s
election de voltage en maximisant les repos (slack). Les deux objectifs
sont altern
es par un crit`
ere de communication qui a le r
ole de fixer le volume local
des communication inter-processeurs sous un seuil fix
e globalement d
ependant des
communications de lapplication et dun facteur K(0 K 10). Ce facteur permet
darr
eter la boucle externe de la m
ethodologie jusqu`
a ce quun optimum est atteint. La deuxi`
eme
etape de la m
ethode traite le DVS pour les t
aches et exploite
la distribution non uniforme des repos (slack) en consid
erant une valeur maximale
pour le temps et l
energie pendant le basculement des voltages [97]. La m
ethode ne
prend pas en consid
eration le placement et lordonnancement des communications ;
les distances des communications sont grossi`
erement estim
ees. Ainsi les deadlines
hard ne sont pas garanties car les d
elais des communications sont ignor
es.
Fig. 4.3 : Methogologie de G.Varatkar et al.
T.Lei et al. [91] utilisent une m
ethode `
a deux
etapes bas
ee sur les G.A pour le
placement et ensuite appliquent les techniques ASAP/ALAP (ASAP : As Soon As
Possible ; ALAP : As Late As Possible) pour lordonnancement des t
aches (figure
4.4). Lobjectif du placement est de maximiser les temps de performance, pendant
que lordonnancement est utilis
e pour respecter les hard deadlines. Les communications ne sont pas plac
ees et schedul
ees et leurs d
elais sont estim
es en utilisant
une distance moyenne dans le NoC ou La distance Manhattan entre processeurs.
Cette m
ethode ne garantie pas les hard deadline cars elle utilise la moyenne dans
des pires cas des temps dex
ecution (WCET Worst Case Execution Times) pour les
t
aches et le chemin de communication critique.
La m
ethodologie a trois
etapes. Dans la phase de partitionnement les t
aches sont
assign
ees aux classes de composants IP. Dans la phase embarquement (embedding
phase) les t
aches sont assign
ees `
a leurs composants IP `
a haute performance dans la
78

classe. ASAP/ALAP est appliqu
ee pour la faisabilit
e de la solution.
J.H et al [41] ont d
evelopp
e une m
ethode doptimisation d
energie qui cherche le
plus court chemin des communications dans le NoC (figure 4.5) et calcule la consommation d
energie pour d
ecider entre des placements possibles pour construire la
solution initiale. Cette m
ethode ne traite pas le voltage s
election et lassignation
r
eseau mais exploite les repos (rel
achement) non uniforme en les distribuant dune
fa
con proportionnelle selon le timing et les profils d
energie des t
aches.
Cette m
ethode fournit des mesures des d
elais de communication, de la consommation d
energie et tend `
a satisfaire les hard deadlines. Elle a deux phases,
energie
dordonnancement (EAS) et recherche-r
eparation (SaR). Durant la phase EAS la solution est construite en se basant sur LS pour le mapping et scheduling des t
aches
parall`
eles et une autre m
ethode d
eterministe pour le mapping et scheduling des
communications parall`
eles. La m
ethode d
eterministe traite lordonnancement des
communications pour toutes les t
aches pr
etes et les processeurs disponibles dans
le but de trouver le temps de terminaison le plus court (EFT) de toutes les t
aches
pr
etes.
Fig. 4.4 : La methodologie de Lei et al.
Fig. 4.5 : Methodologie de J.Hu et al

La m
ethode dArmin et al [55] va
etre pr
esent
ee avec plus d
etail car elle est la
plus r
ecente que celles qui ont pr
ec
ed
e. Dans leur approche les auteurs utilisent
comme mod`
ele dapplication un GT et comme plateforme cible un NOC de dimension deux. Ce processus ils lont nomm
e Core Mapping Technique (CMT) qui
commence par d
efinir un graphe de t
ache repr
esentant lapplication et ces t
aches.
Il se termine par un placement optimal des composants sur des plateformes `
a topologies diff
erentes (voire chapitre I), mais la plus r
ealiste et faisable quils retiennent
est celle dun r
eseau en 2D-mesh. Le graphe TG mod
elisant une application est
une s
erie de t
aches. En plus, chaque composant IP dans le NOC est responsable
de lex
ecution dune t
ache pr
e-assign
ee. Lobjectif est de d
ecider quel composant
IP doit
etre plac
e dune fa
con optimale sur quelle tuile tel que les contraintes de
performance soient satisfaites. Dans ce travail les auteurs cherchent `
a minimiser la
consommation d
energie globale sur tous les liens du r
eseau.
Le graphe TG qui est un graphe caract
erisant lapplication (APCG) est un
graphe direct o`
u chaque sommet Ci repr
esente un IP s
electionn
e. Et chaque arc
aij repr
esente la communication entre Ci etCj . Chaque propri
et
e d(aij ) de larc aij
repr
esente le volume de donn
ees en bits transf
er
ees de Ci Cj sur larc. Dune fa
con
79

g
en
erale TG peut expliciter les d
ependances de donn
ees, les d
ependances logiques
et temporelles entre les t
aches.
Pour larchitecture, un graphe direct ACG permet de la mod
eliser. Chaque sommet ti repr
esente une tuile dans larchitecture et chaque arc rij repr
esente le chemin
ti,tj
de ti tj . Chaque rij a comme propri
et
e Ebit qui repr
esente la consommation d
enerti,tj
gie moyenne par lenvoie dun bit de ti `
a tij . Le calcul de Ebit a
et
e propos
e dans
les travaux de [96] selon la formule suivante :
ti,tj
= nhops xESbit + (nhops 1)xElbit
Ebit
titj
O`
u Ebit
est l
energie consomm
ee par bit entre les nuds. ESbit est l
energie
consomm
ee par les switchs entre les nuds et nhops est le nombre de bit transf
er
es
de la tuile source `
a la tuile destination. Ceci permet de voir que pour un 2D-Mesh
avec un routage minimal la consommation moyenne d
energie par lenvoi dun bit
entre deux nuds ti , tj est d
etermin
ee par la distance de Manhattan entre eux. Ceci
est bas
e sur le fait que tous les liens ont les m
emes caract
eristiques. Dans ce travail les auteurs pour g
en
eraliser ont suppos
e que chaque lien a un Elbit diff
erent et
chaque switch a un ESbit diff
erent. Ce qui donne lexpression suivante pour le calcul
de la consommation d
energie totale des liens.
ti,tj
Ebit
=
nhops
X
k=1
Esbit +
nhops1
X
Elbit
(4.1)
k=1
Do`
u la consommation d
energie totale pour transf
erer les donn
ees peut
etre calcul
ee en multipliant l
energie obtenue lors de l
equation pr
ec
edente par le volume
des donn
ees :
ti,tj
ti,tj
Etotal
= datasizeti,tj Ebit
(4.2)
Ensuite pour le placement des t

aches, ces auteurs, d
etermine une liste TPL (Task
Priority List) qui donne la liste des t
aches selon les priorit
es de leur placement. Pour
la plateforme ils utilisent la liste PPL (Platforme Priority List) qui ordonnance les
tuiles selon lordre descendant des degr
es de connectivit
es (voisinage), ainsi dans
cette liste les tuiles du centre sont les premi`
eres et celles des fronti`
eres sont `
a la fin
de la liste. Les priorit
es des placements sont exprim
ees par les r`
egles suivantes :
1. Les t
aches qui communiquent le plus sont plac
ees le plus proche possible.
80

2. Les t
aches fonctionnellement tr`
es li
ees doivent avoir la distance Manhattan la
plus petite.
3. Les t
aches `
a degr
e de connectivit
e le plus
elev
e ne doivent pas
etre plac
ees sur
des tuiles du bord du NOC mais de pr
ef
erence sur celles du centre.
Enfin pour d
eterminer le placement, une fonction co
ut est d
efinie bas
ee sur la
distance minimale et les exigences de la bande passante entre les nuds source et
destination. Comme exemple de la fonction co
ut relative `
a la r`
egle 2 on a :
C(i) = max[deg(Ti )] ; o`
u Ti est une t
ache dans TG
Approches avec assignation r
eseau
D.shin et Al. [21] ont propos
e une m
ethodologie (figure 4.6) bas
ee sur lassignation r
eseau et lallocation des vitesses des liens pour r
eduire la consommation
d
energie dans les NoC avec une
echelle de voltage des liens. Le placement des
t
aches et lassignation r
eseau cible `
a minimiser le volume des communications interprocesseurs, cependant la s
election statique du voltage et la gestion statique de
l
energie tendent `
a r
energie des liens. Le placement de
t
aches permet la v
erification des contraintes de dimensionnement. Les hard deadlines sont aussi garanties, car quand lordonnancement des communications nest
pas performant, les pires d
elais des communications (Worst Case Communication
Delay) des liens sont appliqu
es. Les liens peuvent
etre partag
es par plusieurs arcs
sans contraintes sur les volumes des communications. Comme cons
equence davoir
ignor
e lordonnancement des communications, la s
election du voltage des liens et la
gestion d
energie sont trait
ees dune fa
con statique.
Cette m
ethode utilise le GA pour le placement des t
aches et lassignation r
eseau. Pour lordonnancement des t
aches et lassignation des vitesses de liens cest
LS qui est utilis
ee. Le GA dans cette m
ethode est bas
e sur un chromosome de
placement, un croisement `
a deux points et une mutation al
eatoire. Le GA pour lallocation utilise les permutations des tuiles (Tile :
el
ements de larchitecture) comme
chromosome, les cycles de croisement pour g
en
erer les solutions acceptables et des
changements al
eatoire comme mutation. Le GA pour le placement du routage des
communications utilise des chromosomes binaires pour coder les mouvements selon
les directions X et Y, ce qui a un impact sur les volumes des communications de
chaque lien et par l`
a sur les d
elais de communications.
LS utilise la mobilit
e des t
aches (|ASAP startALAP end|) comme priorit
e statique
qui est bas
ee sur lestimation pessimiste des d
elais des communications.
Fig. 4.6 : Methodologie de D.Shin et al.

81

Hsin-chou et al[37] propose un algorithme qui fait le placement et lordonnancement simultan
ement pour ce cas, en utilisant la technique TDM (Time Division
Multiplexing) pour le partage des liens du r
eseau. Ainsi plusieurs arcs de communication peuvent se partager un m
eme lien entre deux nuds en se partageant sa
bande passante. Ici aussi les auteurs utilisent comme mod`
eles deux graphes : CTG
(U,E) (Communication Task Graph) o`
u chaque sommet ui U repr
esente un IP, et
0
chaque arc eij E repr
esente la communication de lIP ui versl IP uj . La propri
et
e de
larc eij not
ee par wij repr
esente la bande passante n
ecessaire pour communiquer
entre ui etuj . Le deuxi`
eme graphe est nom
e N AG(V, P ) (NOC Architecture Graph).
Chaque sommet vi V repr
esente une tuile dans larchitecture et chaque arc pij P
repr
esente le chemin de vi vj . La valeur rij associ
ee au lien repr
esente la bande passante.Pour ces auteurs le mapping est d
efini par la fonction MAP(U) :
M AP : U 7 V vj = map(ui ), ui U, vj V
(4.3)
L(pm,n ) est lensemble des chemins pm,n .

Un lien est not
e par li,j.
rij peut
etre obtenu par la relation :
ms|v|
rij =
B(li,j , Pm,n ) Wm,n
(4.4)
ns|v|
o`
u
B(li,j , Pm,n ) = 1sili, j L(Pm,n ); B(li,j , Pm,n ) = OSinon
(4.5)
En supposant que la bande passante de chaque lien est la m

eme, lalgorithme
qui mappe CTG (U,E) `
a NAG(V,P) doit au moins satisfaire l
equation maxrij
bandepassantedulien.
La latence est d
efinie comme
etant la dur
ee denvoie dun paquet de l
emetteur au
r
ecepteur. Elle d
epend de la latence du switch et de la latence du lien not
ees par
ls etll . La latence du chemin de communication Cn pour lenvoie dun bit de donn
ee
de la tuilei `
a la tuilej peut
etre calcul
ee par :
LCN =
LSi + (nhops 1) Ll
(4.6)
inhops
82

O`
u nhops est le nombre de switchs rencontr
es par le bit pendant son transfert.
enote la latence du switch Si dans le chemin de communication, elle
La latence LSi d
est obtenue par la relation : LSi = TT ransf ert + TW aiting .
TT ransf ert est le temps de transfert du switch. Ce temps est
egal `
a la dur
ee que prend
un wicth pour faire passer le paquet sans le stocker dans son buffer. Le temps dattente TW aiting est le temps de stockage du paquet dans le buffer, il d
epend de lalgorithme dordonnancement et il est
egal `
a z
ero sil ny a pas de stockage de paquet.
P
Donc pour ces auteurs lobjectif est de minimiser LCN pourn | N |. O`

u | N | est
le nombre des chemins de communication dans le NOC. Du fait que LCN d
epend de
LSi alors lobjectif de lordonnancement pour ces auteurs devient
XX
min
TW aiting ; i | M || K |
. O`
u | M | est le nombre de switch et | K | est le nombre de chemin de communications dans le switch.
Fig. 4.7 : Exemple de placement du CTG sur le NOC. Les lignes flechees dans le NOC
representent les chemins de communications reservees par lalgorithme de placement.
Hin-chou et al font le placement et lordonnancement en deux
etapes. Dans la
premi`
ere il d
etermine le placement `
a laide dune heuristique, le r
esultat est utilis
e
pour ordonnancer les chemins de communication dans la deuxi`
eme
etape (figure
4.6-bis). Si les r
esultats de lordonnancement ne v
erifient pas les contraintes de la
latence de communication alors le placement est refait en r
e-ex
ecutant la premi`
ere
etape. Le processus est r

ep
et
e jusqu`
a ce que toutes les latences de communication
soient v
erifi
ees.
R
esum
e
Les tables 4.1 et 4.2 [77] synth
etisent les
etapes et les objectifs des m
ethodologies
vues pr
ec
edemment.
Comme on le voit dans ces tableaux les m
ethodologies des N0C ne couvrent
pas compl`
etement lespace dexploration surtout si on prend en consid
eration les
communications. Une approche traite de lassignation r
eseau [21] et une autre lordonnancement des communications [41]. Bien que deux approches [[35],[21]] minimise le volume des communications inter-processeur durant le placement des t
aches.
La consommation d
energie est lobjectif pr
ef
er
e dans les approches doptimisation. Quatre de ces approches [[35],[41] , [21],[37] ] sont bas
ees sur le probl`
eme,
83
Ref
G.Varatkar
et al
T.Lei
et al
J.Hu et al.
D.Shin et al.
Mapping
Network
assignment
Task Tile Com
LS
2-GA
LS
GA
GA
Exact
GA
Scheduling
Tile
LS
ASAP/
ALAP
LS
LS
Com
Exact
-
Voltage
Selection
Tile Com
ILP
-
LS
Power
Manage
Tile Com
LS
Tab. 4.1 Methodologies pour les NOC
Ref
G.Varatkar et al
T.Lei et al.
J.Hu et al.
D.Shin et al
Consommation denergie
Dynamique
Statique
Task Comm Task Comm
DVS
Y
Y
Y
SVS
ABB
SPM
Contraint
du temp
Hard Soft
Y
Y
Y
Y
-
memoire
Code Data
-
Zone
Tab. 4.2 Objectifs specifies pour les NOC
84

notamment la consommation d
energie des t
aches et des communications. Ainsi, G.
election dynamique des voltages pour les t
aches,
Varatkar et al. [35] utilisent la s
D. Shin et al. [21] utilisent assignation statique des vitesses de liens et la gestion
statique de l
energie pendant que J.Hu et al [41] la distribution non uniforme des
rel
achements durant le placement et lordonnancement.
Toutes ces approches tendent `
a v
erifier les hard deadlines mais seulement deux
ethode maximise les performances
[[41],[21]] les garantissent. T.Lei et al. [91], leur m
dun ensemble dapplications, mais aucune de ces approches ne traite les soft deadlines.
4.3.2
Approches pour les syst`

emes embarqu
es multiprocesseur (MPES ou
MPSoC)
Les syst`
emes embarqu
es multiprocesseurs dont la communication est `
a base de
bus amplifient la complexit
e du probl`
eme de placement et ordonnancement. Car
dans ce type de syst`
emes les bus sont assimil
es `
a des processeurs, ce qui entrane le
m
eme traitement pour les t
aches et les communications. Des approches diverses sont
d
evelopp
ees pour les MPSOC `
a base de bus, elles ciblent toutes diff
erents objectifs
doptimisation et focalisent sur certaines
etapes de conception. Ainsi, la consommation d
energie avec DVS est cibl
ee par M.T.Schmitz et al. [[48],[64]], de m
eme
pour A.Andrei et al. [3], F.Gruian et al.[27] et L.Benini et al.[48]. Le traitement de
lordonnancement avec des deadlines soft est fait par L.A. Cortes et al. [[45],[46]]
pendant que le placement et lordonnancement pour l
equilibrage de charge de la
m
emoire est lint
er
et de R.Szymanek et al. [82].
Approches bas
ees sur l
energie
M.T. Schmitz et al. [[48],[63]] ont d
evelopp
e une m
ethodologie, pour les syst`
emes
embarqu
es h
et
erog`
enes distribu
es, appel
ee LOPOCOS (Low Power CO-Synthesis)
qui tend `
energie en off-line des applications multim
edia ou t
el
ecommunications en garantissant les contraintes temps r
eel Hard et
les contraintes de taille de la puce. Cette m
ethode est constitu
ee de deux boucles
imbriqu
ees : la boucle externe traite lallocation des composants et le placement des
t
aches. La boucle interne pour lordonnancement de temps, placement des communications et la s
election de voltage (Figure 4.8).
Le placement de t
aches est trait
e s
epar
ement du placement des communications et
il est impl
ement
e`
a laide du GA. Lalgorithme nomm
e EE-GMA (Energy Efficient
Genetic Mapping Algorithm) est bas
e sur loptimisation de l
energie dans le sens o`
u
uniquement les solutions de placement et dordonnancement correspondantes `
a la
85

faible consommation d
energie survivent et saccouplent, mais sa principale contribution est le faite de garantir les contraintes de la taille de la puce. Ces contraintes
sont introduites avec des p
enalit
es dans lalgorithme.
Fig. 4.8 : Methodologie de M.T.Schmitz et al.

Le placement des communications est suivi en m
eme temps de lordonnancement
afin de mieux optimiser les objectifs communs. Lordonnancement est impl
ement
e
`
a laide de la combinaison de la m
ethode LS avec le G.A o`
u les priorit
es dynamiques des t
aches dans la liste des processus pr
ets (Ready) est obtenue `
a laide du
GA. Lalgorithme EE-GLSA (Energy Efficient Genetic List Scheduling Algorithm)
cible `
a garantir les deadlines hard et traite le probl`
eme d
energie dans le sens o`
u
les solutions dordonnancement `
a faible consommation d
energie survivent et saccouplent, l`
a aussi les contraintes de temps sont introduites sous formes de p
enalit
es.
La s
election voltage est appliqu
ee pour les t
aches plac
ees et ordonnanc
ees en
utilisant lalgorithme PV-DVS g
en
eralis
e (Power Variation Dynamique Voltage Scaling). Les rel
achements sont exploit
es en consid
erant les profiles
energ
etiques des
t
aches. Cet algorithme ordonnance les t
aches `
a un voltage dans les domaines continus ou deux voltages dans les domaines discrets en ignorant le total des basculements
(switching overhead). Donc PV-DVS est un LS avec des priorit
es dynamiques qui
distribue par incr
ementation les rel
achements disponibles aux t
aches `
a consommation d
energie la plus importante.
A.Andrei et al.[3] combine ABB avec DVS pour r
eduire la perte d
energie des
t
aches `
a cause de l
energie dynamique des syst`
emes multiprocesseurs. Cette approche prend le temps et l
energie comme principaux crit`
eres pour switcher entre
les niveaux de voltage. La programmation math
ematique est appliqu
ee pour des
versions de probl`
emes continus ou discrets avec ou sans le basculement. NLP retourne une seule paire de voltage (Vdd , Vbs ) pour chaque t
ache dans les domaines
continus. MILP retourne le temps utilis
e par chaque t
ache dans chaque paire multivoltage (Vdd , Vbs )dun domaine discret.
F.Gruian et al.[27] a d
evelopp
e une m
ethode dordonnancement et s
election de
voltage pour les t
aches simultan
ement pour les MPSoC avec un placement d
ej`
a fait
(figure 4.8). La m
ethode tend `
a minimiser l
energie consomm
ee par les traitements
en v
erifiant les contraintes temps hard. DVS avec distribution uniforme des rel
achements est appliqu
ee dans les domaines continus et discrets pour des niveaux `
a
simple et double voltage en ignorant la consommation due au switching.
La m
ethode est impl
ement
ee avec LS bas
e sur des niveaux avec des priorit
es
86

dynamiques. LS bas
ee niveau donne la priorit
e `
a la t
ache pr
ete qui donne la plus
large minimisation d
energie si elle est retard
ee dune seule unit
e de temps ou celle
qui va atteindre rapidement son temps de d
ebut le plus tard (LST : Latest Start
Time). Le coefficient est donn
e aux t
aches urgentes, il permet aussi `
a la boucle
externe de trouver loptimum entre les d
elais et la minimisation d
energie.
Fig. 4.9 : Methodologie de F.Gruain et al.
Approche pour les contraintes temps r

eel soft
L.A Cortes et al. [[45],[46]] a propos
e un ordonnancement quasi statique pour
les MPSoC avec des contraintes temps r
eel hard et soft (figure 4.9). Lordonnancement construit, en off line, un arbre des ordonnancements o`
u il explicite les points
de switching d
ependants des temps exig
es, des temps maximums dex
ecution des
t
aches et sur les fonctions utilitaires associ
ees aux t
aches soft. En se basant sur
cet aspect, lalgorithme choisi en on-line le chemin dutilit
e maximum dans larbre
dordonnancement en fonction des temps dex
ecution actuel des t
aches et les points
activ
es de switching. Lordonnancement statique de larbre garanti la v
erification
des deadlines et maximise la fonction dutilit
e totale des taches soft. Ceci sobtient
en premier par lordonnancement des t
aches soft critiques. Il assure aussi le placement des t
aches sur les processeurs, les communications et les calculs sont trait
es
de la m
eme mani`
ere car les bus sont assimil
es `
a des processeurs.
Pour cette approche les deux m
ethodes BB et LS sont utilis
ees pour lordonnancement des deadlines soft et pour d
eterminer les intervalles de temps des points de
switching dans larbre dordonnancement.
Fig. 4.10 : Methodologie de L.A.Cortes et al.

La fonction totale dutilit
e est la somme des fonctions individuelles dutilit
e des
t
aches soft et explicite la qualit
e de d
egradation des performances du syst`
eme quand
les deadlines soft sont ignor
es. Les fonctions dutilit
e associ
ees aux t
aches soft ne
subissent pas daugmentation, elles d
ependent des temps n
ecessaires de traitement
des t
aches soft et permettent de capter limportance et la criticit
e des t
aches. Les
temps dex
ecution des t
aches sont variables et non uniform
ement distribu
e dans un
intervalle.
87

Approche pour les contraintes temps r
eel hard
Dans leur approche L.Benini et al.[48] introduisent une m
ethode complexe pour
le placement et lordonnancement de voltage variable. Ils proposent un formalisme
et une solution pour le probl`
eme doptimalit
e de lallocation, lordonnancement et
la s
election du voltage discret en minimisant la perte d
energie du syst`
eme et du
switching. Cette approche est bas
ee sur la technique de d
ecomposition utilisant les
Benders logiques o`
u le probl`
eme de placement est r
esolu `
a laide de la programmation lin
eaire en nombre entier et lordonnancement `
a laide de la programmation
par contrainte.
Benini prend aussi comme mod`
ele un graphe de t
aches acyclique direct o`
u les
nuds repr
esentent les t
aches ayant comme propri
et
es des deadlines dlt et W CNt
comme nombre de cycles dhorloge n
ecessaire pour son ex
ecution dans le pire cas.
Les arcs repr
esentent les communications inter-t
aches et ont comme valeur le volume de donn
ees
echang
ees entre les t
aches repr
esent
ees par les nuds reli
es par
cet arc. Ils introduisent aussi le nombre de cycles dhorloge n
ecessaires au basculement entre les modes lecture/
ecriture des donn
ees not
es par W CNR et W CNW . Les
t
aches sont ex
ecut
ees sur un ensemble de processeurs P. Chaque processeur peut
fonctionner avec plusieurs modes de vitesse et d
energie. Chaque t
ache n
ecessite de
l
energie pour son ex
ecution et les communications quelle fait. En plus quand un
processeur bascule entre les modes il d
epense du temps et de l
energie. Les auteurs
notent par Eij l
energie d
epens
ee par le processeur quand il bascule de la fr
equence
i`
a la fr
equence j. Et par Tij le temps perdu pour passer de la fr
equence i `
a j. Donc
le probl`
eme est un DVS, pour le traiter les auteurs lont d
ecompos
e en deux sous
probl`
emes. Le premier appel
e probl`
eme global consiste `
a affecter les processeurs
et les fr
equences aux t
aches, le second appel
e sous probl`
eme fait lordonnancement
des t
aches en utilisant les r
esultats du probl`
eme global.
Pour le probl`
eme global ils font le placement avec minimisation de l
energie selon
certaines fr
equences tout en respectant les deadlines de chaque t
ache.
XX
T
X
W CNwtt1
W CNt
W CNrtt1
+
+ Wppt1m
)] dlt t
[Xptm
(Rppt1m
fm
f
fm
m
t =1
(4.7)
Xptm qui est

egale `
a 1 si la t
ache t est affect
ee au processeur p fonctionnant au
mode m, 0 sinon.
W CNt le nombre de cycles dhorloge n
ecessaires `
a lex
ecution de t au pire cas.
fm est la fr
equence de cycle dhorloge quand la t
ache est ex
ecut
ee au mode m.
Rppt1m est
egale `
a 1 si la t
ache t est affect
ee au processeur p, lit les donn
ees au mode
88

`
a partir de t1 quand celle-ci nest pas affect
ee `
a p ; sinon 0.
eme d
efinition que Rppt1m Rppt1m mais en
ecriture.
Wppt1m m
W CNrtt1 le nombre de cycles n
ecessaires pour que t affect
ee `
a R lit `
a partir de t1 .
W CNwtt1 m
eme d
efinition que W CNrtt1 mais en
ecriture.
dlt cest le deadline de la t
ache t.
Dans le sous probl`
eme, Benini essaye de faire lordonnancement tout en respectant les temps de d
ebut et de fin de chaque t
ache. OF, donn
ee ci-apr`
es, est la
fonction objectif minimis
ee dans ce sous probl`
eme :
OF =
P
X
T ranscostij
(4.8)
p=1 (i,j)Sp |next(i)=j
O`
u T ransCostij est une valeur obtenue par la m
ethode introduite par Benini en
utilisant la d
ecomposition `
a laide des Benders. Cette fonction objectif doit
etre
minimis
ee tout en respectant les contraintes de pr
ec
edence. Si l1 etl2 sont deux activit
es qui se suivent alors il faut que :
Startl1 + durationl1 + T ransT imel1l2 Startl2
O`
u Startl1 , Startl2 sont les temps de d
ebut des activit
es l1 etl2 ;
W CNi
Durationl1 = fi
T ransT imel1l2 est le temps dinitialisation sp
ecifi
e dans la matrice des transitions
obtenue avec les Benders.
Approches bas
ees sur la m
emoire
R.Szymanek et al. [[81],[82]] ont d
evelopp
e une m
ethode qui fait le placement et
lordonnancement simultan
ement avec un
equilibrage de lutilisation de la m
emoire
et en v
erifiant les deadlines hard (figure 4.10). La m
ethodologie fait le placement
en m
emoire du code et des donn
ees et sassure aussi que les donn
ees
echang
ees
soient pr
esentes dans les m
emoires du producteur et du consommateur pendant la
communication.
La m
ethodologie est bas
ee sur LS avec un objectif adapt
e et des priorit
es dynamiques qui aident loutil CLP `
a explorer efficacement lespace des solutions. La
t
ache la plus importante en consommation de donn
ees ou urgente (selon lobjectif )
est toujours assign
ee au processeur le plus pauvre en terme dutilisation de la m
emoire en code ou en donn
ees. Les objectifs sont inter-chang
es quand les contraintes
de donn
ees ne sont pas v
erifi
ees.
Fig. 4.11 : R.Szymanek et al.Methodology.

89

R
esum
e
Les deux tables suivantes synth
etisent les m
ethodologies et les objectifs pour le
probl`
eme de placement et dordonnancement dans les MPSOC `
a Bus.
Ref
Mapping
M.T.Schmitz et al
A.Andrei et al
R.Szymanek et al
F.Gruian et al
L.Cortes et al
Task
GA
-
Com
GA
-
Scheduling
Task
GA+LS
LS+CLP
Com
GA+LS
-
LS
BB+LS
Voltage
Selection
Task Com
LS
NLP/
-
Power
Manage
Task Com
LS
-
Tab. 4.3 Methodologies pour MPSOC à base de Bus
Ref
M.T.Schmitz
et al
A.Andrei et al
F.Gruian et al
R.Szymanek et al
L.A.Cortes et al
Consommation denergie
Dynamique
Statique
Task Comm Task Comm
DVS
DVS
DVS
-
ABB
-
Contraint
du temp
Hard Soft
Y
Y
Y
Y
Y
memoire
Code Data
Y
Y
-
Y
-
Zone
Y
-
Tab. 4.4 Les objectifs des MPSOC à bus

Comme on le voit dans ces tableaux les m
ethodologies sont d
evelopp
ees pour certains domaines et objectifs. Ainsi M.T.Schmitz et al. [[48],[64]] ont d
evelopp
e une
m
ethodologie pour la minimisation d
energie quand A.Andrei et al.[3] et F.Gruian
et al. [27] ont focalis
e sur le DVS. L.A.Cortes et al. [[45],[46]] ont d
evelopp
e le placee sur un
ment pour les soft deadlines pendant que R.Szymanek et al. [82] ont travaill
placement et ordonnancement bas
e sur la m
emoire. Dans toutes ces m
ethodes les
deadlines hard sont v
erifi
ees. Les heuristiques constructive (LS) et transformatives
(GA) comme la programmation math
ematique (NLP, MILP, CLP) et les m
ethodes
d
eterministes ont
et
e utilis
ees pour traiter soit s
epar
ement ou simultan
ement les
objectifs d
esign
es.
90
4.4. Comparaison entre les techniques de placement et dordonnancement
4.4
Comparaison entre les techniques de placement et dordonnancement
Les m
ethodes vues auparavant concernant ce probl`
eme vont
etre compar
ees par
la suite selon les crit`
eres : Contraintes de temps, consommation d
energie et les
contraintes de taille ou de surface.
4.4.1
V
erification des contraintes de temps r
eel
Par contraintes de temps r

eel, on sous entend les deadlines soft et Hard. Lordonnancement tend souvent `
a v
erifier les contraintes de temps, mais le placement aussi,
cible la minimisation du d
elai total dex
ecution. M
eme si dans les pr
esentations pr
ec
edentes on a parl
e des MPSOC et NOC, dans la suite de cette comparaison cest
uniquement ces derniers qui seront discut
es car cest uniquement eux qui feront
lobjet de notre
etude.
Les contraintes temps r

eel hard dans les NoC
Les approches pour les NoC ciblent souvent la v
erification des contraintes temps
r
eel hard `
a cause du probl`
eme des communications quy est plus pertinent et complexe. Cest pour cette raison que dans ces syst`
emes on donne plus dattention aux
d
elais des communications et linterd
ependance (topologie) des
el
ements du NOC.
G.Varaktar et al.[35] ne garantissent pas les hard deadlines, les communications
ne sont ni plac
ees et ni ordonnanc
ees dans le NOC. Les d
elais sont ignor
es pendant la v
erification des deadlines. De plus des valeurs moyennes pour le ET (temps
dex
ecution) des t
aches dans le WCET sont utilis
ees. Durant le placement et lordonnancement simultan
es, la t
ache la plus critique est affect
ee au processeur dont
la disponibilit
e est la plus proche ou `
a celui auquel la t
ache la plus communicative
avec elle est affect
ee tout en veillant `
a ce que les deadlines restent v
erifi
es. La t
ache
la plus critique est celle qui a le temps de d
ebut le plus proche (EST : eraliest start
time) plus le temps de fin le plus lointain (LFT : Latest Finish Time) (EST+LFT).
EST explicite le moment o`
u une t
ache est pr
ete et le processeur disponible pour
elle. LFT est le minimum entre le deadline et le temps le plus lointain de d
ebut de
ses successeurs.
T. Lei et al. [91] ne garantissent pas, eux aussi, les hard deadlines car WCET
pour les t
aches et des d
elais moyens pour les communications sont utilis
es pendant
la v
erification des deadlines dans chaque TG de lensemble des TG. Le placement
et lordonnancement des communications ne sont pas trait
es car le chemin minimal
91

des communications quil utilise est estim
e dune fa
con grossi`
ere. Cest du chemin
minimal que d
epend laffectation exclusive des liens et l
evitement des deadlock.
Le d
elai final des communications d
epend du volume des communications, de la
distance minimal de communication et du d
elai de linterface r
eseau pour la paquetisation et d
epaquetisation des messages. Durant lallocation des groupes IP et
le placement des t
aches, le d
elai global du chemin critique est minimis
e pour chaque
TG dans lensemble T. La fonction objectif est le maximum entre le d
elais sur le
chemin critique et le deadline pour chaque TG. Les deadlines Hard sont v
erifi
es
sur le chemin critique quand la fonction objectif a une valeur inf
erieure ou
egale au
deadline maximal de lensemble TG.
D. Shin et al. Garantissent le deadline hard. Ils utilisent le WCET des t
aches et
des valeurs pessimistes pour les d
elais de communication sont utilis
ees pendant la
v
erification des deadlines hard. La communication est plac
ee sur le chemin le plus
court du NOC qui est minimis
e durant lallocation des tuiles. Ceci implique que
plusieurs arcs du GT peuvent utiliser le m
eme lien ce qui rend plus compliqu
e les
probl`
emes de routage et de lordonnancement des communications. Ce ci rend aussi
le d
elai de communication
etroitement li
e `
a la bande passante et la vitesse (fr
equence) de transmission des donn
ees. Le d
elai de larc (Edge delay) est la somme
des d
elais des liens constituant le chemin de routage tout en ignorant les temps
de basculement (dus `
a lordonnancement). Durant lordonnancement des t
aches, la
t
ache la moins mobile est la plus prioritaire. La mobilit
e dune t
ache est donn
ees
par | ASAPstart ALAPend | et elle est bas
ee sur une
evaluation pessimiste des d
elais
de communication.
J.Hu et al [63] garantissent aussi les hard deadlines. WCET des t
aches et communications sont utilis
ees pendant la v
erification des hard deadlines. Communication
est plac
ee et ordonnanc
ee sur le chemin disponible minimal du NOC ayant un deadlock libre (bande passante non satur
ee). Durant le placement et lordonnancement
simultan
es la t
ache la plus critique en temps (EF T BD : BD = Budgeteddeadline)
`
a partir de la liste des t
aches pr
etes (ready list) est affect
ee au processeur le plus
rapide. La t
ache la plus critique en temps est celle qui d
epasse son BD avec une diff
erence maximale EF T BD. Quand aucune t
ache critique (EDF < BD) nest dans
la liste, BD reste v
erifi
e quand on affecte la t
ache `
a forte consommation d
energie
au processeur ayant la consommation la plus faible. EFT contient les d
elais des
communications entrantes et WCET ceux des t
aches pendant que BD contient la
moyenne ET des t
aches et leurs rel
achement (slack) en ignorant les communications.
Les slack sont distribu
es dune fa
con non uniforme sur les t
aches, ils sont bas
es sur
leur
energie et les profils de d
elais (variances).
92

Comparaison
Les tables ?? et ?? r
esument les approches pour les NOC pour v
erifier les
contraintes temps r
eel hard selon les principaux crit`
eres. La table ?? montre comment le temps de communication est minimis
e dans chaque approche et comment
les contraintes deadlines hard sont garanties. La table ?? repr
esente les modalit
es de
maximisation des performances de temps durant le placement et lordonnancement
des t
aches.
Ref
G.Varatkar
et al.
T.Lei et al.
D.Shin et al.
J.Hu
et al.
Temps de Communication
Min
Min
Band
Volume
Distance
passante
TM
TM
-
NA
CM
+CS
Manhattan
Manhattan
Min
Dispo
Const
SVS
Const.
Retard global
T
ache
Temp
ET
Com
WCET
WCET
WCET
WCET
AVG
WCRT
WCRT
Garantie
de
Deadline
N
N
Y
Y
Tab. 4.5 Les delais de communication dans les NOC
Ref
G.Varatkar
et al.
T.Lei et al.
D.Shin et al.
J.Hu et al.
placement des
t
aches
But
affectation PE
disponible le
plus proche
Min.chemin critique
Repair BD
violations EFT<BD
Fastest Greedy
reassignments
Ordonnancement
des t
aches
Priorite
Temp critique
min(EST+LFT)
ASAP, ALAP
temp critique
min|ASAPstar ALAPend |
Temp critique
max(EFTBD),EFT.BD
Tab. 4.6 Delais de traitement dans les NOC
D
elai de communication
Le d
elai de communication dans les NOC a un grand impact sur le co
ut total. Le
d
elai darc (Edge delay) d
epend de la taille message, la bande passante et le d
elai
de transmission unitaire. La taille de message par la bande passante nous donne le
nombre dunit
es `
a transmettre. Ils repr
esentent souvent le volume de communication de larc et de la bande passante du lien respectivement. Le d
elai de transmission
93

par unit
e de communication est influenc
e par lalgorithme de routage et d
epend de
la distance de la communication et du d
elai de communication des composants
dans le NOC tels que le lien, switch et interface r
eseau. Le d
elai du lien d
epend
de la vitesse du lien, volume de communication du lien et la bande passante du
lien. Quand les liens sont utilis
es dune fa
con exclusive le volume de communication du lien est
egal `
a la bande passante, et la vitesse du lien devient le d
elai du lien.
A lexception du volume de communication et distance de communication tous
les autres constituants du d
elai de larc sont donn
es comme constantes et qui sont
uniques pour chaque type de composant de communication dans le NOC. Ainsi minimiser le volume et la distance de la communication a un impact direct sur le d
elai
de communication. Le volume de communication inter processeur peut
etre minimis
e au moment du placement des t
aches pendant que le volume de communication
du lien est optimis
e durant le placement des communications. La minimisation de
la distance (longueur du chemin) de communication se fait pendant lallocation des
tuiles et la minimisation du chemin de routage pour chaque arc se fait durant le
placement de t
aches. Les deadlock (blocage) et congestion peuvent
etre
evit
es en
traitant lordonnancement des communications.
V
erification des deadlines hard
Hard deadlines sont garanties si et seulement si les pires ET des d
elais de t
aches
et communications sont fournies. ET de t
ache sont souvent donn
ee comme WCET.
Lestimation pessimiste des d
elais de communication n
ecessite la connaissance des
pires conditions dans lesquelles la communication est faite, comme exemple, le volume totale des communications des arcs se partageant un lien [21] ou le chemin
minimal disponible quand lusage des liens est exclusif [41].
Maximiser les performances de temps

Les priorit
es des t
aches pendant lordonnancement ou la s
election des processeurs plus un objectif durant le placement de t
aches peut accrotre les chances de
v
erifier les deadlines hard tout en minimisant le co
ut ou le temps global. Ainsi, un
meilleur ordonnancement peut
etre trouv
e si la priorit
e des t
aches englobe des informations sur les communications entrantes et rel
achements disponibles. On peut
faciliter la v
erification des deadlines hard par laffectation des t
aches les plus critiques aux processeurs les plus rapides [41].
94
4.4.2
La minimisation de la consommation d
energie
Par minimisation d
energie on veut dire r
eduction dynamique et statique de la
consommation d
energie par les t
aches et les communications durant le placement
de t
aches et la s
election de voltage. La majorit
e des approches introduites dans
la section 4.3 ciblent la minimisation dynamique d
energie de t
aches. Certaines
dentre elles traitent m
eme les deux probl`
emes de placement de t
ache selon l
energie et le DVS des t
aches. Une seule approche traite SVS pour les liens quand les
approches pour les NOC tendent `
a minimiser l
energie de communication en minimisant les communications du NOC sur le plan volume et distance. Les autres
m
ethodes traitent la r
eduction statique de l
energie.
Placement de t
ache avec optimisation de l
energie
Plusieurs approches on
et
e propos
ees, nous citerons ci-apr`
es quelques unes et
insistant sur limpact de la priorit
e des t
aches, assignation des PE et les objectifs
sp
ecifi
es pour la minimisation d
energie.
G.Varatkar et al.[35] tendent de minimiser l
energie des communications en minimisant le volume des communications interprocesseur. Ils se basent aussi sur le
fait que les communications ne d
epassent pas un certain seuil (crit`
ere de communication). Durant le placement et ordonnancement simultan
es des t
aches, la t
ache
la plus urgente est assign
ee au processeur auquel est affect
ee la t
ache avec laquelle
elle communique le plus tout en v
erifiant les deadlines hard. L
energie de communication d
epend du volume de la communication inter processeur et de la distance
moyenne de communication dans le NOC. Le placement et ordonnancement des
communications ne sont pas trait
es, ce qui ne permet pas de connatre le volume
de communication par lien. Le crit`
ere de communication est utilis
e par ces auteurs
pour veiller `
a ce que le volume local moyen de communication par arc (`
a partir des
arc entrant dans le TG) ne d
epasse pas le volume moyen global de communication
(`
a partir de tous les arcs dans TG) multipli
e par un param`
etre K (0 k 10), arr
et
e
par lutilisateur.
D.Shin et al.[21] tendent de minimiser l
energie de communication en minimisant le volume de communication inter processeur et les distances de communication
dans le NOC durant le placement et lassignation r
eseau. L
energie de communication est la somme des
energies statique et dynamique de tous les liens. L
energie
dynamique des liens d
epend du volume total des communications des arcs partageant le m
eme lien, la vitesse (fr
equence) du lien et la capacit
e de switching du lien.
Le volume de communication de chaque lien est connu apr`
es le placement.
95

J..Hu et al. [41] tendent de minimiser la consommation d
energie totale. Durant
le placement et ordonnancement simultan
es les t
aches non critiques avec le plus
grand intervalle de consommation d
energie sont affect
ees aux processeurs ayant
les consommations les plus faibles mais qui soient assez rapide pour v
erifier les
deadlines hard. Lintervalle de consommation d
energie dune t
ache est la diff
erence
entre les deux premi`
eres valeurs minimales de la consommation globale d
energie
obtenue `
a partir des ordonnancements partiaux. Les taches non critiques sont celles
ayant EF T < BD. La communication est plac
ee et ordonnanc
ee sur le chemin le plus
court disponible et non satur
e dans le NOC. La consommation d
energie globale est
la somme des
energies de calcul de toutes les t
aches plus l
energie de communication de tous les arcs. L
energie de communication dun arc d
epend du volume des
communications de cet arc (en bits) et l
energie de transfert dun bit. L
energie de
communication par bit sobtient par une formule fonction de la longueur du chemin
de routage, l
energie du lien et l
energie de switching.
Ref
G.Varatkar
et al.
D.Shin et al.
Priorite
-
Task mapping
affectation PE
La plupart de volume
de communication
-
J.Hu et al.
difference
denergie
energie
dernièrement
But
limite les volumes
de communication
min les volumes
de communication
-
Tab. 4.7 Placement de t

aches avec optimisation de lenergie
La priorit
e de la t
ache au moment de lordonnancement aussi bien que lassignation des PE et lobjectif doptimisation du placement peuvent augmenter la
pr
eservation de la consommation d
energie dynamique. A cet effet il est conseill
e
daffecter la t
ache avec le plus grand intervalle de consommation d
energie `
a son
processeur de consommation minimale durant le traitement du placement et ordonnancement (J.Hu et al. [41]). Le mod`
ele d
energie de communication d
epend du
volume de communication et l
energie de transmission. J.Hu et al.[41] introduisent
les informations de routage dans l
energie de transmission par bit quand D.Shin et
al. [21] introduisent des informations pour lassignation de la vitesse de lien.
En se basant sur ces crit`
eres on peut dire que lapproche [41] est la meilleure
m
ethodologie doptimisation d
energie pour les NOC car elle minimise la consommation totale d
energie et ordonnance les communications sur le plus court chemin
disponible en v
erifiant le deadlock. La deuxi`
eme meilleure m
ethode est celle de
energie de communication et la distance de commuD.Shin et al.[21] qui minimise l
96
4.5. Conclusion
nication. G.Varatkar et al [35] minimise uniquement le volume de communication
inter processeur sans traiter le placement de communication.
4.4.3
Contraintes mat
erielles et m
emoire
Les contraintes mat

erielles sont relatives `
a la capacit
e de la m
emoire ou au
nombre de t
aches pouvant
etre ex
ecut
ees par un
el
ement de calcul. Parmi les approches introduites dans la section 4.3 seulement trois traitent ce probl`
eme.
D.Shin et al. [21] traitent ces contraintes durant le placement de t
aches en imposant que chaque
el
ement de calcul saccommode avec la tuile du NOC. Ce qui
revient `
a v
erifier que pour chaque nombre de t
aches affect
ees `
a un processeur, la
taille m
emoire et seuil maximal ne d
epassent pas les caract
eristiques de la tuile du
N0C.
M.T.Schmitz et al. [[48],[64]] traitent eux aussi ces contraintes lors du placement
de t
aches. Pour eux les contraintes mat
erielles sont relatives `
a la taille de la m
emoire
et la surface de la puce d
ependant du type de mat
erielle (DSP, ASIC, FPGA). Dans
la fonction objectif ils introduisent des coefficients permettant de p
enaliser la non
v
erification de ces contraintes.
Pour R.Szymanek et al.[82]] les contraintes sont v
erifi
ees apr`
es le placement en
v
erifiant pour chaque m
emoire si le code et la quantit
e des donn
ees affect
ees ne
d
epassent pas la taille disponible.
4.5
Conclusion
L
etude de l
etat de lart dans le domaine du placement sur les NOC nous a
permis de tirer quelques constations. La premi`
ere est que dans ce domaine, par
placement on d
esigne Assignation, affectation et ordonnancement (AAS). Effectivement dans les travaux vus, et surtout ceux fait r
ecemment, on ne traite jamais
le placement sans ordonnancement ou linverse. Tous les travaux les abordent ensemble. Seulement la mani`
ere change, pour certains ils sont trait
es s
equentiellement, cest-`
a-dire placement ensuite ordonnancement, pour dautres ils sont trait
es
ensemble cest-`
a-dire simultan
ement. Pour chacune de ces approches on a vu quil y
a des avantages et des inconv
enients, m
eme si la deuxi`
eme approche lemporte. Le
deuxi`
eme constat est que ce probl`
eme est trait
e pour atteindre certains objectifs,
comme le temps r
eel, consommation d
energie, m
emoire, etc. Souvent ces objectifs sont cherch
es ensembles. Car, on ne peut minimiser le temps de calcul global
sans minimiser le co
ut de communication global, ou augmenter les performances
97
4.5. Conclusion
du NOC sans penser `
a minimiser la perte de l
energie, etc. Do`
u notre conviction
que ce probl`
eme ne peut
etre solutionner en cherchant des objectifs s
epar
ement
mais dessayer dau moins datteindre quelques objectifs pertinents ensemble. Cest
ce quon appelle loptimisation multi-objectifs qui sera pr
esent
ee dans le chapitre
suivant. En plus de ce qui a
et
e avanc
e, du fait des domaines quon aborde o`
u les
applications peuvent
etre hi
erarchiques o`
u on rencontre des t
aches r
ep
etitives et
dautres non, forc
ement les techniques quon va utiliser seront de familles diff
erentes. Si les m
eta-heuristiques (transformatives) simposent pour lirr
egulier dans
les probl`
emes de grande taille, il faut plut
ot penser `
a des m
ethodes d
eterministes
pour les applications `
a t
aches r
ep
etitives.
98
Chapitre 5
Optimisation multi-objectif
Sommaire
5.1
. . . . . . . . . . . . . . . . . . . . . . . 100
5.2
Loptimisation combinatoire multi-objectif . . . . . . . . . . . . . . . 101

5.2.1
Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.2.2
Les solutions dun problème multi-objectif . . . . . . . . . . . . . . . . . 101
5.2.3
Caracteristique du front Pareto . . . . . . . . . . . . . . . . . . . . . . . 103
5.2.4
Choix de la methode daide à la decision . . . . . . . . . . . . . . . . . . 104
5.3
Probl`
emes doptimisation multi-objectif . . . . . . . . . . . . . . . . . 105
5.4
Classification des m
ethodes . . . . . . . . . . . . . . . . . . . . . . . . 107
5.5
Approches de r
esolution . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.5.1
5.6
Les methodes bi-objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Conclusion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
99
5.1. Loptimisation combinatoire
Loptimisation
combinatoire consiste `
a trouver une solution optimisant une
fonction co
ut, g
en
eralement pour des probl`
emes complexes de grandes tailles. Dans
le monde industriel, g
en
eralement, les probl`
emes doptimisation sont de nature
multi-objectif puisque plusieurs crit`
eres permettent de caract
eriser une solution.
Pour les SoC, objet de notre
etude, les crit`
eres les plus connus sont le temps de
calcul, la consommation d
energie, les dimensions de la puce, taille m
emoire, etc.
5.1
Un probl`
eme doptimisation combinatoire est d
efini par un ensemble fini de solutions dites r
ealisables (formant lespace de d
ecision ) et une fonction objectif (f )
associant `
a chaque solution de lespace de recherche un co
ut. Cet ensemble de valeurs constitue lespace objectif (Y, nous avons donc f : Y ). Ainsi une solution
r
ealisable x peut
etre d
ecrite par un vecteur de d
ecision (x1 , x2 ,. . ., xn ) `
a laquelle une
valeur objectif est associ
ee `
a f(x). La r
esolution dun probl`
eme doptimisation combinatoire revient donc `
a trouver la ou les solutions(s) r
ealisable(s) de co
ut minimal
6
7
(ou maximal dynamiques ) de dynamiques .
D
efinition 1 : x (x ) est une solution optimale si et seulement si :
x f (x) f (x)
Dans loptimisation combinatoire, la difficult
e majeure r
eside dans le ph
enom`
ene
dexplosion combinatoire (laugmentation de la taille des donn
ees engendre laugmentation exponentielle de la taille de lespace de recherche). Ce qui nous emm`
ene
`
a parler de la classe des probl`
emes NP-difficiles qui correspondent aux probl`
emes
pour lesquels aucun algorithme de r
esolution polynomial en temps nest connu.
Cest cette explosion de la taille de lespace de recherche qui emp
eche lexploration
en un temps raisonnable.
Les m
ethodes utilis
ees en optimisation combinatoire peuvent
etre class
ees en deux
grandes cat
egories :
dun cot
e nous avons les m
ethodes exactes permettant de trouver la (ou les)
solution(s) optimale(s).
dun autre cot
e, nous avons les m
ethodes approch
ees permettant de trouver
une solution de bonne qualit
e mais non optimale.
Du fait que les m
ethodes exactes sont gourmandes en temps de recherche qui augmente dune fa
con exponentielle avec la taille du probl`
eme, elles coupent des parties
6
7
Notons que min(f(x)) = -max(-f(x))

Dans la suite de ce document, nous considerons un problème de minimisation.
100
5.2. Loptimisation combinatoire multi-objectif

non int
eressantes de lespace de recherche. Elles permettent de trouver la solution
optimale mais sont limit
ees dans la taille des probl`
emes quelles r
esolvent. Les m
ethodes approch
ees effectuent des recherches guid
ees `
a lint
erieur de lespace de
recherche afin de caract
eriser rapidement une solution de bonne qualit
e.
Avec ces m
ethodes, la solution trouv
ee nest pas optimale (ou si elle lest, la preuve
nest pas faite). Par contre, ces m
ethodes ne sont pas limit
ees par la taille des probl`
emes.
Actuellement, surtout dans lindustrie, les probl`
emes doptimisation rencontr
es sont
de nature multi-objectif du fait de lexistence de plusieurs objectifs pour la solution
finale. Cest pour cette raison que la suite de ce chapitre sera consacr
ee uniquement
`
a loptimisation combinatoire multi-objectif.
5.2
Loptimisation combinatoire multi-objectif
On commence dans ce paragraphe par quelques particularit

es de loptimisation
combinatoire multi-objectif, suivies ensuite, par une pr
esentation rapide des principales m
ethodes de r
esolution approch
ees.
5.2.1
D
efinition
Un vecteur de fonction co
ut, est un vecteur dont chacune de ses composantes est
un objectif. Donc un probl`
eme doptimisation combinatoire multi-objectif consiste `
a
optimiser plusieurs de ces composantes. Si nous notons ? lespace d
ecisionnel, alors
un probl`
eme doptimisation multi-objectif peut se d
efinir par :
M inf (x) = (f1 (x), f2 (x), . . . , fk (x)) n avec x
Avec f la fonction qui associe `
a chaque variable x de un vecteur co
ut et K le
nombre dobjectifs consid
er
es. La figure 5.1montre un exemple avec deux variables
de d
ecision et trois fonctions objectifs.
Fig. 5.1 Exemple de problème doptimisation combinatoire multi-objectif
5.2.2
Les solutions dun probl`

eme multi-objectif
Solutions optimales et notion de Pareto Optimalit

e
Un probl`
eme doptimisation multi-objectif nadmet pas une solution optimale
unique mais un ensemble de solutions optimales dites de meilleurs compromis. En
effet, les solutions nadmettent pas une relation dordre total car une solution peut
101
etre meilleure quune autre sur certains objectifs mais moins bonne sur dautres.
Donc une solution doptimalit
e doit
etre d
efinie pour permettre de cerner un ensemble de solutions optimales. Edge-worth [77] introduit la notion la plus utilis
ee
qui est g
en
eralis
ee par la suite par Pareto [78]. Cest ce qui a permis de parler
maintenant dans ce domaine de Pareto et de solution Pareto optimale (cest-`
a-dire
au sens Pareto). Nous parlerons aussi de lensemble des solutions Pareto optimales.
La d
efinition suivante permet de caract
eriser la notion de dominance entre deux
solutions.
D
efinition 2 : Dans un probl`
eme de minimisation avec K objectifs, une solution x
0
domine une solution x si et seulement si :
(
k [1..k], fk (x) fk (x )
0
k [1..k], fk (x) < fk (x )
Nous noterons x x
La figure 5.2 illustre une solution x donn

ee, lespace qui domine cette solution,
lespace domin
e par cette solution et les deux espaces qui nadmettent pas de relation dordre avec x au sens de Pareto, pour un probl`
eme bi-objectif. Si pour deux
0
0
0
0
solutions x et x , x 6 x et x 6 x alors nous noterons x x .
D
efinition 3 : Une solution x est dite Pareto optimale si et seulement si elle nest
domin
ee par aucune autre solution r
ealisable.
Fig. 5.2 Notion de dominance
Fig. 5.3 Exemple de front Pareto optimale

D
efinition 4 : Pour un probl`
eme doptimisation donn
ee, lensemble des solutions
Pareto not
e (P ) est d
efini par :
0
0
P = x | 6 x , x x.
esentant limage dans Y des solutions de lenLa figure 5.3 donne un ensemble repr
semble Pareto (ensemble des solutions non-domin
ees) pour un probl`
eme bi-objectif,
ceci est appel
e front Pareto.
Points particuliers
Les points particuliers qui existent dans lespace des objectifs permettent de
borner lensemble Pareto ou encore de discuter de lint
er
et des solutions trouv
ees.
102

Ces points peuvent
etre r
ealisables ou non (figure 5.4).
1. Le point Ideal, Z I , est d
efini par : Z I = (f1 (Z I ), . . . , fk (Z I ))
avec fq (Z I ) = minx fq (x) q [1..K]. Ce point a pour chaque objectif la valeur
optimale de cet objectif. Il nous donne donc une borne inf
erieure du front
Pareto.
2. Le point utopique, Z U , est d
efini par :Z U = Z I U
avec > 0 et U le vecteur unitaire (U = (1, 1, . . . , 1) <K ). Ce point sera donc
un point dominant le point Ideal, il sera bien entendu non r
ealisable.
3. Le point Nadir, Z N , est d
efini par Z N = (f1 (Z N ), . . . , fk (Z N ))
N
avec fq (Z ) = maxxP fq (x)3 q [1..K]. Cette solution repr
esente pour chaque
objectif la solution appartenant `
a lensemble Pareto ayant la valeur la plus
mauvaise sur cet objectif. Elle nous donne donc une borne sup
erieure du front
Pareto.
Fig. 5.4 Points particulier de front de Pareto
Dans le cas Bi-objectif cette solution est d
efinie par Z N = (f1 (Z N ), f2 (Z N )), avec
i [1..2]fi (Z N ) = fj (Z I ), o`
u j 6= i. Il apparat donc que la recherche du point Nadir
en Bi-Objectif ne demande aucun calcul suppl
ementaire si le point Id
eal est connu.
Comme on le voit lespace de recherche pertinent peut
etre born
e par le point Id
eal
et le point Nadir. Pour les m
ethodes exactes le but est de limiter lespace de recherche `
a ces seules parties pertinentes. Le point Id
eal et le point Nadir seront donc
primordiaux dans de nombreuses m
ethodes exactes.
5.2.3
Caract
eristique du front Pareto
Solution support
ees/non support
ees
Le front Pareto comporte plusieurs solutions, de meilleur compromis, appel
ees
solutions Pareto Optimales. Nous allons caract
eriser les diff
erents types de solutions
composants ce front. Deux types de solutions le composent.
Les solutions support
ees : leurs images dans Y se trouvent sur lenveloppe
convexe de Y. Chacune de ces solutions peut
etre trouv
ee en optimisant une
agr
egation lin
eaire des objectifs (voir la th
eorie de Geoffrion [79]).
Les solutions non support
ees : elles sont Pareto optimales mais leurs images
dans Y ne sont pas situ
ees sur lenveloppe convexe de Y. Aucune de ces solutions ne peut
etre trouv
ee en optimisant une agr
egation lin
eaire des objectifs
(corollaire du th
eor`
eme de Goffrion).
Nous pouvons donc avoir des cas extr
emes dans lesquels la fronti`
ere Pareto est
e
totalement convexe ou concave (figure 5.5). Souvent le front Pareto sera compos
103

de solutions support
ees et non support
ees (comme illustr
e dans la figure 5.6). Les
solutions non support
ees ne se trouvent pas sur lenveloppe convexe et ne sont la
solution optimale daucune agr
egation dobjectif. Il peut donc paratre l
egitime de
se demander si elles doivent
etre recherch
ees ou non. Pour avoir un compromis
entre les objectifs il nous faudra donc choisir une solution non-support
ee.
Fig. 5.5 Front Pareto concave/convexe
Fig. 5.6 Exemple de front Pareto Bi-objectif
Ensemble Pareto minimal complet/Ensemble Pareto maximal complet

Si toutes les valeurs Pareto pouvant
etre obtenues sont repr
esent
ees parmi les
solutions de lensemble alors il est appel
e ensemble Pareto complet. Certaines m
ethodes, ne permettent pas de trouver lensemble Pareto complet (exemple : la m
ethode par agr
egation). Il faut remarquer aussi que le nombre de solutions Pareto
d
epend de lespace consid
er
e (espace d
ecisionnel/espace objectif ). Car deux solutions diff
erentes de lespace d
ecisionnel peuvent avoir le m
eme vecteur co
ut et donc
repr
esenter le m
eme point de lespace des objectifs. Lensemble Pareto de lespace
d
ecisionnel est appel
e ensemble Pareto maximal et celui de lespace objectif est appel
e ensemble Pareto minimal. Il est donc n
ecessaire de d
efinir lensemble recherch
e
car cela fera varier le nombre de solutions Pareto.
5.2.4
Choix de la m
ethode daide `
a la d
ecision
Dapr`
es nos insertions pr
ec
edentes un probl`
eme multi-objectif nadmet pas une
solution optimale unique mais un ensemble de solutions Pareto optimales, do`
u la
n
ecessit
e de lintervention humaine `
a travers un d
ecideur pour le choix de la solution finale `
a impl
ementer.
Donc, avant de lancer la r
eme multi-objectif, il faut se poser
la question du moment o`
u le d
ecideur intervient. Il existe trois types dapproches
distinctes pour la r
eme multi-objectif [mesmer] :
1. A priori : Le d
ecideur oriente la recherche d`
es le d
ebut en donnant des pr
ef
erences (exemple : agr
egations) `
a chacun des objectifs. Avec cette m
ethode une
solution unique est obtenue. Celle-ci ne convient pas forc
ement `
a ce qui
etait
souhait
e ; par exemple, les solutions non support
ees ne peuvent
etre atteintes
par agr
egation. En revanche lobtention du r
esultat est assez rapide.
104
5.3. Problèmes doptimisation multi-objectif

2. Interactive : Dans cette m
ethode il y a interaction de d
ecideurs avec le programme. Ce dernier propose r
eguli`
erement une solution au d
ecideur qui devra
alors r
eorienter la recherche en fonction de ses objectifs. Linconv
enient de
cette approche r
eside dans le fait que le d
ecideur doit attendre entre chaque
etape avant dobtenir `

a nouveau la main, ce qui est parfois long.
3. A posteriori : Lensemble du front Pareto est obtenu par le d
ecideur afin quil
choisisse la solution la plus adapt
ee. Lobtention du front complet peut sav
erer
tr`
es longue et le nombre des solutions peut
etre tr`
es grand en entranant de
ce fait un probl`
eme de d
ecision de la solution `
a choisir.
Fig. 5.7 Approche interactive : cooperation progressive entre le solveur et le decideur
Chacune de ces approches pr
esente des inconv
enients et des avantages. Dans ce
document, nous nous pla
cons dans une approche `
a posteriori qui permet au d
ecideur de faire le choix le plus appropri
e. Ce type dapproche peut se d
ecomposer
en deux
etapes : une phase de recherche de lint
egralit
e du front Pareto (phase
doptimisation) et une phase de d
ecision.
D
efinition 5 : Un voisinage N est une fonction N : P () ; qui associe pour
chaque x un sous ensemble N (x)de des voisinages de x.
Cette d
efinition est importante car la notion de voisinage est tr`
es utilis
ee dans les
m
etaheuristiques de recherche locale comme la recherche tabou ou le recuit simul
e.
Ce voisinage est d
efini par un op
erateur de recherche locale.
Dans la figure 5.8, 10 solutions sont repr
esent
ees dans un espace objectif bi
dimensionnel. Les segments connectant les solutions repr
esentent la structure du
voisinage.
Fig. 5.8 Optimum Pareto local

D
efinition 6 : Une solution x est localement Pareto optimale si et seulement si
w N (x), w ne domine pas x. dans la figure 5.8, les solutions Pareto optimales sont
associ
ees aux points 1,8,9 et les solutions 4 et 10 sont localement Pareto optimales.
5.3
Probl`
emes doptimisation multi-objectif
Dans les 30 derni`

eres ann
ees, la plupart des travaux ont port
e sur la programmation multi-objectif lin
eaire en variables continues. Les raisons principales de cet
int
er
et sont dune part le d
eveloppement de la programmation lin
eaire uni-objectif
en recherche op
erationnelle, et la facilit
e relative de traiter de tels probl`
emes, et
dautre part labondance des cas pratiques qui peuvent
etre formul
es sous forme
105
5.3. Problèmes doptimisation multi-objectif

lin
eaire. Ainsi, un certains nombre de logiciels ont vu le jour depuis le d
eveloppement de la m
ethode du simplexe multi-objectif [80,81]. Mais ce qui nous int
eresse
ici ce sont plut
ot les probl`
emes doptimisation combinatoire multi-objectif pour lesquels il y a beaucoup dint
er
et actuellement. Ci-apr`
es quelques exemples aussi bien
acad
emiques quindustriels.
A-Applications acad
emiques
La plupart des benchmarks utilis
es dans la comparaison dalgorithme doptimisation multi-objectif ont
et
e r
ealis
es sur des probl`
emes acad
emiques. Les probl`
emes
les plus
etudi
es sont :
Optimisation de fonctions continues : dans la communaut
e Algorithmes
G
en
etiques , les fonctions de Schaffer sont souvent utilis
ees pour
evaluer et
comparer les performances des algorithmes. La fonction bi-crit`
ere f2 est la plus
utilis
ee.
(
f21 (x) = x2 ;
f22 (x) = (x 1)2 .
S.C x [10, 10]

Pour ce probl`
eme, la fronti`
ere Pareto est continue et se trouve dans lintervalle
[0..2].
Optimisation combinatoire : plusieurs probl`
emes classiques doptimisation
combinatoire ont
et
e
etudi
es dans une version multi-objectif [82] : Sac `
a dos
[83], ordonnancement [8,9], plus court chemin dans un graphe [86], arbre recouvrant (minimum spanning tree) [87], affectation [88], voyageur de commerce
[89], routage de v
ehicule [90], etc.
Prenons comme exemple illustratif le probl`
eme du sac `
a dos multi-objectif qui
peut
etre mod
elis
e de la mani`
ere suivante [83] :
Pm
j
M ax(fi (x)) = j=1 Ci xj (i = 1, . . . , n); x
= {x | x < ; j = 1 . . . n};
j j
x {0, 1}; j = 1, . . . m.
j
O`
u
xj =
1sil0 elementjestdanslesac;
0sinon.
Uj le poids (volume) de l
el
ement j, et Cij lutilit
e de l
el
ement j par rapport au
crit`
ere i.
B- Applications industrielles La plupart des travaux portant sur loptimisation
combinatoire multi-objectif concernent des applications industrielles. Plusieurs probl`
emes ont
et
e trait
es dans diff
erents domaines dapplication :
106
5.4. Classification des methodes

Design de syst`
emes dans les sciences pour ling
enierie (m
ecaniques, a
eronautique, chimie, etc.) : ailes davion, moteurs dautomobiles.
Ordonnancement et affectation : ordonnancement en productique, localisation
dusines, planification de trajectoires de robots mobiles, etc.
Transport : gestion de containers, design de r
eseau de transport, trac
e dautoroutier, etc.
Environnement : gestion de la qualit
e de lair, distribution de leau, etc.
T
el
ecommunications : design dantennes, design de r
eseaux cellulaires, design
de constellation de satellites, affectation de fr
equences, etc.
Une liste plus compl`
ete dexemples dapplication peut
etre trouv
ee dans [91].
5.4
Classification des m
ethodes
Dans la litt
erature, une attention particuli`
ere a port
e sur les probl`
emes `
a demi
crit`
eres en utilisant les m
ethodes exactes tels que le branch and bound [85,92],
lalgorithme A* et la programmation dynamique [94]. Ces probl`
emes sont efficaces
pour des probl`
emes de petites tailles. Pour des probl`
emes `
a plus de deux crit`
eres
ou de grandes tailles, il nexiste pas de proc
edures exactes efficaces,
etant donn
e
les difficult
es simultan
ees de la complexit
e NP-difficile, et le cadre multicrit`
ere des
probl`
emes.
Ainsi, des m
ethodes heuristiques sont n
ecessaires pour r
esoudre les probl`
emes de
grandes tailles et/ou les probl`
emes avec un nombre de crit`
eres sup
erieurs `
a deux.
Elle ne garantissent pas de trouver de mani`
ere exacte lensemble PO (Pareto optimale), mais une approximation de cet ensemble not
e PO*. Les m
ethodes heuristiques peuvent
etre divis
ees en deux classes : dune part les algorithmes sp
ecifiques
`
a un probl`
eme donn
e qui utilisent des connaissances du domaine, et dautre part
les algorithmes g
en
eraux applicables `
a une grande vari
et
e de PMO, cest-`
a-dire les
m
etaheuristiques qui feront lobjet de notre int
er
et dans la suite de ce chapitre. Plusieurs adaptations de m
etaheuristiques ont
et
e propos
ees dans la litt
erature pour
la r
esolution de PMO et la d
etermination des solutions Pareto : le recuit simul
e,
la recherche tabou et les algorithmes
evolutionnaires (algorithmes g
en
etiques, strat
egies
evolutionnaire). Les approches utilis
ees pour la r
esolution de PMO peuvent
etre class
ees en trois cat
egories [talbi] (figure 5.9).
Fig. 5.9 Classification des methodes doptimisation multi-objectif

Approches bas
ees sur la transformation du probl`
eme en un probl`
eme uniobjectif : Cette classe dapproches comprend par exemple les m
ethodes bas
ees
sur lagr
egation qui combinent les diff
erentes fonctions : co
ut f (x) du probl`
eme
en une seule fonction objectif F . Ces approches n
ecessitent pour le d
ecideur
107
5.5. Approches de resolution

davoir une bonne connaissance de son probl`
eme
Approche non-Pareto : les approches non-Pareto ne transforment pas le PMO
en un probl`
eme uni-objectif. Elles utilisent des op
erateurs de recherche qui
traitent s
epar
ement les diff
erents objectifs.
Approche Pareto : Les approches Pareto utilisent directement la notion doptimalit
e Pareto dans leur processus de recherche. Le processus de s
election des
solutions g
en
er
ees est bas
e sur la notion de non-dominance.
Parmi ces trois approches cest cette derni`
ere qui sera retenue lors de la r
esolution de notre probl`
eme. Les d
etails de son utilisation seront vus dans le chapitre 4.
5.5
5.5.1
Approches de r
esolution
Les m
ethodes bi-objectif
Utilisation de la recherche lexicographique

Fourman [95] propose une classification des objectifs en fonction dun ordre dimportance. Ensuite les fonctions objectifs sont trait
ees dans cet ordre, cest-`
a-dire que
le premier objectif dans lordre dimportance est dabord optimis
e. Ensuite la valeur
de cet objectif est conserv
ee et le deuxi`
eme objectif est optimis
e. Ceci est r
ealis
e
it
erativement jusqu`
a loptimisation de tous les objectifs tout en ayant conserv
e les
valeurs trouv
ees pour les pr
ec
edents.
Comme exemple on peut prendre deux objectifs selon lordre f1 puis f2 . Tout
dabord lobjectif f1 est optimis
e ensuite, la solution x1 (x1 = (f1 (x1 ), f2 (x1 )), avec
f1 (x1 ) = f1 ) est alors trouv
ee. Ensuite la valeur f1 (x1 ) est conserv
ee pour le premier objectif et le second est optimis
e, la solution x2 (x2 = (f1 (x2 ), f2 (x1 )), avec
0
f1 (x2 ) = f1 (x1 ) = f1 ) est trouv
ee. De plus, nous savons que x2 est telle que : x
0
0
si f1 (x ) = f1 alors f2 (x ) f 2(x). Le principe de cette m
ethode est illustr
e sur la
figure 5.10 pour le cas Bi-objectif.
Fig. 5.10 Exemple de recherche lixicographique

Cette m
ethode ne trouve quune seule solution Pareto (un extr
eme). Il est cependant possible de faire des variantes (avec des contraintes,..) permettant de trouver
lensemble du front Pareto. Il faut noter que cette m
ethode reste assez inappropri
ee
pour obtenir lensemble du front Pareto dun probl`
eme Multi-objectif, par contre
elle est tr`
es bien adapt
ee pour trouver les extr
emes.
108

La m
ethode des sommes pond
er
ees et la m
ethode dichotomique
La m
ethode des sommes pond
er
ees, la plus connue et utilis
ee, transforme le probl`
eme multi-objectif en un probl`
eme Mono-objectif en effectuant une combinaison
lin
eaire des objectifs [Mes]. Les probl`
emes r
esolus sont de la forme : 1 f1 + 2 f2 (cas
Bi-objectif ). Selon le th
eor`
eme de G
eoffrion [79], toutes les solutions support
ees
peuvent
etre trouv
ees en choisissant correctement les agr
egations, cependant aucune solution non-support
ee ne peut
etre trouv
ee de cette mani`
ere.
La m
ethode dichotomique trouve lint
egralit
e du front Pareto gr
ace `
a un d
ecoupage
dichotomique de lespace de recherche. Dans un premier temps les deux solutions
extr
emes du front Pareto sont trouv
ees (gr
ace `
a la r
esolution de deux optimisations
lexicographiques). Puis, pour chaque paire de solutions dans lespace objectif (f(s)
et f(r)), une solution est recherch
ee en optimisant le probl`
eme suivant :
min x f \ (x) = 1 f1 + 2 f2
avec
(
et
f1 (x) < f1 (s)(C1);

f2 (x) < f2 (r)(C2).
1 = f2 (r) f2 (s) :
2 = f1 (s) f1 (r).
La figure 6.11 est une illustration de cette recherche. A chaque

etape cette m
ethode
trouve une solution Pareto entre f (r) et f (s), si il en existe une. Dans ce cas, elle
sera `
a lint
erieur du rectangle f (r)Y f (s)Z, o`
u Y est le point (f1 (s), f2 (r)) et Z est
le point (f1 (s), f2 (s)). Si une nouvelle solution, t , est trouv
ee alors deux nouvelles
recherches seront lanc
ees, une entre f (r) et f (t) et une entre f (t) et f (s) (figure
5.12). On remarque aussi que les solutions non-support
ees seront trouv
ees car les
contraintes (C1) et (C2) emp
echent la recherche de trouver les solutions f (r) et f (s)
d
ej`
a obtenues.
On constate ainsi que toutes les solutions Pareto seront trouv
ees gr
ace `
a cette
n
m
ethode. Elle n
ecessite par contre de lordre 2 recherches, o`
u n est le nombre de
solutions de lensemble Pareto. Si chacune des recherches est NP-difficile alors cette
m
ethode demandera un temps de calcul important.
Fig. 5.11 Direction de recherche (Gauche) , et Nouvelles recherches (Droite)
Utilisation de la m
etrique de Tchebycheff
Pour trouver une solution Pareto optimale, il est possible de trouver une solution minimisant sa distance au point Ideal Z I ou au point Utopique Z U . Il nous faut
109

donc d
efinir une notion de distance entre deux points. La distance la plus souvent
utilis
ee est la m
etrique pond
er
ee de Tchebycheff, d
efinie comme ceci :
I
min (max (i | fi (x) fi (Z ))) x i = 1..k
Si les poids () sont choisis dune fa
con appropri
ee, toutes les solutions Pareto
peuvent
etre trouv
ees. Pour le cas Bi-objectif, il est, par exemple, possible dutiliser
la m
ethode Tchebycheff de mani`
ere dichotomique sur des rectangles de recherche.
Premi`
erement les extr
emes sont calcul
es (r et s). Puis une recherche est effectu
ee
dans le rectangle form
e par le point Id
eal et le point Nadir (figure 5.12(Gauche)).
Une fois une nouvelle solution trouv
ee, deux nouvelles recherches sont lanc
ees dans
les rectangles cr
ees de mani`
eres dichotomiques (figure 5.12(Droite)).
Fig. 5.12 Recherche entre le point Ideal et le point Nadir (Gauche), et Division en deux sous
recherches (Droite)
Haimes et al. [96] ont propos
e cette approche pour
etre appliqu
ee pour un
nombre quelconque dobjectifs. Elle consiste `
a borner K-1 objectifs (o`
u K est le
nombre dobjectifs) et `
a optimiser le dernier. Les probl`
emes r
esolus sont de la
forme (en posant M lensemble des contraintes et Mj la contrainte sur lobjectif j) :
(
minx fi (x), i {1, .., k};

avecjj 6= i, fj (x) < Mj .
Cette approche peut trouver toutes les solutions Pareto en choisissant des contraintes
appropri
ees. La m
ethode e-contraintes, quon va voir, est une application de lapproche e-contrainte pour les probl`
emes Bi-objectif. Dabord un des deux extr
emes
est calcul
e, prenons par exemple lextr
eme ayant la plus petite valeur sur f1 . Puis,
cette solution nous donne une borne sur lobjectif f2 . La meilleure solution sur lobjectif f1 respectant cette borne est calcul
ee (figure 5.13). G
en
eralement, lobjectif
le plus facile `
a optimiser peut
etre celui `
a optimiser (f1 dans lexemple) et lautre
sera donc utilis
e comme borne.
En r
ealisant cette m
ethode it
erativement, en utilisant `
a chaque
etape la solution
pr
ec
edente afin de d
efinir la nouvelle borne (figure 5.14), il est possible gr
ace `
a une
m
ethode mono-objectif de trouver lensemble du front Pareto. Cette m
ethode sarr
ete lorsqu`
a une
etape donn
ee aucune solution Pareto nest g
en
er
ee. Dans lexemple
erot
ees (BorneB1, BorneB2,..)
complet illustr
e par la figure 5.15, les bornes sont num
et les solutions sont aussi num
erot
ees en fonction de lordre dans lequel elles sont
trouv
ees.
Cette m
ethode requiert une recherche par solution de lensemble Pareto. Chacune
de ces recherches est born
ee, ce qui signifie souvent l
enum
eration de nombreuses
solutions afin de trouver la solution recherch
ee. De plus, si il existe une m
ethode
de r
esolution mono-objectif efficace lajout de cette borne emp
echera g
en
eralement
son utilisation. Les recherches peuvent donc prendre un temps de calcul important
110

et
etre nombreuses.
Fig. 5.13 Exemple de recherche pour la Methode des e-contraintes
Fig. 5.14 Nouvelle recherche
Fig. 5.15 Methode des e-contraintes
La m
ethode Deux phases
Cette m
ethode appel
ee aussi TPM (Two Phase Method) a
et
e, initialement,
propos
ee par Ulungu et Teghem pour la r
esolution du probl`
eme daffectation BiObjectfi[92]. Cette m
ethode est compos
ee de deux phases, une premi`
ere phase o`
u
sont recherch
ees les solutions support
ees et une seconde o`
u sont recherch
ees les
solutions non-support
ees.
La premi`
ere phase
La premi`
ere phase consiste `
a trouver lint
egralit
e des solutions support
ees. Pour
ceci des agr
egations du type 1 f1 + 2 f2 sont utilis
ees pour v
erifier lexistence dune
solution support
ee entre (dans lespace objectif ) deux autres solutions support
ees.
Pour commencer, les deux extr
emes (qui sont des solutions support
ees) sont calcul
es afin de borner lespace de recherche (figure 5.16.a).
Pour rechercher entre deux solutions support
ees xr et xs, o`
u f(xr) et f(xs) sont leurs
images dans lespace des objectifs (supposons que f1 (xr ) < f1 (xs ) et f2 (xr ) > f2 (xs )),
la direction de recherche sera perpendiculaire `
a la ligne (f (xr ), f (xs )) en fixant
1 = f2 (xr ) f2 (xs ) et 2 = f1 (xs ) f1 (xr ) (figure 5.16.b). Avec cette recherche sil
existe au moins une solution support
ee xt avec f (xt ) entre f (xr ) et f (xs ) dans
lespace objectif alors elle sera trouv
ee. Si une nouvelle solution est trouv
ee alors
r
t
deux nouvelles recherches seront lanc
ees, une entre f (x ) et f (x ) lautre entre f (xt )
et f (xs ) (figure 5.16.c) [Mesmer]. On constate quil y a une forte ressemblance entre
cette m
ethode et la m
ethode dichotomique. Mais ici seules les solutions support
ees sont trouv
ees car aucune contrainte nest ajout
ee, lors dune recherche entre
r
s
deux solutions (x etx ), lune de ces deux solutions peut
etre trouv
ee (f (xr )ouf (xs )),
contrairement `
a la m
ethode dichotomique. A la fin de cette phase, toutes les solutions support
ees sont connues (figure 5.16.d).
Fig. 5.16 La methode deux phases

La deuxi`
eme phase
Dans cette phase on cherche toutes les solutions non-support
ees de lensemble Pa111
5.6. Conclusion
reto. Elles ne peuvent
etre trouv
ees gr
ace `
a une agr
egation des objectifs. Par contre
u
ee entre f (xr ) et
nous savons que toutes solutions non support
ees x avec f (xu ) plac
f (xs ) (o`
u f (xr ) et f (xs ) sont des solutions support
ees) alors f1 (xr ) < f1 (xu ) < f1 (xs ) et
f2 (xr ) > f2 (xu ) > f2 (xs ).
Graphiquement, les solutions support
ees entre f (xu ) et f (xs ) se situent forc
ement
r
s
dans les triangles bas
es sur les solutions f (x ) et f (x ) (figure 5.18.e). Entre chaque
paire de solutions support
ees un triangle de recherche est construit. Tous les triangles sont alors explor
es afin de trouver toutes les solutions non-support
ees (figure
5.19.f ). La m
ethode de recherche `
a lint
erieur de chacun des triangles d
epend du
probl`
eme
etudi
e. A la fin de cette phase, toutes les solutions Pareto sont trouv
ees
(figure 5.19.g).
5.6
Conclusion
Ce chapitre nous a permis de faire le tour des probl`

emes doptimisation multiobjectifs (MOP). Une pr
esentation actualis
ee des diff
erentes m
ethodes a aussi
et
e
r
ealis
ee. Bien s
ur faire une
etude plus approfondie de ces concepts n
ecessite plus
quun chapitre, dans la mesure o`
u des th`
eses ont
et
e consacr
es enti`
erement aux
MOP. Ce chapitre, m
eme sil est tr`
es synth
etis
e, nous a paru important `
a ce stade
de la lecture de ce document pour pouvoir comprendre la d
emarche quon a apport
e
pour r
esoudre le probl`
eme de mapping dans les SoC dans sa globalit
e cest-`
a-dire
le GILR. Cette d
emarche et cette contribution pour solutionner ce probl`
eme feront
lobjet du chapitre suivant.
112
Chapitre 6
Contribution
Sommaire
6.1
Mod`
ele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
6.2
Formulation math
ematique
6.3
Premi`
ere phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.4
Seconde phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
6.5
Algorithmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.6
Mapping des t
aches r
ep
etitives. . . . . . . . . . . . . . . . . . . . . . . 123
6.7
Routage et optimisation des communications . . . . . . . . . . . . . 130

6.7.1
6.8
Generation de chemin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.7.2
Problème de generation du chemin
6.7.3
Routage statique des paquets . . . . . . . . . . . . . . . . . . . . . . . . 134
6.7.4
Problème du routage des paquets . . . . . . . . . . . . . . . . . . . . . 135
6.7.5
Temps dexecution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
. . . . . . . . . . . . . . . . . . . . 133
mapping Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

6.8.1
6.9
. . . . . . . . . . . . . . . . . . . . . . . . 115
Demarche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Le choix dune m
ethode `
a base de GA pour le placement irr
egulier 137
6.9.1
paramètres de lalgorithme genetique . . . . . . . . . . . . . . . . . . . . 137
6.9.2
Choix des operateurs genetiques . . . . . . . . . . . . . . . . . . . . . . 139
6.9.3
Transformation de la fonction objectif en fonction Fitness . . . . . . . . 140
6.9.4
Fonction devaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.9.5
Formalisation du problème de placement : . . . . . . . . . . . . . . . . . 142
6.9.6
Bande passante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.9.7
M
emoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
6.9.8
File dattente
6.10 Conclusion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
113
6.1. Modèle
Le problème quon a à resoudre dans sa globalite est un problème dassignation,

daffectation et dordonnancement AAS . Les travaux pr
esent
es par Lahua [60],
Prestana [69] et Benini [55] pr
esentent des insuffisances car ces travaux consid`
erent
la topologie des communications en Bus. Les autres tels Hu [41], Mural [47] et
Lei [91] pr
esentent des m
ethodes doptimisation mono-objectif. Cest-`
a-dire que
ces m
ethodes ne permettent lobtention que dun seul objectif : temps dex
ecution,
consommation d
energie, surface, etc. jamais dans ces travaux on a essay
e de trouver
ou de se rapprocher dune solution satisfaisant au moins deux objectifs. En plus tous
les travaux pr
esent
es et cit
es pr
ec
edemment, notamment dans le chapitre 4 nont
pas pris en consid
eration des applications de grandes tailles structur
ees dune fa
con
hi
erarchique o`
u le mod`
ele est un graphe hi
erarchique dont les nuds peuvent
etre
simples, r
ep
etitifs ou compos
es. Par cons
equent notre travail sera bas
e sur ce dernier
probl`
eme en proposant une approche de r
esolution multi-objectif permettant de
trouver le meilleur mapping dune application de ce type sur une architecture NoC.
6.1
Mod`
ele
Les communications entre les composantes dune application sont repr

esent
ees
par un graphe dapplication orient
e (figure 6.1).
Fig. 6.1 Exemple de problème doptimisation combinatoiremulti-objectif

D
efinition 1 : Le graphe dapplication (TG : Task Graph) est un graphe orient
e
G(V,E) o`
u chaque sommet vi V repr
esente un module (t
ache) de lapplication et
larc orient
e (vi , vj ) not
e eij E repr
esente les communications entre les modules vi
et vj . Le poids de larc eij not
e par Qij repr
esente le volume des communications de
vi `
a vj .
La connectivit
e et la bande passante des liens physiques sont repr
esent
ees par le
graphe darchitecture.
D
efinition 2 : le graphe darchitecture NT (NoC Topology graph) est un graphe
orient
e P(U,F) o`
u chaque sommet ui U repr
esente un nud de la topologie et
larc (ui , uj ) not
e par fij F repr
esente un lien physique direct entre les
el
ements
de ui et uj de larchitecture. Le poids de larc fij not
e par bwij repr
esente la bande
passante disponible `
a travers le lien physique fij .(figure6.2)
Fig. 6.2
La figure 6.3 repr
esente une application r
eelle dun d
ecodeur vid
eo avec communication.
114
6.2. Formulation mathematique

Fig. 6.3
Le mapping du graphe dapplication G(V,E) sur le graphe darchitecture P(U,F)
est d
efini par la function mapping map :
map : V = U , telque :
map(vi ) = uj vi V, uj U.
Le mapping est d
efini quand | V || U |
D
efinition 3 : Un graphe dapplication hi
erarchique HCG (respectivement graphe
Fig. 6.4
darchitecture hi
erarchique HNT) est un graphe dapplication (respectivement graphe
darchitecture) o`
u certains sommets (nomm
es nuds compos
es) repr
esentent des
graphes dapplication (respectivement graphe darchitecture) (figure6.5).
Le mapping du HTG sur HNT consiste `
a chercher le mapping des graphes dun
m
eme niveau. Si HTG et HNT ont trois niveaux, on commence par chercher le
mapping de tous les HTG sur les HNT dans le niveau 3. Ensuite on fait de m
eme
au niveau 2 et apr`
es le niveau 1.
D
efinition 4 : le mapping ou laffectation des communications au r
eseau consiste `
a
placer une communication entre deux t
aches ti et tj repr
esent
ee par larc eij E sur
le r
eseau de communication. Ce placement consiste `
a trouver le chemin qui souvent
est constitu
e de plusieurs liens physiques contigus utilis
es pour envoyer les donn
ees
de ti `
a tj .
Mais avant de consid
erer le mapping dans sa globalit
e on doit tout dabord proposer une solution pour un mapping multi-objectif dun seul graphe TG sur un seul
graphe NT dans un m
eme niveau.
6.2
Formulation math
ematique
Pour un TG chaque nud ou sommet repr

esente une t
ache avec ses caract
eristiques ou propri
et
es.
Soit T = t1 , t2 , . . . , tn lensemble des t
aches repr
esent
ees par lensemble des sommets
V dans TG.
P = p1 , p2 , . . . , ps lensemble des processeurs repr
esent
es par lensemble des nuds U
dans NT.
On consid`
ere que chaque processeur p peut sex
ecuter `
a des modes diff
erents m1 ,
m2 or m3 .
115

Comme variable de d
ecision on prend des variables binaires Xijm tels que [7].
Xijm = 1 si la t
ache i est plac
ee sur le processeur j et sex
ecute au mode m, o sinon.
0m
dij = la dur
ee dex
ecution de la t
ache ti plac
ee sur pj sex
ecutant au mode m (sans
prendre en compte les communications) .
W CN m
0
dijm = f m ij where W CNijm est le nombre de cycles n
ecessaires `
a la t
ache i pour
j
sex
ecuter sur le processeur j au mode m.
equence dhorloge du processeur j au mode m.
fjm est la fr
dli est le deadline de la t
ache ti . Cest le temps auquel la t
ache ti doit
etre termin
ee.
Ainsi dlf inal = dln est le deadline de la derni`
ere t
ache tn et aussi celui de lapplication.
Qij est le volume de donn
ees
echang
ees entre les t
aches ti et tj .
0
m est la dur
ee des communications entre les t
aches ti et tj si elles sont plac
ees
dQijpq
respectivement sur les processeurs p et q au mode m. On va voir apr`
es comment ce
param`
etre est calcul
e.
m est la dur
qpq
ee de communication unitaire (bit, octet ou paquet) entre p et q au
mode m.
em
energie consomm
ee par une unit
e de donn
ee (bit, octet ou paquet ) durant
pq est l
son transfert de p `
a q au mode m.
Sil nexiste pas un lien direct entre p et q soit (p, q) = (pi, pj) le chemin (succession
de liens) reliant p `
a q.
Alors la dur
ee dutilisation des liens est :
0
m
dQijpq
=
m
Qij qplpk
ou(pl, pk) (p, q)
La consommation d
energie due `
a la communication des t
aches i et j si elles sont
plac
ees sur les processeurs p et q au mode m en utilisant le m
eme chemin est :
m
Eijpq
=
Qij em
plpk ou(pl, pk) (p, q).
Dans ce mod`
ele on consid`
ere que la consommation d
energie due aux communications intra-processeurs est n
egligeable, et de m
eme pour la dur
ee des communications. On peut aussi consid
erer que ces param`
etres sont inclus dans les temps
dex
ecution et l
energie consomm
ee. Chaque chemin contient un certains nombres
de switch et de routeurs qui consomment de l
energie et causent des dur
ees suppl
ementaires de communication.
Dans les travaux de Ascia et al le probl`
eme est pos
e mais ils nexpliquent pas comment ils le traitent. Dans ce travail on propose une valeur moyenne de consommation
(CSW ) et de dur
ee (dSW ) due `
a lutilisation des switch et routeurs. On peut les estimer en consid
erant les communications en entr
ee et sortie des routeurs comme
stochastique.
116

Ainsi si | (p, q) | est la longueur du chemin (p, q), la consommation totale des switch
et routeurs de ce chemin est
egale `
a:
=| (p, q) | +1) Csw
Et la dur
ee totale est :
=| (p, q) | +1) dsw
On peut donner maintenant l
equation de la consommation totale due aux communications des t
aches i et j affect
ees aux processeurs p et q au mode m.
0
m
m
Eijpq
= Eijpq
+
Et la dur
ee totale des communications :
0
m
dQm
ijpq = dQijpq +
Donc le temps total dex

ecution dune t
ache i en prenant en consid
eration les
communications est :
Di =
mn
X
m=m1
dipm +
N X
S
S
X
X
mn
X
m m
Xip
Xjq dQm
ijpq aveci 6= j, p 6= q
j=1 p=1 q=p+1 m=m1
Cette
equation peut
etre simplifi
ee car p est fixe et on consid`
ere par hypoth`
ese que
P m
les communications intra-processeur sont n
egligeables. Pour un i fix
e,
Xip = 1
start
Pour une t
ache i, si Di
est son temps de d
ebut, alors son temps de terminaison
f in
est Di , il est donn
e par la formule suivante :
Dif in = Distart + Di
Lordonnancement est obtenu par LS o`
u le d
ebut de lapplication correspond
avec le d
ebut de sa premi`
ere t
ache t1 et sa fin correspond `
a la fin de la derni`
ere
start
t
ache tn . Ainsi, pour la t
ache ti son temps de d
ebut Di
correspond au temps
de fin de la derni`
ere des t
aches qui la pr
ec`
edent. Donc la liste LS est obtenue en
utilisant la strat
egie ASAP (As Soon As Possible).
Dnf in = Dnstart + Dn
est le temps de fin de la derni`
ere t
ache tn .
Ce temps est donc le temps de fin de lapplication Df in qui est donn
e par la
formule suivante :
ebut de lapplication, qui corDf in = Dnstart + Dn Donc si Dstart est le temps de d
respond au temps de d
ebut de la premi`
ere t
ache D1start , et Df in le temps de fin de
117
6.3. Première phase

lapplication qui est aussi celui de la derni`
ere t
ache Dnf in , alors la dur
ee dex
ecution
totale de lapplication est :
D = Df in Dstart
Cest ce temps quon doit minimiser et sassurer quil v
erifie la contrainte temps
r
eel hard, cest-`
a-dire :
D dlf inal . La consommation d
energie totale est donn
ee par la formule suivante
en prenant en consid
eration la consommation des processeurs, des liens, des switch
et des routeurs.
E=
N X
s
X
mn
X
m
xm
ip ETip +
i=1 p=i+1 m=ml
N X
N X
s
s
X
X
mn
X
m
m
xm
ip xjp Eijpq
i=1 j=i+1 p=1 q=p+1 m=ml
m est la consommation de la t
ETip
ache i affect
ee au processeur p au mode m. La
m
ethode propos
ee pour quelle soit utilis
ee apr`
es dans le mapping global, cest-`
a-dire
le GILR doit pouvoir traiter des probl`
emes de grandes tailles. Donc pour converger rapidement lors de la recherche dune solution optimale pour un probl`
eme de
grande taille on doit utiliser un algorithme
evolutionnaire. Dans cette contribution,
on verra par la suite que pour les applications r
ep
etitives un algorithme exact est
choisi. Il sera pr
esent
e par la suite et comment
e. Mais pour le moment on doit traiter le cas dapplication quelconque et de grande taille tout en essayant datteindre
plusieurs objectifs en m
eme temps. Do`
u cette approche hybride bas
ee sur lalgorithme
evolutionnaire et une m
ethode de recherche des communications optimale.
On a `
a chercher un ensemble de solutions sous plusieurs objectifs. On consid`
ere
ici sp
ecialement deux objectifs ; le temps dex
ecution totale et la consommation
d
energie globale. Notre approche est constitu
ee de deux phases. Dans la premi`
ere
on cherche tous les placements qui satisfont le deadline final dlf inal . Do`
u lors de
cette phase on doit fixer le mode dex
ecution (au mode modmax) et chercher tous
les placements dont le temps total dex
ecution dlf inal .
Ensuite, dans la deuxi`
eme phase on essaye doptimiser la consommation d
energie
en variant les modes cest-`
a-dire en ralentissant les processeurs et les communications.
Les deux phases ont `
a atteindre aussi un autre objectif qui consiste `
a loptimisation
des communications. Cest-`
a-dire que pour toute solution sassurer quon a choisi
les communications les moins co
uteuses en temps et
energie.
6.3
Premi`
ere phase
Dans cette phase on fixe le mode dex

ecution `
a sa valeur maximale. Cest-`
a-dire
les processeurs sont utilis
es lors de cette recherche `
a leur vitesse dex
ecution la plus
118
6.3. Première phase
elev
ee (m = modmax ), alors l
equation 3 devient :
0
S
S
m m
m
Di = dipm + N
j=1
p=1
q=p+1 Xip Xjq dQijpq avec i 6= j, p 6= q
Pour cette phase on propose une technique bas
ee sur les AG hybrid
ee avec une
heuristique de recherche du chemin optimal dans larchitecture mat
erielle. Le choix
de cette m
ethode est justifi
e, apr`
es, par rapport `
a dautres m
ethodes, en plus,
du fait quelle permet de prendre en consid
eration le multi-objectif. Avec plus de
pr
ecision, un algorithme
evolutionnaire front Pareto (SPEA Strength Pareto Evolutionary Algorithm) qui maintient un ensemble externe pour pr
eserver les solutions
non domin
ees rencontr
ees avant. Le chromosome est une repr
esentation de la solution du probl`
eme qui dans ce cas d
ecrit le mapping. Chaque
el
ement dex
ecution
dans le mesh lui est associ
e un g`
ene qui encode la t
ache qui lui est affect
ee. Si
on a un NoC en Mesh de S processeurs et une application avec N t
aches alors le
chromosome est form
e de S g`
enes. Chaque g`
ene contient N bits.
Comme exemple prenant 2 processeurs et 3 t
aches, alors le chromosome 101010
repr
esente le mapping de 3 t
aches : les t
aches 1 et 3 sont affect
ees au processeur 1,
la t
ache 2 affect
ee au processeur 2 (le premier g`
ene est 101 et le second est 010).
On doit ins
erer une contrainte qui sp
ecifie lassignation unique de chaque t
ache,
cest-`
a-dire une t
ache ne peut
etre mapp
ee (ou affect
ee) qu`
a un seul processeur `
a
la fois et elle ne peut
etre ex
ecut
ee qu`
a un seul mode.
S M odmax
X
X
p=1
m
Xip
= 1, ti T
m=1
n
On it`
ere cette phase k fois, o`
u k = 10
si n > 100 sinon k = 3 (apr`
es exp
erimentations),
n
avec une population = 5 . Les r
esultats de cette
etape sont tous les placements ayant
des co
ut dex
ecution total dlf inal .
Ayant un chromosome chri , on note par D0 (chri ) la dur
ee de calcul selon l
equation
6. Ainsi :
0
S = {chri /D (chri ) dlf inal } est lensemble de tous les placements ayant D
dlf inal .
Ce r
esultat sera lentr
ee de la phase 2. Avant de la pr
esenter on doit aussi savoir
comment on peut augmenter la vitesse de recherche de cette
etape ou autrement
dit, comment diminuer le temps de convergence durant cette phase. Comme en le
sait toute heuristique ou m
ethode it
erative d
epend du choix de ses param`
etres et
de la solution initiale. Pour notre algorithme on a essay
e de placer les t
aches qui
communiquent le plus sur des processeurs voisins ou carr
ement sur le m
eme processeur Afin de sassurer que dans la population initiale on a quelques bons individus.
(ti ) = {tj T ouV | (ti , tj ) E}
Et
119
6.4. Seconde phase

(pi ) = {pj U ouP | (pi , pj ) F }
Alors | (ti ) | nous donne le nombre de voisins de ti .
Alors | (pi ) | nous donne le nombre de voisins de pi .
Pour le premier placement (initial) on affecte la t
ache ayant le plus de voisins
au processeur ayant le plus de liens physiques directs.
Soit t1i cette t
ache et p1j ce processeur. Alors,
T 1 = T t1j etP 1 = P p1j .
Ensuite on refait le processus pour les t
aches de T 1 avec les processeurs de P 1 .
Seulement ici on choisit en premier la t
ache qui a un lien avec la t
ache t1i . Sinon, on
prend celle qui a le plus grand nombre de voisins en absolu. On arr
ete ce placement
initial quand `
a lit
eration n on obtient
T n1 = T n 2 {tin1 }.
Souvent le nombre de processeurs est inf
erieur au nombre de t
aches (S < N ). Dans
k
ce cas d`
es que `
a une phase quelconque de cet algorithme P = 1, alors r
einitialiser
k+1
k
P
`
a P P .
6.4
Seconde phase
Dans cette
etape on cherche `
a optimiser l
energie consomm
ee pour les placements trouv
es lors de l
etape 1. Etant donn
e S, lensemble des solutions de l
etape
pr
ec
edente, comme entr
ee de cette phase. Comme sortie de celle-ci on obtient lensemble S. Ce dernier
etant lensemble des solutions non domin
ees qui minimisent
la consommation et v
erifient le deadline final dlf inal comme contrainte. Pour cette
phase on d
efinit un autre codage d
eriv
e`
a partir des chromosomes de S. Ainsi si on
a M modes de fonctionnement des processeurs, le chromosome maintenant va
etre
constitu
e de S g`
enes tel que chacun est constitu
e de n M bits. Si le bit k + i du
k
g`
ene j a comme valeur 1 alors Xij = 1 ; cest `
a dire que la t
ache i est mapp
ee sur le
processeur j et sex
ecutant au mode k.
On d
efinit une application qui transforme un chromosome de S vers la phase 2.
00
S = (S ) = Chri /chri = (chrj )etchrj S
Cette application va nous permettre de pr

eserver le mapping trouv
e lors de
Car dans la phase deux on cherche `
energie
sans faire d
eplacer les t
aches ou r
eaffecter les communications. On ne cherche ici qu`
a
faire diminuer la consommation d
energie en jouant sur la vitesse des processeurs.
Exemple : pour 2 processeurs et 3 t
aches on peut avoir `
a l
etape 1 le chromosome
l0 tape1.
120
6.5. Algorithmes
101010. Dans l
etape 2 on peut avoir p1 et p2 sex
ecutant `
a deux modes diff
erents.
0
Ainsi si 101010 S alors
00
(101010) = {001100000010, 101000001000, . . .} S Et100010100000 6 S
00
Donc, dans cette

etape on essaye de minimiser la consommation d
energie formul
ee
dans l
equation 5 et en m
eme temps on doit respecter le temps dex
ecution trouv
e
dans la phase 2 comme contrainte. Comme r
esultat on obtient un autre front Pareto
0
SS.
6.5
Algorithmes
Pour l
etape 1, on utilise un algorithme bas
e sur le GA qui a les m
emes
etapes
que nimporte quel algorithme
evolutionnaire (figure 6.6). Avant dexpliciter lalgorithme, on essaye de pr
esenter et de d
ecrire les phases les plus importantes le
constituant. On commence par la m
ethode principale (son corps) qui est inspir
e du
GA (figure 6.7).

Dans la premi`
ere
etape on cherche `
a trouver toutes les solutions dont le temps
total dex
ecution (
equation 4) est dlf inal . Les r
esultats de cette
etape sont toutes
les solutions (mapping) qui v
erifient dlf inal . Ces r
esultats sont consid
er
es comme
entr
ee de l
etape 2, et on essaye ensuite de minimiser la consommation d
energie tel
que dlf inal reste v
erifi
e (
equation 5). Pour cette
etape un autre algorithme hybride
est propos
e bas
e sur une m
ethode exacte et une heuristique inspir
ee de lalgorithme
de Dijkstra. Dans l
etape pr
ec
edente la taille dun chromosome est NxS o`
u N est le
nombre de t
aches et S le nombre de processeurs.
Avec plus de d
etails, un chromosome ici est compos
e de S g`
enes et chaque g`
ene
contient N xM bits. On remarque ici que la taille du chromosome a augment
e mais
la taille du domaine de d
ecision a diminu
e, cest ce qui a justifi
e notre choix pour
une m
ethode exacte lors de cette phase.
Algorithme de l
etape 1
1 D
ebut
2 lire le graphe de t
aches et le graphe darchitecture
3 Lire leurs propri
et
es, contraintes et les param`
etres du GA
121
6.5. Algorithmes
4 G
en
erer une solution initiale en se basant sur la technique de la phase 1
5 R
ep
eter
6 Pour chaque population faire
7 Pour chaque chromosome faire
8 V
erifier que chaque t
ache est affect
ee `
a un seul processeur
8 Traiter les contraintes
9 Calculer le chemin le plus court
10 Calculer le temps global dex
ecution
11 Si le chromosome ne v
erifie pas les contraintes tel l
equilibrage, taille m
emoire,
largeur de bande et file dattente ajouter des p
enalit
es `
a sa fitness
12 Cr
eer une nouvelle population en utilisant croisement et mutation
13 Utiliser la fitness pour s
electionner le meilleur
14 Jusqu`
a crit`
ere darr
et v
erifi
e
15 Fin
Algorithme de l
etape 2
1 D
ebut
2 Initialisation
3 Soit SS lensemble des solutions trouv
ees lors de la phase 1 et d
eriv
ees selon la
description donn
ee en 6.4
4 Soit BestCostE : consomation d
energie la plus petite obtenue dans la phase 1
(dans cette phase tous les processeurs sex
ecutent `
a vitesse max) et OPT la solution
correspondante `
a BestCostE alors SS = SS OP T
5 Tantque SS 6= faire
6 Selectionner Si ; SS = SS Si
7 Calculer le temps dex
ecution D(Si ) correspondant
8 SI (D(Si) < dlf inal ) alors
9 Calculer la consommation E(Si)
10 FINSI
11 SI (E(Si ) < BestCostE) alors BestCostE = E(Si ) et OP T = Si FSI
12 FINTANQUE
13 (Retourner (Best(OPT, BestCostE))
14 FIN.
Algorithme du premier bon choix de l
etap1
1 D
ebut
2 Soit T T = T lensemble des t
aches et P P = P lensemble des processeurs
3 Calculer (ti ) = {tj T ouV | (ti , tj ) E} pour toutes les t
aches de TT. Cest
lensemble des voisins de chacune delle
4 Calculer (pi ) = {pj P orU | (ti , tj ) F } pour toutes les t
aches de PP. Cest
122
6.6. Mapping des t

aches repetitives.
lensemble des voisins directs de chaque processeur
5 Trier TT et PP selon lordre d
ecroissant des | (ti ) | et | (pj ) |
6 Affecter le premier
el
ement de T T (t1i ) au premier
el
ement de P P (p1j )
7 T T = T T {t1i } et P P = P P {p1j }
8 choisir un t2i de TT de telle fa
con que t2i soit parmi les premiers
el
ements de TT
2
1
2
et ti (ti ). Sinon prendre ti t
ete de liste de TT
2
9 choisir pj de PP de telle fa
con que p2j soit parmi les premiers
el
ements de PP et
ete de liste PP
Pj2 (Pi1 ). Sinon prendre p2j comme t
a p2j . T T = T T t2i et P P = P P p2j
10 affecter t2i `
11 A une it
eration k < n (n
etant le nombre de t
aches) faire
k
k
12 choisir un ti de TT de telle fa
con que ti soit parmi les premiers
el
ements de
k1
k
k
ete de liste de TT.
TT et ti (ti ). Sinon prendre ti t
k
13 choisir pj de PP de telle fa
con que pki soit parmi les premiers
el
ements de PP
k1
k
k
ete de liste PP
et Pi (Pi ). Sinon prendre pj comme t
k
k
k
14 affecter ti `
a pj . T T = T T ti et si k < S alors P P = P P pkj sinon PP=P
15 si k < n alors allez `
a 11 sinon affectez tkn `
a au premier PjK de PP
16 Fin
6.6
Mapping des t
aches r
ep
etitives.
Les t
aches r
ep
etitives ont la particularit
e de pr
esenter les m
emes caract
eristiques : nombre de cycles dex
ecution et la taille des donn
ees trait
ees. En plus ces
t
aches sappliquent sur des donn
ees de m
eme dimension et structures, quon appelle
motifs. La figure suivante illustre lapplication de d
etection de contour. Une image
est un tableau de valeurs
el
ementaire appel
ees pixel. La d
etection de contour dune
image est r
ealis
ee par une convolution . Une convolution est une op
eration simple
qui produit chaque pixel de limage de sortie `
a partir dune combinaison lin
eaire de
certains pixels de limage dentr
ee. Les cfficients de la combinaison lin
eaire sont
donn
es dans une matrice de coefficient (figure 6.8).
Fig. 6.8 Illustre lapplication detection de contour

Ces t
aches par leurs caract
eristiques sont affect
ees `
a une architecture pr
esentant une certaine particularit
e. En effet la plateforme dex
ecution est constitu
ee
elle aussi d
el
ement dex
ecution et de communications identiques. Cest pour cette
raison quon d
esigne ce type darchitecture par lappellation r
eguli`
ere , (figure
6.9).
Figure 6.9 :
Ce type dapplication r
eguli`
ere est tr`
es bien d
ecrit et sp
ecifi
ee par le langage
123
6.6. Mapping des t

aches repetitives.
Fig. 6.9 modèle darchitecture regulière
array-ol pr
esent
e auparavant (figure 6.10).
Figure 6.10 : pavage complet dun tableau par une tuile 3,4
Fig. 6.10 Illustre lapplication detection de contour
Donc avec Array-ol on est en mesure de sp
ecifier des sous tableaux motifs qui ont
le m
eme profil. Cette sp
ecification est tr`
es importante car elle constitue un formalisme de donn
ees dans le traitement vectoriel. Ainsi les traitements effectu
es sur les
motifs sont les m
emes. Do`
u la notion de t
aches r
ep
etitives. Ces derni`
eres `
a partir
dun tableau de donn
ees en entr
ee et des param`
etres permettant de localiser le sous
tableau quelles doivent avoir en entr
ee elles produisent dautres tableaux en sortie
avec des profils diff
erents (figure 6.8). Ces tableaux de donn
ees sont ind
ependants
(ind
ependance de donn
ees) et de m
eme pour les tableaux de sortie. Ceci rend les
t
aches ind
ependantes et par cons
equent facilement parall
elisables. Cet aspect est
bien explicit
e par Array-Ol et quon essaye de traiter `
a part. Ce traitement on la
nomm
e traitement de t
aches r
ep
etitives sur des architectures r
eguli`
eres . Dans le
graphe hi
erarchique dapplication HTG (d
efinition 3) ces t
aches sont d
esign
ees par
des nuds r
ep
etitifs quon essaye de placer et ordonnancer sur des architectures
r
eguli`
eres cest dire des processeurs identiques.
Ces traitements qui caract
erisent les applications DSP ou vectoriel sont gourmands
en temps de calcul. Ils manipulent des tableaux de grande taille en entr
ee. Par
cons
equent lapproche pour faire le scheduling de ce type dapplication diff`
ere de la
d
emarche adopt
ee pr
ec
edemment pour les t
aches quelconques ou non r
ep
etitives.
Ce type de traitements est dit souvent r
egulier pour le distinguer du pr
ec
edent qui
est irr
egulier, Ainsi en associant ces deux types de traitements on obtient le GILR
(Globalement Irr
egulier Localement R
egulier). Donc pour le mapping du r
egulier
on nessaye pas de placer toutes les t
aches r
ep
etitives en m
eme temps mais de le
faire par partie en d
eterminant un paquet de t
aches quon place en minimisant le
temps dex
ecution et la consommation d
energie. Ensuite cest m
eme nombre de
t
ache qui est r
ep
et
e sur dautres donn
ees selon la sp
ecification dArray-Ol.
La figure 6.11 illustre un exemple de r
ep
etition dun paquet de t
aches.
Fig. 6.11 Repetition de motifs pour generer lordonnancement de N t

aches
On voit, dans la figure pr
ec
edente, que cest le m
eme placement des communications et des t
aches qui est r
ep
et
e selon laxe de temps. Pour expliquer lapproche
adopt
ee pour r
esoudre ce probl`
eme dAllocation, Assignation et Scheduling (AAS)
on doit d
efinir certains concepts et termes qui facilitent la pr
esentation de lalgorithme.
124
6.6. Mapping des t

aches repetitives.
Du fait du nombre limit
e de ces t
aches la m
ethode utilis
ee pour ce placement est `
a
base de m
ethode exact (branch and bound).
Paquet de t
aches : est un ensemble de N t
aches ind
ependantes avec un temps dex
ecution unitaire et qui peut sex
ecuter en parall`
ele selon nimporte quel ordre.
Plateforme : Cest un ensemble de S processeurs identiques connect
es avec une topologie dinterconnexion arbitraire (Mesh, Cube, Arbre, etc.)
D
efinition : Un Motif est un ensemble de traitements (t
aches) et communications
plac
es (AAS) sur un ensemble d
el
ements dex
ecution (PE) connect
es `
a travers un
r
eseau de larchitecture.
Objectifs : Lid
ee derri`
ere le motif est bas
ee sur deux objectifs de base, premi`
erement, faire de la technique dAAS ind
ependamment du nombre total des t
aches.
Deuxi`
emement, minimiser la complexit
e du placement.
Dans les applications DSP on a g
en
eralement un flot de donn
ees infini qui sont
trait
ees par des t
aches r
ep
etitives. Consid
erer cette infinit
e de t
aches r
ep
etitives
lors de la recherche du placement optimal va accrotre la complexit
e de traitement
du processus AAS. Cest pour cette raison quon g
en`
ere des motifs et pour g
en
erer
le placement total (AAS) de toutes les t
aches (T otaltaches ) on a qu`
a r
ep
eter le placement du motif X fois (figure 6.11). Ainsi un placement de motif est g
en
er
e sans
prendre en consid
eration le nombre total de t
aches, en fait comme r
esultat de son
placement on obtient le nombre de t
aches qui le constituent (M otiftaches ). Et X peut
etre calcul
e selon la formule suivante :
T otaltaches
X=
M otiftaches
D
efinition : La r
ep
etition dans un motif est le nombre de placements (AAS) de
communications et t
aches r
ep
et
es dans un m
eme motif avec une m
eme quantit
e de
donn
ees en entr
ee avant de commencer les sorties du motif. On lappelle aussi motif
inter-r
ep
etition.
Lexemple de la figure 6.12 donne des motifs illustr
es avec le diagramme de Gantt,
o`
u la partie sup
erieur du diagramme repr
esente lAAS des communications et la
partie inf
erieure lAAS des t
aches ou calculs.
Figure 6.12 : lAAS des communications et t
aches avec 5 processeurs. A : une seule
inter-r
ep
etition, B : Deux inter-r
ep
etitions, et C : trois inter-r
ep
etitions.
Objectif : lobjectif derri`
ere linter-r
ep
etition est de trouver le bon nombre de t
aches
quon r
ep`
ete au sein dun m
eme motif. Les crit`
eres quon a retenus sont la diminution de la consommation d
energie et lutilisation maximale des ressources tout en
respectant les deadlines.
Soit dli = dlt le deadline dune t
ache. Il est aussi celui de toutes les t
aches car elles
sont identiques.
125
6.6. Mapping des t

aches repetitives.
Xijm = 1 si la t
ache i est plac
ee sur le processeur j et sex
ecute au mode m, o
sinon.
0
dijm = la dur
ee dex
ecution de la t
ache ti plac
ee sur pj sex
ecutant au mode m (sans
prendre en compte les communications) . On remarque que par rapport au premier
0
formalisme globalement irr
egulier ici dijm nest pas fonction des processeurs car dans
0
0
une architecture r
eguli`
ere tous les proceseurs sont identiques. Ainsi, dijml = dikml pour
k 6= i sil fonctionnent au m
eme mode m = ml
0
W CN m
dijm = f m ij o`
u W CNijm est le nombre de cycles n
ecessaires `
a la t
ache i pour
j
m
sex
ecuter sur le processeur j au mode m.l`
a aussi W CNij varie uniquement selon le
mode dex
ecution des processeurs.
fjm est la fr
equence dhorloge du processeur j au mode m.Elle est aussi la m
eme
pour tous les processeurs `
a un m
eme mode.
Ainsi si dans un motif, apr`
es ordonnancement, la t
ache k est la derni`
ere dans
lex
ecution et dlk est son deadline alors dlf inalmotif = dlk . Il est le temps avant lequel
se termine le motif et qui correspond au temps de fin de la derni`
ere t
ache du motif.
Qij est le volume de donn
ees
echang
ees entre les t
aches ti et tj .Il est le m
eme
pour toute les t
aches.
0m
dQijpq est la dur
ee des communications entre les t
aches ti et tj si elles sont plac
ees
respectivement sur les processeurs p et q au mode m. ce temps ne d
epend pas de
la nature des liens car ils sont identiques mais uniquement de la distance ou la
longueur du chemin reliant les processeurs sur lesquels sex
ecutent ces t
aches. On
va voir apr`
es comment ce param`
etre est calcul
e.
m
q est la dur
ee de communication unitaire (bit, octet ou paquet) entre p et q au
mode m.
em est l
energie consomm
ee par une unit
e de donn
ee (bit, octet ou paquet ) durant
son transfert de p `
a q au mode m.
Sil nexiste pas un lien direct entre p et q soit (p, q) = (pi, pj) le chemin (succession
de liens) reliant p `
a q.
Alors la dur
ee dutilisation des liens est :
0
m
dQijpq
=| (p, q) | q m
| (p, q) | est la longueur du chemin (p, q).

La consommation d
energie due `
a la communication des t
aches i et j si elles sont
plac
ees sur les processeurs p et q au mode m en utilisant le m
eme chemin est :
0
m
dEijpq
=| (p, q) | em
126
6.6. Mapping des t

aches repetitives.
Dans ce mod`
ele on consid`
ere que la consommation d
energie due aux communications intra-processeurs est n
egligeable, et de m
eme pour la dur
ee des communications. On peut aussi consid
erer que ces param`
etres sont inclus dans les temps
dex
ecution et l
energie consomm
ee. Chaque chemin contient un certains nombres
de switch et de routeurs qui consomment de l
energie et causent des dur
ees suppl
ementaires de communication.
Dans les travaux de Ascia et al le probl`
eme est pos
e mais ils nexpliquent pas comment ils le traitent. Dans ce travail on propose une valeur moyenne de consommation
(CSW ) et de dur
ee (dSW ) due `
a lutilisation des switch et routeurs. On peut les estimer en consid
erant les communications en entr
ee et sortie des routeurs comme
stochastique.
Ainsi, la consommation totale des switch et routeurs de ce chemin est
egale `
a:
=| (p, q) | +1) Csw
Et la dur
ee totale est :
0
=| (p, q) | +1) dsw

(CSW ) et (dSW ) sont respectivement la consommation moyenne et la dur
ee due `
a
lutilisation des switch et routeurs. On peut donner maintenant l
equation de la
consommation totale due aux communications des t
aches i et j affect
ees aux processeurs p et q au mode m.
m
m
Eijpq
= Eijpq
+
Et la dur
ee totale des communications :
0
m
dQm
ijpq = dQijpq +
Donc le temps total dex

ecution dune t
ache i en prenant en consid
eration les
communications est :
P
mn
S
S
N
m m
m
m
Di = mn
m=m1 Xip Xjq dQijpq avec i 6= j, p 6= q
q=p+1
p=1
m=m1 dip +
j=1
Cette
equation peut
etre simplifi
ee car p est fixe et on consid`
ere par hypoth`
ese
P m
que les communications intra-processeur sont n
egligeables. Pour un i fix
e, Xip = 1
start
Pour une t
ache i, si Di
est son temps de d
ebut, alors son temps de terminaison
f in
est Di , il est donn
Dif in = Distart + Di
127
6.6. Mapping des t

aches repetitives.
Lordonnancement est obtenu par LS o`
u le d
ebut de lapplication correspond
a la fin de la derni`
ere
avec le d
ebut de sa premi`
ere t
ache t1 et sa fin correspond `
start
t
ache tn . Ainsi, pour la t
ache ti son temps de d
ebut Di
correspond au temps
de fin de la derni`
ere des t
aches qui la pr
ec`
edent. Donc la liste LS est obtenue en
utilisant la strat
egie ASAP (As Soon As Possible).
Dnf in = Dnstart + Dn
est le temps de fin de la derni`
ere t
ache tn du motif.
Ce temps est donc le temps de fin du motif Df in qui est donn
Df in = Dnstart + Dn
Donc si Dstart est le temps de d
ebut du motif, qui correspond au temps de d
ebut
start
f
in
de la premi`
ere t
ache D1 , et D
le temps de fin du motif qui est aussi celui de la
f
in
derni`
ere t
ache Dn , alors la dur
ee dex
ecution totale de lapplication est :
D = Df in Dstart
Cest ce temps quon doit minimiser et sassurer quil v
erifie la contrainte temps
r
eel hard, cest-`
a-dire :
D dlf inal
La consommation d
energie totale est donn
ee par la formule suivante en prenant en
consid
eration la consommation des processeurs, des liens, des switch et des routeurs.
E=
N X
s
X
mn
X
i=1 p=i+1 m=ml
m
xm
ip ETip +
N X
N X
s
s
X
X
mn
X
m
m
xm
ip xjp Eijpq
i=1 j=i+1 p=1 q=p+1 m=ml
Objectifs : essayer de minimiser la consommation d

energie tout en exploitant au
maximum les ressources. Le crit`
ere quon a adopt
e ici, en premier, pour lexploitation maximal des ressources est totalslack . O`
u totalslack correspond au temps de repos
ou rel
achement des ressources. Cest ce temps quon doit minimiser pour augmenter lexploitation des ressources. On voit bien que ce crit`
ere est conflictuel avec le
deuxi`
eme objectif qui correspond `
a la minimisation de la consommation d
energie.
En effet exploiter plus les ressources nous am`
ene `
a consommer plus d
energie. La
minimisation de la consommation d
energie revient `
a optimiser lobjectif donn
e par
la formule 13 par contre le deuxi`
eme objectif doit
etre expliciter ci apr`
es.
Donc si on a S ressources dex
ecution et N t
aches constituant le motif. Notant par
S
ee dex
ecution dun motif (formule 12) constitu
e de N t
aches et sex
ecuDn la dur
tant sur S processeurs.
128
6.6. Mapping des t

aches repetitives.
Alors Tdis = DnS S donne le temps de disponibilit
e des ressources.
aches du motif peut
etre
Le temps doccupation Toc des S processeurs par les N t
obtenu `
a partir de l
equation 10.
PN
Ainsi , Toc = i=1 Di
Alors le temps total de rel
achement (ou des slack) des S processeurs utilis
es pour
lex
ecution dun motif de N t
aches est obtenu par :
totalslack = Tdis Toc
Cest ce temps quon doit minimiser en jouant sur le nombre de t
aches constituant le motif.
n,s
Pour g
en
eraliser lexpression notant par totalslack
le temps total de rel
achement d
u
au placement de n t
ache sur S processeurs du NoC.
Donc lobjectif est de trouver le N = N N tels que :
nn,s
n,s
totalslack
= mintotalslack
n = S, . . . , 2S
Etant donn
ee que le nombre de processeurs est donn
ee dans une architecture
r
eguli`
ere et qui est souvent raisonnable, alors le nombre de t
aches constituant le
motif est lui aussi raisonnable par rapport au nombre total des t
aches r
ep
etitives.
Pour ce placement on a propos
e une approche bas
ee une m
ethode exacte pour atteindre les objectifs. Pour optimiser les chemins de communication on a, comme
pour le GI, utilis
e une approche bas
ee sur dijkstra.
La m
ethode propos
ee pour solutionner ce probl`
eme est une m
ethode hybride constitu
ee dune part dune m
ethode exacte permettant de trouver le meilleur placement
selon plusieurs objectifs. Et dautre part dune m
ethode bas
ee sur Dijkstra pour
trouver le mapping des communications. Une fois loptimisation AAS, dun motif,
obtenue on peut aborder le placement de toutes les taches r
ep
etitives.
D
efinition : Le processus de r
ep
etition dun motif X fois est appel
e r
ep
etition de
motif, o`
u:
X=
T otaltaches
M otif taches
Objectif : g
en
erer le placement de toutes les t
aches r
ep
etitives.
Donc la r
ep
etition dun motif est un moyen pour g
en
erer lAAS complet dun
nombre donn
ee de t
aches
egale `
a T otaltaches X fois sans augmenter la complexit
e
des traitements. Ceci est bien illustr
e par la figure 6.11.
Algorithme de placement des t
aches r
ep
etitives
1 D
ebut
2 Introduire le nombre de PE, S et la matrice de topologie
3 Introduire les caract
eristiques de larchitecture et des t
aches r
ep
etitives
4 M otiftaches = 0 ; totalslack =
129
6.7.
Routage et optimisation des communications
5 Pour N = S `
a N = S S faire
6 utiliser la m
ethode exacte pour trouver le placement au mode max des processeurs
7 Utiliser lalgorithme doptimisation des communications
8 calculer totalN slack selon la formule
9 Si totalN slack < totalslack alors totalslack = totalN slack et M otiftaches = N sinon rien fsi
10 fin pour
11 faire changer le mode des processeurs
12 Calculer pour chaque placement la dur
ee dex
ecution et l
energie selon les
equations 12 et 13
13 Retenir le front Pareto ou les solutions non domin
ees
14 FIN.
6.7
Cette phase est tr`

es importante dans tout processus doptimisation AAS. Dans
un graphe dinterconnexion (directionnel ou bidirectionnel) dune plateforme multicore, le routage d
esigne la s
election dun chemin en utilisant certains algorithmes
de routage (Bellman-Ford, Dijkstra, etc.) et des techniques de transmission de donn
ees (boite au lettres, direct, etc.) entre des
el
ements source et destinateur. En
plus souvent `
a travers ce routage en essaye datteindre certains objectifs et v
erifier
certaines contraintes. La s
election du chemin et lenvoie des donn
ees peuvent
etre
impl
ement
es dune fa
con statique ou dynamique en utilisant quelques concepts de
transfert de message car dans nimporte quel environnement multiprocesseurs le
mapping des communications constitue une partie int
egrante de tout lAAS.
Le routage peut
etre class
e en deux cat
egories : routage d
eterministe et routage
adaptatif. Dans le premier, le chemin quun paquet doit suivre est enti`
erement et
compl`
etement d
etermin
e par les adresses sources et cibles du paquet. Le deuxi`
eme
ne d
epend seulement que des adresses sources et cibles du paquet `
a transf
erer mais
aussi des conditions dynamiques du r
eseau, telles la congestion des liens due `
a la
variabilit
e du trafic. Le terme routage adaptif est surtout utilis
e dans le contexte
dun routage dynamique, o`
u les d
ecisions de s
election dun chemin sont donn
ees au
niveau des routeurs.
Le routage dynamique pr
esente certains avantages car il permet d
eviter les congestions en utilisant dynamiquement dautres chemins de routage, mais le routage
d
eterministe est beaucoup plus utilis
es pour les applications sur NoC `
a cause de :
La limitation des ressources et les exigences strictes de la latence : un des
avantages principaux du routage d
eterministe cest sa simplicit
e en en terme
130
6.7.
de sp
ecification des routeurs. A cause de la logique simple des routeurs ce type
de routage fournit une latence faible quand le r
eseau nest pas congestionn
e.
Et dun cot
e impl
ementer des routeurs adaptatifs n
ecessite plus de ressources.
En plus dans un routage adaptatif les paquets doivent respecter lordre dutilisation ce qui n
ecessite limpl
ementation dautres protocoles qui ne peuvent
qualourdir la deuxi`
eme solution et la rendre co
uteuse.
Estimation du trafic : La plupart des NoC sont d
evelopp
es pour une seule
application ou au plus pour une petite classe dapplications. Par cons
equent
le concepteur a une id
ee sur les communications et les caract
eristiques de la
plateforme cible, ce qui lui permet dutiliser ses informations pour bien placer
les IP et trouver un routage
evitant les congestions. Cest ce quon a fait dans
ce travail en v
erifiant pour chaque plus court chemin trouv
e, en terme de co
ut,
la non saturation de la bande passante. Ce qui rend dans ce type de syst`
eme
lavantage du routage adaptatif insignifiant.
Donc le concepteur quand il a `
a choisir entre les deux concepts il doit analyser
les sp
ecificit
es du domaine dapplication. Dans notre cas, pour les raisons quon a
avanc
e auparavant, on a opt
e pour le routage d
eterministe ou off-line car le deuxi`
eme
napporte pas davantages. Au contraire il complique la conception du syst`
eme et
alourdis son soft ce qui est tr`
es d
econseill
e dans les SoC. Dun autre cot
e avec le
premier type de routage on a une estimation `
a lavance des co
uts de communication du moment o`
u ce co
ut est calcul
e comme
etant la somme des co
ut des liens qui
constitue le chemin de routage.
6.7.1
G
en
eration de chemin
Le probl`
eme de g
en
eration de chemin on la formul
e comme le plus court chemin
`
a origine unique. Ce probl`
eme consiste `
a trouver un chemin entre deux sommets
tels que la somme des valeurs des arcs le constituant soit minimale. Dune fa
con
plus formelle, ayant un graphe valu
e o`
u V est lensemble des sommets, E lensemble
des arc et une fonction d
evaluation qui associ
e `
a chaque arc une valeur r
eelle :
w : E R. La valeur du chemin = (v1 , v2 , . . . , vk ) est la somme des valeurs des arcs
le constituant.
W () =
k
X
w(vi1 , vi )
i=1
et le chemin de valeur minimale reliant u `

a v est donn
e par :
"
(u, v) =
min{W () : u v}s0 iluncheminentreuetv

sinon.
Le plus court chemin entre les sommets uetv est df ini par n0 importe quel chemin
avec un cot :
131
6.7.
W () = (u, v)
Si (u, v) = alors il nexiste pas de chemin entre ces deux sommets.
les diff
erentes variantes des probl`
emes du plus court chemin
Les variantes suivantes des probl`
emes du plus court chemin peuvent
etre r
esolues par lalgorithme du probl`
eme de lorigine unique.
Origine unique : consiste `
a chercher tous les chemin `
a partir dun sommet origine
unique `
a tous les sommets v de V ( cest `
a dire one to n).
Probl`
eme du plus court chemin pour cible unique : Cest trouver le chemin le plus
court vers un sommet cible et `
a partir de tous les sommets de V. ( n to one ).
Probl`
eme du plus court chemin entre une paire de sommets : cest le plus court
chemin entre les sommets u et v. Ce probl`
eme a une solution si le probl`
eme dorigine unique donne des solutions. (c-`
a-d one to one).
Probl`
eme du plus court chemin entre toutes paires de sommets : trouve le plus
court chemin entre de u vers v pour les couples de sommets (u, v) V V . (c-`
a-d n
to n ).
Le tableau suivant donne les algorithmes plus connus pour ce type de probl`
eme.
Tableau 1 : Quelques algorithmes importants utilis
es pour r
esoudre le probl`
eme
du plus court chemin `
a origine unique.
On peut citer aussi une m
ethode tr`
es utilis
ee dans les r
eseaux et surtout dans
les r
eseaux `
a Mesh, cest la m
ethode X-Y ou Nord-Est. Elle est facile `
a impl
ementer
et converge rapidement. Seulement cette m
ethode donne le plus court chemin en
terme de nombre darcs et non pas la somme des valeurs.
Algorithme de Dijkstra
1 D
ebut
2 Introduire G,W,s
3 Initialise origine unique (G, s)
4 S
5 Q V [G] /* Q est une liste de priorit
e contenant V S */
6 Tantque Q 6= faire
7 U EXT RACT M IN (Q)
8 S S {u}
9 Pour chaque sommet v Adj[u] faire
10 relax (u,v,w)
11 sid[v] > d[u] + w(u, v) alors d[v] d[u] + w(u, v)
12 fsi
132
6.7.
13 fpr
14 ftq
15 retourner un ensemble de liens (chemin)
16fin
Etant donn
ee que lalgorithme de placement des communications est bas
e directement sur lalgorithme de recherche du plus court chemin, il est important de
connatre sa complexit
e car `
a chaque placement on fait appel `
a lalgorithme de
placement des communications. La complexit
e de notre algorithme AAS d
epend
etroitement de la complexit
e en temps de lalgorithme de placement des communications. Le tableau suivant donne les diff
erentes complexit
es de lalgorithme selon
la structure de donn
ees choisie.
T emps = (V ).TEXT RAIT M IN + (E).TDECREASEKEY
Q
Array
Binaire
Fibonacci
T EXT RAIT M IN
O(V)
O(lgV)
O(lgV)
T DECREASE KEY
O(1)
O(lgV)
O(1)
TOTAL (Worst case)

O(V2)
O(ElgV)
O(E + V lgV )
Tab. 6.1 Tableau 2 : Implementation de lalgorithme de Dijkstra avec des structures de donnees
differentes
Donc lalgorithme `
a base de Dijkstra a
et
e utilis
e pour solutionner les trois probl`
emes de base suivants :
Premi`
erement : A partir dune topologie dinterconnexion quelconque (Mesh, arbre,
cube, etc.) Construire un ensemble de PE selon leur distance `
a partir du PE racine.
Deuxi`
emement : A partir dun ensemble de chemins courts, trouver celui qui a le
co
ut minimal.
Troisi`
emement : sassurer de l
equilibrage de charge entre les diff
erents liens de
communications du r
eseau.
L
equilibrage de charge du r
eseau ou
equilibrage des communications consiste `
a
sassurer que les communications utilisent tous les liens du r
eseau et non pas uniquement certains. Ceci a lavantage dexploiter toutes les ressources du NoC et par
l`
a de minimiser le risque de la congestion.
6.7.2
Probl`
eme de g
en
eration du chemin
Apr`
es avoir expliqu
e le fonctionnement des diff
erentes parties constituant notre
solution du probl`
eme du plus court chemin, on peut pr
esenter maintenant notre
algorithme. La strat
egie quon a arr
et
ee et qui correspond `
a la r
ealit
e du probl`
eme
cest-`
a-dire de g
en
erer les plus courts chemins `
a partir dune origine unique et une
133
6.7.
cible unique.
u les valeurs des arcs sont
Formulation : A partir dun graphe direct G = (V, E), o`
toutes sup
erieures ou
egales `
a z
ero, on essaye datteindre lobjectif consistant `
a
trouver le chemin le plus court entre deux sommets o`
u le co
ut est
egale `
a la somme
des co
uts de tous les arcs le constituant. Ainsi, ayant un graphe valu
e constitu
e
dun ensemble V de sommets, dun ensemble E darcs et dune fonction d
evaluation w : E R. La valeur du chemin = v0 , v1 , .., vn est la somme des valeurs des arcs
le constituant. Lalgorithme suivant r
esume les diff
erentes
etapes de lalgorithme de
g
en
eration dun chemin.
Algorithme de g
en
eration
1 D
ebut
2 Pour p = 1 `
a S faire
3 Si P E = RootP E alors return aucun chemin nest exig
e
4 Sinon appeler Dijkstra (rootPE,PE, Gparta)
5 Retourne le chemin (P tsi ) c-`
a-d lensemble des liens
6 Faire lordonancement des paquets
7 V
erifier la contrainte de charge et de bande passante
8 Si les contraintes sont v
erifi
ees faire le mapping des communications sur les liens
sinon rien
9fin
6.7.3
Routage statique des paquets
Le routage statique (ou routage off-line) est r

ealis
e au moment de la compilation, ce qui veut dire que tous les chemins de routage doivent
etre trouv
es avant
les traitements.
Routage direct ou routage statique des paquets

Le routage direct est un cas sp
ecial du routage o`
u le chemin est g
en
er
e uniquement entre lorigine et la cible. Il faut
eviter la collision des paquets et une fois
inject
es ils doivent atteindre leur cible. Chaque paquet, dans ce cas, a un seul param`
etre qui consiste en son temps dinjection. Ce type de routage est important
quand les buffers sont chers ou non disponibles tel que dans les r
eseaux `
a fibre
optique. En consid
erant les NoC ou MPSoC ce type de routage est b
en
efique car
il permet de r
eduit la surface SoC. Cest ce qui a motiv
e son utilisation lors du
routage et placement des communications dans notre algorithme.
134
6.8. mapping Global
6.7.4
Probl`
eme du routage des paquets
Ce probl`
eme joue un r
ole central dans lordonnancement des t
aches et surtout
les ordinateurs parall`
eles de grande taille dans le sens du nombre de processeurs et
de la longueur de son r
eseau dinterconnexion. Le routage des paquets consiste `
a
d
eplacer les donn
ees dun endroit `
a un autre dans le r
eseau. Le but est de transf
erer
tous les paquets `
a leur destination aussi rapidement que possible et avec un minimum dattente si cest possible. Ce probl`
eme on la formul
e de la fa
con suivante.
Ayant des paquets P ksi avec des chemins sp
ecifi
es P tsi (path) dans le r
eseau, o`
u
chaque paquet a une source Si et une destination di , lobjectif est dobtenir un ordonnancement du routage direct tel que `
a un instant ti pour chaque paquet P ksi ce
dernier est inject
e pour son transfert direct `
a sa destination sans collision et avec
un minimum de temps.
Le temps de routage : soit ti linstant dinjection du paquet P ksi dans le r
eseau. Et
| P i | la longueur du chemin de routage associ
e `
a ce paquet. Alors le paquet P ksi
atteint sa destination `
a linstant ti + | P i |(le temps total du routage dun paquet) et
le dernier paquet arrive `
a linstant maxi{ti + | P i |}.
Lordonnancement des paquets dans notre approche AAS
1 D
ebut
2 Pour p = 1 `
a S faire
3 Si P E = RootP E alors return aucun chemin nest exig
e
a
4 Sinon appeler Dijkstra (RootPE,PE, Gpart )
5 Return lensemble des liens constituant le chemin P tsi
6 Associer lensemble paquet P ksi au chemin P tsi
7 D
efinir les temps de d
ebut denvoie et fin du paquet `
a travers chaque lien du
chemin
8 Envoie des donn
ees
9fin
Gparta partie du r
eseau correspondant au nud dans le graphe hi
erarchique
6.7.5
Temps dex
ecution
6.8
mapping Global
Dans la d
emarche quon propose pour r
esoudre le probl`
eme du mapping dans
sa globalit
e (cest `
a dire le GILR), on essaye de faire laffectation dun HTG (Hierarchical Task Graph) `
a un HNT (Hierarchical Network Graph) avec des niveaux
identiques. Dans notre approche on simpose certaines hypoth`
eses quon cite ciapr`
es et peuvent
etre enlev
ees dans de futurs travaux :
135
6.8. mapping Global

Topologie
Arbre
Mesh
Mesh
A buffer
Hypercube
Autre topologie
de reseau direct
Problème
Problème de routage arbitraire
sur une topologie en arbre arbitraire
Avec n nuds : permutations
Avec chemin arbitraire
Avec n entree : destinations
et permutations aleatoires
Avec n nuds : destinations
et permutations aleatoires
Avec packets de donnees infnies et
source et destination fixes
complexite
O(C+D)
O(n1/2 )
O(C + D)
O(lgn)
O(lgn)
O((E + M )M logM )2
ou O(C + D)
Tab. 6.2 Complexite des algorithmes de routage direct

1. le nombre de niveaux est connu et donn
e comme entr
ee
2. Les deux graphes ont les m
emes niveaux
3. On consid`
ere aussi qu`
a nimporte quel niveau on a le m
eme nombre de noeuds
compos
es
4. On extrait de lensemble un optimum (D, E) ou (D, E)
5. Le dernier niveau contient uniquement des noeuds
el
ementaires repr
esentants
des t
aches dans le HTG ou processeurs dans le HNT
6.8.1
D
emarche
Pour trouver le mapping optimal du HTG sur le NHT on commence par chercher le mapping de tous les noeuds compos
es et r
ep
etitifs dans le HTG sur les
noeuds compos
es et r
eguliers du HNT `
a lavant dernier niveau. Si on a N niveaux,
on commence par le niveau N 1. Quand tous les mapping des nuds compos
es de
ce niveau sont trouv
es on proc`
ede de m
eme pour le niveau N 2 en consid
erant les
mapping trouv
es au niveau N 1 comme contraintes. Apr`
es on fait de m
eme pour le
niveau N 2 et ainsi de suite jusqu`
a atteindre le niveau 1 ou la racine. Les grandes
lignes de cette d
emarche sont dans lalgorithme quon propose ci-apr`
es :
Algorithme de parcours des arbres HTG et HNT.
Algorithme de parcours des arbres HTG et HNT
1 D
ebut
2 l = 1
3 Au niveau N 1 on construit deux ensembles
STNC1 = {EnsembledesnoeudscompossdansleniveauN 1inHT G}
SPNC1 = {EnsembledesnoeudscompossdansleniveauN 1inHN T }
N l
4 Pour chaque tci STNCl on calcule (tci ) et de m
eme pour pcj SpC
136
6.9. Le choix dune methode `

a base de GA pour le placement irregulier
5 On trie STNC1 selon | (tci ) | telque pour deux noeuds successifs tci et tci+1 STNC1
ebut de lensemble STNC1 on a le noeud tci avec le plus
on a | (tci ) |>| (tci+1 ) | et au d
grand nombre de voisins. Et on fait de m
eme avec SPNC1 .
6 heardt top of list STNC1
7 heardp top of list SPNC1
8 Envoie des donn
ees
9 map(heardt , heardp ) ou map(graph(heardt ), graph(heardp )) o`
u graph(heardt ) est le graphe
repr
esent
e par le noeud compose heardt
10 STNC1 = STNC1 {heardt } ; SPNC1 = SPNC1 {heardp }
11 if STNC1 or SPNC1 = allez `
a5
c
c
12 Pour chaque couple (ti , pj ) on a le co
ut de placement optimal C (tci , pcj ) obtenu
par lutilisation des algorithmes des
etapes 1 et 2 dans le cas dun nud compos
e.
(Pour les nuds r
ep
etitifs on fait appel `
a la m
ethode placement de t
aches r
ep
etitives).
13 Si | level l 1 | alors on peut consid
erer les placements (tci , pcj ) trouv
es dans le
niveau level l comme contrainte et allez `
a l
etape 2 sinon STOP.
14 FIN
6.9
Le choix dune m
ethode `
a base de GA pour le placement
irr
egulier
Notre choix dune approche bas

ee sur le g
en
etique pour l
etape 1 et consolid
e
par une
etude comparative avec dautres approches (voir chapitre suivant). Des jeux
dessai nous ont permis de conclure que la proposition dun algorithme `
a base du
g
en
etique peut
etre tr`
es efficace `
a condition que les param`
etres soient bien arr
et
es. En effet les r
esultats obtenus nous permis aussi de dire que lefficacit
e de cet
algorithme d
epend
etroitement des ses param`
etres, notamment de la taille de la
population et le nombre dit
erations.
6.9.1
param`
etres de lalgorithme g
en
etique
Nombre de g`
enes
On a une configuration de S SOCs (processeurs) et de N t
aches. On prend la
taille dun chromosome en g`
enes : Ch = S N .
Le codage
Dans les sections 6.3 et 6.4 on d
ecrit comment se fait le codage. On a surtout
insist
e sur le fait quon a opt
e pour de type de codage : le premier codage utilis
e
137

dans la premi`
ere phase de lalgorithme est un codage binaire o`
u chaque chromosome est constitu
e de N*S bits ou de S g`
enes chacun compos
e de N bits. N
etant
le nombre de t
aches et S le nombre de processeurs. Pour un g`
ene k correspondant
au processeur k la valeur de son i bit indique laffectation ou non de la t
ache i au
me
k
processeur (1 ou 0).
Dans la deuxi`
eme phase les chromosomes sont constitu
es de S g`
enes, chacun est
constitu
e N M bit. Si on veut dans chaque g`
ene on a M paquets de N bits. Pour
un g`
ene k correspondant au processeur k, le paquet m dans le g`
ene correspond au
me
mode m de fonctionnement du processeur. Donc si le i g`
ene de ce paquet est
egale
`
a 1 cela veut dire que la t
ache i est affect
ee au processeur k fonctionnant au mode
m.
Puisque, ce mapping se fait en off-line tel quon la justifi
e dans les sections pr
ec
edentes alors une t
ache est affect
e`
a un seul processeur et sex
ecute enti`
erement en un
seul mode. Ce qui nous a pouss
e`
a introduire dans notre d
emarche des contraintes
dint
egrit
e des chromosomes. Ces contraintes sont de la forme suivante :
S M odmax
X
X
p=1
m
Xip
= 1ti T
m=1
Pour simplifier cette contrainte on essaye lors de limpl

ementation et apr`
es chaque
croisement ou mutation ne v
erifier que les bits concern
es. Cest-`
a-dire en supposant quon a un chromosome chrx obtenu `
a une certaine it
eration. Supposant que ce
chromosome correspond `
a un placement o`
u la t
ache i est affect
ee au processeur j.
Dans ce cas le bit i du g`
ene j de ce m
eme chromosome est
egal `
a 1. Alors il faut que
me
tous les autres i bit des autres g`
enes soient
egaux `
a 0. Souvent dans une it
eration
on ne modifie que quelques bits dont le nombre ne d
epasse pas 10essaye de v
erifier
lint
egrit
e du chromosome uniquement pour les bits concern
es. Ainsi pour notre
exemple on r
eaffecte la t
ache i apr`
es mutation ou croisement on sassure que :
S1
X
Chri+N LP ourL{indicesdesbitsconcerns}
L=0
Chr(i) est la valeur du bit i du chromosome et N le nombre de t

aches.
On pense que le remplacement de la formule 16 par cette derni`
ere va nous permettre
lors de limpl
ementation d
economiser 80 `
a 90% des calculs dus `
a la v
erification des
int
egrit
es des chromosomes.
D
etermination de la population initiale
Pour la premi`
ere population ou population initiale on a opt
e pour lal
eatoire total. Quelques chromosome sont choisis al
eatoirement mais pour compl
eter le nombre
de chromosome constituant la population initiale on choisit quelques chromosomes
138

selon la strat
egie vue dans la section 6.3. En effet, il ne faut pas oublier que le g
en
etique ou tout autre algorithme
evolutionnaire est bas
e sur des ph
enom`
enes naturels
ou d
evolution tel que cest le cas pour le g
en
etique. Donc si on prend un cheptel de
mouton et que lon essaye dam
eliorer la race selon certains crit`
eres, alors si dans le
cheptel initial aucun de ces crit`
eres nest v
erifi
e au d
epart par aucun de ces moutons
on pourra difficilement obtenir un cheptel dont les moutons v
erifient ces crit`
eres.
Par contre si au d
epart on sassure que dans le cheptel il existe certains moutons
qui v
erifient certains crit`
eres alors on peut rapidement obtenir par croisement et
mutation un autre cheptel constitu
e de moutons dont certains v
erifient les crit`
eres.
Cest ce principe qui a justifi
e notre choix pour des chromosomes correspondant `
a
de bons placements.
6.9.2
Choix des op
erateurs g
en
etiques
S
election
Pendant la cr
eation des g
en
erations, les premiers chromosomes `
a
etre choisis
pour la procr
eation sont les deux meilleurs de la g
en
eration parent. Il sagit dune
adaptation de la strat
egie
elitiste. Les autres chromosomes seront choisis selon le
principe de la roulette.
Croisement
Le croisement est le processus selon lequel les g`
enes de deux chanes
elues sont
interchang
es afin de g
en
erer une nouvelle population.
Il existe plusieurs type de croisement : croisement en un seul lieu, croisement en
deux lieus, croisement uniforme.
On a opt
e pour le croisement uniforme, parce que si on croise deux bons chromosomes, alors on garde les points communs entre ces deux derniers et on a une
probabilit
e de 50Le croisement des deux
el
ements issus de la s
election
elitiste donnera deux enfants et celui des quatre choisis par la roulette donne douze enfants.
Si le nombre des individus choisis est sup
erieur au nombre denfants g
en
er
es alors
on compl`
ete les chromosomes manquants al
eatoirement.
Mutation
Pendant le processus de mutation, un seul bit est choisi al
eatoirement parmi
lintervalle [1, S N ] avec une probabilit
e de P m . La valeur du g`
ene quon va muter
est choisie au hasard. Selon ce principe, il est possible quun g`
ene ne subisse aucune
mutation puisque sa valeur initiale peut
etre choisie de nouveau par le processus de
139

randomisation.
6.9.3
Transformation de la fonction objectif en fonction Fitness
Il est n
ecessaire de pr
eciser que les valeurs de la fonction fitness doivent
etre non
n
egatives pour que le meilleur individu re
coive la valeur fitness maximum, pour cela
des transformations simposent :
(
F (x) = CM AX ZlorsqueZ < Cmax ;

F (x) = 0Autrement.
Z : correspond `
a la fonction objectif.
6.9.4
Fonction d
evaluation
Un des
el
ements cl
es de lalgorithme g
en
etique est la fonction d
evaluation (Fitness ou Fonction objective).
Le probl`
eme de placement des t
aches dune application sur un NOC revient `
a minimiser la fonction objective.
Il peut
etre formul
e de la mani`
ere suivante :
Etant donn
e:
Le graphe dapplication (taille de la tache, m
emoire dex
ecution requise, bande
passante requise pour un message et taille du message).
Le graphe darchitecture (
equilibrage de charge (charge minimum et maximum), m
emoire disponible dans un SOC, taille de la file dattente, bande
passante et vitesse de transmission des bus).
Minimiser :
Le co
ut total Z.
Par choix :
Du placement des taches sur les diff
erents SOCs.
Ce qui est
equivalent `
a:
"
M inimiserZ = sumnj=1 Cj Xj i = 1, . . . , m;
xj {0, 1}j = 1, . . . n.
La d
etermination de la fonction Fitness (Fonction dadaptation ou
evaluation) passe
par plusieurs
etapes. Chaque fois quune population est g
en
er
ee la fonction fitness
de chaque un de ses chromosomes doit
etre
evalu
ee .Les
etapes d
evaluation sont
les suivantes :
140

On a en entr
ee :
Un chromosome qui repr
esente un placement des taches de lapplication dans
larchitecture NOC cible.
Evaluation :
Pour un chromosome, faire la somme des co
uts de communication de tous ses
messages en
eliminant pour chaque message les chemins dont la bande passante
est inf
erieure `
a celle requise par le message (en utilisant lalgorithme du plus
court chemin), donc : F itness = CM AX C
CM AX : est le co
ut maximal possible dun placement.
C : correspond au co
ut total des communications.
On consid`
ere trois p
enalit
es :
de charge : F itness = CM AX C Pequi .

1. Equilibrage
2. Memoire : F itness = CM AX C Pmem .
3. File dattente : F itness = CM AX C PP f il .
Remarque 1 :
Il ne faut pas oublier que les valeurs de la fonction fitness doivent toutes
etre positives. Dans le premier cas (respect des contraintes), les valeurs seront s
urement
positives puisque le co
ut total dun placement ne d
epassera jamais le co
ut maximal
observ
e jusquici (tout les points de lespace de recherche ont un co
ut compris entre
0 et CM AX ). Par contre, en p
enalisant les co
uts dans le deuxi`
eme cas, on risque
davoir des valeurs n
egatives. Le mieux serait de remplacer les valeurs n
egatives de
la fonction fitness correspondant `
a des configurations infaisables par des 0.
Remarque 2 : Les coefficients de p
enalit
es sont choisis de telle fa
con quun placement ayant un co
ut faible mais ne respectant pas les contraintes ait une valeur
fitness inf
erieure `
a celle dun placement ayant un co
ut plus
elev
e et qui respecte les
contraintes qui sont multipli
ees par le co
ut total des messages dun chromosome si
ces contraintes ne sont pas respect
ees de telle fa
con quun chromosome qui respecte
ces contraintes soit meilleur que celui qui ne les respecte pas m
eme si ce dernier a
un co
ut de communication sup
erieur au premier.
Et on a en sortie la fonction d
evaluation qui est d
efinit de la mani`
ere suivante :
F itness =
CM AX Csicontrainterespecte;
CM AX C Pequi sil0 quilibragedechargen0 estpasrespect;
CM AX C Pmem silammoiren0 estpasrespecte;
CM AX C Pf il silaf iled0 attenten0 estpasrespecte;
0siC < C P nalit.
141

Comme nous pouvons le constater, la phase d
evaluation comporte plusieurs
etapes
et de longs calculs. Remarquer que l
evaluation doit
etre faite pour chaque chromosome ; si une population comporte 100 chromosomes, nous devrons r
ealiser 100
evaluations pour une g

en
eration. Si nous d
ecidons de produire 40 g
en
erations, alors
notre syst`
eme aura calcul
e 4000 diff
erents co
uts, rang de matrice et fitness.
6.9.5
Formalisation du probl`
eme de placement :
Pour ex
ecuter une application r
epartie, il est n
ecessaire de d
eterminer le meilleur
placement des taches qui la composent sur larchitecture NOC cible tout en essayant datteindre les objectifs (temps dex
ecution, consommation d
energie) sous
contraintes d
equilibrage de charge, m
emoire disponible, de taille de la file dattente
et bande passante ce qui va conduire automatiquement a la r
eduction de la consommation d
energie.
D
efinition des contraintes
Equilibrage de charge
tq T, Si S |
n
X
ta(tq ) xqi > Char(Si ) (C = C Pequi )
q=1
ta(tq ) est la taille de la t

ache tq . Char(Si ) est la charge tol
er
ee du processeur Si ,
elle peut
etre donn
ee ou estim
ee selon le contexte.
Principe constituant `
a r
epartir aussi
equitablement que possible la charge de travail entre plusieurs
el
ements dex
ecution du SoC. Son but est de garantir quaucun
processeur ne reste inactif quand il y a dautres processeurs qui sont lourdement
charg
es dans le syst`
eme h
et
erog`
ene. La p
enalit
e de l
equilibrage de charge est calcul
ee par lop
e
ration
suivante
:
q
P equi = Cmax
.
C
6.9.6
Bande passante
b(mj ) b0 (br )
Cest la quantit
e dinformations qui peut passer dans un lien par unit
e de temps, et
dans notre probl`
eme la bande passante requise pour envoyer un message doit
etre
inf
erieure ou
egale `
a celle du lien.
142
6.10. Conclusion
6.9.7
M
emoire
tq T, Si S | Si = F (tq ) M em0 (tq ) > mem(Si ) (C = C Pmem )
La m
emoire dex
ecution requise par une t
ache doit
etre inf
erieure ou
egale `
a
celle disponible dans le processeur auquel elle a
et
e affect
ee par le placement. La
p
enalit
e de la m
emoire dex
ecution est calcul
ee par lop
eration suivante :
Cmax
Pmem = C .
6.9.8
File dattente
tq T, Si S | Si = F (tq )
n
X
ta(tq ) > F il(Si ) (C = C Pf il )
q=1
La file dattente permet de stocker les t

aches si le processeur est occup
e par le
traitement dautres taches. Il faut
eviter daffecter une t
ache `
a un SOC qui a une
file dattente satur
ee. La p
enalit
e de la file dattente est calcul
ee par lop
eration
suivante :
Pf il = Cmax
.
C
6.10
Conclusion
Dans ce chapitre on a essay

e de proposer une d
emarche de r
esolution du probl`
eme du mapping dans sa globalit
e (le GILR). On a vu que cette d
emarche n
ecessite lhybridation de plusieurs techniques pour r
epondre aux besoins sp
ecifiques
de cette probl
ematique. En effet, la r
esolution de ce probl`
eme n
ecessite `
a la fois
des m
ethodes de r
esolution de probl`
emes de petites tailles et dautres de grandes
tailles. En plus de la sp
ecificit
e des applications embarqu
ees, il faut aussi r
esoudre
ce probl`
eme en essayant datteindre plusieurs objectifs `
a la fois. Toute d
emarche ne
peut
etre jug
ee positivement quapr`
es sa r
ealisation. Par le pass
e on vu plusieurs
m
ethodes et algorithmes bas
es sur des th
eories solides ou des formalismes math
ematiques rigoureux mais au moment de leurs impl
ementations ils sav`
erent
etre en
d
ecalage sur le plan des r
esultats par rapport aux attentes des concern
es auxquels
sont destin
ees ces solutions. Cest `
a ces questions quon va essayer de r
epondre dans
le chapitre suivant consacr
e enti`
erement `
a limpl
ementation et aux r
esultats.
143
Chapitre 7
Mise en uvre et validation
144
7.1. Introduction
7.1
Introduction
Quelque soit la conception dun problème, son implementation pose souvent

des contraintes et le programmeur se trouve confront
e`
a des difficult
es. De ce fait,
linformaticien se doit de faire une
etude suppl
ementaire r
eserv
ee au cot
e impl
ementation de son travail afin de rendre le logiciel interactif et conforme aux normes
des logiciels professionnels. Par ce chapitre aussi, on a essay
e dobtenir et pr
esenter
quelques r
esultats nous permettant de valider la d
emarche pr
esent
ee pr
ec
edemment. Comme ils peuvent aussi nous permettre de faire des critiques qui vont nous
ouvrir dautres perspectives qui feront lobjet de futurs travaux. La plupart des
travaux accomplis dans ce projet ont
et
e d
evelopp
es en langage Java sous lenvironnement Eclipse qui constitue un outil IDE. Ce choix est tr`
es judicieux car le
langage Java sur le plan technique est devenu un langage tr`
es puissant surtout pour
les applications distribu
ees. Dun autre cot
e sur le plan conceptuel cet outil permet
une translation relativement facile `
a partir du mod`
ele UML.
7.2
Sp
ecification des besoins
Compte tenu de la nature de l

etude men
ee sur les r
eseaux sur puce, des exigences
du probl`
eme de placement et des diff
erentes notions relatives aux algorithmes de
mapping, le logiciel doit
etre capable de r
epondre aux besoins suivants :
La possibilit
e de choisir le type de saisie (matricielle ou graphique).
La saisie graphique nous permet de repr
esenter :
Larchitecture du NOC sous forme de SOCs (carr
e) reli
es par des bus (arc),
elle permet aussi de param
etrer chaque SOC (charge minimum, charge maximum, m
emoire dex
ecution disponibles et taille de la file dattente) et chaque
bus (vitesse de transmission et bande passante).
Lapplication quon veut placer sur larchitecture sous forme de taches (cercle)
communicants via des messages (arc), et permet aussi de param
etrer chaque
tache (m
emoire dex
ecution requise et taille de la tache) et chaque message
(Taille du message et bande passante requise).
La saisie matricielle nous permet de repr
esenter :
Larchitecture du NOC en saisissant une matrice dincidence (processeurprocesseur) et de v
erifier sa coh
erence en la validant, elle permet aussi de
param
etrer ses diff
erentes propri
et
es avec des matrices (charge minimum,
charge maximum, m
emoire dex
ecution disponibles et taille de la file dattente, vitesse de transmission et bande passante).
Lapplication en saisissant une matrice dincidence (t
ache-t
ache) et de v
erifier sa coh
erence en la validant, elle permet aussi de param
etrer ses diff
erentes propri
et
es avec des matrices (m
emoire dex
ecution requise et taille
de la t
ache, taille du message et bande passante requise).
La possibilit
e de sauvegarder et charger un mod`
ele.
145
7.3. Choix du language de programmation

La possibilit
e de sauvegarder et charger une architecture.
La possibilit
e de sauvegarder et charger une application.
La possibilit
e de lancer une recherche permettant de trouver le placement
optimal dune application sur une architecture `
a moindre co
ut de communication (en utilisant lalgorithme du plus court chemin) sous les contraintes
suivantes :
emoire dex
ecution disponible, taille de
la file dattente et bande passante des bus, et cela par limpl
ementation dun
algorithme g
en
etique.
La possibilit
e de varier les param`
etres de lalgorithme g
en
etique (probabilit
e
de croisement, de mutation, taille de la population, nombre de g
en
erations,
p
enalit
e d
equilibrage de charge, p
enalit
e de m
emoire et p
enalit
e de file dattente) .
La possibilit
e daffecter `
a priori une t
ache `
a un SOC (contrainte daffectation).
La g
en
eration dun rapport comportant les principales informations concernant
les r
esultats de lalgorithme g
en
etique.
7.3
Choix du language de programmation
Pour atteindre ces objectifs, nous avons opt

e pour le langage de programmation
JAVA, un choix qui se justifie par les nombreux avantages quil offre du point de
vue interface et traitement.
Eclipse est un environnement de programmation visuelle orient
e objet permettant le d
eveloppement dapplications en vue de leur d
eploiement sous Windows ou
sous Linux. En utilisant JAVA sous Eclipse, vous pouvez cr
eer de puissantes applications inter op
erable.
JAVA sous Eclipse propose un ensemble doutils de conception pour le d
eveloppement rapide dapplications selon le concept IP, dont des experts programmateurs
et des mod`
eles dapplications ou de fiches, et g`
ere la programmation orient
ee objet
avec deux biblioth`
eques
etendues de classes. Cet environnement constitue un bon
outil pour lIDM (ou MDE).
Le projet r
ealis
e est constitu
e de plusieurs modules d
evelopp
es pendant une
dur
ee relativement longue. La premi`
ere partie du projet est constitu
ee dun logiciel
qui cherche le mapping `
a laide dun algorithme
evolutionnaire pour le Globalement
Irr
egulier (GI), la deuxi`
eme partie est limpl
ementation de la d
emarche pour le
placement des t
aches r
ep
etitives sur des architectures r
eguli`
eres (ou Localement
R
egulier LR). En fin, la troisi`
eme consiste en limpl
ementation de la d
emarche
pour le mapping de probl`
emes hi
erarchiques (GILR) en int
egrant les deux outils
pr
ec
edents.
146
7.4. Justification du choix de la methode pour le placement irregulier de grande taille
7.4
Justification du choix de la m
ethode pour le placement irr
egulier de grande taille
Il existe plusieurs approches pour solutionner le probl`

eme doptimisation combinatoire de grande taille : coupe de graphe de Stone, Tabou, recuit simul
e, g
en
etique,
Ant, PSO, etc. Plusieurs travaux r
ealis
e r
ecemment dans le domaine et quon a cit
e
dans le chapitre 4 ont utilis
e des m
ethodes inspir
ees du g
en
etique sans donner de
raisons ou justifications, `
a part davancer que cette technique est `
a la mode actuellement et donne de meilleurs r
esultats. Pour appuyer notre choix on a compar
e
cette m
ethode avec une autre consid
er
ee jusqu`
a r
ecemment comme une m
ethode
r
ef
erence pour loptimisation combinatoire. Cette derni`
ere connue sous le nom du
recuit simul
e Simulated annealing sinspire dun proc
ed
e de refroidissement
dans la m
etallurgie. Elle est tr`
es connue pour ses bons r
esultats dans loptimisation
mono-objectif, m
eme si certains lui reprochent sa convergence lente. On doit aussi
signaler ici que dautres travaux sont en cours actuellement pour montrer son utilisation possible pour le multi-objectif, comme dailleurs la m
ethode Tabou, branch
and bound, etc (Conf
erence META08). Lapproche du recuit simul
e consiste essentiellement `
a trouver dans le voisinage dune configuration initiale donn
ee une
nouvelle configuration quon esp`
ere meilleure `
a celle courante. Dans le cas o`
u cette
nouvelle configuration am
eliore la solution courante, elle est choisie comme nouvelle configuration initiale pour continuer le processus de perturbation. Dans le cas
contraire, la nouvelle configuration obtenue, qui d
etermine la solution courante, est
maintenue avec une probabilit
e p qui d
ecrot dans le temps.
Lexp
erience a port
e sur des topologies constitu
ees de 12, 20, 40 et 100 nuds.
Dans presque tous les cas, lalgorithme g
en
etique offre de meilleures solutions. On
remarque m
eme, dans un cas, une am
elioration de 43% du temps de recherche. Encore une fois, les excellents r
esultats obtenus par lalgorithme g
en
etique semblent
d
ecouler dun choix judicieux de ses param`
etres.
Nombre
de variables
12
20
40
100
Recuit simule
Temps(ms) Co
ut
46
73
49
150
197
123
405
2304
Algorithme genetique
Temps(ms)
Co
ut
32
72
57
132
172
101
331
2056
%
Temps
43%
1,2%
14,5%
22%
%
Co
ut
1%
13%
21%
12%
Tab. 7.1 Sommaire des resultats comparatifs obtenus par recuit simule et AG
Donc la proposition dun algorithme `
a base du g
en
etique peut
etre tr`
es efficace
`
a condition que les param`
etres soient bien arr
et
es. Cest quon essayera de cerner
147
7.5. Description du logiciel (Aspect general)

et expliquer dans les sections suivantes.
7.5
Description du logiciel (Aspect g

en
eral)
Le logiciel doptimisation du placement dapplication dans un NOC utilisant un

algorithme g
en
etique est constitu
e de plusieurs composants dont linterface structur
ee en plusieurs fen
etres :
1. Form1 (Saisie) : Cest la fen
etre principale du logiciel, elle offre le choix de la
saisie de lapplication et de larchitecture (graphique ou matricielle).
2. Form2 (Graphe dapplication) : Elle permet la saisie graphique dune application sous forme de t
aches reli
ees par des messages, dafficher et de modifier les
propri
et
es des taches et des messages.
3. Form3 (Graphe darchitecture) : Elle permet la saisie graphique dune architecture sous forme de SOCs reli
es par des bus, dafficher et de modifier les
propri
et
es des SOCs et des bus.
4. Form4 (SOC) : Elle permet de saisir et de modifier les propri
et
es des SOCs.
5. Form5 (Bus) : Elle permet de saisir et de modifier les propri
et
es des Bus.
6. Form6 (Tache) : Elle permet de saisir et de modifier les propri
et
es des taches.
7. Form7 (Message) : Elle permet de saisir et de modifier les propri
et
es des
messages
7. Form8 (Placement g
en
etique) : Elle permet de saisir les param`
etres g
en
etiques
et de lancer lalgorithme de placement et affiche en r
esultat un rapport comprenant : la meilleure population, le meilleur placement, les plus courts chemins
et la courbe d
evolution de la fitness.
8. Form9 (Contraintes et r
eglages) : Elle permet de saisir ou de modifier les
probabilit
es de croisement et de mutation ainsi que les p
enalit
es d
equilibrage
de charge, m
emoire dex
ecution et de file dattente. elle permet aussi daffecter
une t
ache directement `
a un SOC (contrainte daffectation).
9. Form10 (Propri
et
es de lArchitecture) : Elle permet de saisir dune fa
con matricielle les propri
et
es de larchitecture (charge minimum, charge maximum,
m
emoire dex
ecution disponible et taille de la file dattente, vitesse de transmission et bande passante). elle permet aussi de modifier les valeurs par d
efaut
de ces derni`
eres.
10. Form11 (Propri
et
es de lApplication) : Elle permet de saisir dune fa
con matricielle les propri
et
es de lApplication (m
emoire dex
ecution requise et taille
de la tache, taille du message et bande passante requise). elle permet aussi de
modifier les valeurs par d
efaut de ces derni`
eres.
148
7.6. Presentation des organigrammes du logiciel
7.6
Pr
esentation des organigrammes du logiciel
Nous pr
esentons maintenant les organigrammes qui d
ecrivent, de mani`
ere g
en
erale, notre logiciel.
7.6.1
Organigramme repr
esentant les principales
etapes du logiciel
Lorganigramme ci-dessous (figure 7.1) d

ecrit dune mani`
ere g
en
erale les enchanements des modules qui r
egissent le logiciel. Dabord, lutilisateur doit choisir le
type de la saisie, ensuite, soit on est en mode graphique et il introduit le graphe
de lapplication et darchitecture avec leurs caract
eristiques graphiquement. Soit en
mode matricielle et l`
a il introduit les matrices dincidences darchitecture et dapplication avec leurs caract
eristiques sous forme matricielle. Ensuite, lutilisateur peut
lancer lalgorithme g
en
etique en ayant la possibilit
e de modifier ses param`
etres et les
contraintes, puis il consulte le rapport contenant les r
esultats finaux de la recherche.
7.6.2
Organigramme repr
esentant le fonctionnement de lalgorithme g
en
etique (A.G)
Les algorithmes g
en
etiques suivent tous un principe commun et limpl
ementation
pr
esent
ee ny fais pas d
efaut : une phase de constitution de population initiale,
suivie de phases de r
eg
en
eration de populations gr
ace aux op
erateurs g
en
etiques de
s
election, mutation et croisement, comme lindique la figure 7.2. Chaque g
en
eration
produira, en principe, des placements plus performants que les pr
ec
edents. Plus
le nombre de g
en
erations est grand, plus la solution se raffinera et la derni`
ere
g
en
eration devrait contenir une bonne solution. Pendant le processus de cr
eation,
deux populations existent en parall`
ele : la population courante, do`
u sont puiser
les chromosomes parents, et la nouvelle g
en
eration en voix de r
ealisation, o`
u se
retrouverons les chromosomes enfants.
7.6.3
Organigramme repr
esentant le processus d
evaluation des individus
dune population
Lorganigramme de la figure 7.3 repr

esente le processus d
evaluation dun seul
individu de la population. Qui se d
eroule en deux phases :
1. Plus courts chemins : elle passe par 4
etapes :
G
en
eration de la matrice dincidence du co
ut en temps et cela en
eliminant
les chemins dont la bande passante est insuffisante et en divisant la taille du
message sur les vitesses des bus, on aura en sortie une matrice qui contient
les co
uts en temps de tous les chemins possibles.
Trouver les processeurs source et les processeurs destination des messages
suivant un placement donn
e.
La g
en
eration des plus courts chemins proprement dits et leurs co
uts.
149
7.6. Presentation des organigrammes du logiciel

Affectation des r
esultats `
a la matrice des plus courts chemins.
2. P
enalit
e : on a trois contraintes :
emoire dex
ecution
disponible et taille de la file dattente.
Si le placement ne respecte pas les contraintes il sera multipli
e par des p
enalit
es
qui augmenterons sa fitness et diminuera par cons
equent ces chances d
etre choisit
pour le croisement.
Fig. 7.1 Les principales etapes de letude
Fig. 7.2 Fonctionnement de lalgorithme genetique.
Fig. 7.3 Evaluation dun individu appartenant à une population.
150
7.7. Experimentations pour determiner les valeurs des paramètres de lalgorithme
7.6.4
Diagramme de classe de lapplication pour Le GI `

a base du g
en
etique
Les organigrammes vus pr

ec
edemment nous donnent les t
aches principales de
cette partie de tout le GILR et quon a nomm
e S/logiciel GI (Globalment Irrgulier).
Le diagramme suivant nous donne toutes les classes le constituant et dans la section
7.6 on aura plus de d
etails des diff
erents
el
ements
ecrit en langage algorithmique.
Fig. 7.4 Evolution de la fitnesse.
7.7
Exp
erimentations pour d
eterminer les valeurs des param`
etres
de lalgorithme
Nous avons soumis limpl

ementation de lalgorithme g
en
etique d
etaill
ee pr
ec
edemment `
a une s
erie de tests. Ces tests visent principalement `
a la mesure de lefficacit
e de lalgorithme et de la qualit
e des solutions quil fournit. Nous avons effectu
e
des analyses de sensibilit
e relatives aux param`
etres intrins`
eques de lalgorithme g
en
etique, puis mesur
e l
evolution de la performance en fonction des variations de ces
param`
etres.
Les valeurs obtenues pour la configuration de r
ef
erence sont :
Taille de la
Nombre de
Probabilit
e
Probabilit
e
population : 20 chromosomes
g
en
erations : 40
de croisement : 0,8
de mutation : 0,25
Etant donn
e le grand nombre dexp
eriences possibles, nous avons d
ecid
e de ne
faire varier quun seul param`
etre `
a la fois, les autres conservent les valeurs de la
configuration de r
ef
erence.
7.7.1
Evolution du temps dex

ecution en fonction de la taille du probl`
eme
La figure 7.5 pr
esente leffet de la taille du probl`
eme. Nous avons effectu
e six
exp
eriences de tailles diff
erentes : 15, 25,45, 65, 80, 95. On constate quavec une population de 20 chromosomes la convergence devient lente. On a d
eduit `
a partir de
ce tableau quil y a corr
elation entre la taille de la population (nombre de chromosomes) et la taille du probl`
eme. Ceci nous a amen
e`
a d
edier une partie de ce travail
pour d
eterminer les intervalles dans les quels on choisi les tailles des populations
selon la taille du probl`
eme.
151

Fig. 7.5 Influence de la taille du problème sur le temps dexecution.
7.7.2
Effet du nombre de g
en
erations
Nous avons voulu savoir comment se comparent les solutions obtenues `

a la vingti`
eme, et quaranti`
eme g
en
eration. Etudions l
evolution des solutions selon les g
en
erations. La figure ?? trace l
evolution des solutions de la configuration de r
ef
erence
de chaque g
en
eration. Ce test a
et
e r
ep
et
e plusieurs fois et on trace trois s
eries
correspondant `
a ces derniers.
Nous pouvons constater que plus le nombre de g
en
eration est grand plus la solution sam
eliore.
Fig. 7.6 Evolution des solutions en fonctions du nombre de generations.
Dapr`
es la figure 7.6, on serait port
e`
a croire quil nest pas n
ecessaire d
etendre
la recherche au del`
a de 20 g
en
erations. En effet les exp
eriences tendent plut
ot
`
a confirmer quun nombre
elev
e de g
en
erations pourrait produire de meilleures
solutions en termes de fitness, mais ne d
et
eriorera pas la meilleure solution, une
fois trouv
ee.
7.7.3
Effet de la population
La prochaine s
erie dexp
eriences
etudie linfluence du nombre de chromosomes
de la population sur la qualit
e de la solution. Nous avons obtenu des r
esultats pour
des populations de 10 et 60 chromosomes. La figure 7.8Illustre le comportement des
solutions de deux s
eries typiques, avec une population de 10 chromosomes sur une
p
eriode de 40 g
en
erations.
Fig. 7.7 Suivi dune population de 10 chromosomes.
Les r
esultats confirment lhypoth`
ese de leffet quune population de petite taille
va in
evitablement apporter peu de vari
et
e aux chromosomes de la population. La
figure 7.8 indique que la solution optimale a
et
e trouv
ee apr`
es 19 `
a 22 g
en
erations.
152

Fig. 7.8 Suivi dune population de 60 chromosomes.
En comparaison, la figure 7.9 Montre le suivie des r

esultats dune population
de 60 chromosomes sur une p
eriode de 40 g
en
erations. Nous remarquons quil y
a une bonne diversit
e de la population de g
en
eration en g
en
eration ce qui influe
positivement sur la qualit
e de la solution et la rapidit
e de la trouver. La figure 7.9.
Indique que la solution optimale a
et
e trouv
ee apr`
es la premi`
ere g
en
eration.
Les populations de grande taille sont gage de diversit
e de chromosomes, et de
ce fait de diversit
e de solutions dans une m
eme population, ceci dit, dans certains
cas, la meilleure solution pourrait apparatre m
eme dans la population initiale. Une
population de petite taille pourrait tout aussi produire rapidement la meilleure solution, il suffit que des croisements ad
equats se produisent.
Donc pour un utilisateur potentiel de ce logiciel on le conseille dopter pour une
population de 100 chromosomes et 20 g
en
erations. Ces param`
etres sont les plus
utilis
es par la communaut
e des chercheurs dans le domaine [98]. En effet pour les
probl`
emes de grandes tailles en g
en
eral cest des populations de 100 chromosomes
qui sont choisis et cest ce quon a constat
e avec nos r
esultats o`
u souvent avec
des populations de 60 chromosomes et plus on a des solutions de bonnes qualit
es.
Ceci dit, pour des probl`
emes de petites tailles ces param`
etres restent valides et
ne diminuent pas la qualit
e de la solution, n
eanmoins le temps de convergence (ou
de recherche) augmente inutilement. Cest pour cette raison que nous conseillons
lutilisateur dadapter ces param`
etres selon ses probl`
emes.
7.7.4
Influence de la probabilit
e de croisement
Une s
erie dexp
eriences a
et
e r
ealis
ee pour
etudier linfluence des variances de
la probabilit
e de croisement. Nous donnerons les valeurs de probabilit
e suivantes :
0,3 ; 0,6 ; 0,85.
Fig. 7.9 Influence des probabilites de croisement
Nous remarquons quune probabilit

e de croisement autour de 0,85 donne une
grande valeur de fitness donc une solution optimale, cela veut dire que nous retrouvons beaucoup plus de copies intactes de parents jug
es performants.
153
7.7.5
Influence de la probabilit
e de mutation
Lop
erateur de mutation a comme seul but damener une certaine diversit
e, les
tests de variation de ce param`
etre visaient `
a trouver la meilleure valeur de mutation.
Fig. 7.10 Influence des probabilites de mutation
Dapr`
es la figure 7.10 nous constatons que les tests ont affirm
es que la probabilit
e
de 0.05 donne une grande valeur pour la fonction fitness, cest-`
a-dire une solution
meilleure.
7.7.6
Influence de larchitecture sur le co

ut
Pour faire le mapping on doit avoir en entr

ee une application et une architecture.
Cette derni`
ere est constitu
ee dun nombre d
el
ements dex
ecution et des liens physiques qui les lient. La mani`
ere de faire ces liens constitue la topologie du NoC. Les
caract
eristiques des
el
ements dex
ecution sont pris en consid
eration dans le mod`
ele
math
ematique (chapitre 6) et utilis
ees comme entr
ee lors de la saisie du graphe darchitecture. Par contre la mani`
ere avec laquelle ce fait les communications na pas
et
e introduite dans le mod`
ele. A travers lexp
erience suivante on essaye de montrer
linfluence de la topologie sur la convergence de lalgorithme de placement et notamment la qualit
e de la solution. Pour y arriver on a fait ex
ecuter la m
eme application
sur diff
erentes architectures ayant des topologies diff
erentes vues dans le chapitre 1.
Fig. 7.11 Influence de larchitecture sur le temps de recherche
Nous remarquons que toutes les architectures donnent `

a peu pr`
es le m
eme temps
de recherche qui varie entre 481 ms et 590 ms, sauf pour celle de linterconnexion
totale qui a donn
e un temps de 1 s et 111 ms. Nous remarquons aussi que larchitecture en interconnexion totale a donn
e le temps le plus important. La topologie en
maille correspond aux topologies des Mesh-2D. Elle tr`
es utilis
ee dans les syst`
emes
embarqu
es. Dans tous nos mod`
eles on sest bas
e sur elle m
eme si lapplication r
ealis
ee `
a travers son param
etrage permet la prise en consid
eration darchitectures avec
des topologies diff
erentes.
154
7.7.7
Mapping multiobjectif dune application r

eel
Nous avons repris lexemple dune application r

eelle dun d
ecoder vid
eo avec
communication (figure 7.12).
Fig. 7.12 Diagramme de bloc de lapplication
Fig. 7.13 Le graphe de t

ache de lapplication figure 7.12
Les communications ainsi que les volumes d

echanges sont donn
es par la matrice
suivante :
t1
t1
t2
t3
t4
t5
t6
t7
t8
t9
t10
t11
t12
t13
t14
t15
t16
t2
70
t3
t4
t5
t6
t7
t8
t9
t10
t11
t12
t13
t14
t15
t16
27
362
362
49
357
353
300
313
313
500
49
16
16
157
16
16
16
362
Tab. 7.2 matrice des communications inter-t
aches
Larchitecture cible est un Mesh-2D constitu

e de 9 processeurs de deux types
diff
erents. Le premier type un GP, le deuxi`
eme est un FPGA. La topologie est illustr
e par le graphe 7.20 o`
u les valeurs sur les arcs indiquent la vitesse de transmission
dune unit
e de temps et la bande passante du lien correspondant. Les caract
eristiques des processeurs sont donn
ees par le tableau 7.3.
V1 la vitesse des processeurs au mode minimum cest-`
a-dire lent elle correspond
155

Fig. 7.14
au nombre de cycle ex
ecut
es par unit
e de temps, e1
etant l
energie consomm
ee en
unit
e voltage pour lex
ecution dun cycle `
a cette vitesse. V2 et e2 ont les m
emes
d
efinitions mais au mode max des processeurs, cest-`
a-dire le mode rapide. Les
ees
tailles des t
aches sont donn
ees dans le tableau 7.4 suivant. Ces tailles sont mesur
en nombre de cycles selon le type de processeur.
En utilisant le GI on obtient toutes les bonnes solutions v
erifiant les deadlines
obtenues au mode max. Ces placements sont donn
es dans le tableau 7.3 suivant o`
u
la premi`
ere colonne d
esigne les t
aches, les autres colonnes les diff
erents placements
cest-`
a-dire les processeurs auxquels ces t
aches sont affect
ees. Lavant derni`
ere ligne
nous donne les co
uts dex
ecution en unit
e de temps (ut) correspondants aux diff
erents placements.
Le deadline de cette application est de 18000 ut, donc des meilleures solutions
donn
ees dans le tableau 7.5 on d
egage lensemble S des solutions v
erifiant le deadline.
0
S = {pla2 , pla3 , pla4 , pla6 , pla7 , pla9 , pla10 , pla11 , pla12 }
On constate que pour le moment le meilleur en temps dex
ecution cest le placement 10, il est aussi le plus co
uteux en terme de consommation d
energie. Le tableau
suivant illustre le placement et lordonnancement obtenu pour le Placement 10. Le
scheduling des autres placements sobtient de la m
eme mani`
ere.
Lordonnancement est obtenu par liste LS. Le temps de fin de lapplication selon
ce placement est
egal au temps de fin de la derni`
ere t
ache, Tf in =Tf in (T11)= 1583,99
ut. Le temps dex
ecution de lapplication est
egal au temps de fin de la derni`
ere
t
ache moins le temps de d
ebut de la premi`
ere t
ache dans lex
ecution. Pour simplifier les calculs on a pris comme temps de d
ebut linstant Tdebut (T1)=t0 =0 alors
D=Tdebut (T1)-Tf in (T11)= 1583,99.
Fig. 7.15 explicitant le placement et lordonnancement des differentes taches
Dans la deuxi`
eme phase de ce mapping objectif on essaye, pour les placements
de lensemble S, de ralentir les processeurs afin de minimiser l
energie de tout en
respectant les deadlines. Ceci va nous permettre de ne garder que les solutions non
domin
ees finales qui vont nous donner le front Pareto optimal. Le tableau suivant
r
ecapitule les solutions non domin
ees constituant le front Pareto.
156
p1
P2
P3
P4
P5
P6
P7
P8
P9
Type
de processeurs
1
1
2
1
1
2
2
2
1
v1
v2
200
100
650
20
150
650
350
400
200
400
200
850
450
250
950
650
800
300
e1
en 103
5
3
8
5
4
8
6
8
5
e2
en 103
7,5
4,5
12
7,5
6,5
13
9
12
7,5
Tab. 7.3 matrcice des carateristiques de la machine
Tache
t1
t2
t3
t4
t5
t6
t7
t8
t9
t10
t11
t12
t13
t14
t15
t16
Nbr de cycle selon

processeur type 1
14000
30000
24000
30000
14000
25000
32000
45000
17000
17000
25000
14000
32000
24000
17000
30000
Nbr de cycle selon

processeur type 1
1900
36000
16000
36000
19000
15000
18000
32000
19000
19000
15000
19000
18000
16000
19000
36000
Tab. 7.4 Les tailles des t

aches selon le type du processeur
157
pla6
p1
p2
p3
p1
p6
p5
p8
p7
p3
p3
p5
p6
p2
p9
p4
p1
pla7
p6
p4
p3
p9
p6
p5
p1
p7
p2
p3
p5
p6
p2
p7
p4
p2
pla8
p3
p4
p3
p6
p9
p1
p1
p2
p5
p8
p4
p3
p1
p7
p9
p2
pla9
p3
p6
p9
p6
p5
p1
p4
p2
p4
p8
p7
p3
p4
p7
p9
p2
1759,64
1764,06
1876,68
1763,15
1583.99
1715
1715
2998
2920
3106
3198
3465
3238
2953
1693,29
3190
pla5
p4
p2
p2
p1
p6
p5
p4
p7
p3
p2
p5
p6
p9
p9
p4
p2
1843,70
1775,4
3164
pla4
p8
p1
p2
p1
p3
p8
p4
p7
p1
p2
p5
p6
p3
p9
p4
p2
2793
pla3
p8
p4
p3
p1
p3
p8
p4
p6
p2
p2
p5
p7
p9
p9
p4
p8
1689
pla2
p6
p2
p3
p1
p3
p8
p6
p5
p4
p2
p1
p7
p2
p1
p4
p8
2937
pla1
p9
p2
p9
p5
p3
p8
p6
p4
p4
p2
p1
p1
p2
p1
p4
p8
1913.9
10 3 mv dexecution
energie en Co
ut
Tache
t1
t2
t3
t4
t5
t6
t7
t8
t9
t10
t11
t12
t13
t14
t15
t16
2962
pla10
p8
p7
p9
p6
p5
p1
p4
p3
p4
p8
p7
p6
p4
p7
p9
p4
pla11
p1
p7
p9
p6
p5
p4
p4
p3
p4
p8
p7
p4
p4
p7
p9
p1
pla12
p1
p2
p9
p6
p5
p1
p2
p3
p4
p8
p7
p4
p3
p7
p9
p1
Tab. 7.5 Les meilleurs placements
158

(ex
ecution,
energie)={(1913,2926),(1775.14,3164),(1689,2937),
(1843.70,2793),(1759.64,2998),(1764.04,2920),(1876.68,3106),(1763.15,3198),
(1583.99,3465),(1715,3238),(1751,2953),(1696.62,2876),(1714.11,2804),
(1723.34,2811),(1775,2590),(1838.31,2527),(1706.85,2811),(1842.96,2688)}.
Linterpr
etation graphique de ces solutions est illustr
ee par le graphe 7.16.
Fig. 7.16 Front Pareto des solutions de ce problème
159
7.8. Lalgorithme exact pour les applications DSP (LR)
7.8
Lalgorithme exact pour les applications DSP (LR)
Comme on la avanc
e dans le chapitre pr
ec
edent, le mapping des t
aches r
ep
etitives (LR) sur des architectures r
eguli`
eres se traite par une approche diff
erente.
Cet algorithme est bas

e sur une m
ethode exacte qui est inspir
e du brand and
bound hybrid
ee avec une autre m
ethode doptimisation des communications analogue `
a celle utilis
e dans le GI.
160

Ici, aussi, on a essay
e de travailler dans le m
eme environnement de d
eveloppement pour avoir, `
a la fin, un produit enti`
erement int
egr
e. La mod
elisation par UML
et sa translation dans notre contexte de d
eveloppement a donn
e lieu `
a un ensemble
de classes dont celle pr
esent
ee ci-apr`
es constitue un exemple.
7.8.1
R
esultats
Cet algorithme a
et
e
elabor
e pour les t
aches r
ep
etitives afin de pouvoir trouver
un motif selon la sp
ecification dArray-Ol pr
esent
e dans le chapitre 3. Donc le but
est de trouver un sous ensemble de t
aches qui peuvent sex
ecuter en exploitant
dune fa
con optimale les ressources. Cet ensemble de t
aches va
etre r
ep
et
e jusqu`
a
ex
ecution de toutes les autres t
aches. Mais avant de chercher ces r
esultats, on a
essay
e de valider nos r
esultats par rapport `
a dautres outils qui font r
ef
erence dans
cette probl
ematique. Le premier outil est Syndex, d
evelopp
e sp
ecialement pour les
calculs vectoriels de grandes tailles. Le deuxi`
eme outil est celui d
evelopp
e par Menna
au sein de l
equipe west et qui donne lui aussi de bons r
esultats. Donc on a ex
ecut
e
notre algorithme pour des applications `
a t
aches r
ep
etitives sur des architectures de
16, 64, 256 et 1024 processeurs. Ces r
esultats sont compar
es, `
a ceux obtenus par les
deux outils cit
es auparavant, dans le tableau 7.7 suivant.
Les exp
eriences suivantes nous ont permis de trouver le motif ayant le meilleur
AAS. La figure 7.17 illustre le placement de 12 t
aches r
ep
etitives ainsi que leurs
communications sur 5 processeurs. Ce m
eme profil est r
ep
et
e pour ex
ecuter toutes
les autres t
aches. Ce placement est optimal car il minimise le temps de repos (slack)
des processeurs en permettant par l`
a dexploiter au maximum les ressources disponibles sur une longue dur
ee
Nous constatons que nos r
esultats ne sont toujours meilleurs par rapport aux
autres outils (Syndex et Hashesh). Syndex est un outil tr`
es puissant et il est consid
er
e comme un standard pour ce type dapplication. N
eanmoins, ces deux outils ne
prennent pas en consid
eration les modes diff
erents des
el
ements dex
ecution et de
communication. Cest ce qui constitue un plus et un avantage dans notre application
LR.
Fig. 7.17 Recherche du meilleur motif
161
Placement
tache processeur
t1
p8
t2
p7
t3
p9
t4
p6
t5
p5
t6
p1
t7
p4
t8
p3
t9
p4
t10
p8
t11
p7
t12
p6
t13
p4
t14
p7
t15
p9
t16
p4
Co
ut
execution
23.75
55.38
80.00
37.89
56.00
62.50
71.11
37.65
37.78
23.75
23.08
20.00
71.11
24.62
56.67
66.67
Co
ut
comm
17.50
0.00
181.00
120.67
119.00
117.67
117.67
100.00
52.17
99.00
88.25
3.20
0.00
4.00
5.33
120.67
Co
ut
total
41.25
55.38
261.00
158.56
175.00
180.17
188.78
137.65
89.94
122.75
111.33
23.20
71.11
28.62
62.00
187.33
Ordonnancement
Tdebut
Tf in
0.00
41.25
41.25
96.63
96.63
357.63
357.63
516.20
516.20
691.20
691.20
871.36
871.36 1060.14
1060.14 1197.97
1197.97 1287.73
1287.73 1410.48
1410.48 1583.99
1287.73 1310.93
1310.93 1382.04
1382.04 1410.66
1410.66 1472.66
516.20
703.53
Tab. 7.6 Placement et ordonnancement
Taille
Matrice
4*4=16
8*8=64
16*16=256
32*32=1024
SynDex (unite de temps)

Flatten
Non Flatten
40
78
98
288
303
1062
1176
4166
Menna
LR
26
74
266
1034
32
56
126
2100
Tab. 7.7 Resultats comparatifs entre notre approche, Syndex et Menna
162
7.9. La methode pour le hierarchique (ou le GILR)
7.9
La m
ethode pour le hi
erarchique (ou le GILR)
Nous avons d
evelopp
e une application qui permet de calculer le r
esultat de placement optimal dun ensemble de t
aches hi
erarchiques sur une application hi
erarchique. Loutil d
evelopp
e permet dintroduire deux graphes hi
erarchiques (figure
7.18). Le premier mod
elise lapplication, le second mod
elise larchitecture. Ces deux
graphes sont compos
es de noeuds appartenant `
a un des trois types de nud d
efinis
dans le chapitre3 : les nuds simples, compos
es ou r
ep
etitifs. Dans le chapitre pr
ec
edent on a pr
esent
e notre d
emarche pour le GILR. Donc dans cette application les
deux r
esultas des deux logiciels ( GI et LR) pr
esent
es pr
ec
edemment sont utilis
es
comme entr
ee `
a chaque appel selon le traitement de nuds r
ep
etitifs ou compos
es.
Lintroduction de ce graphe se fait par une matrice dincidence sommet-sommet, `
a
cause des d
ependances et communications entre les t
aches.
Fig. 7.18
Les diff
erents composants de cet outil sont illustr
es par le diagramme de classe
de la figure 7.19.
Fig. 7.19 Recherche du meilleur motif
7.9.1
Descriptif de lapplication
Nous allons pr
esenter linterface de notre application. Dans la premi`
ere fen
etre,
on trouve deux zones textuelles o`
u on peut introduire le nombre de t
aches et le
nombre des SoCs.
Fig. 7.20 la fenetre principale
163

Fig. 7.21 Saisie dun graphe hierarchique
Fig. 7.22 saisie dune architecture hierarchique
7.9.2
Etude de cas et validation exp

erimentale
Nous allons, ici, expos

e une
etude de cas `
a laide dun exemple plus complet,
et ainsi valider de mani`
ere exp
erimentale les diff
erentes contributions et leurs int
egrations dans le processus complet. Le mod`
ele de SoC quon va pr
esenter est un
encodeur vid
eo H.263 plac
e sur une architecture multiprocesseur.
7.9.3
Application encodeur H.263 sur MPSoC
Nous avons choisi cette application car elle est typique des applications vis
ees
par Gaspard : Cest une application gourmande en puissance de calcul effectuant
un traitement dimage. Le standard H.263 [ref 28 peil] permet de compresser un
flux vid
eo. Il a
et
e d
evelopp
e pour la transmission de la vid
eo sur des lignes `
a tr`
es
bas d
ebits pour les applications de visiophonie, les syst`
emes de surveillance sans fil,
etc tel que chaque image de la vid
eo est trait
ee s
epar
ement. Limpl
ementation que
nous visons convertit une vid
eo au format QCIF dans le format compress
e H.263.
Lapplication est compos
ee de trois t
aches ex
ecut
ees s
equentiellement :
La transform
ee en cosinus discr`
ete (DCT, pour Discrete Cosine Transform)
permet d
eliminer la redondance de donn
ees et de transformer les donn
ees du
domaine spatial en une repr
esentation fr
equentielle
La quantification consiste `
a diviser chaque coefficient de la DCT par un pas
de quantification et mettre les coefficients non significatifs `
a z
ero.
Le codage permet dencoder les macro-blocs trait
es en attribuant `
a chaque
coefficient DCT quantifi
e un mot binaire dont la longueur est dautant plus
courte que le coefficient est fr
equent. La m
ethode de codage utilis
ee est celle
de Huffman [56 piel].
Et enfin la dernière fenetre permet de donner le resultat du placement final represente par un
arbre hierarchique dont chaque nud contient une matrice de placement qui est dans longlet à
droite.
Fig. 7.23 saisie dune architecture hierarchique
164

La taille dune image dune s
equence QCIF est de 176x144 pixels. Dans lalgorithme dencodage, les donn
ees manipul
ees sont structur
ees sous forme de macroblocs qui repr
esentent un espace de 16x16 pixels dune image vid
eo. Le format de
donn
ees du macro-bloc est le YCbCr qui contient trois composantes : luminance
(Y), chrominance bleu (Cb), et chrominance rouge (Cr). Les blocs de luminance
d
ecrivent lintensit
e des pixels tandis que les blocs de chrominance contiennent des
informations sur les couleurs des pixels. La couleur verte nest pas explicitement
cod
ee, elle peut
etre d
eriv
ee `
a partir des valeurs des trois composantes. Un macrobloc contient 6 blocs de 8x8 valeurs : 4 blocs contiennent les valeurs de la luminance,
un bloc contient les valeurs de la chrominance bleu et un bloc contient les valeurs
de la chrominance rouge.
La figure 7.24 pr
esente lalgorithme tel quil a
et
e mod
elis
e`
a laide du profil Gaspard. On peut voir chaque niveau de hi
erarchie en parcourant le mod`
ele de haut
en bas. VideoSequence est le composant de base, il contient juste une r
ep
etition
de 400 QCIF2H263. Cela permet de traiter 400 images dune vid
eo. Ce nombre
correspond `
a la s
equence vid
eo de r
ef
erence que nous utilisons pour les simulations.
Pour la g
en
eration finale du SoC le concepteur placerait l`
a une r
ep
etition infinie
(repr
esent
ee par le caract`
ere
). Comme `
a chaque fois pour les t
aches de base,
elle ne contient aucun port,
etant donn
e quelle ne n
ecessite pas d
etre connect
ee `
a
dautres t
aches : les entr
ees et sortie se font via des sous t
aches d
edi
ees.
QCIF2H263 est le composant qui traite une image, il est compos
e de trois sous
t
aches. La t
ache QCIFReader se charge de lire une s
equence vid
eo au format QCIF
et produit trois tableaux, chacun correspondant `
a une composante YCbCr. Dans
le cadre de la simulation, nous d
eploierons cette t
ache sur une fonction lisant un
fichier, mais dans la r
ealit
e cette t
ache sera charg
ee de lacquisition des donn
ees
depuis une cam
era. Quant `
a la t
ache CompressFileSave, elle se charge de sauvegarder le flux compress
e. Le format utilis
e est choisi pour accommoder la restriction
pos
ee par le mod`
ele de calcul : il oblige `
a connatre `
a lavance toutes les tailles des
tableaux de donn
ees. Les donn
ees sont transmises via un tableau dont la premi`
ere
dimension est de 384
el
ements, tandis quun second tableau sp
ecifie le nombre r
eel
d
el
ements utilis
es (si la compression a
et
e efficace, largement inf
erieur `
a 384). 384
correspond `
a la taille maximale d
el
ements que peut g
en
erer lencodeur `
a partir
dun macro-bloc (8x8x6).
Entre ces deux t
aches la t
ache dencodage H263Encoder est appel
ee. Elle contient
r
eellement tout lalgorithme pour encoder une image. Cest une t
ache r
ep
etitive qui
a pour sous t
ache H263MacroBlock. La r
ep
etition consiste `
a travailler sur chacun
des 11x9 macro-blocs composant limage. Comme on peut le voir par la taille des
ports dentr
ee de H263MacroBlock, un macro-bloc correspond `
a 16x16 pixels de la
165

luminance et 8x8 pixels des chrominances. La d
ecoupe de limage dentr
ee se fait
`
a laide des Tilers. Par Exemple, le Tiler pour la chrominance bleu a un ajustage
de ((1,0), (0,1)) indiquant une tuile compacte : lorsque lon avance dun
el
ement
dans la premi`
ere dimension du motif, on avance
egalement dun
el
ement dans la
premi`
ere dimension du tableau et lorsque lon avance dun
el
ement dans la seconde
dimension du motif, on avance dun
el
ement dans la seconde dimension du tableau.
Fig. 7.24 Vue principale de limplementation de lencodeur H.263 en mode Gaspard.
Le pavage est de ((8,0),(0,8)) : pour lire le motif suivant dans la premi`

ere dimension de la r
ep
etition il faudra se d
ecaler de 8 pixels dans la premi`
ere dimension du
tableau, de m
eme pour la seconde dimension. Cela est illustr
e dans la figure 7.25.
Les motifs ayant une taille de 8x8, les tuiles dans le tableau sont bord `
a bord. Enfin,
lespace de r
ep
etition est de 11x9, on va donc lire lensemble des 88x72
el
ements du
tableau.
Fig. 7.25 Vue partielle du tableau des elements de chrominance. Chaque lecteur de motif
correspond à une tuile compacte de 8x8 elements du tableau. Ici sont representes les elements
lus pour trois repetitions de tache differentes.
Pour l
ecriture du flot compress
e, les deux dimensions de lespace de r
ep
etitions
sont lin
earis
ees. Ainsi le Tiler entre les ports size a un pavage de ((1),(11)) indiquant
que pour la premi`
ere dimensio de la r
ep
etition il faut placer chacun des 11
el
ements
lus les uns apr`
es les autres et que pour la seconde dimension de la r
ep
etition il faut
se d
ecaler de 11
el
ements `
a chaque fois,
ecrivant ainsi chaque bloc de 11
el
ements
lun apr`
es lautre.
Le composant H263MacroBlock correspond `
a lalgorithme tel que nous lavons
d
ecris plis haut : un appel `
a la DCT (Dct2MacroBlock), puis `
a la quantification
(Quan2MacroBlock), et au codage (Coding). Cette derni`
ere t
ache est une t
ache
el
ementaire, nous lavons d
eploy
e sur un adaptateur appelant une fonction de code
de Huffman
Le composant Dct2MacroBlock se charge dappeler pour chaque bloc de 8x8
el
ements la t
ache
el
ementaire Dct2Block qui effectue une DCT bi-dimensionnelle.
Ainsi, pour traiter la luminance, des Tilers permettent de d
ecouper le bloc de 16x16
en quatre motifs puis de reconstituer le bloc complet. Similairement, le composant
166

Quan2MacroBlock appelle pour chaque bloc de 8x8
el
ements la t
ache
el
ementaire
Quan2Block qui effectue une quantification.
Les fonctions auxquelles correspondent les t
aches
el
ementaires n
etant pas disponibles dans une biblioth`
eque de composants (telle GaspardLib), nous avons d
ecrit enti`
erement le d
eploiement de chaque t
ache
el
ementaire directement dans le
mod`
ele. La figure 7.26 pr
esente une partie du d
eploiement des t
aches
el
ementaires. Quan2Block est d
eploy
ee sur limpl
ementation abstraite quantization, qui
ne contient quune seule impl
ementation dIP : quantization-c. Cette impl
ementation utilise un fichier (quantization.c) et fait appel `
a la fonction quant 2d().
Le type des ports de limpl
ementation d
efini le type des donn
ees trait
ees, il
est unsignedchar pour lentr
ee comme pour la sortie. Remarquons que ce type de
donn
ees est
el
ement explicite du mod`
ele, on retrouve sa d
efinition comme type
primitive en bas `
a droite dans la figure. Enfin, il faut
egalement noter que la d
ependance ImplementedBy porte deux sp
ecialisations : X SIZE et Y SIZE. Elles sont
utilis
ees par la quant 2d() pour connatre la taille des tableaux de donn
ee, elle peut
etre adapt
ee `
a nimporte quelle taille de donn
ees. La caract
eristique executionTime
qui permettra `
a la simulation PA de simuler le temps de traitement a
et
e mesur
ee
manuellement dans une simulation du processeur au niveau CABA.
Similairement, la t
ache
el
ementaire QCIF correspond `
a une taille dimage sp
ecifique de 176x144 pixels, limpl
ementation dIP contenue, qcif-from-file-c ne permet
pas au concepteur de sp
ecifier la taille des donn
ees quelle g
en`
ere : chaque port a
une taille fix
ee.
Fig. 7.26 vue du deploiement des t

aches elementaires Quan2Block et QCIFReader. En bas à
droite est presente le type des donnees traitees par les fonctions : unsigned char.
167
7.9.4
Architecture mat
erielle
Larchitecture mat
erielle mod
elis
ee est relativement simple (figure 7.27). Elle a
pour composant principal HardwArchit. Ce composant est compos
e de deux m
emoires, un r
eseau dinterconnexion et quatre processeurs MIPS. Le r
eseau dinterconnexion est un crossbar mod
elis
e `
a laide de deux ports multiples. Lun de ces
ports est de type In et permet de connecter les composants ayant des ports initiateurs de transaction (tels que les processeurs). En fonction du nombre de composants `
a brancher le concepteur peut faire varier sa multiplicit
e. Similairement,
lautre port est de type Out, auquel on peut connecter les composants ayant des
ports esclaves lors des transactions.
Cest sur ce second port que sont connect
ees les deux m
emoires. Lune des m
emoires est destin
ees aux donn
ees et lautre aux instructions mais m
eme si les noms
choisis sont expliites, vis-`
a-vis du code g
en
er
e ce nest pas dans le mod`
ele darchitecture que cette s
emantique est sp
ecifi
ee, elle sera sp
ecifi
ee lors de lassociation.
Les deux composants sont
el
ementaires, ils sont d
eploy
es sur une impl
ementation
abstraite de RAM disponible dans la biblioth`
eque de composant GaspardLib. Pour
relier ces composants sur un port diff
erent du r
eseau dinterconnexion, nous utilisons deux Reshapes qui indiquent comment distribuer le port dune m
emoire sur le
slave de multiplicit
e 2. Ainsi les deux Reshapes sont pratiquement identiques : ils
s
electionnent le port de la m
emoire gr
ace au Tiler tin puis le lace dans le tableau
du port slave g
ace `
a lautre Tiler. Pour la m
emoire i, lorigine du Tiler est 0, tandis
que pour d lorigine est 1. Les m
emoires sont ainsi connect
ees respectivement au
port slave dindice 0 et 1.
Le composant MultiMips a une interface avec un port de multiplicit
e 4, il est
donc possible de le connecter directement au r
eseau dinterconnexion. Ce composant
est un composant r
ep
etitif : il contient un sous-composant ProcessingUnit r
ep
et
e
quatre fois. Cest ainsi que lon sp
ecifie que larchitecture est quadriprocesseur.
Le composant ProcessingUnit est lui-m
eme compos
e de deux sous-composants. Il
contient un processeur nomm
e mips et un cache nomm
e c qui fait linterface entre
le processeur et lext
erieur de unit
e de calcul.
M
eme si les types des composants
el
ementaires indiquent leur fonction g
en
erique
(processeur, r
eseau de communication, RAM) et que les noms des composants
el
ementaires ont
et
e choisis de mani`
ere `
a refl
eter au mieux la fonctionnalit
e des composants, pour la transformation ils ne signifient rien tant quils nont pas
et
e d
eploy
e
esente le d
eploiement des composants Cache et MIPS. Nous
sur IP. La figure 7.28 pr
avons pu utiliser des IP d
efinis dans la biblioth`
eque GaspardLIb pr
esent
e dans les
chapitres pr
ec
edents. Ainsi, apr`
es importation de cette biblioth`
eque dans le mod`
ele,
Cache a
et
e d
eploy
e sur une impl
ementation abstraite dun cache de 32Ko. MIPS
168

a
et
e d
eploy
e sur une impl
ementation abstraite de processeur MIPS. La caract
eristique selectdFrequency=100 a
et
e ajout
ee afin de choisir la vitesse dex
ecution
du processeur. Notons que dans le cadre de la g
en
eration vers une simulation PA,
limpl
ementation du processeur nest utilile que pour connatre linterface des ports,
les IP ne sont pas utilis
es `
a ce niveau dabstraction.
Fig. 7.27 Vue principale de larchitecture materielle du MPSoC en modèle Gaspard
Fig. 7.28 : Vue du deploiement des composants Cache et MIPS
Le diagramme de lapplication (figure 7.24) nous permet dextraire le graphe de

t
ache hi
erarchique (figure 7.29). On peut faire de m
eme pour le graphe dapplication hi
erarchique `
a partir de la figure 7.28.
Fig. 7.29 Graphe de t

ache hierarchique de lencodeur H.263
Cest un graphe de t
ache hi
erarchique type aux graphes dapplications plac
ees
dans les SoC. En particulier Gaspard prend bien en charge ce type de graphe et
permet de les traiter `
a tous les niveaux de son flot de conception. On remarque que
la t
ache H263mb est une t
ache r
ep
etitive qui se r
ep`
ete 11x9 fois. De m
eme pour
dctlum et quanlum qui se r
ep`
etent 2x2 fois.
On a essay
e, `
a travers cette exp
erimentation de monter la pertinence de traiter
des graphes hi
erarchiques lors dun placement. Les qualit
es des placements ont d
ej`
a
et
e discut
ees pr
ec
edemment pour le GI et le LR. Ce graphe mis `
a plat est constitu
e de 110 t
aches. Le placement de ces t
aches comme un graphe non hi
erarchique
cest-`
a-dire quon a enlev
e lhi
erarchisation a trouv
e la solution dans un temps de
75 ut. Le meilleur placement sur les processeurs, mais cette fois ci en prenant en
consid
eration laspect hi
erarchique de lapplication, a
et
e trouv
e dans un temps de
67ut (figure 7.31).
En essayant de g
en
eraliser pour dautres probl`
emes, on a fait des exp
erimentations sur des applications ayant un nombre de t
aches diff
erents pour des niveaux
diff
erents. Cest-`
a-dire quon a pris une application ayant un nombre de t
aches
egal
`
a 50 par exemple quon a essay
e de placer sur une architecture en consid
erant son
169
7.10. conclusion
Fig. 7.30
Fig. 7.31
HTG dans la premi`

ere phase `
a un seul niveau. Ensuite `
a deux niveaux, etc. On
a proc
ed
e de la m
eme mani`
ere pour les autres applications ayant des nombres de
t
aches diff
erents (tableau 7.8).
Nombre de taches
10
20
30
40
50
Niveau 1
37
64
75
80
86
Niveau 2
32
59
72
75
82
Niveau 3
33
58
69
73
79
Niveau 4
29
54
63
71
73
Tab. 7.8 R : Les evolutions des temps de recherche selon les tailles des applications et le
nombre de niveaux du HTG
Un autre r
esultat quon peut d
eduire suite `
a limpl
ementation de notre approche
est que la hi
erarchisation des applications facilite leurs repr
esentations, mod
elisations et traitements. Quand on est en face dapplications de tr`
es grandes tailles cet
argument est tr`
es important. En plus `
a partir des r
esultats obtenus on a constat
e
que la cherche de solutions est plus rapide quand on a des graphes hi
erarchiques
`
a plusieurs niveaux. Ceci peut sexplique par le fait que le temps de recherche, de
nimporte quel algorithme de placement, est en premi`
ere consid
eration proportionnel `
a la taille de lespace de recherche. En effet plus la taille de lespace de recherche
est grande plus le temps de recherche des solutions est grand. N
eanmoins la hi
erarchisation a des limite, car on a aussi constat
e dun autre cot
e un nombre de niveau
important influe inversement sur le temps de recherche. Donc il faut encore pousser
les exp
erimentations afin de d
eterminer une plage de niveau en fonction des tailles
des probl`
emes dans laquelle lalgorithme est efficace
7.10
conclusion
Ce chapitre on la compl`
etement d
edi
e `
a la mise en ouvre de notre approche.
Notre souci est dexp
erimenter cette approche dans un contexte sp
ecifique qui est
170
7.10. conclusion
Fig. 7.32 evolution des temps de recherche du GILR en fonction de la taille des application
et du nombre de niveau
dans notre cas les NOC. L

equipe DaRT dans la quelle jai men
e ce travail est sp
ecialis
ee dans les flots de conception de ces syst`
eme. Gapard est son produit et notre
travail on a essay
e en premier de le placer dans ce flot. Ce souci ne doit pas aussi
nous
eloigner des autres objectifs que doit atteindre tout travail acad
emique et en
particulier une th`
ese d
etat. Cest dans cet esprit quon a essay
e de faire dautres
exp
erimentations plus larges pour des probl`
emes r
eels divers dans le domaine.
171
Conclusion g
en
erale et perspectives
172
Durant la conception des systèmes informatiques beaucoup de contraintes doivent
etre prises en consid

eration par les concepteurs. Ces contraintes deviennent encore
plus importantes et pertinentes dans les syst`
emes distribu
es et sp
ecialement les
syst`
emes distribu
es embarqu
es (NoC). En effet, dans ces derniers o`
u en parle de
co-modeling pendant la conception ; les contraintes mat
erielles et logicielles ne sont
plus prises s
epar
ement comme dans les syst`
emes traditionnelles mais elles sont
consid
er
ees en m
eme temps. Dans ce type de syst`
eme o`
u on fait du logiciel d
edi
e et
inversement pour le mat
eriel, les deux types de contraintes sont v
erifi
ees en m
eme
temps. Ces derni`
eres, du fait de la nature du syst`
eme, sont diverses. On parle de
contrainte de consommation d
energie, de contrainte temps r
eel, de surface, de m
emoire, etc. Donc pendant la co-conception et surtout lors de la phase de mapping on
doit les prendre en consid
eration. Par mapping on parle dassignation, daffectation
et dordonnancement d
el
ements dapplications sur des
el
ements darchitectures.
Ce probl`
eme est souvent d
esign
e dans la communaut
e par lAAS (Assignation, Affectation et Scheduling). Les contraintes dont on a parl
e ne peuvent
etre trait
ees
s
epar
ement do`
u pour que lAAS soit r
ealiste on doit consid
erer certaines dentre
elles comme des objectifs quon doit atteindre simultan
ement. Cest ce qui rend ce
probl`
eme, un probl`
eme doptimisation combinatoire multi-objectif (MOP).
Plusieurs approches on
et
e propos
ees pour r
esoudre ce probl`
eme (lASS), mais
la plupart lont trait
e comme un SOP, cest `
a dire un probl`
eme `
a un seul objectif.
Donc notre premi`
ere contribution se situe `
a ce niveau en essayant de traiter le probl`
eme de mapping dans les NoC Comme un MOP et non pas comme un SOP. Dans
notre travail on a plut
ot trait
e deux objectifs et des contraintes mais qui peut
etre
facilement
etendu `
a plusieurs objectifs. Pour cette d
emarche et `
a cause de la nature
du probl`
eme on a propos
e un algorithme hybride. Une partie de lalgorithme se base
sur une m
ethode
evolutionnaire pour la recherche de solutions acceptables en trouvant lensemble du front Pareto. Le choix de cette m
ethode est surtout du, dune
part `
a proposer une solution pour des probl`
emes de grandes tailles, et dautre part,
avoir une d
emarche multi-objectif. Lautre partie de lalgorithme est bas
ee sur une
heuristique doptimisation des communications. Cette derni`
ere est tr`
es importante
car delle d
epend en partie la qualit
e de la solution. Dans un NoC, o`
u les chemins
de communication peuvent varier, la recherche du chemin permettant doptimiser, et la latence, et l
energie consomm
ee durant le transfert des donn
ees ne peut
quam
eliorer sensiblement et qualitativement la solution finale. Limpl
ementation
des algorithmes propos
es a
et
e faite dans un environnement bas
e sur lapproche
IDM permettant linterop
erabilit
e des IP logiciels. Les r
esultats obtenus peuvent
etre consid
er
es satisfaisants et qui peuvent
etre am
elior
es surtout sur le volet du
temps de convergence en essayant avec dautres travaux de bien cerner les param`
etres des algorithmes propos
es, notamment lalgorithme
evolutionnaire. On peut
aussi essayer de revoir les algorithmes propos
es pour plus doptimalit
e et les rendre
173
plus efficaces.
Une autre partie tr`
es importante de notre travail consistait `
a proposer une solution
pour le mapping des applications DSP sur des architectures r
eguli`
eres. Ce probl`
eme
ne peut
etre trait
e de la m
eme mani`
ere que celui pr
ec
edemment
evoqu
e m
eme si
on doit consid
erer les m
emes objectifs et les m
eme contraintes. Tel que on les a vu
dans le chapitre 3, les applications DSP quon a pr
esent
e avec le langage Array-ol
pr
esentent une sp
ecificit
e particuli`
ere. Elles traitent de grande quantit
e de donn
ees
mais de la m
eme mani`
ere, cest-`
a-dire quil y a r
ep
etition dans les calculs. Donc
m
eme si la taille des donn
ees est importante, lespace de d
ecision est r
eduit. Cest
ce quon a exploit
e en proposant une m
ethode exacte qui nous permet datteindre
plusieurs objectifs `
a optimiser. Le motif trouv
e est constitu
e dun nombre r
eduit de
t
aches qui ex
ecutent des donn
ees diff
erentes et dont on r
eit`
ere lex
ecution `
a linfini
sans que ceci naugmente la complexit
e de la m
ethode.
Le dernier volet de notre travail et qui constitue une contribution tr`
es importante par son originalit
e, car il na jamais
et
e trait
e par les chercheurs travaillant
dans ce domaine, consiste `
a faire le mapping des applications hi
erarchiques. Ce probl`
eme consiste `
a placer une application hi
erarchis
ee sur une architecture ayant la
m
eme structuration. Cest ce quon appelle le GILR (Globalement Irr
egulier Localement R
egulier). La d
emarche propos
ee et apr`
es exp
erimentation nous a permis
de constater que la hi
erarchisation des applications et des architectures permet de
r
eduire consid
erablement la complexit
e.
Ces r
esultats obtenus, ne doivent pas nous emp
echer de faire dautres exp
erimentations pour plus de validation et de prospecter dautres perspectives. En effet,
on consid`
ere quon est quau d
ebut de la r
esolution de ce probl`
eme, et par cons
equent on est sure que certains sous probl`
emes du GILR peuvent
etre approch
es et
solutionn
es autrement. Cest ce qui va constituer lobjet dautres travaux dans cet
axe.
174
Bibliographie
[1] PhD thesis.
[2] S. Edwards N. Halbwachs P.L. Guernic A. Benveniste, P. Caspi and R.de Simone. The synchronous language twelve years later. In Procs. of the IEEE,
volume 91, pages 6483, jan 2003.
[3] P.Eles Z.Peng A.Andrei, M.Schmitz and B.M.Al-Hashimi. Overhead-conscious
voltage selection for dynamic and leakage energy reduction of time-constrained
systems. Design, Automation and Test in Europe Conference and Exhibition,
1 :10518, 2004.
[4] A.Baghdadi. Lexploitation est conception syst
ematique darchitecture multiprocesseurs monopuces d
edi
ees `
a des applications sp
ecifiques. PhD thesis,
Institut TELECOM France, 2002.
[5] P.Marquet A.Cuccuru, JL.Dekeyser and P.Boulet1.
[6] A.Geoffrion. Proper efficiency and theory of vector maximization. Journal of
Mathematical Analysis and Applications, 22 :618630, 1968.
[7] AH.Benyamina and P.Boulet. Multi-objective mapping for noc architectures.
Journal of Digital Information Management (JDIM), 5(6) :378384, December
2007.
[8] Abdelkader Amar, Pierre Boulet, and Philippe Dumont. Projection of the
Array-OL specification language onto the kahn process network computation
model. In International Symposium on Parallel Architectures, Algorithms, and
Networks, Las Vegas, Nevada, USA, December 2005.
[9] J.Haddock A.Nagar and S.Heragu. Multiple and bicriteria scheduling : A literature survey. European Journal of Operational Research, 81(1) :88104,
February 1995.
[10] Arteris. Enabling network-on-chip for soc design. In http :
WWW.arteris.net/document, page 28. Arteris-background, 2004.
[11] Pierre Boulet. Contributions aux environnements de programmation pour le
calcul intensif. Technical report, Univeit
e des Sciences et Technologies de Lille,
December 2002.
175
BIBLIOGRAPHIE
[12] Robert L. Carraway, Thomas L. Morin, and Herbert Moskowitz. Generalized
dynamic programming for multicriteria optimization. European Journal of
Operational Research, 44(1) :95104, January 1990.
[13] C.Coello and A.Carlos. A comprehensive survey of evolutionary-based multiobjective optimization techniques. In Knowledge and Information Systems,
volume 1, pages 269308, 2004.
[14] Eclipse Consortium. Emf, 2007. http ://www.eclipse.org/emf.
[15] Radu Cornea, Shivajit Mohapatra, Nikil Dutt, Alex Nicolau, and Nalini Venkatasubramanian. Power-aware multimedia streaming in heterogeneous multiuser environments. In Concurrent Information Processing and Computing Advanced Research Workshop, Sinaia, Romania, July 5-10 2003.
[16] COSI. Uprojet inria-cnrs. http ://www.irisa.fr/Cosi/Alpha.
[17] Alain Demeure and Yannick Del Gallio. An array approach for signal processing
design. In In Sophia-Antipolis Conference on Micro-Electronics (SAME 98),
France, October 1998.
[18] Alain Demeure, Anne Lafarge, Emmanuel Boutillon, Didier Rozzonelli, JeanClaude Dufourd, and Jean-Louis Marro. Array-OL : Proposition dun formalisme tableau pourle traitement de signal multi-dimensionnel. In Gretsi,
Juan-Les-Pins, France, September 1995.
[19] D.J.White. The set of efficient solutions for multiple-objectives shortest path
problems. Computers and Operations Research, 9 :101107, 1982.
[20] D.Lyonnard. Approche dassemblage syst
ematique d
el
ements dinterface pour
la g
en
eration darchitecture multiprocesseur. th`
ese de doctorat, Institut national Polytechnique de Grenoble, Grenoble, 2003.
[21] D.Shin and J.Kim. Power-aware communication optimization for networks-onchips with voltage scalable links. In CODES+ISSS 04 : Proceedings of the
2nd IEEE/ACM/IFIP international conference on Hardware/software codesign and system synthesis, pages 170175, New York, NY, USA, 2004. ACM.
[22] D.Veldhuizen and G.B.Lamont. Multiobjective evolutionary algorithm test
suites. In SAC, pages 351357, 1999.
[23] EETIMES.RONW. Is soc really different ? Technical report, EETIMES, 1999.
[24] E.L.Ulungu and J.Teghem. Multi-objective combinatorial optimization problems : A survey. JMCDA, 3 :83104, 1994.
[25] Wikipedia. Informatique embarqu
e. informatique embarqu
e. Technical report,
Wikip
edia lencyclop
edie libre, 2005.
[26] S.Krichen F.BenAbdelaziz and J.Chaouchi. Meta-heuristics : Advances and
trends in local search paradigms for optimization, chapter A hybrid heuristic
for multi-objective knapsack problems. Kluwer Academic Publishers, 1999.
176
BIBLIOGRAPHIE
[27] LensS F.Gruian, K.Kuchcinski. Task Scheduling for Lower-energy Systems
Using Variable Supply Voltage Processors. ASP-DAC, 2001.
[28] Michael P. Fourman. Compaction of symbolic layout using genetic algorithms.
In Proceedings of the 1st International Conference on Genetic Algorithms,
pages 141153, Hillsdale, NJ, USA, 1985. L. Erlbaum Associates Inc.
[29] F.Y.Edgeworth. Mathematical physics. P.Keagn, 1981.
[30] Abdoulaye Gamati
e, Eric Rutten, Huafeng Yu, Pierre Boulet, and Jean-Luc
Dekeyser. Synchronous modeling of data intensive applications. Technical
Report INRIA RR-5876, Laboratoire dInformatique Fondamentale de Lille,
April 2006.
[31] Object Management Group. Uml2 infrastructure (final adopted specification).
[32] Object Management Group. Mof qvt final adopted specification.omg document
final. IBM systems journal, 2005. http ://www.omg.org/docs/ptc/05-11-01pdf.
[33] Object
Management
Group.
(uml)
profile
for
schedulabity,
performance,
and
time,
January
2005.
http ://www.omg.org/technology/documents/formal/schedulability.htm.
[34] Paul Le Guernic, Paul Le Guernic, Jean pierre Talpin, Jean pierre Talpin, Jean
christophe Le Lann, Jean christophe Le Lann, and Projet Espresso. Polychrony
for system design. Journal of Circuits, Systems and Computers. World Scientific, 12, 2003.
[35] R.Marculescu G.Varatkar. Communication, complexity and criticaly issue in
designing silicon networks. In Date, 2006.
[36] G.Zhou and M.Gen. Genetic algorithm approach on multi-criteria minimum spanning tree problem. European Journal of Operational Research,
114(1) :141152, April 1999.
[37] C.Wu H.Chou and J.Lee. Integrated mapping and scheduling for circuitswitched network-on-chip architectures. Electronic Design, Test and Applications, IEEE International Workshop on, 0 :415420, 2008.
[38] R.Colletti H.Tardieu, A.Rochfeld and G.Panet. La methode Merise : Principes
et outils. Editions dorganisation, 1991.
[39] M. Sheets A. Mihal K. Keutzer S. Malik J. Rabaey, M. Sgroi and
A. Sangiovanni-vincentelli. Addressing the system-on-a-chip interconnect woes
through communication-based design. In In Proc. Design Automation Conference, pages 667672, 2001.
[40] J.B
ezivin. On the unification power of models. Software and System Modeling
(SoSym), 4(2) :171188, mai 2005.
[41] J.Hu and R.Marculescu. Energy-aware communication and task scheduling for
network-on-chip architectures under real-time constraints. Design, Automation
and Test in Europe Conference and Exhibition, 1 :10234, 2004.
177
BIBLIOGRAPHIE
[42] K.Johnson M.Kaashoek J.Jannotti, D.Gifford and J.OToole. Overcast :reliable
multicasting with an overlay network. In Of USENIX OSDI00, pages 197212,
October 2000.
[43] G. Lakshminarayana K. Lahiri, A. Raghunathan and S. Dey. Communication
architecture tuners : A methodology for the design of high-performance communication architectures for system-on-chips. In Design Automation Conf,
pages 513518, June 2000.
[44] Richard M. Karp, Raymond E. Miller, and Shmuel Winograd. The organization
of computations for uniform recurrence equations. J. ACM, 14(3) :563590,
July 1967.
[45] P.Eles L.A.Cortes and Z.Peng. Static scheduling of monoprocessor real-time
systems composed of hard and soft tasks. Electronic Design, Test and Applications, IEEE International Workshop on, 0 :115, 2004.
[46] P.Eles L.A.Cortes and Z.Peng. Quasi-static scheduling for multiprocessor realtime systems with hard and soft tasks. Real-Time Computing Systems and
Applications, International Workshop on, 0 :422428, 2005.
[47] L.Benini and G.Micheli. Networks on chips : A new soc paradigm. In Computer,
volume 35, pages 7078, Jan 2002.
[48] A.Guerri M.Milano L.Benini, D.Bertozzi. Allocation, Scheduling and Voltage
Scaling on Energy Aware MPSoCs, volume 3990/2006. Heidelberg, 2006.
[49] Edward A. Lee and David G. Messerschmitt. Static scheduling of synchronous
data flow programs for digital signal processing. IEEE Trans. on Computers,
36(1) :2435, January 1987.
[50] Edward A. Lee and David G. Messerschmitt. Synchronous data flow. IEEE,
75 :12351245, September 1987.
[51] L.Fesquet. Integration de sous-systems photoniques dans les architectures de
communications multiporcesseurs. Electronique, Paul Sabatier, Toulous, 1997.
[52] L.Hammond and K.Olukotun. Considerations in the design of hydra : A
multiprocessor-on-a-chip microarchitecture. Computer Systems Lab Technical Report CSL-TR-98-749, Stanford University, February 1998.
[53] WESTTeam LIFL. Graphical array specification for parallel and distributed
computing (gaspard-2), 2005. http ://www.lfl.fr/west/ gaspard.
[54] R. Ho M. A. Horowitz and K. W. Mai. The future of wires. IEEE, 89 :490504,
April 2001.
[55] A.Khademzadeh M.Armin, S.Saeidi and A.Afzali-Kusha. Spiral : A heuristic
mapping algorithm for network on chip. IEICE Electronics Express, 4(15) :478
484, 2007.
[56] M.Ashish. Allocation, Assignation et Ordonnancement pour les syst`
emes sur
multi-processeurs. Docteur en informatique, Universit
e des sciences et technologie de Lille, Lille, France, d
ecembre 2006.
178
BIBLIOGRAPHIE
[57] Christophe Mauras. Alpha : un langage
equationnel pour la conception et la
e
programmation darchitectures parall`
eles synchrones. PhD thesis, Universit
de Rennes I, December 1989.
[58] M.Benes. Design and implementation of communication and switching techniques for the pleiades family of processors. Master of science, University of
California and Berkley, 2000.
[59] M.C.Herbordt. the evaluation of massively parallel array architectures. Technical report M-CS-1995-007, University of Massachusetts Amherst, MA, USA,
USA, 1995.
[60] V.Maniezzo M.Dorigo and A.Colorni. The ant system : Optimization by
a colony of cooperating agents. IEEE Transactions on Systems, Man, and
Cybernetics-Part B, 26 :2941, 1996.
[61] F.Maraninchi M.Moy and L.Maillet-Contoz. Pinapa : an extraction tool for
systemc descriptions of systems-on-a-chip. In Wayne Wolf, editor, EMSOFT,
pages 317324. ACM, 2005.
[62] Projet MopCom. Modeling and specialization of platform and components
mda. http://www.mopcom/doku.php.4.2.
[63] B.M.Al-Hashimi M.T.Schmitz and P.Eles. A co-design methodology for energyefficient multi-mode embedded systems with consideration of mode execution
probabilities. Design, Automation and Test in Europe Conference and Exhibition, 1 :10960, 2003.
[64] B.M.Al-Hashimi M.T.Schmitz and P.Eles. Iterative schedule optimization for
voltage scalable distributed embedded systems. Trans. on Embedded Computing Sys., 3(1) :182217, 2004.
[65] P. K. Murthy and Edward A. Lee. An extension of multidimensional synchronous dataflow to handle arbitrary sampling lattices. In Int. Conf. Acoustics,
Speech, and Signal Processing, pages 33063309, May 1996.
[66] P.K. Murthy and Edward A. Lee. A generalization of multidimensional synchronous dataflow to arbitrary sampling lattices. Technical Report UCB/ERL
M95/59, EECS Department, University of California, Berkeley, March 1995.
[67] Praveen K. Murthy and Edward A. Lee. Multidimensional synchronous dataflow. IEEE Transactions on Signal Processing, July 2002.
[68] M.Zeleny. Multiple criteria problem solving. McGraw- Hill, NewYork, 1982.
[69] P.Blanchfield N.Hallam and G.Kendall. Handling diversity in evolutionary
multiobjective optimization. In Congress on Evolutionary Computation, pages
22332240, 2005.
[70] N.Wocjik. ch
erence et compl
etude des mod`
eles de placement de gaspard2.
Master de recherche, USTL, Lille, France, Juin 2008.
179
BIBLIOGRAPHIE
[71] O.Labbani. Mod
elisation `
a haut niveau du contr
ole dans des applications de
ese de doctorat (phd thetraitement syst
ematique `
a parall
elisme massif. Th`
sis), Universit
e de Lille 1, France, November 2006. Laboratoire dInformatique
Fondamentale de Lille.
[72] Y. B. Park and C. P. Koelling. An interactive computerized algorithm for
multicriteria vehicle routing problems. Comput. Ind. Eng., 16(4) :477490,
1989.
[73] C.Dumoulin P.Boulet, J.Dekeyser and P.Marquet. Mda for system-on-chip
design, intensive signal processing expriment. In I.FDL03, Fankfurt, Germany,
september 2003.
[74] N. Halbwachs andJ. A. Plaice P.Caspi, D. Pilaud. Lustre : a declarative language for real-time programming. In Proceedings of the 14th ACM SIGACTSIGPLAN symposium on Principles of programming languages, pages 178188,
New York, NY, USA, 1987. ACM.
[75] Ivan Doynov Petkov. Conception des bibliographies des syst`
emes multiprocesseurs de la simulation vers la r
ealisation. PhD thesis, Universit
e Joseph
Fourier, janvier 2006.
[76] P.Guerrier and A.Greiner. A generic architecture for on-chip packet-switched
interconnections. In Proceedings of the design automation and Test in Europe
(Date), pages 250256, Paris Franc, 2002.
[77] Ruxandra Pop and Shashi Kumar. A survey of techniques for mapping and
scheduling applications to network on chip systems. In School of Engineering,
J
onk
oping University, ISSN 1404-0018 Research Report 04 :4, Dec 2004.
[78] R.Hartenstein. Coarse grain reconfigurable architecture (embedded tutorial).
In ASP-DAC 01 : Proceedings of the 2001 conference on Asia South Pacific
design automation, volume 5, pages 564570, New York, NY, USA, 2001. ACM
Press.
[79] Tanguy Risset. Contribution `
a la compilation de nids de boucle sur silicium.
Technical report, Universit
e de Rennes1, Octobre 2000.
[80] R.Stever. Multiple Criteria optimization : Theory, computation and Application. Wiley, NewYork, 1986.
[81] R.Szymanek. Memory aware task assignment and scheduling for multiprocessor
embedded systems. Masters thesis, Milan, 2001.
[82] R.Szymanek and K.Kuchcinski. Design space exploration in system level synthesis under memory constraints. EUROMICRO Conference, 1 :1029, 1999.
[83] P. Serafini. Simulated annealing for multiobjective optimization problems. In
Proceedings of the 10th International Conference on Multiple Criteria Decision
Making, Taipei-Taiwan, volume I, pages 8796, 1992.
180
BIBLIOGRAPHIE
[84] S.Kent. Model driven engineering. In Proceedings of the Third International
Conference on Integrated Formal Methods, pages 286 298. Springer-Verlag
London, UK, 2002.
[85] S.Chatha S.Krishnan and G.Konjevod. Linear-programming-based techniques
for synthesis of network-on-chip architectures. IEEE Transaction on very large
scale integration (VLSI) systems, 14(4), April 2006.
[86] J-P.Soininen M.Forsell Millberg J.Oberg K.Tiensyrja A.Hemani S.Kumar,
A.Jantsch. A network on chip architecture and design methodology. In VLSI,
2002. Proceedings. IEEE Computer Society Annual Symposium on, pages 105
112, Washington, DC, USA, April 2002. IEEE Computer Society.
[87] Julien Soula. Principe de compilation dun langage de traitement de signal.
PhD thesis, Laboratoire dInformatique Fondamentale de Lille, Universit
e des
Sciences et Technologies de Lille, December 2001.
[88] S.Sayin and S.Karabati. A bicriteria approach to the two-machine flow shop
scheduling problem. European Journal of Operational Research, 113(2) :435
449, March 1999.
[89] B.S. Stewart and C.C. White. Multiobjective A*. Journal of the Association
for Computing Machinery, 38(4) :775814, 1991.
[90] T.Bjerregaard and S.Mahadevan. A survey of research and practices of
network-on-chip. ACM Computing Surveys, 38(1), 2006.
[91] T.Lei and S. Kumar. A two-step genetic algorithm for mapping task graphs to
a network on chip architecture. In Euromicro Symposium on, editor, Digital
System Design, pages 180 187. 0-7695-2003-0, 2003.
[92] E.L. Ulungu and J. Teghem. The two phases method : An efficient procedure to solve bi-objective combinatorial optimization problems. Foundations
of Computing and Decision Sciences, 20(2) :149165, 1995.
[93] V.Pareto. Cours dEconomie Politique, volume 1-2. Lausane, switzerland, 1896.
[94] A. Warburton. Approximation of pareto optima in multiple-objective, shortestpath problems. Oper. Res., 35(1) :7079, 1987.
[95] W.Hall Y.Haimes and H.Freedman. Y.Haimes, W.Hall, and H.Freedman. Elsevier Scientific Publishing edition, NewYork, 1975.
[96] J.Hu Y.O.Umit and R.Marculescu.
Key research problems in noc design : a holistic perspective. In CODES+ISSS 05 : Proceedings of the 3rd
IEEE/ACM/IFIP international conference on Hardware/software codesign
and system synthesis, pages 6974, New York, NY, USA, 2005. ACM.
[97] Y. Zhang, X. Hu, and D. Chen. Task scheduling and voltage selection for
energy minimization, 2002.
181

Thèse

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Thèse

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE

BENYAMINA Abou Elhassen

Devant les membres du jury

Table des mati`

Liste des tableaux

Motivation et objectifs des syst`emes embarques

Les types de syst`emes embarques

Caracteristiques principales dun syst`eme embarque . . . . . . . . . . . .

Les differentes architectures des differents syst`emes embarques . . . . . . . . . .

Les multiprocesseurs on SOC (MPSOC) . . . . . . . . . . . . . . . . . . .

Les NOC (Network On Chip) . . . . . . . . . . . . . . . . . . . . . . . . .

Architecture reguli`ere `a base de tableau de processeurs identiques . . . .

Linterconnexion dans les SOC . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Le Bus centralise ou partage : . . . . . . . . . . . . . . . . . . . . . . . . .

Les reseaux en etoile et en anneau : . . . . . . . . . . . . . . . . . . . . .

Les reseaux Crossbar

Les reseaux commutes ou `a maille : . . . . . . . . . . . . . . . . . . . . . .

LIngenierie Dirigee par les Mod`eles (IDM)

Model Driven Architecture MDA . . . . . . . . . . . . . . . . . . . . . . . . . . .

Extensibilite dUML : la notion de profil . . . . . . . . . . . . . . . . . . .

GASPARD : Flot de conception pour les SOC . . . . . . . . . . . . . . . . . . . .

Modelisation des applications DSP . . . . . . . . . . . . . . . . . . . . . .

Principe de modelisation dans Gaspard2 . . . . . . . . . . . . . . . . . . .

Nud Direct Acyclique : . . . . . . . . . . . . . . . . . . . . . . . . .

Exemples dapplications (hautement reguli`eres) . . . . . . . . . . . . . . . . . . .

Exemples dapplication DSP `a t

Specification multidimensionnelle et mod`eles de calcul pour le TSI . . . . . . . .

MDSDF : Multidimensional Synchronous Dataflox . . . . . . . . . . . . .

ARRAY-OL (Array Oriented Language) . . . . . . . . . . . . . . . . . . .

Objectifs de conception des NoC . . . . . . . . . . . . . . . . . . . . . . . . . . .

Problematique du placement et ordonnancement . . . . . . . . . . . . . . . . . .

Le mod`ele darchitecture et le mod`ele dapplication . . . . . . . . . . . . .

Etat de lart des approches existantes . . . . . . . . . . . . . . . . . . . . . . . .

Approches pour les NoC . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Approches pour les syst`emes embarques multiprocesseur (MPES ou MPSoC) 85

Comparaison entre les techniques de placement et dordonnancement . . . . . . .

Verification des contraintes de temps reel . . . . . . . . . . . . . . . . . .

La minimisation de la consommation denergie . . . . . . . . . . . . . . .

Contraintes materielles et memoire . . . . . . . . . . . . . . . . . . . . . .

Loptimisation combinatoire multi-objectif . . . . . . . . . . . . . . . . . . . . . . 101

Les solutions dun probl`eme multi-objectif . . . . . . . . . . . . . . . . . . 101

Caracteristique du front Pareto . . . . . . . . . . . . . . . . . . . . . . . . 103

Choix de la methode daide `a la decision . . . . . . . . . . . . . . . . . . . 104

Probl`emes doptimisation multi-objectif . . . . . . . . . . . . . . . . . . . . . . . 105

Classification des methodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Approches de resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Les methodes bi-objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Formulation mathematique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Premi`ere phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Seconde phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Mapping des taches repetitives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Routage et optimisation des communications . . . . . . . . . . . . . . . . . . . . 130

Generation de chemin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Probl`eme de generation du chemin

Routage statique des paquets . . . . . . . . . . . . . . . . . . . . . . . . . 134

Probl`eme du routage des paquets . . . . . . . . . . . . . . . . . . . . . . 135

Temps dexecution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

mapping Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Le choix dune methode `a base de GA pour le placement irregulier . . . . . . . . 137

param`etres de lalgorithme genetique . . . . . . . . . . . . . . . . . . . . . 137

Choix des operateurs genetiques . . . . . . . . . . . . . . . . . . . . . . . 139

Transformation de la fonction objectif en fonction Fitness . . . . . . . . . 140

Fonction devaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140