Ordonnancement Hiérarchique d`Application Temps Réel Sur Une

Transcription

RÉPUBLIQUE ALGÉRIENNE DÉMOCRATIQUE ET POPULAIRE
Université d’Oran Es-Senia
Faculté des Sciences
Département d’Informatique
Ordonnancement Hiérarchique
d’Application Temps Réel Sur Une
Architecture NOC
MÉMOIRE DE FIN D’ÉTUDE
présenté et soutenu publiquement le 06 juillet 2009
pour l’obtention du
Diplôme d’Ingénieur d’Etat en Informatique
(Option informatique Industrielle)
par
Mohamed akli REDJEDAL
Abdelhak OULHACI
Encadreur : Dr A.BENYAMINA.
Co-Encadreur : Pr P.BOULET [Lille1]
Devant les membres du jury
Président :
Dr. M.BOUAZZA
Examinateurs :
Dr. M.SAYAH
Dr. L.BOUDJANI
N◦ PFE:15/2009
Promotion 2008-2009
Remerciements
Monsieur Abou Elhassen BENYAMINA
Nous tenons à vous exprimer notre profond respect et notre reconnaissance pour avoir dirigé
ce travail, pour vos conseils précieux et pour votre grande patience et bonne compréhension.
Monsieur pierre BOULET
Pour nous avoir aidé dans la réalisation de ce travail et pour avoir consacrer le temps voulu
malgré vos responsabilités. Nous vous exprimerons notre profond respect.
Monsieur Mohamed.BOUAZZA
On tient à vous remercier de nous avoir honoré en acceptant la présidence de Jury de notre
mémoire de fin d’étude.
Monsieur Mohamed SAYAH
Madame Leila BOUDJANI
Nous tenons à vous exprimer ici nos remerciements et notre respect pour avoir accepté de
juger ce travail.
i
Je dédie ce mémoire
à mes parents qui m’ont soutenu durant mes d’études
à mes frères BELKCEM,BENAMAR et ma sœur FATIMA ZOHRA
à mes bon amis et camarades
Une spéciale dédicace à mon binôme et à tous ceux qui ont participé
de près ou de loin à l’aboutissement de ce projet
à toute ma famille.
à tous ceux qui m’aiment et que j’aime.
Abdelhak OULHACI
ii
Je dédie ce mémoire
à la mémoire de mon père,
à ma très chère mère
à mon frère NABIL et mes sœurs TAOUS et FARIDA
et surtout BRAHIM, HAYAT et MARWA
à toute ma famille.
à ma très chère FATIMA
à mes très bon amis
Une spéciale dédicace à mon binôme et à tous ceux qui
ont participé de près ou de loin à l’aboutissement de ce projet
à touts qui m’aiment et que j’aime.
Mohamed Akli REDJEDAL
iii
Table des matières
Table des figures
ix
Liste des tableaux
xi
Résumé
xii
Introduction générale
Partie I
xiii
Introduction aux Système Embarqué et Flots de Conception
1
Chapitre 1
Les Systèmes Embarqués
1.1
1.2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.1.1
Qu’est-ce que les Systèmes Embarqués ? . . . . . . . . . . . . . . . . .
3
1.1.2
L’Informatique Embarquée ? . . . . . . . . . . . . . . . . . . . . . . .
3
L’étendus des Systèmes Embarqués . . . . . . . . . . . . . . . . . . . . . . .
4
1.2.1
Domaines d’Applications . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2.2
Domaines de Recherches . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3
Tendances Architecturales Physiques
. . . . . . . . . . . . . . . . . . . . . .
4
1.4
Un Système Embarqué typique . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.5
les Différences avec un ordinateur du bureau . . . . . . . . . . . . . . . . . .
5
1.6
Les Contraintes des Systèmes Embarqués . . . . . . . . . . . . . . . . . . . .
6
1.6.1
Temps Réel et Activités
. . . . . . . . . . . . . . . . . . . . . . . . .
6
1.6.2
Consommation énergétique . . . . . . . . . . . . . . . . . . . . . . . .
6
1.6.3
Mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.6.4
Tolérance aux fautes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.6.5
Hétérogénéité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.6.6
Réutilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.6.7
Contraintes de coût de communication . . . . . . . . . . . . . . . . .
8
iv
1.6.8
Adaptabilité aux environnements mobiles . . . . . . . . . . . . . . . .
8
1.7
Conception d’un Système Embarqué
. . . . . . . . . . . . . . . . . . . . . .
9
1.8
Architectures des différents systèmes embarqués . . . . . . . . . . . . . . . .
10
1.8.1
mono-puce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.8.2
Caractéristiques des SOC . . . . . . . . . . . . . . . . . . . . . . . . .
11
1.8.3
Multiprocesseurs on SOC (MPSOC) . . . . . . . . . . . . . . . . . . .
11
1.8.4
Architectures des systèmes MPSOC . . . . . . . . . . . . . . . . . . .
13
1.8.5
génération . . . .
15
Réseau de communication sur puce (NOC) . . . . . . . . . . . . . . . . . . .
16
1.9.1
Les Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
1.9
Les caractéristiques des architectures MPSOC
2eme
Chapitre 2
Flots de Conception des SOC
2.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.2
Flot de conception Classiques . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.2.1
Flot séquentiel de conception de circuits spécifiques . . . . . . . . . .
22
2.2.2
Flot de co-conception de circuits spécifiques . . . . . . . . . . . . . .
22
2.2.3
Flots basés sur la notion de la plate-forme . . . . . . . . . . . . . . .
22
Flots de conception modernes . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.3.1
Co-Développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.3.2
Co-Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
Ingénierie Dirigée par les modèles . . . . . . . . . . . . . . . . . . . . . . . .
27
2.4.1
GASPARD : Flot de conception pour les SOC . . . . . . . . . . . . .
28
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
2.3
2.4
Partie II
Le placement Dans les NOC et Méthodologie de Résolution
32
Chapitre 3
Le Placement et l’Ordonnancement dans Les NOC
3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.2
Les objectifs de la conception des NOC . . . . . . . . . . . . . . . . . . . . .
34
3.3
Approches pour les NOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.3.1
Approches sans assignation réseau . . . . . . . . . . . . . . . . . . . .
34
3.3.2
Approches avec assignation réseau . . . . . . . . . . . . . . . . . . . .
39
Approches pour les systèmes MPSoC . . . . . . . . . . . . . . . . . . . . . .
44
3.4
v
3.4.1
Approches basées sur l’énergie . . . . . . . . . . . . . . . . . . . . . .
44
3.4.2
Approche pour les contraintes temps réel soft . . . . . . . . . . . . . .
46
3.4.3
Approche pour les contraintes temps réel hard . . . . . . . . . . . . .
47
3.4.4
Approches basées sur la mémoire
. . . . . . . . . . . . . . . . . . . .
49
Comparaison entre les techniques de placement et d’ordonnancement . . . .
51
3.5.1
Vérification des contraintes de temps réel . . . . . . . . . . . . . . . .
51
3.5.2
La minimisation de la consommation d’énergie . . . . . . . . . . . . .
54
3.5.3
Contraintes matérielles et de mémoire . . . . . . . . . . . . . . . . . .
56
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
3.5
Chapitre 4
Optimisation Multi-Objectifs
4.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.2
Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
4.3
les algorithmes d’optimisation . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.3.1
l’algorithme de Brunch & Bound . . . . . . . . . . . . . . . . . . .
61
4.3.2
Algorithme génétique (AG) . . . . . . . . . . . . . . . . . . . . . . .
65
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
Partie III
Les Approches pour la Résolution du Placement Hiérarchique
Multiobjectifs
72
Chapitre 5
Modélisation du Problème de Placement et Ordonnancement Hiérarchique
5.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
5.2
Modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
5.3
Fonction coût . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
5.4
Contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
5.4.1
Les propriétés de matériel et de logiciel : . . . . . . . . . . . . . . . .
79
5.4.2
Les types de noœud des deux graphes : . . . . . . . . . . . . . . . . .
79
5.4.3
Le niveau hiérarchique des graphes : . . . . . . . . . . . . . . . . . .
79
5.4.4
L’équilibrage des charges : . . . . . . . . . . . . . . . . . . . . . . . .
79
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
vi
Chapitre 6
Contribution
6.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
6.2
Modèle Mathématique [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
6.3
les Algorithmes Utilisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
6.3.1
Graphe potentiel Tâches . . . . . . . . . . . . . . . . . . . . . . .
84
6.3.2
ACP(Analyse de Composante Principale) . . . . . . . . . . . . . . .
84
6.3.3
Djiskra multi-Objectifs . . . . . . . . . . . . . . . . . . . . . . . .
85
Démarche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
6.4
Partie IV
Implementation & Experimentation
92
Chapitre 7
Implementation
7.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
7.2
Présentation de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
7.3
Spécification des besoins
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
7.4
Les Outils et Plateformes utilisés . . . . . . . . . . . . . . . . . . . . . . . . .
94
7.5
Principales étapes de développement . . . . . . . . . . . . . . . . . . . . . . .
95
7.6
Architecture de l’Application . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
7.6.1
Le Pattern et Modèle (MVC) . . . . . . . . . . . . . . . . . . . . . . .
96
7.6.2
Architecture en packages de l’application . . . . . . . . . . . . . . . .
98
7.7
l’interface graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
7.8
Modélisation UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.8.1
Diagramme de class du noyau . . . . . . . . . . . . . . . . . . . . . . 105
7.8.2
7.8.3
7.8.4
Diagramme de class de l’interface . . . . . . . . . . . . . . . . . . . . 108
7.8.5
Diagramme de séquence de l’application . . . . . . . . . . . . . . . . . 109
7.8.6
Diagramme Activité de Saisi de l’Arbre Hiérarchique . . . . . . . . . 110
vii
Chapitre 8
Experimentation
8.1
introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8.2
L’application : Encodeur H2.63 [18] . . . . . . . . . . . . . . . . . . . . . . . 112
8.3
L’architecture : MPSOC [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
8.4
L’impact de l’hiérchisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Conclusion Générale
120
Glossaire
122
Index
123
Bibliographie
viii
Table des figures
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
Schema typique d’un système embarqué . . . . . . . .
Schema typique d’un SOC . . . . . . . . . . . . . . .
Un exemple d’architecture monoprocesseur . . . . . .
Architecture d’un monoprocesseur . . . . . . . . . . .
Architecture d’un multiprocesseur première génération
Architectures multiprocesseurs de deuxième génération
Architecture point à point . . . . . . . . . . . . . . . .
Architecture Bus Partagé . . . . . . . . . . . . . . . .
Architecture d’Anneau et d’étoile . . . . . . . . . . . .
Architecture Crossover . . . . . . . . . . . . . . . . . .
Architecture à Commuté et Maillage Complet . . . . .
2.1
2.2
2.3
2.4
Flot de conception classique
Flot de conception modèrne
flot de conception en Y . .
Un exemple de modélisation
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
10
12
14
14
15
17
17
18
18
19
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
26
29
30
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
Méthodologie de G.Varatkar et al . . . . . . .
La méthodologie de Lei et al . . . . . . . . .
Méthodologie de J.Hu et al. . . . . . . . . . .
Méthodologie de D.Shin et al. . . . . . . . . .
Exemple de placement du CTG sur le NOC .
Méthodologie de M.T.Schmitz et al. . . . . .
Méthodologie de F.Gruain et al. . . . . . . .
Méthodologie de L.A.Cortes et al. . . . . . .
Méthodologie de R.Szymanek et al. . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
36
37
40
42
45
46
47
50
4.1
4.2
4.3
4.4
4.5
4.6
Un Front Pareto . . . . . . . . . . . . . . . . . . . . .
D’un Espace de Recherche Vers Un Front Pareto . . .
Les Algorithmes d’optimisation . . . . . . . . . . . . .
Organigramme de Branch & Bound . . . . . . . . . .
les cinq niveaux d’organisation d’un AG . . . . . . . .
illustration schématique du codage des variables réelles
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
60
60
61
64
66
67
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
par Gaspard .
ix
.
.
.
.
4.7
4.8
4.9
4.10
4.11
la méthode de sélection de la roulette .
Exemple de croisement en un seul point
Exemple de croisement en deux points .
Exemple de mutation . . . . . . . . . . .
Organigramme de l’AG . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
68
69
69
69
70
5.1
5.2
5.3
5.4
Graphe
Graphe
Graphe
Graphe
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
74
75
76
77
6.1
6.2
6.3
6.4
6.5
liste scheduling . . . . . . . . . . . . . . . . . . . .
Exemple de classification par ACP . . . . . . . . .
Diagramme d’Activité de Validation structurelle .
Diagramme d’Activité de Détection des Anomalies
Diagramme d’Activité de Mapping Hiérarchique .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
84
85
88
89
90
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
7.11
7.12
7.13
7.14
Les différentes étapes de développement . . . . . . . . . . .
Architecture en Package de l’Application . . . . . . . . . . .
La fenêtre principale de l’application . . . . . . . . . . . . .
La partie Nord de l’interface . . . . . . . . . . . . . . . . . .
La partie West de l’interface . . . . . . . . . . . . . . . . . .
La partie Est de l’interface . . . . . . . . . . . . . . . . . .
La partie Sud de l’interface . . . . . . . . . . . . . . . . . .
Diagramme de class du noyau (architecture) (1/4) . . . . .
Diagramme de class du noyau (application)(2/4) . . . . . .
Diagramme de class du noyau (structure de données) (3/4)
Diagramme de class du noyau (traitement)(4/4) . . . . . . .
Diagramme de classe de l’interface . . . . . . . . . . . . . .
Diagramme Séquence d’Ouvrir un nouveau projet . . . . . .
Diagramme Activité de Saisi de L’Arbre Hiérarchique . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
96
98
99
100
101
102
103
104
105
106
107
108
109
110
8.1
8.2
8.3
8.4
8.5
8.6
Le graphe hiérarchique de l’encodeur H.263. . . . . . . . . . . . . . . . . . . . . .
L’implémentation de l’encodeur H.263 en profil Gaspard. . . . . . . . . . . . . . .
Le graphe hiérarchique de l’MPSOC. . . . . . . . . . . . . . . . . . . . . . . . . .
Résultat d’association à plat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Résultat d’association à deux niveaux. . . . . . . . . . . . . . . . . . . . . . . . .
Évolution des temps de recherche du GILR en fonction de la taille des application
et du nombre de niveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
113
114
115
116
117
d’application . . . . . . . .
d’architecture . . . . . . .
Hiérarchique d’application
Hiérarchique d’architecture
.
.
.
.
.
.
.
.
.
.
.
.
118
x
Liste des tableaux
1.1
Classification de Flynn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
3.2
3.3
3.4
3.5
3.6
3.7
Méthodologies pour les NOC . . . . . . . . . . . .
Objectifs spécifiés pour les NOC . . . . . . . . . .
Méthodologies pour MPSOC à base de Bus . . . .
Les objectifs des MPSOC à bus . . . . . . . . . . .
Les délais de communication dans les NOC . . . .
Délais de traitement dans les NOC . . . . . . . . .
Placement de tâches avec optimisation de l’énergie
8.1
Résultats de temps de Placement hiérarchique . . . . . . . . . . . . . . . . . . . . 118
xi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
43
43
50
51
53
53
56
Résumé
Ce mémoire cible une phase très importante dans le cycle de développement des
systèmes embarqués, celle de la conception software.
Dans cette phase, le processus de placement d’une application hiérarchique sur une
architecture hétérogène constitue un défi à relever , afin de satisfaire des objectifs
contradictoires et de fournir des résultats dans des délais raisonnables. En utilisant
des différentes approches exactes et heuristiques, et en adoptant un modèle permettant de représenter n’importe quelle structure, à different niveaux d’abstraction, afin
d’être plus proche des problèmes d’association de l’arbre hiérarchique application et
architecture.
Mots-clés: Système Embarqué, SOC, MPSOC, Hiérarchique, Optimisation multi-objectifs
xii
Introduction générale
Dans le pratique, une tâche particulière peut être réaliser par plusieurs machines fonctionnant en synergie .Par exemple dans une voiture, il existe plusieurs systèmes embarqués afin de
faciliter la conduite et d’assurer la sécurité du conducteur et des passagers ( ABS,ESP. . . ).
L’apparition des appareils mobiles et autres nouvelles technologies a poussé les concepteurs
à équiper ces appareils de différents systèmes.
Un système embarqué peut être défini comme un système électronique et informatique autonome ne possédant pas d’entrées/sorties standards comme un clavier ou un écran.
Sur une puce (SOC ,System On Chip) un ou plusieurs différents systèmes peuvent être embarqués, de nature hétérogènes et donc complexes. celle ci sont constitués de plusieurs différents
processeurs (FPGA, DSP, GP par exemple), avec des fonctions dédiées ou reconfigurables.
L’évolution des systèmes embarqués a suggéré l’idée de faire connecter les SOC dans des
NOC pour tirer profit d’une caractéristique très importante, celle du parallélisme afin de minimiser le temps d’exécution et par conséquent, l’énergie consommée.
Dans ce mémoire, nous espérons étudier un problème très répandu dans le domaine de la
conception des systèmes embarqués, celui de placement d’une application sur un NOC, en respectant un ensemble de contraintes (temps d’exécution réduit, le minimum d’énergie consommer,
la bande passante bien utilisé).
Dans le cadre de notre travail, une application est un ensemble de tâches qui communiquent
entres elles, via les bus sur une architecture hétérogène, pour échanger des messages. Notre rôle
est de placer ces tâches sur les différents processeurs, en minimisant le temps d’exécution et donc
l’énergie consommée.
Pour résoudre ce problème, nous avons utilisé l’Algorithme Génétique, inspirée du modèle
des lois de la nature de Darwin. Cette technique a été définie par J.Holland [20] et formalisée par
E. Goldberg [15] . Efficace dans de nombreux domaines, tels que l’optimisation des réseaux, le
traitement d’images ainsi le contrôle des systèmes industriels. Alors que l’algorithme de Branch
xiii
& Bound, est une méthode de recherche exacte, permettant de trouver une solution dans un
ensemble fini.
Plan du Document
Afin de permettre au lecteur de suivre et de comprendre notre démarche, l’exposé s’articule
en 8 chapitres regroupés en 4 parties .
– Partie I :
– Chapitre I : Introduction aux systèmes embarqués et présentation de leur caractéristiques
et leur domaines d’application.
– Chapitre II : Une définition des différents flots de conception des systèmes embarqués.
Et la présentation de la tendance la plus utilisée les MDA {Model Driven Architecture}.
– Partie II :
– Chapitre III : Introduction au problématique du placement et l’ordonnancement dans
les NOC {Network On Chip}.
– Chapiter IV : Introduction au problème d’optimisation multi-Objectifs, et définition des
Algorithmes utilisés B&B {Brunch and bound } et AG {Algorithme génétique}.
– Partie III :
– Chapiter V : Modélisation du problème de placement et d’ordonnancement hiérarchique.
– Chapiter VI : Résolution du problème de placement et d’ordonnancement hiérarchique.
– Partie IV :
– Chapiter VII : Implementation et diagrammes UML {Unified Modeling Language}.
– Chapitre VIII : Résultats des experimentations générées par notre application.
xiv
Première partie
Introduction aux Système Embarqué
et Flots de Conception
1
Chapitre 1
Les Systèmes Embarqués
2
1.1. Introduction
1.1
1.1.1
Introduction
Qu’est-ce que les Systèmes Embarqués ?
Les systèmes embarqués sont des systèmes informatiques déployés dans le monde physique.
Ils captent des informations de leur environnement, s’adaptent et agissent sur lui sans aucune ou
presque aucune intervention humaine. Ils communiquent généralement à travers des réseaux qui
véhiculent des flux de données toujours plus importants. Les systèmes embarqués incluent tous
les appareils intégrants des logiciels dans leur fonctionnement, que ceux-ci soient visibles à leur
utilisateurs ou non. La réalisation des systèmes embarqués réunit de nombreuses compétences
(informatique, électronique, architecture de systèmes, mathématiques).
Elle nécessite de prendre fondamentalement en compte l’hétérogénéité des composants et
des logiciels ; de plus, un système embarqué peut être défini comme un système électronique et
informatique autonome, dédié à une tâche bien précise, Il ne possède généralement pas d’entrées/sorties standards comme un clavier ou un écran d’ordinateur, Le système matériel et
l’application étant intimement liés.
1.1.2
L’Informatique Embarquée ?
Il est intéressant de noter que l’informatique change : elle tend a évoluer vers le développement
d’une multitude d’objets informatiques accessibles et personnalisés pour et par les utilisateurs.
Les gros serveurs de calcul centralisant l’information cohabitent avec une informatique nomade
dotée de capacité forte de communication. L’omniprésence se manifeste par le fait qu’actuellement nous trouvons des appareils électroniques dans beaucoup de produits de la vie courante,
dans nos téléphones portables, dans nos montres, dans nos machines à laver, . . . .De plus, la
tendance est d’interconnecter tous ces petits appareils les uns aux autres, dans le but de les faire
interagir. L’acceptation de ces objets mobiles et communicants par les utilisateurs a été favorisée
par leur grande ergonomie.
Toutefois, ce facteur clef de l’intégration de ces objets portables et communicants amène
des problématiques nouvelles quant au développement du logiciel et des systèmes d’exploitation
embarqués permettant d’exploiter au mieux les spécificités et les contraintes de ce domaine.
Le logiciel embarqué doit à la fois être très proche du matériel sur lequel il fonctionne, mais
aussi facile d’utilisation, il doit supporter une multitude de normes différentes, en particulier
pour les protocoles de communication (WIFI 802.x, Bluetooth). Enfin, dans le cas d’utilisation
de batteries, le logiciel enfoui (embarqués) doit supporter une gestion de l’énergie efficace lui
permettant de fonctionner le plus longtemps possible.
3
1.2. L’étendus des Systèmes Embarqués
1.2
1.2.1
L’étendus des Systèmes Embarqués
Domaines d’Applications
L’électronique embarquée touche plusieurs domaines tels que :
– Le Transport : Automobile, Avionique, ITS (Intelligent Transport System) . . .
– La Communication : Mobile (UMTS, GPRS, GSM . . .), Guidage satellite (GPS), Télévision
numérique . . ..
– Autres : Domestique (objets communicants), Applications Multimedia (Audio, Vidéo),
Appliances (électronique à faible coût), Bio-informatique.. . .
1.2.2
Domaines de Recherches
Cette discipline offre aussi beaucoup de voix à la recherche, comme :
– Architecture, Compilation : Pour résoudre des problèmes tels que : Le parallélisme, la
conception conjointe logiciel-matériel, l’ordonnancement, Mémoire, Taille du code,Communication
sur la puce.
– Systèmes et protocoles : Les systèmes embarqués utilisent des protocoles de communication
spécifiques tels que eX-Ray, TDMA ou CAN, projet Trio0).
– Formalisme et systèmes critiques : Les environnement temps réel nécessitent un formalisme
vu la difficulté et la complexité des systèmes embarqués.
1.3
Tendances Architecturales Physiques
Avec le développement de l’électronique et les progrès de la recherche dans le domaine du
matériel, les systèmes embarqués se sont scindés en deux tendances architecturales majeures,
les monoprocesseurs monopuces et multiprocesseurs monopuces, donc deux domaines quasi différents de part leur caractéristiques et exigences.
L’origine de ces deux tendances vient naturellement de la classification de Flynn ; où l’idée
d’utiliser plusieurs processeurs pour améliorer les performances est apparue avant même la fabrication du tout premier microprocesseur. En effet, en 1966, Flynn propose un modèle simple de
classement des ordinateurs, qui reste encore utile aujourd’hui pour caractériser les processeurs
parallèles. Son analyse se base sur le parallélisme dans les flots d’instructions et de données ce
qui a donné naissance à quatre catégories qui sont répertoriées dans la figure 1.1.
Cette figure résume les quatre possibilités d’architectures de processeurs parallèles. La première, SISD (Single Instruction Single Data), correspond à une seule instruction sur une seule
donnée ce qui est équivalent à une architecture monoprocesseur de type « Von Neumann ». La
deuxième, SIMD (Single Instruction Multiple Data), correspond à une seule instruction appliquée à de multiples données : on parle aussi de traitement vectoriel des données. Les processeurs
SIMD permettent au composant d’effectuer des traitements identiques sur des données de taille
réduite (par exemple, sur un chemin de données de largeur 32 bits, au lieu d’effectuer 1 seule
4
1.4. Un Système Embarqué typique
opération sur une donnée de 8 bits, on scinde l’opérateur en 4 ce qui permet d’effectuer le même
traitement sur 4 données en même temps, permettant de réduisant le nombre de cycles de calcul).
La classe des architectures MISD (Multiple Instruction Single Data) peut être apparentée
avec précaution aux architectures pipelinées. Quant aux architectures MIMD (Multiple Instruction Multiple Data), il s’agit de processeurs parallèles exécutant des instructions différentes sur
des données multiples. Ces processeurs présentent des propriétés très intéressantes pour l’exploitation de processus disjoints, comme le parallélisme au niveau tâche.
Flot
d’instruction
Unique
Multiple
Flot de données
Unique Multiple
SISD
SIMD
MISD
MIMD
Tab. 1.1 – Classification de Flynn.
1.4
Un Système Embarqué typique
La figure 1.1 nous présente un modèle standard et typique d’un système embarqué :
On trouve en entrée des capteurs généralement analogiques couplés à des convertisseurs A/N.
On trouve en sortie des actionneurs généralement analogiques couplés à des convertisseurs N/A.
Au milieu : le calculateur mettant en oeuvre un processeur embarqué et ses périphériques d’E/S.
Il est à noter qu’il est complété généralement par un circuit FPGA jouant le rôle de co-processeur
afin de proposer des accélérations matérielles à celui ci.
On trouve, en fait, un beau système d’asservissement entre les entrées et les sorties. Notant
que l’expression la plus simple de cette figure est de considérer comme capteurs, des interrupteurs
et des actionneurs.
1.5
les Différences avec un ordinateur du bureau
– L’interface IHM peut être aussi simple qu’une diode qui clignote ou aussi complexe qu’un
système de vision de nuit en Temps Réel.
– Des circuits numériques FPGA, ASIC ou des circuits analogiques sont utilisés pour augmenter les performances du système ou sa fiabilité.
– Le logiciel à une fonctionnalité fixe ; exécuter une application bien spécifique .
5
1.6. Les Contraintes des Systèmes Embarqués
Fig. 1.1 – Schema typique d’un système embarqué
1.6
1.6.1
Les Contraintes des Systèmes Embarqués
Temps Réel et Activités
Le Temps Réel est un concept un peu vague et chacun a sa propre idée sur la question.
On pourrait le définir comme : Un système est dit Temps Réel lorsque l’information après
acquisition et traitement reste encore pertinente. Plus précisément, cela veut dire que dans le
cas d’une information arrivant de fa¸con périodique (sous forme d’une interruption périodique
du système), les temps d’acquisition et de traitement doivent rester inférieurs à la période de
rafraı̂chissement de cette information. Un temps maximum d’exécution est garanti (pire cas) et
non un temps moyen. En effet, beaucoup de systèmes embarqués interagissent directement avec
leur environnement via des capteurs/actionneurs ou un réseau de communications sans fil. Ces
intéractions contraignent les temps de réponse du système embarqué de manière plus ou moins
forte selon le domaine d’applications visé. On parle alors de système temps-réel dans le sens
où le temps de livraison des résultats d’un calcul fait partie intégrante de la spécification de ce
dernier, au même titre que le résultat lui-même.
1.6.2
Consommation énergétique
Une grande majorité des systèmes embarqués (téléphones cellulaires, ordinateurs de poche,
. . .) sont confrontés au problème de l’autonomie. Aussi, afin d’étendre l’autonomie de fonction6
nement d’un système deux approches complémentaires sont possibles :
– Augmenter la capacité de stockage des batteries.
– Réaliser un système embarqué à faible consommation énergétique.
Dans le cadre de cette dernière approche, plusieurs méthodes sont alors envisagées qui
touchent à la fois le domaine de l’électronique et du logiciel, la conception de composants électroniques consommant le minimum d’énergie, l’optimisation du logiciel afin de diminuer le coût
énergétique de son exécution, et enfin la conception de stratégies logicielles exploitant les fonctionnalités du matériel.
1.6.3
Mémoire
La mémoire est une ressource limitée dans un grand nombre de systèmes embarqués (de
quelques Kilo-octets dans une carte à puce à quelques Mega-octets dans un téléphone portable),
et par conséquent une bonne utilisation de la ressource mémoire est cruciale pour ces systèmes.
Les méthodes permettant d’utiliser des systèmes à faible capacité mémoire vont de l’utilisation
de codes interprétés compacts, comme par exemple le Bytecode Java, à l’utilisation d’algorithmes
de compression, (en passant par des algorithmes d’allocation dynamique de mémoire optimisés
pour limiter le morcellement de la mémoire, ou fragmentation ).
Une difficulté supplémentaire dans les systèmes embarqués est que la gestion de la mémoire
soit compatible avec les contraintes temps-réel des applications. Bien que de nombreux systèmes
temps-réel se cantonnent à une gestion statique de la mémoire, quelques études récentes visent
à utiliser des techniques de gestion de mémoire élaborées (allocation et libération automatique
de mémoire - garbage collection, espaces d’adressages séparés) dans un contexte temps-réel
embarqué, on parle aussi de la mémoire cache : Vue que mémoire cache est sur la même puce
que le processeur, sa taille est très limitée (une petite fraction de la mémoire principale). Il s’agit
en général de SRAM (Static RAM) plutôt que de DRAM (Dynamic RAM) : la mémoire cache
est plus rapide mais très chère. Les temps d’accès sont très courts (1 cycle d’horloge en général)
alors qu’il en faut plusieurs pour accéder à la mémoire principale.
1.6.4
Tolérance aux fautes
Certains systèmes embarqués doivent pouvoir remplir leur fonctions malgré la présence de
fautes, qu’elles soient d’origine physique ou humaine. Les moyens pour la sûreté de fonctionnement, et plus spécifiquement les méthodes de tolérance aux fautes, permettant au système
de remplir ses fonctions en dépit des fautes pouvant affecter ses composants, ont fait l’objet de
travaux fournis dans les trente dernières années pour des systèmes généralistes. Par exemple, en
ce qui concerne les fautes d’origine physique, il est nécessaire de détecter les erreurs, par l’utilisation de méthodes telles que les codes détecteur d’erreurs, les contrôles de vraisemblance ou
encore le diagnostic en-ligne, puis d’effectuer un recouvrement d’erreur permettant au système
de continuer à remplir ses fonctions malgré l’erreur, que ce soit par reprise de son exécution à
partir d’un état sauvegardé au préalable (point de reprise) ou par compensation exploitant la
redondance présente dans le système (par exemple la duplication active de tâches).
7
Les difficultés issues du contexte embarqué sont relatives aux contraintes de temps des logiciels
embarqués, ainsi qu’aux ressources limitées de l’architecture. Ceci contraint les types de méthodes de tolérance aux fautes utilisables dans un contexte embarqué temps-réel. En particulier,
dans les systèmes temps-réel, il est nécessaire d’intégrer les mécanismes de tolérance aux fautes
dans l’analyse d’ordonnancement du système.
1.6.5
Hétérogénéité
Les système embarquée sont généralement composés de partie logiciel et matériel ; la partie
logiciel concerne l’application qui s’exécute sur un processeur alors que la partie matériel consiste
un composant physique qui implémente une fonctionnalité spécifique.
Cette hétérogénéité peut avoir plusieurs aspects comme : type de composants(CPU, mémoire,
ASIC, etc. . .), protocole de communication utilisé (FIFO, etc . . .), type de donne échangée ou
même la nature des composants (électronique, mécanique, optique ), des composants d’écrits
dans différent langage ce qui ajoute un aspect d’hétérogénéité en plus.
1.6.6
Réutilisation
La réutilisation peut influencer l’étape d’exploitation architecturale d’un système. Si le modèle ne facilite pas la réutilisation des composants de base, un changement du système implique
un effort plus important de la part du concepteur pour réimplanter les adaptateur de communication, pour cela, la réutilisation est devenue l’issue principale pour mener a bien la conception
de système embarquée, on parle de la réutilisation des composant et d’outils.
1.6.7
Contraintes de coût de communication
On a tendance à négliger dans la conception de systèmes embarqués le coût de la communication, c’est à dire le coût d’envoi et de réception de messages entre les différents composants
du systèmes, surtout dans des systèmes embarqués traitants de l’information multimedia ou de
l’information de routage ; et plus on avance dans ce domaine plus sera complexe l’interconnexion
entre les différents composants et par ricochët le coût de la communication augmente.
Donc, l’aspect Communication prend de plus en plus d’importance dans le domaine de l’embarqué et plus spécialement dans celui des systèmes embarqués multiprocesseurs monopuces
MPSOC. Dans notre travail de fin d’étude, on s’intéresse justement entre autre à cet aspect qui
est le coût de la communication dans les MPSOC.
1.6.8
Adaptabilité aux environnements mobiles
Comme on le sait tous maintenant, on peut trouver des systèmes embarqués dans des téléphones cellulaires, dans des systèmes de surveillances mobiles, dans des satellites, etc. . . ; en
d’autres termes, les systèmes embarqués s’utilisent de plus en plus dans des environnements embarqués ; deux exemples d’utilisation qui ont fait beaucoup parler d’eux, et qui sont les réseaux
ad-hoc et les réseaux de capteurs.
8
1.7. Conception d’un Système Embarqué
On remarque rapidement l’importance de l’adaptabilité des systèmes embarqués aux environnements mobiles, et cet aspect induit à l’apparition de nouveaux domaines de recherches ; la
Mobilité des systèmes embarqués est une spécialité à part entière.
1.7
Conception d’un Système Embarqué
C’est bien là le point le plus excitant et qui est l’essence même de ce mémoire. Du point de
vue technique, la conception d’un système embarqué demande à son concepteur d’être pluridisciplinaire : électronique, informatique, réseaux, sécurité n’ont pas de secrets pour lui. Mais le
concepteur se doit aussi d’être un bon gestionnaire car concevoir un système embarqué revient
finalement à un exercice d’optimisation : minimiser les coûts de production pour des fonctionnalités optimales. Le système embarqué doit être :
–
–
–
–
–
–
Robuste.
Simple. La simplicité est gage de robustesse.
Fiable.
Fonctionnel Le système doit toujours fonctionner correctement.
Sûr surtout si la sécurité des personnes est en jeu.
Tolérant aux fautes.
D’autres contraintes sont aussi prise en compte :
–
–
–
–
–
–
L’encombrement.
Le poids.
Le packaging : difficulté de faire cohabiter dans un faible volume, électronique analogique.
électronique numérique et RF sans interférences.
L’environnement extérieur.
La consommation électrique : Le système embarqué nomade doit être faible consommation
car il est alimenté par des batteries. Une consommation excessive augmente le prix de
revient du système embarqué car il faut alors des batteries de plus forte capacité.
– Le coût. Beaucoup de systèmes embarqués sont fabriqués en grande série et doivent avoir
des prix de revient extrêmement faibles.
– Le temps de développement. Dans un marché concurrentiel et de niches, il convient d’avoir
un système opérationnel le plus rapidement possible pour être le premier sur le marché.
Devant toutes ces contraintes, le concepteur adopte des règles de bon sens :
– Faire simple.
– Utiliser ce que l’on a déjà fait ou fait par d’autres. On appellera cela pudiquement du
design reuse.
– Ne pas se jeter sur les technologies dernier cri. Quelle est leur pérennité dans le temps ?
9
1.8. Architectures des différents systèmes embarqués
– Ne pas se jeter sur le dernier composant sorti surtout s’il est grand public. Quelle est
sa pérennité dans le temps surtout si l’on travaille pour la défense où l’on demande une
maintenance sur 30 ans !
– Utiliser des technologies éprouvées . Ces dernières peuvent d’ailleur avoir plusieurs générations de retard par rapport à leur homologues grand public.
Pour le grand public, le concepteur de systèmes embarqués peut sembler faire de l’inertie
face aux nouvelles technologies mais il faut le comprendre : c’est pour le bien du système qu’il
conçoit surtout si la sécurité des personnes est en jeu.
Cela explique en partie le décollage difficile des logiciels libres et de Linux pour l’embarqué.
Mais ceci est oublié, la déférence logiciels libres balaie une à une toutes les réticences.
1.8
Architectures des différents systèmes embarqués
Un SOC désigne l’intégration d’un système complet sur une seule puce de silicium.Ce terme
est devenu populaire dans le milieu industriel malgré l’absence d’une définition standard.on peut
avoir une définition telle que un SOC est un résultat de la cohabitation sur silicium de nombreuses
fonctions déjà complexes en elle même (processeurs, convertisseurs, mémoire, bus..etc).avec un
strict minimum qui se résume en une unité de traitement de logiciel(CPU) avec une dépendance
totale(ou partielle) des composants externes pour exécuter sa tâche.Mais le plus important c’est
d’avoir à la fois du materiel et du logiciel.
1.8.1
mono-puce
dans la figure 1.2 est présenté un exemple de système mono-puce typique.Il se compose d’un
coeur de processeur (CPU), d’un processeur de signal numérique (DSP), de la mémoire embarquée, et de quelques périphériques tels qu’un DMA (Direct Memory Access) et un contrôleur
d’E/S.
Fig. 1.2 – Schema typique d’un SOC
Le CPU peut exécuter plusieurs tâches via l’intégration d’un OS, le DSP permet de décharger
le CPU en faisant le calcul numérique sur les signaux en provenance du convertisseur A/N. Le
10
système pourrait être construit exclusivement de composants existants et de solutions faites sur
mesure.Maintenant avec la finesse de gravure sur silicium on peut implementer des MPSOC.
pour des raisons différentes la solution mono-puce est considérée comme un moyen élégant pour
implementer un système, surtout avec la fusion de la logique et de la mémoire grâce aux avances
technologiques qui ont permis cette fusion. La conséquence est que le temps de latence pour
accéder aux mémoires externes est maintenant annulée, la taille de la puce est réduite avec la
suppression des broches qui sont devenues inutiles puisqu’il n’y a pas d’accès à la mémoire,
toutes ces modifications rapportent un gain sur le coût total du système embarqué qui est égal
généralement a 50% du coût total ce qui permet de produire des systèmes embarqués fiables et
économiques côté énergie.
1.8.2
Caractéristiques des SOC
a) Hétérogénéité : Le système monopuce n’encapsule pas des systèmes purement électroniques, il peut intégrer aussi des composants non électroniques. C’est le cas, par exemple, des
systèmes intégrant des éléments micro-mécaniques . Une première classification se fait entre parties analogiques et parties numériques. Un exemple quotidien de tels systèmes, dits hybrides, est
le téléphone portable, où la partie radio (analogique) et la partie traitement de signal et gestion
de l’interface utilisateur (numérique) cohabitent souvent sur la même puce.
b) Embarquement : les systèmes embarqués sont par définition des sous-systèmes englobes
par des systèmes plus larges, cela dans le but d’avoir des fonctions particuliéres.Les SOC sont
aussi des systèmes embarqués car ils sont toujours appelés à évoluer dans l’environnement du
système qui les englobe.L’intéraction entre les SOC et leur environnements se fait via des convertisseurs analogique/numérique.
c) spécification : Les systèmes mono-puce sont différents par rapport aux ordinateurs qui
ont un usage général, mais un SOC est destiné à faire une tâche particulière bien définie.Cette
caractéristique a fait la difference au niveau de la méthodologie de conception entre les systèmes
mono-puce et les systèmes à usage général. Il faut indiquer que grâce aux méthodologies de
conception des SOC, il est maintenant possible de réutiliser des composants des autres systèmes
déjà conçus, mais dans le cadre des spécifications du SOC actuel.
1.8.3
Multiprocesseurs on SOC (MPSOC)
Maintenant, une puce peut contenir plusieurs centaines de millions de transistors, cela est le
résultat de progrès technologiques qui ont fait apparaı̂tre deux types d’architectures différentes
pour faire face à cette nouvelle situation.
la première se résume à l’utilisation des architectures mono-puce avec une amélioration des
performances du CPU utilisé et l’utilisation de Co-processeur.Les CPU utilisés sont caractérisés
par une fréquence de fonctionnement très élevée, une structuration matérielle appropriée, un
jeu d’instructions sophistiqué avec plusieurs niveaux de caches (hiérarchie de mémoire) ainsi
11
que des techniques d’optimisation spécialisées (nombre d’accès mémoire,taille...).La figure 1.3
illustre une architecture Processeur/co-processeur.
Fig. 1.3 – Un exemple d’architecture monoprocesseur
Dans de telles architectures, la communication est basée sur le principe maitre/esclaves. Le
CPU est le maitre et les périphériques sont des esclaves.
La deuxième consiste à utiliser des architectures microprocesseurs qui sont jusqu’a présent
réservées aux machines de calculs scientifiques.cette tendance est nourrie par le fait qu’il est de
plus en plus difficile d’avoir des architectures mono-puce assez rapides alors que les microprocesseurs sur puce sont déjà réalisables.On peut citer d’autres raisons comme :
Le parallélisme : Les transistors supplémentaires disponibles sur la puce sont utilisés par les
concepteurs principalement pour extraire le parallélisme à partir des programmes, afin d’effectuer plus de travail par cycle d’horloge. La majorité des transistors sont employés pour
construire les processeurs super scalaires. Ces processeurs visent à exploiter une quantité
plus élevée de parallélisme au niveau instruction, malheureusement, comme les instructions
sont, en général, fortement interdépendantes, les processeurs qui exploitent cette technique
voient leur rendement diminuer malgré l’augmentation quadratique de la logique nécessaire
au traitement de multiples instructions par cycle d’horloge, une architecture microprocesseurs évite cette limitation en employant un type complètement différent de parallélisme :
le parallélisme au niveau tâche. Ce type de parallélisme est obtenu en exécutant simultanément des séquences d’instructions complètement séparées sur chacun des processeurs.
Les retards causés par les interconnections : Ils sont devenus plus significatifs à cause de
la rapidité croissante des portes Cmos et des tailles des puces sont devenues physiquement
plus grandes. dans les prochaines années , nous ne pourrons acheminer des signaux que sur
une petite partie de la puce durant chaque cycle d’horloge, ce qui diminue la performance
dans le cas de large puce multiprocesseur. Cependant, une puce microprocesseur peut être
conçue de telle façon que chacun de ses petits processeurs occupe un secteur relativement
petit.
12
Le temps de conception : Il est déjà difficile de concevoir des processeurs. Le nombre croissant de transistors, les méthodes de plus en plus complexes d’extraction de parallélisme au
niveau instruction et le problème des retards causés par les interconnections rendront ceuxci encore plus difficiles. Une architecture multiprocesseurs mono-puce, permet de réduire
ce temps de conception car il permet l’instanciation de plusieurs composants pré-validés,
qui peuvent être réutilisés dans plusieurs applications de différentes tailles (en changeant le
nombre de composants). Seulement la logique d’interconnexion entre composants n’est pas
entièrement reproduite. Puisqu’une architecture multiprocesseur mono-puce traite tous ces
problèmes potentiels d’une façon directe et extensible, pourquoi ne sont ils pas déjà répandus ? Une raison est que les densités d’intégration viennent juste d’atteindre les niveaux, où
ces problèmes deviennent assez significatifs pour considérer un changement de paradigme
dans la conception des systèmes. Une autre raison, est la survenue de problème de synchronisation et de communication entre les différents processeurs. Ceci rappelle encore une
fois l’importance de l’architecture de communication dans les systèmes multiprocesseurs.
1.8.4
Architectures des systèmes MPSOC
Dans cette section, nous passons en revue les étapes importantes qui ont marqué l’évolution
des architectures matérielles des systèmes monopuces.
a) Les ASIC : Le terme ASIC signifie circuit intégré spécifique à l’application. Se contentant
de cette définition, tous les systèmes monopuces tels que définis plus hauts ne sont autres que des
ASIC. Cependant, le terme ASIC a désigné des circuits purement matériels qui implémentent
des fonctions bien spécifiques sur une même puce [33].
Pour des applications beaucoup plus complexes, il est coûteux et peu pratique de concevoir
le système entier comme un bloc matériel figé. De nos jours, les ASIC désignent des composants
plutôt élémentaires réalisant des fonctions bien déterminées (telle qu’une transformé de fourier
rapide) sous forme d’une propriété intellectuelle qui peut être intégrée dans des systèmes plus
larges.
b) Les architectures monoprocesseur : Pour augmenter la flexibilité des systèmes monopuces et réduire leur coûts, les premières architectures mettant en oeuvre la solution logicielle
ont été des architectures monoprocesseurs (Fig 1.4). Ces architectures sont souvent centrées autour d’un processeur à usage général, exécutant un programme placé dans une mémoire locale
et communicant avec des composants matériels appelés périphériques via un bus système.
La partie logicielle représentée par le processeur prendra généralement en charge la partie
contrôle de l’application (flot de contrôle). Les autres parties de l’application qui demandent
un traitement plus intensif des données (flot de données) seront réalisées sur des périphériques
spécialisés (ASIC) jouant le rôle d’accélérateurs matériels. Les microcontrôleur conventionnels
constituent un exemple typique de ces architectures.
13
Fig. 1.4 – Architecture d’un monoprocesseur
c) Les architectures multiprocesseurs de première génération : les architectures multiprocesseurs de la première génération représentent un changement important sur les architectures
monoprocesseurs, car ces derniers étaient équipés d’un accélérateur matériel dédié au traitement
des données, mais maintenant un nouveau composant est ajouté à ces architectures qui sont
des processeurs spécialisés (DSP) donnant naissance à la première génération des architectures
multiprocesseurs.
Fig. 1.5 – Architecture d’un multiprocesseur première génération
L’architecture multiprocesseur de première génération est composée d’un processeur central,
de nombreux périphériques, et de quelques processeurs annexes, il s’agit souvent de processeurs
spécialisés comme les DSP.
d) Les architectures multiprocesseurs de deuxième génération : L’évolution du besoin
en terme de puissance de traitement , et la percée importante de la capacité d’intégration , ont
contribué à la mise au point d’architectures hautement parallèles intégrant un nombre important
de processeurs et de composants matériels sur une même puce.
Pour pouvoir supporter conjointement en puissance et en flexibilité, ces architectures comprennent de plus en plus de processeurs, qui peuvent chacun se comporter en maı̂tre : l’architec14
ture couramment utilisée basée sur un processeur central contrôlant le reste du système, n’est
donc plus suffisante. [14]
Auparavant, on avait des problèmes avec les calculs. Désormaiss notre problème est au niveau
de communication, qui est devenu un critère de définition d’architecture.dans la figure 1.6 on a
quelques exemples sur des architectures MPSOC de la deuxième génération.
Fig. 1.6 – Architectures multiprocesseurs de deuxième génération
Le premier exemple est basé sur des communications par bus : ce modèle de communication
consomme peu de surface, mais risque de devenir un goulet d’étranglement.Le deuxième est basé
sur des communications en barres croisées très performantes mais aussi très coûteuses en surface.
Le troisième exemple donne une solution intermédiaire, par réseau commuté. Enfin le dernier
exemple montre qu’il est possible de mixer plusieurs modèles de communication et d’apporter
de la hiérarchie dans l’architecture.
1.8.5
Les caractéristiques des architectures MPSOC 2eme génération
nous allons examiner de plus prés les architectures multiprocesseurs mono-puces ( de deuxième
génération) : leur spécifications, leur enjeux et les contraintes qui conditionnent leur conceptions.
a) Architectures hétérogènes et massivement parallèles : la grande différence entre les
architectures de la première génération et celle de la deuxième génération c’est que les architectures de la seconde sont massivement parallèles.Ce fort parallélisme a une conséquence directe
15
1.9. Réseau de communication sur puce (NOC)
sur la complexité croissante des applications embarquées, qui exige des capacités de traitement
très importantes.Pour détourner ce problème, les concepteurs ont décidé d’augmenter la fréquence pour faire face au besoin de traitement, mais il semble actuellement atteindre les limites
pour deux raisons :
– les technologies sont en voie d’atteindre la saturation en terme de délai de progression.
– cette solution à une repercution très importante sur la consommation d’énergie
Pour cela, le parallélisme s’avère la meilleure solution pour faire face à ce défis.Un point commun entre ces deux architectures, c’est qu’elles sont hétérogènes ( l’application est distribuée
sur plusieurs processeurs) ce qui constitue une difference majeure entre les systèmes multiprocesseurs classiques ( super-ordinateurs) et les systèmes multiprocesseurs modernes, du fait que
les super-ordinateurs ont des architectures homogènes.
b) La communication : Augmenter le degré de parallélisme n’est pas sans avoir de conséquences directe sur les architectures des systèmes mono puce. En effet , un problème important
auquel font face ces architectures concerne la communication qui désormais constitue un goulet
d’étranglement vu la quantité importante d’informations qui doit être échangée entre les différents composants de l’architecture. Les systèmes classiques centrés autour d’un bus simple ne
sont plus à même de fournir la bande passante nécessaire pour supporter le trafic généré par
les MPSOC. Une deuxième solution à ces problèmes consiste à remplacer le bus simple par une
hiérarchie de bus interconnectés par des ponts (bridge). Ce type de solution est implementé , a
titre d’exemples, par la norme AMBA ou encore Sonics.
1.9
Réseau de communication sur puce (NOC)
Les réseaux de communication sur puce (NOC ) de l’Anglais network on chip) constituent
une alternative radicale aux bus partagés [47] [16].une architecture à base de réseau sur puce
est formée de plusieurs nœuds qui communiquent par envoi de message à travers le réseau
de communication. Ces nœuds peuvent être de différentes natures, en l’occurrence logiciels,
matériels, . . .etc. Par ailleur, un nœud peut être hiérarchique, c’est-à-dire renfermant lui-même
un réseau de communication .
1.9.1
Les Topologies
Les réseaux de communication présentent donc aujourd’hui une grande variété d’implementations physiques. Ce paragraphe présente donc les principes des familles de topologies les plus
utilisées, sachant que de nombreuses solutions spécifiques sont développées à partir de ces familles
pour adapter le réseau de communication à l’application cible. Les Figures suivantes présentent
ainsi le schéma de principe de quelques unes des topologies les plus couramment employées.
16
Point à point :Il s’agit de l’utilisation de ressources de transmission spécifiques et dédiées à
l’implémentation d’un lien entre deux éléments. La ressource de transmission étant dédiée
à une unique communication, elle est toujours disponible pour cette dernière et peut ainsi
lui offrir sa pleine bande passante. De plus, du fait de la simplicité du contrôle de telles
connexions, les débits y sont élevés et les latences dépendent principalement de la longueur
du chemin. Par contre, la surface de ces connexions sera proportionnelle au nombre de liens.
Fig. 1.7 – Architecture point à point
Les topologies multipoints :Le bus centralisé est en abandon progressif en tant que médium
principal de communication par l’ensemble des acteurs qui se veulent à la pointe des
solutions ”système sur silicium”. Le marché se déplace, de plus en plus rapidement, vers
des solutions globales de transport et de management du trafic au sein des systèmes sur
silicium, s’inspirant fortement des réseaux de calculateurs parallèles. Les systèmes sur
silicium présentant une forte hétérogénéité de composants possèdent rarement un seul
type de réseau embarqué.
Bus centralisé ou partagé :Il s’agit d’implémenter plusieurs liens logiques de communication par un unique médium de communication à accès partagé : le bus. Ce médium permet
la mise en place de liens unis ou multi-directionnels entre un maı̂tre et un ou plusieurs
esclaves. Les bus Ethernet et USB sont deux exemples célèbres de bus partagés. Tous les
éléments sont susceptibles de piloter les lignes du bus de données, mais seul un ou certains
d’entre eux peuvent piloter le bus d’Adresse.
Fig. 1.8 – Architecture Bus Partagé
17
Les réseaux en étoile et en anneau :Une première alternative intéressante au bus partagé
est le réseau en étoile, de type Ethernet et un serveur central, en anneau. L’Octagon a
récemment su tirer parti des avantages conjugués de ces deux architectures . Ces systèmes
contiennent des commutateurs de paquets, au centre de l’étoile ou sur chaque nœud de
l’anneau .Elles peuvent offrir une grande bande passante dans le réseau et une bande
passante réduite moins coûteuse avec le composant
périphérique.
Fig. 1.9 – Architecture d’Anneau et d’étoile
Les réseaux crossbar :Il s’agit de la mise en parallèle de n lignes de transmission concurrentes.Le réseau de périphériques s’articule autour d’une matrice (appelée Switch Fabric)
permettant la mise en oeuvre concurrente de plusieurs canaux de communication.La configuration de cette matrice peut être :
– Statique par programmation de la matrice lors de la fabrication, compliquant ainsi la
réutilisation de la plateforme.
– Dynamique par reconfiguration des interconnexions à chaque démarrage de l’application
Fig. 1.10 – Architecture Crossover
18
Les réseaux commutés ou à maille :Ce type de réseau comporte plusieurs étages, dont le
franchissement s’opère au travers d’un commutateur qui se charge de router le message.
L’implémentation de chaque commutateur peut être à base de multiplexeurs, voire à base
de petits bus crossbar. La propagation de l’information peut suivre l’un des deux schémas
suivants :
– Une connexion source-destination (aussi appelée session) permettant le transport continu
et transparent de l’information au travers des étages
– Une propagation de l’information d’étage en étage où elle est temporairement mis en
buffer dans une unité de routage. Ce mode de transmission est appelé wormhole.
Si deux paquets entrants doivent être routés vers la même sortie, on parle alors de collision,
et un paquet doit être élu et transmis tandis que l’autre est mis en buffer pour ne pas être
perdu.
Fig. 1.11 – Architecture à Commuté et Maillage Complet
19
Conclusion
L’architecture des systèmes embarqués a connu une évolution importante depuis l’ère des
SOC jusqu’à celle des NOC, qui dominent actuellement le marché des systèmes embarqués.
L’évolution technologiques dans le domaine de telecommunication, a permis de faire connecter
des machines ou bien des SOC via des réseaux de communications à grande échelle comme le
système de localisation par satellite(GPS ).
20
Chapitre 2
Flots de Conception des SOC
21
2.1. Introduction
2.1
Introduction
Un flot de conception est caractérisé par une séparation entre la conception de la partie
matérielle et celle de logicielle, cette séparation s’effectue dés qu’un partitionnement initial de
la spécification fonctionnelle est opéré .Vers la fin du flot de conception ( étape d’intégration)
les deux parties sont recombinées d’une même description bas niveau.
2.2
Flot de conception Classiques
on peut classer les différents flots existants en trois catégories.
2.2.1
Flot séquentiel de conception de circuits spécifiques
Ce type de flot est quasiment sans restriction concernant l’architecture cible. l’architecture
matérielle est conçue en se basant sur les specifications initiales de l’application, une fois la
conception du matériel terminé alors la partie logicielle va commencer, et après un long cycle
séquentiel où les concepteurs sont forcé à atteindre une implementation finale de l’architecture
matérielle.
2.2.2
Flot de co-conception de circuits spécifiques
Afin de résoudre le problème de séquentialité dans le flot précédent, les cycles de conception
des parties logicielles et matérielles doivent être concurrents. Cette concurrence est dirigée par
des contraintes sur l’architecture cible, par ce moyen, les concepteurs des parties logicielle et
matérielle peuvent être menés en parallèle.
Il est possible d’automatiser les étapes de conceptions des parties logicielle et matérielles, en
imposant un formalisme particulier au niveau de la spécification de l’application [Ism94].Mais
à cause des contraintes et des hypothèses, ces flots sont devenus trop contraignants pour être
utilisables en pratique.Il est de plus admis que la conception d’architecture aussi complexe que
les MPSoc est un art en ce sens qu’il est difficile de la rendre complètement automatique.
2.2.3
Flots basés sur la notion de la plate-forme
Récemment, la conception basée sur la notion de plate-forme (plateforme based Design) a
suscité un intérêt croissant dans ,le domaine de la conception des MPSoC. [42] [26] [22]
Dans ce type d’approche, Le problème de la séquentialité de la conception logicielle/matérielle
est abordé en déplaçant une grande partie de la conception de l’architecture en amont du flot de
conception. Ceci donne lieu à la notion de famille génératrice d’architecture, spécification à un
domaine d’application. Une étape de configuration/spécification de cette architecture générique
est alors nécessaire pour chaque application particulière, appartenant à ce domaine. On parle
souvent d’étape d’instanciation d’architecture.
22
2.2. Flot de conception Classiques
Bien que le degré de spécificité de l’architecture finale vis-à-vis de l’application reste inférieur
aux deux approches précédentes, ce type de flot constitue un compromis intéressant entre performances de plus en plus important qui est celui du coût de développement du masque (dépassant
le million de dollar pour les technologies les plus récentes).
En effet, une solution intéressante consiste à faire appel à la capacité de configuration des
composants matériels programmables( tel que les FPGA ) lors de spécification ou d’instanciation
de l’architecture matérielle.
23
2.2. Flot de conception Classiques
Fig. 2.1 – Flot de conception classique
24
2.3. Flots de conception modernes
2.3
Flots de conception modernes
Si le flot de conception classique pouvait suffire pour les première et deuxième générations
de système sur puce, la troisième génération, fortement hétérogène et multi-maı̂tre, est trop
complexe pour que les limitations précédemment énoncées soient acceptables. De nouveaux flots
sont nécessaires, basés sur de nouvelles méthodes.
2.3.1
Co-Développement
Le co-développement ou codesign a pour but de développer conjointement les diverses parties
d’un système hétérogène. C’est pourquoi une description globale du système est nécessaire.
pour la description il y a deux moyens possibles :
– fournir un langage unique pour décrire toutes les parties de l’application ainsi l’architecture.
– avantage : plus simple pour les outils et les utilisateurs de gérer un langage unique
– inconvénient : difficile de définir un langage qui soit vraiment adapté à toutes les parties du système
– au lieu de fournir un langage unique pour toutes les parties, on fournit des langages appropriés pour chaque partie.
– avantage :il est possible d’avoir un langage pour chaque partie
– inconvénient : il est difficile de gérer touts les langages.
dans ce flot, la séparation entre le logiciel et le matériel est effectuée plus tard par l’équipe
d’architecture s’occupant du système global et de la coordination entre elles.
2.3.2
Co-Simulation
La co-simulation a pour but de simuler conjointement les diverses parties d’un système
hétérogène.Il existe deux méthodes pour effectuer cette co-simulation :
– la première consiste à traduire les descriptions de diverses parties dans un unique langage.
– La deuxième méthode consiste à conserver les descriptions spécifiques des diverses parties et à exécuter, en parallèle, les divers simulateurs. Un programme appelé bus de cosimulation, assure les communications et la synchronisation entre les divers simulateurs.[14]
25
2.3. Flots de conception modernes
Fig. 2.2 – Flot de conception modèrne
26
2.4. Ingénierie Dirigée par les modèles
2.4
Ingénierie Dirigée par les modèles
Les systèmes étudiés peuvent être modélisés selon différentes approches adaptées à la nature
de ces systèmes et au contexte d’application dans lequel ils sont définis. Parmi ces approches,
l’Ingénierie Dirigée par Les Modèles présente une contribution importante dans le domaine de
la conception de systèmes logiciels [26]. Elle représente une forme d’ingénierie générative, par
laquelle tout ou une partie d’une application est générée à partir des modèles.
Un des apports essentiels de l’approche IDM, consiste à automatiser la transformation de
modèles. Il s’agit de transformer le code d’un langage en un autre, ou une modélisation abstraite
en une structure de classe, ou même un modèle de données en un autre modèle tout en assurant
que les propriétés des données sont conservées lors de la transformation. Dans ce contexte, la
vérification de modèles basée sur des approches formelles donnant de spécifications rigoureuses a
pour objectif de garantir que les modèles possèdent toutes les qualités attendues, en particulier,
lorsqu’ils ont en charge de modéliser la fabrication de systèmes critiques développés dans des
secteurs comme les transports ferroviaires, l’avionique, le spatial, les télécommunications ou
l’énergie.
L’approche IDM ouvre ainsi de nouvelles perspectives dans le cadre de la conception des systèmes embarqués critiques. De plus, une caractéristique principale de l’approche IDM consiste à
favoriser l’étude séparée des différents aspects du système. Cette séparation augmente la réutilisation et aide les membres de l’équipe de conception à partager et à s’échanger leur travaux
indépendamment de leur domaine d’expertise. Ce concept est particulièrement intéressant dans
le domaine de conception des systèmes sur puce où les deux technologies logicielle et matérielle
vont interagir pour la définition du comportement global du système.
L’approche IDM est basée essentiellement sur la notion du modèle qui est en fait une abstraction simplifiée d’une réalité ou d’un élément à modéliser en négligeant certains détails et en
conservant que les détails qui nous intéressent dans la modélisation.
Dans l’approche IDM, les trois points constituants une approche en Y font référence à des
notions sensiblement différentes :
– 1. Modèle indépendant des plateformes (PIM, plateforme Independent Model ) : Un
modèle capturant de façon ”abstraite” les éléments constituant un système. Le terme ”abstrait” signifie simplement ”indépendamment de toute technologies d’implémentation”.
– 2. Modèle de définition d’une plateforme (PDM, plateforme Definition Model ) : Un
modèle définissant les éléments constituant une technologie d’implémentation,
– 3. Modèle spécifique à une plateforme (PSM, plateforme Specific Model ) : Sans rentrer dans les détails méthodologiques, un PSM est le ”produit” d’un PIM et d’un PDM.
27
A partir d’une description indépendante de toute technologie d’implémentation et de la
description d’une technologie d’implémentation, on produit une description spécifique à
une technologie
2.4.1
GASPARD : Flot de conception pour les SOC
Gaspard se situe ainsi à la frontière de deux domaines de recherche : la conception des
systèmes sur puce, et l’ingénierie dirigée par les modèles. Si la notion de ”flot en Y ” existe dans
ces deux domaines, avec une articulation autour de trois points, il est important de noter que
le ”Y ” de Gaspard correspond à un flot tel qu’on le définit généralement dans le domaine de
la conception de systèmes sur puce (ou plus généralement dans le domaine de la conception de
systèmes embarqués incluant des parties logicielle et matérielle) :
Application : Spécification de la fonctionnalité attendue d’un système.
Architecture matérielle : Spécification de l’architecture matérielle qui sera utilisée pour
supporter l’exécution d’une application et réaliser ses fonctionnalités attendues.
Association : Spécification du placement d’une application sur une architecture matérielle
donnée.
Il adopte un flot de conception en ”Y”, ce qui permet aux concepteurs du système de modéliser de manière indépendante l’application et l’architecture matérielle du système, ensuite l’étape
d’association permet de les réunir en plaçant l’application sur l’architecture. Ces trois modèles
permettent, par l’intermédiaire de transformations, de générer des simulations à des niveaux de
précision de plus en plus importants.
La vérification formelle de la modélisation de l’application est rendue possible par la génération de langages synchrones déclaratifs comme lustre ou Signal. L’exécution concurrente de
différents processus sur une architecture multi-processeurs est rendue possible par la génération de langages procéduraux comme Fortran/Open MP. La finalité étant de générer un code
de simulation, avec System C par exemple, prenant en considération à la fois les parties matérielles et logicielles du système sur puce complet. La figure 2.3 illustre le flot de conception en ”Y”.
28
Fig. 2.3 – flot de conception en Y
29
La figure 2.4 illustre un exemple d’unité de calcul « Processing Unit » définit à l’aide de trois
composants élémentaires : un processeur MIPS, une mémoire Memory et un crossbar Crossbar4. Ce modèle est généré par l’environnement de Gaspard.
Fig. 2.4 – Un exemple de modélisation par Gaspard
30
Conclusion
Les particularités multiples des systèmes embarqués a entraı̂né la complexité des flots de
conception des systèmes actuels. Dans le domaine d’ingénierie dirigée par les modèles (IDM) le
plus utilisé est celui de conception en Y.
31
Deuxième partie
Le placement Dans les NOC et
Méthodologie de Résolution
32
Chapitre 3
Le Placement et l’Ordonnancement
dans Les NOC
33
3.1. Introduction
3.1
Introduction
Les principaux thèmes sont les étapes de conception, les buts de conception et des algorithmes
pour la mise en place. Un diagramme accompagnant chaque description permettra de comprendre
la multitude de concepts de chaque méthodologie.
3.2
Les objectifs de la conception des NOC
Dans la phase de conception du NOC, il y a des objectifs à respecter comme le minimisation
de la consommation d’énergie,la réduction de la surface de la puce, maximisation du temp de
performance. Dans tous ces objectifs, le plus important celui de la réduction de la consommation d’énergie dans le cas des systèmes embarqués mobiles, car leur fonctionnement dépend de
la durée de vie de la batterie. En deux la réduction de la surface de la puce, car 80% de la
surface (pour la plupart des NOC) est occupée par les switchs et les mémoires. Pour résoudre
ce problème, on doit optimiser les algorithmes de routage au niveaux des switches et augmenter
l’utilisation des mémoires.
En réalité ces objectifs sont contradictoire car en réduisant l’énergie consommée on augmente
le temps d’execution des composants(CPU), qui fonctionnant en mode économie, pour cela on
est obligé de faire du multi-objectifs afin de trouver un compromis entre les différents objectifs
contradictoires.
3.3
Approches pour les NOC
Les NOC constituent un domaine de recherche vierge, où seulement quelques méthodologies
de placement ont été développées. La plupart ne prenant pas en considération le placement
et l’ordonnancement des communications encore moins pour l’ordonnancement . Le plus court
chemin dans le NOC est souvent déterminé au moment du placement des communications.
3.3.1
Approches sans assignation réseau
G.Varatkar et al. [17] ont développé une méthodologie en deux étapes pour minimiser la
consommation d’énergie totale dans le NOC (3.1). L’étape communication traite simultanément le mapping et le scheduling des tâches, en cherchant à réduire la consommation d’énergie
par la minimisation du volume des communications inter-processeurs. Cela facilite aussi la minimisation d’énergie des tâches dans l’étape de selection de voltage, en maximisant les repos
(slack). Les deux objectifs sont alternés par un ‘critère de communication, qui a le rôle de fixer
le volume local des communications inter-processeurs sous un seuil fixe globalement dependant
des communications de l’application, et d’un facteur K(0 ≤ K ≤ 10). Ce facteur permet d’arrêter
la boucle externe de la méthodologie jusqu’à ce qu’un optimum soit atteint. La deuxième étape
de la méthode traite le DVS pour les tâches et exploite la distribution non uniforme des repos
(slack) en considérant une valeur maximale pour le temps et l’énergie pendant le basculement
34
3.3. Approches pour les NOC
des voltages [48]. La méthode ne prend pas en considération le placement et l’ordonnancement
des communications ; les distances des communications sont grossièrement estimées. Ainsi les
deadlines hard ne sont pas garanties car les délais des communications sont ignorés.
Fig. 3.1 – Méthodologie de G.Varatkar et al
Méthodologie de G.Varatkar et al. T.Lei et al utilisent une méthode à deux étapes basée 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 l’ordonnancement des tâches (3.2). L’objectif du
placement est de maximiser les temps de performance, pendant que l’ordonnancement est utilisé
pour respecter les hard deadlines. Les communications ne sont pas placées et schedulées et leur
délais sont estimés en utilisant une distance moyenne dans le NOC, ou La distance Manhattan
entre processeurs. Cette méthode ne garantie pas les hard deadline car elle utilise la moyenne
dans des pires cas des temps d’exécution (WCET Worst Case Execution Times) pour les tâches
et le chemin de communication critique.
J.H et al [24] ont développé une méthode d’optimisation d’énergie qui cherche le plus court
chemin des communications dans le NOC, (Figure 3.3) et calcule la consommation d’énergie,
pour décider quels sont les placements possibles qui vont construire la solution initiale. Cette
méthode ne traite pas l’assignation réseau mais exploite les repos (relâchement) non uniformes
en les distribuant d’une façon proportionnelle selon le timing et les profils d’énergie des tâches.
35
Fig. 3.2 – La méthodologie de Lei et al
36
Fig. 3.3 – Méthodologie de J.Hu et al.
Cette méthode fournit des mesures des délais de communication, de la consommation d’énergie et tend à satisfaire les hard deadlines. Elle a deux phases, énergie d’ordonnancement (EAS)
et recherche-reparation (SaR). Durant la phase EAS la solution est construite en se basant sur
LS pour le mapping et scheduling des tâches parallèles, et une autre méthode déterministe pour
le mapping et scheduling des communications parallèles.La méthode déterministe traite l’ordonnancement des communications pour toutes les tâches prêtes et les processeurs disponibles, dans
le but de trouver le temps de terminaison le plus court (EFT) de toutes les tâches prêtes.
La méthode d’Armin et al [34] va être présentée avec plus détail car elle est la plus récente
que celles qui ont précédé. Dans leur approche, les auteurs utilisent comme modèle d’application
un GT et comme plate forme cible un NOC de deux dimensions. Ce processus, ils l’ont nommé
Core Mapping Technique (CMT ) qui commence par définir un graphe de tâche représentant
37
l’application et ces tâches. Il se termine par un placement optimal des composants sur des plateformes à topologies différentes, mais la plus réaliste et faisable est celle d’un réseau en 2D-mesh.
Le graphe TG modélise une application avec une série de tâches. En plus, chaque composant IP
dans le NOC est responsable de l’exécution d’une tâche pré-assignée. L’objectif est de décider
quel composant IP doit être placé, d’une façon optimale sur quelle tuile, pour que les contraintes
de performance soient satisfaites. Dans ce travail, les auteurs cherchent à minimiser la consommation d’énergie globale sur tous les liens du réseau.
Pour l’architecture, un graphe ACG permet de la modéliser. Chaque sommet ti représente
une tuile dans l’architecture et chaque arc rij représente le chemin de ti à tj . Chaque rij a comme
propriété E titj bit qui représente la consommation d’énergie moyenne par l’envoi d’un bit de ti à
tj . Le calcul de E titj bit a été proposé dans les travaux de [76] selon la formule suivante :
titj
Ebit
= nhope × ESbit + (nhope − 1) × Elbit
titj
Où Ebit
est l’énergie consommée par bit entre les noeuds. ESbit est l’énergie consommée
par les switchs entre les noeuds et nhops est le nombre de bit transférés 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’énergie par l’envoi d’un bit entre deux noeuds ti , tj est déterminée
par la distance de Manhattan entre eux. Ceci est basé sur le fait que tous les liens ont les mêmes
caractéristiques. Dans ce travail, les auteurs ont supposé que chaque lien a un Elbit différent
et chaque switch a un ESbit différent. Ce qui donne l’expression suivante pour le calcul de la
consommation d’énergie totale des liens.
(nhope −1)
nhope
titj
Ebit
=
X
k=1
ESbit +
X
Elbit
k=1
D’où la consommation d’énergie totale pour transférer les données peut être calculée en multipliant l’énergie obtenue lors de l’équation précédente par le volume des données :
titj
ETtitj
otal = Datasize ∗ Ebit
Ensuite, pour le placement des tâches, ces auteurs, déterminent une liste TPL (Task Priority
List) qui donne les tâches selon les priorités de leur placement. Pour la plateforme, ils utilisent
la liste PPL (Plateforme Priority List) qui ordonnance les tuiles selon l’ordre descendant des
degrés de connectivité (voisinage), ainsi dans cette liste, les tuiles du centre sont les premières
et celles des frontières sont à la fin. Les priorités des placements sont exprimées par les règles
suivantes :
38
1. Les tâches qui communiquent le plus sont placées le plus proche possible.
2. Les tâches fonctionnellement très liées doivent avoir la distance Manhattan la plus petite.
3. Les tâches à degré de connectivité le plus élevé ne doivent pas être placées sur des tuiles
du bord du NOC mais de préférence sur celles du centre.
Enfin, pour déterminer le placement, une fonction coût est définie, basée sur la distance
minimale et les exigences de la bande passante entre les nœuds source et destination. Comme
exemple la fonction coût relative à la règle 2 on a :
C(i) = max [deg(Ti )] ; où Ti est une tâche dans TG
3.3.2
Approches avec assignation réseau
D.shin et Al. [10] ont proposé une méthodologie (figure ‘3.4) basée sur l’assignation réseau et
l’allocation des vitesses des liens pour réduire la consommation d’énergie dans les NOC avec une
échelle de voltage des liens. Le placement des tâches et l’assignation réseau ciblent à minimiser
le volume des communications inter-processeurs, cependant la sélection statique du voltage et la
gestion statique de l’énergie tendent à réduire la consommation d’énergie des liens. Le placement
des tâches permet la vérification des contraintes de dimensionnement. Les hard deadlines sont
aussi garanties, car quand l’ordonnancement des communications n’est pas performant, les pires
délais des communications (Worst Case Communication Delay) des liens sont appliqués. Ces
derniers peuvent être partagés par plusieurs arcs sans contrainte sur les volumes des communications. Comme conséquence d’avoir ignoré l’ordonnancement des communications, la sélection
du voltage des liens et la gestion d’énergie sont traités d’une façon statique.
Cette méthode utilise le AG pour le placement des tâches et l’assignation réseau. Pour l’ordonnancement des tâches et l’assignation des vitesses de liens c’est LS qui est utilisée. Le AG
dans cette méthode est basé sur un chromosome de placement, un croisement à deux points
et une mutation aléatoire. Le AG pour l’allocation utilise les permutations des tuiles comme
chromosome, les cycles de croisement pour générer les solutions acceptables et des changements
aléatoire comme mutation. La AG 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 là sur les délais de communications.
LS utilise la mobilité des tâches (|ASAPstart -ALAPend|), comme priorité statique qui est
basée sur l’estimation pessimiste des délais des communications.Hsin-chou et al [67] propose un
algorithme qui fait le placement et l’ordonnancement simultanément pour ce cas, en utilisant
la technique ‘ TDM (Time Division Multiplexing) pour le partage des liens du réseau. Ainsi
plusieurs arcs de communication peuvent se partager un même lien entre deux nœuds en se
partageant sa bande passante. Ici aussi, les auteurs utilisent comme modèles deux graphes :
CTG (U,E) (Communication Task Graph) où chaque sommet u ∈ U représente un IP, et chaque
39
Fig. 3.4 – Méthodologie de D.Shin et al.
40
arc eij ∈ E représente la communication de l’IP ui vers l’IP uj . La propriété de l’arc eij notée
par wij représente la bande passante nécessaire pour communiquer entre ui et uj . Le deuxième
graphe est nommé NAG(V,P) (NOC Architecture Graph). Chaque sommet vi ∈ V représente
une tuile dans l’architecture et chaque arc pij ∈ P représente le chemin de vi à vj . La valeur rij
associée au lien représente la bande passante.
Pour ces auteurs, le mapping est défini par la fonction MAP(U) :
M AP : U → V ⇒ vj = map(ui), ui ∈ U, vj ∈ V
L(pm,n ) est l’ensemble des chemins pm,n .
Un lien est noté par li,j .
rij peut être obtenu par la relation :
m≤|v|
X
ri,j =
b(li,j , pi,j )wm,n
n≤|v|
Où
(
B(li,j , pi,j ) =
1 : li,i ∈ L(pm,n )
0 : li,i 6∈ L(pm,n )
La latence est définie comme étant la durée d’envoi d’un paquet de l’émetteur au récepteur.
Elle dépend de la latence du switch et celle du lien notée par ls et ll . La latence du chemin de
communication Cn pour l’envoi d’un bit de donnée de la tuilei à la tuilej elle peut être calculée
par :
LCN =
X
LSi + (nhope − 1) × L1
i≤nhope
Où nhops est le nombre de switchs rencontrés par le bit pendant son transfert. La latence LSi
dénote la latence du switch Si dans le chemin de communication, elle est obtenue par la relation :
Lsi = Ttransf ert + TW aiting
TT ransf ert est le temps de transfert du switch. Ce temps est égal à la durée que prend un
switch pour faire passer le paquet sans le stocker dans son buffer. Le temps d’attente TW aiting
est celui de stockage du paquet dans le buffer, il dépend de l’algorithme d’ordonnancement et il
est égal à zéro s’il n’y a pas de stockage de paquet.
41
Donc, pour ces auteurs l’objectif est de minimiser
X
{
LCN pourn ≤ |N | }
Où |N| est le nombre des chemins de communication dans le NOC. Du fait que LCN depend de
LSi alors l’objectif de l’ordonnancement pour ces auteurs devient
XX
min{
TW aiting ; i ≤ |M ||K|}
Où |M| est le nombre de switch et |K| est le nombre de chemin de communications dans le switch.
Fig. 3.5 – Exemple de placement du CTG sur le NOC
Les lignes fléchées dans le NOC représentent les chemins de communications réservées par
l’algorithme de placement.
Hin-chou et al font le placement et l’ordonnancement en deux étapes. Dans la première, il
détermine le placement à l’aide d’une heuristique, le résultat est utilisé pour ordonnancer les chemins de communication dans la deuxième étape. Si les résultats de l’ordonnancement ne vérifient
pas les contraintes de la latence de communication, alors le placement est refait en ré-exécutant
la première étape. Le processus est répété jusqu’à ce que toutes les latences de communication
soient vérifiées.
résumé On synthétise les méthodologies vus précédemment et leur objectifs par ces deux
tableaux :
Comme on le voit dans ces tableaux les méthodologies des N0C ne couvre pas complètement
l’espace d’exploration surtout si on prend en considération les communications. Une approche
traite de l’assignation réseau [10] et une autre l’ordonnancement des communications [24]. Bien
que deux approches [59,64] minimise le volume des communications inter-processeur durant le
placement des tâches.
42
Réf
G.Varatkar
et al[17],[48]
T.Lei
et al[45]
J.Hu et al. [24]
D.Shin et al. [10]
Mapping
Network
assignment
Task Tile Com
LS
2-GA
LS
GA
GA
Exact
GA
Scheduling
Tile
LS
ASAP/
ALAP
LS
LS
Com
-
Voltage
Selection
Tile Com
ILP
-
Exact
-
-
LS
Power
Manage
Tile Com
-
-
-
LS
Tab. 3.1 – Méthodologies pour les NOC
Réf
G.Varatkar et al
[[17],[48]]
T.Lei et al.
[[45]]
J.Hu et al.[[24]]
D.Shin et al
.[[10]]
Consommation d’énergie
Dynamique
Statique
Task Comm Task Comm
DVS
Y
-
-
Y
Y
SVS
-
-
ABB
SPM
Contraint
du temp
Hard Soft
Y
-
mémoire
Code Data
-
-
Y
-
-
Y
Y
-
-
-
Zone
Y
Tab. 3.2 – Objectifs spécifiés pour les NOC
43
3.4. Approches pour les systèmes MPSoC
La consommation d’énergie est l’objectif préféré dans les approches d’optimisation. Quatre
de ces approches [[17],[24],[10], [9]] sont basées sur le problème, notamment celle des tâches et
des communications. Ainsi, G. Varatkar et al. [[17]] utilisent la sélection dynamique des voltages
pour les tâches, D. Shin et al. [[10]] utilisent assignation statique des vitesses de liens et la gestion statique de l’énergie pendant que J.Hu et al [[24]] utilisent la distribution non uniforme des
relâchements durant le placement et l’ordonnancement.
Toutes ces approches tendent à vérifier les hard deadlines mais seulement deux [[24],[10]] les
garantissent. T.Lei et al. [[45]], leur méthode maximise les performances d’un ensemble d’applications, mais aucune de ces approches ne traite les soft deadlines.
3.4
Approches pour les systèmes MPSoC
Les systèmes embarqués multiprocesseurs dont la communication est à base de bus amplifient
la complexité du problème de placement et ordonnancement. Car dans ce type de systèmes les
bus sont assimilés à des processeurs, ce qui entraı̂ne même le traitement pour les tâches et les
communications. Des approches diverses sont développées pour les MPSOC à base de bus, elles
cible toutes différents objectifs d’optimisation et focalisent sur certaines étapes de conception.
3.4.1
Approches basées sur l’énergie
M.T. Schmitz et al. [[31],[36]] ont développé une méthodologie, pour les systèmes embarqués
hétérogènes distribués, appelée LOPOCOS (Low Power CO-Synthesis) qui tend à minimiser la
consommation d’énergie en off-line des applications multimedia ou télécommunications, en garantissant les contraintes temps réel Hard et les contraintes de taille de la puce. Cette méthode
est constituée de deux boucles imbriquées : la boucle externe traite l’allocation des composants
et le placement des tâches. La boucle interne pour l’ordonnancement de temps, placement des
communications et la sélection de voltage.
Le placement des tâches est traité séparément du placement des communications et il est
implementé à l’aide dAG. L’algorithme nommé EE-GMA (Energy Efficient Genetic Mapping
Algorithm) est basé sur l’optimisation de l’énergie dans le sens où uniquement les solutions de
placement et d’ordonnancement correspondantes à la faible consommation d’énergie survivent
et s’accouplent, mais sa principale contribution est de garantir les contraintes de la taille de la
puce. Ces contraintes sont introduites avec des pénalités dans l’algorithme.
Le placement des communications est suivi en même temps de l’ordonnancement afin de
mieux optimiser les objectifs communs. L’ordonnancement est implementé à l’aide de la combinaison de la méthode LS avec le AG, où les priorités dynamiques des tâches dans la liste
des processus prêts (Ready) est obtenue à l’aide du AG. L’algorithme EE-GLSA (Energy Efficient Genetic List Scheduling Algorithm) cible à garantir les deadlines hard traite le problème
d’énergie dans le sens où les solutions d’ordonnancement à faible consommation d’énergie sur44
Fig. 3.6 – Méthodologie de M.T.Schmitz et al.
45
vivent et s’accouplent, là aussi les contraintes de temps sont introduites sous formes de pénalités.
La sélection voltage est appliquée pour les tâches placées et ordonnancées en utilisant l’algorithme PV-DVS généralisé (Power Variation Dynamique Voltage Scaling). Les relâchements
sont exploités en considérant les profiles énergétiques des tâches. Cet algorithme ordonnance
les tâches 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
priorités dynamiques qui distribue par incrémentation les relâchements disponibles aux tâches à
consommation d’énergie la plus importante.
F.Gruian et al. [[13]] ont développés simultanément une méthode d’ordonnancement et sélection de voltage pour des tâches pour les MPSoC avec un placement déjà fait 3.7. La méthode
tend à minimiser l’énergie consommée par les traitements, en vérifiant les contraintes temps hard.
DVS avec distribution uniforme des relâchements est appliquée dans les domaines continus et discrets pour des niveaux à simple et double voltage en ignorant la consommation due au switching.
Fig. 3.7 – Méthodologie de F.Gruain et al.
La méthode est implementée avec LS basée sur des niveaux avec des priorités dynamiques.
LS bas niveau donne la priorité à la tâche prête, qui donne le minimum d’énergie si elle est
retardée d’une seule unité de temps, ou celle qui va atteindre rapidement son temps de debut le
plus tard (LST : Latest Start Time). Le coefficient α est donne aux tâches urgentes, il permet
aussi a la boucle externe de trouver l’optimum entre les délais et la minimisation d’énergie.
3.4.2
Approche pour les contraintes temps réel soft
L.A Cortes et al. [[30],[29]] a proposé un ordonnancement quasi statique pour les MPSoC
avec des contraintes temps réel hard et soft 3.8, où il explicite les points de switching dépendants
46
des temps exigés, des temps maximums d’exécution des tâches et sur les fonctions utilitaires associées aux tâches. En se basant sur cet aspect, l’algorithme choisir en on-line le chemin d’utilité
maximum dans l’arbre d’ordonnancement en fonction des temps d’exécution actuel des tâches
et les points activés de switching. L’ordonnancement statique de l’arbre garantir la vérification
des deadlines et maximise la fonction d’utilité totale des tâches. Ceci s’obtient en premier par
l’ordonnancement des tâches critiques. Il assure aussi le placement des tâches sur les processeurs,
les communications et les calculs sont traités de la même manière car les bus sont assimilés à
des processeurs.
Fig. 3.8 – Méthodologie de L.A.Cortes et al.
Pour cette approche, les deux méthodes BB et LS sont utilisées pour l’ordonnancement des
deadlines soft et pour déterminer les intervalles de temps des points de switching dans l’arbre
d’ordonnancement.
La fonction totale d’utilité est la somme des fonctions individuelles d’utilité des tâches,
et explicite la qualité de dégradation des performances du système quand les deadlines soft
sont ignorés. Les fonctions d’utilité associée aux tâches ne subissent pas d’augmentation, elles
dépendent des temps nécessaires de traitement des tâches et permettent de capter les tâches
critiques. Les temps d’exécution des tâches sont variables et non uniformément distribués dans
un intervalle.
3.4.3
Approche pour les contraintes temps réel hard
Dans leur approche L.Benini et al.[[31]] introduisent une méthode complexe pour le placement et l’ordonnancement de voltage variable. Ils proposent un formalisme et une solution pour
le problème d’optimisation de l’allocation, l’ordonnancement et la sélection du voltage discret
en minimisant la perte d’énergie du système et du switching. Cette approche est basée sur la
technique de décomposition, utilisant les Benders logiques où le problème de placement est ré-
47
solu à l’aide de la programmation linéaire en nombre entier et l’ordonnancement à l’aide de la
programmation par contrainte.
Benini prend aussi comme modèle un graphe de tâches acyclique direct où les nœuds représentent les tâches ayant comme propriétés des deadlines dlt et W CNt comme nombre de cycles
d’horloge nécessaire pour son exécution dans le pire des cas. Les arcs représentent les communications inter-tâches et ils ont comme valeur le volume de données échangées entre les tâches
représentées par les nœuds reliés par ces arcs. Ils introduisent aussi le nombre de cycles d’horloge
nécessaires au basculement entre les modes lecture/écriture des données notées par W CNR et
W CNW . Les tâches sont exécutées sur un ensemble de processeurs P. Chaque processeur peut
fonctionner avec plusieurs modes de vitesse et d’énergie. Chaque tâche nécessite de l’énergie pour
son exécution et des communications. En plus, quand un processeur bascule entre les modes, il
dépense du temps et de l’énergie. Les auteurs notent par Eij l’énergie dépensée par le processeur
quand il bascule de la fréquence i à la fréquence j. Et par Tij le temps perdu pour passer de
la fréquence i à j.Pour le traiter, les auteurs l’ont décomposé en deux sous problèmes. Le premier appelé « problème global » consiste à affecter les processeurs et les fréquences aux tâches,
le second appelé « sous problème » fait l’ordonnancement des tâches en utilisant les résultats du
« problème global » .
Pour ce dernier ils font le placement avec minimisation de l’énergie selon certaines fréquences
tout en respectant les deadlines de chaque tâche.
M
P X
X
p=1 m=1
[Xptm
T
W CNrttl
W CNt X
W CNwttlm
(Rpptlm
+
+ Wpttlm
)] ≤ dlt ∀t
fm
fm
fm
t =1
i
–
–
–
–
Xptm : égale à 1 si la tâche t est affectée au processeur p fonctionnant au mode m, 0 sinon.
W CNt : le nombre de cycles d’horloge nécessaires à l’exécution de t au pire cas.
fm : est la fréquence de cycle d’horloge quand la tâche est exécutée au mode m.
Rppt1m : est égale à 1 si la tâche t est affectée au processeur p, lit les données au mode à
partir de t1 quand celle-ci n’est pas affectée à p ; sinon 0.
– Wptt1m : même définition que Rppt1m mais en écriture.
– W CNrtt1 : c’est le nombre de cycles nécessaires pour que t affectée à R lit à partir de t − 1.
– W CNwtt1 : même définition que W CNrtt1 mais en écriture.
– dlt : c’est le deadline de la tâche t.
Dans le sous problème, Benini essaye de faire l’ordonnancement tout en respectant les temps
de début et de fin de chaque tâche. OF est la fonction, objectif à minimiser dans ce sous
problème :
OF =
P
X
p=1
X
T ransCostij
(i,j)∈Sp
next(i)=j
Où T ransCostij est une valeur obtenue par la méthode introduite par Benini en utilisant la
décomposition à l’aide des Benders. Cette fonction objectif doit être minimisée tout en respectant
48
les contraintes de precedence. Si l1 et l2 sont deux activités qui se suivent alors, il faut que :
Startl1 + durationl1 + T ransT imel1 l2 ≤ Startl2
Où Startl1 , Startl2 sont les temps de début des activités l1 et l2 ;
Durationl1 =
W CNi
fi
T ransT imel1 l2 est le temps d’initialisation spécifié dans la matrice des transitions obtenue
avec les Benders.
3.4.4
Approches basées sur la mémoire
R.Szymanek et al.[40],[41] ont développé une méthode qui fait le placement et l’ordonnancement simultanément avec un équilibrage de l’utilisation de la mémoire et en vérifiant les deadlines
hard 3.9. La méthode fait le placement en mémoire du code et des données, et s’assure aussi que
les données échangées soient présentes dans les mémoires du producteur et du consommateur
pendant la communication.La méthode est basée sur LS avec un objectif adapté et des priorités
dynamiques qui aident l’outil CLP à explorer efficacement l’espace des solutions. La tâche la
plus importante en consommation de données ou urgente (selon l’objectif) est toujours assignée
au processeur le plus pauvre en terme d’utilisation de la mémoire en code ou en données. Les
objectifs sont inter-changés quand les contraintes de données ne sont pas vérifiées.
49
Fig. 3.9 – Méthodologie de R.Szymanek et al.
Résumé Comme on le voit dans les tableaux (3.3,3.4)les méthodologies sont développées pour
certains domaines et objectifs. Ainsi M.T.Schmitz et al. [65,68] ont développé une méthodologie
pour la minimisation d’énergie quand A.Andrei et al.[[4]] et F.Gruian et al. [[13]] ont focalisé sur le
DVS. L.A.Cortes et al. [[30],[29]] ont développé le placement pour les soft deadlines pendant que
R.Szymanek et al. [[41]] ont travaillé sur un placement et ordonnancement basé sur la mémoire.
Dans toutes ces méthodes les deadlines hard sont vérifiées. Les heuristiques constructives (LS)
et transformatives (GA) comme la programmation mathématique (NLP, MILP, CLP) et les
méthodes déterministes ont été utilisées pour traiter séparément ou simultanément les objectifs
désignés.
Réf
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. 3.3 – Méthodologies pour MPSOC à base de Bus
50
3.5. Comparaison entre les techniques de placement et d’ordonnancement
Réf
M.T.Schmitz
et al
A.Andrei et al
F.Gruian et al
R.Szymanek et al
L.A.Cortes et al
Consommation d’énergie
Dynamique
Statique
Task Comm Task Comm
DVS
DVS
DVS
-
-
ABB
-
-
Contraint
du temp
Hard Soft
Y
Y
Y
Y
Y
Y
mémoire
Code Data
Y
Y
-
Y
-
Zone
Y
-
Tab. 3.4 – Les objectifs des MPSOC à bus
3.5
Comparaison entre les techniques de placement et d’ordonnancement
Les méthodes vues auparavant concernant ce problème vont être comparées par la suite
selon les critères : Contraintes de temps, consommation d’énergie et les contraintes de taille ou
de surface.
3.5.1
Vérification des contraintes de temps réel
Par contraintes de temps réel, on sous entend les deadlines soft et Hard. L’ordonnancement
essaie souvent à vérifier les contraintes de temps, mais le placement aussi, cible la minimisation
du délai total d’exécution. Même si dans les présentations précédentes, on a parlé des MPSOC
et NOC, dans la suite de cette comparaison, c’est uniquement ces derniers qui sont l’objet de
notre étude.
a) Les contraintes temps réel hard dans les NOC Les approches pour les NOC ciblent
souvent la vérification des contraintes temps réel hard à cause du problème des communications
qui est plus pertinent et plus complexe. C’est pour cette raison que dans ces systèmes, on donne
plus d’attention aux délais des communications et l’interdépendance (topologie) des éléments du
NOC.
G.Varaktar et al.[[17]] ne garantissent pas les hard deadlines, les communications ne sont ni
placées, ni ordonnancées dans le NOC et les délais sont ignorés pendant la vérification des deadlines. De plus, des valeur moyennes pour le ET (temps d’exécution) des tâches dans le WCET
sont utilisées. Durant le placement et l’ordonnancement simultanés, la tâche la plus critique est
affectée au processeur dans la disponibilité la plus proche, ou à celui auquel la tâche la plus
communicative avec elle est affectée, tout en veillant à ce que les deadlines restent vérifiés. La
tâche la plus critique est celle qui a le temps de début 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 où une tâche est prête et le processeur disponible pour elle. LFT est le minimum entre
51
le deadline et le temps le plus lointain de début de ses successeurs.
T. Lei et al. [[45]] ne garantissent pas, eux aussi, les hard deadlines car WCET pour les tâches
et des délais moyen pour les communications sont utilisés pendant la vérification des deadlines
dans chaque TG de l’ensemble des TG. Le placement et l’ordonnancement des communications
ne sont pas traités car le chemin minimal des communications qu’il utilise est estimé d’une façon
grossière. C’est du chemin minimal que dépend l’affectation exclusive des liens et l’évitement
des deadlock. Le délai final des communications dépend de leur volume, de la distance minimale
de communication et du délai de l’interface réseau pour la « paquetisation et dépaquetisation »
des messages. Durant l’allocation des groupes IP et le placement des tâches, le délai global du
chemin critique est minimisé pour chaque TG dans l’ensemble T. La fonction objectif est le
maximum entre le délais sur le chemin critique et le deadline pour chaque TG. Les deadlines
Hard sont vérifiés sur le chemin critique quand la fonction objectif à une valeur inférieure ou
égale au deadline maximal de l’ensemble TG.
D. Shin et al. Garantissent le deadline hard. Ils utilisent le WCET des tâches et des valeur
pessimistes pour les délais de communication sont utilisées pendant la verification des deadlines
hard. La communication est placée sur le chemin le plus court du NOC qui est minimisé durant
l’allocation des tuiles. Ceci implique que plusieurs arcs du GT peuvent utiliser le même lien ce qui
rend plus compliquées, les problèmes de routage et de l’ordonnancement des communications.
Ceci rend aussi le délai de communication étroitement lié à la bande passante et la vitesse
(fréquence) de transmission des données. Le délai de l’arc (Edge delay) est la somme des délais
des liens constituant le chemin de routage tout en ignorant les temps de basculement (due a
l’ordonnancement). Durant l’ordonnancement des tâches, la tâche la moins mobile est la plus
prioritaire. La mobilité d’une tâche est donnée par
|ASAPstart − ALAPend |
et elle est basée sur une évaluation pessimiste des délais de communication.
J.Hu et al [[24]] garantissent aussi les hard deadlines. WCET des tâches et communications
sont utilisées pendant la verification des hard deadlines. La communication est placée et ordonnancée sur le chemin disponible minimal du NOC ayant un deadlock libre (bande passante non
saturée). Durant le placement et l’ordonnancement simultanés, la tâche la plus critique en temps
(EFT . BD : BD = Budgeted deadline) à partir de la liste des tâches prêtes (ready list) est affectée au processeur le plus rapide. La tâche la plus critique en temps est celle qui dépasse son BD
avec une différence maximale EFT-BD. Quand aucune tâche critique (EDF < BD) n’est dans
la liste, BD reste vérifie quand on affecte la tâche à forte consommation d’énergie au processeur
ayant la consommation la plus faible. EFT contient les délais des communications entrantes et
WCET ceux des tâches pendant que BD contient la moyenne ET des tâches et leur relâchement
(slack) en ignorant les communications. Les slack sont distribués d’une façon non uniforme sur
les tâches, ils sont basés sur leur énergie et les profils de délais (variances).
52
b ) Comparaison Les tableaux 3.5 et 3.6 résument les approches pour les NOC pour vérifier
les contraintes temps réel hard selon les principaux critères. La table 3.5 montre comment le
temps de communication est minimisé dans chaque approche et comment les contraintes deadlines hard sont garanties. La table 3.6 représente les modalités de maximisation des performances
de temps durant le placement et l’ordonnancement des tâches.
Réf
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
Tâche
Temp
ET
Com
WCET
WCET
WCET
WCET
AVG
WCRT
WCRT
Garantie
de
Deadline
N
N
Y
Y
Tab. 3.5 – Les délais de communication dans les NOC
Réf
G.Varatkar
et al.
T.Lei et al.
D.Shin et al.
J.Hu et al.
placement des
tâches
But
affectation PE
disponible le
plus proche
Min.chemin critique
Repair BD
violations EFT<BD
Fastest Greedy
reassignments
Ordonnancement
des tâches
Priorité
Temp critique
min(EST+LFT)
ASAP, ALAP
temp critique
min|ASAPstar − ALAPend |
Temp critique
max(EFTBD),EFT.BD
Tab. 3.6 – Délais de traitement dans les NOC
1. Délai de communication : Le délai de communication dans les NOC à un grand impact
sur le coût total. Le délai d’arc (Edge delay) dépend de la taille message et le délai de transmission unitaire. La taille de message par la bande passante nous donne le nombre d’unités
à transmettre. Ils représentent souvent le volume de communication de l’arc et de la bande
passante du lien respectivement. Le délai de transmission par unité de communication
est influencé par l’algorithme de routage, et dépend de la distance de la communication,
et du délai de communication des composants dans le NOC tels que le lien, switch et
interface réseau. Le délai du lien dépend de sa vitesse, son volume de communication et
sa bande passante du lien. Quand les liens sont utilisés d’une façon exclusive, le volume
de communication du lien est égal à la bande passante, et sa vitesse devient le délai du lien.
53
A l’exception du volume de communication et distance de communication, tous les autres
constituants du délai de l’arc sont donnés comme constantes et 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 délai de communication. Le volume
de communication inter-processeur peut être minimisé au moment du placement des tâches
pendant que le volume de communication du lien est optimisé durant le placement des
communications. La minimisation de la distance (longueur du chemin) de communication
se fait pendant l’allocation des tuiles et la minimisation du chemin de routage pour chaque
arc se fait durant le placement des tâches. Les deadlock (blocage) et congestion peuvent
être évités en traitant l’ordonnancement des communications.
2. Vérification des deadlines hard :Hard deadlines sont garanties si et seulement si les
pires ET des délais de tâches et communications sont fournies. ET de tâche sont souvent
donnée comme WCET. L’estimation pessimiste des délais de communication nécessite
la connaissance des pires conditions dans lesquelles la communication est faite, comme
exemple, le volume total des communications des arcs se partageant un lien [[10]] ou le
chemin minimal disponible quand l’usage des liens est exclusif.
3. Maximiser les performances de temps :Les priorités des tâches pendant l’ordonnancement ou la sélection des processeurs plus un objectif, durant le placement de tâches peut
accroı̂tre les chances de vérifier les deadlines hard tout en minimisant le coût ou le temps
global. Ainsi, un meilleur ordonnancement peut être trouvé si la priorité des tâches englobe
des informations sur les communications entrantes et relâchements disponibles. On peut
faciliter la vérification des deadlines hard par l’affectation des tâches les plus critiques aux
processeurs les plus rapides [[24]].
3.5.2
La minimisation de la consommation d’énergie
Par minimisation d’énergie on veut dire réduction dynamique et statique de la consommation
d’énergie par les tâches et les communications, durant le placement de tâches et la sélection
de voltage. La majorité des approches cible la minimisation dynamique d’énergie de tâches.
Certaines d’entre elles traitent même les deux problèmes de placement de tâche selon l’énergie
et le DVS des tâches. Une seule approche traite SVS pour les liens quand les approches pour
les NOC tendent à minimiser l’énergie de communication en minimisant les communications
du NOC sur le plan volume et distance. Les autres méthodes traitent la réduction statique de
l’énergie.
a )Placement de tâche avec optimisation de l’énergie Plusieurs approches ont été proposées, nous citerons ci-après quelques unes en insistant sur l’impact de la priorité des tâches,
assignation des PE et les objectifs spécifiés pour la minimisation d’énergie.
G.Varatkar et al.[[17]] tendent de réduire l’énergie des communications en minimisant le volume des communications inter-processeur. Ils se basent aussi sur le fait que les communications
54
ne dépassent pas un certain seuil (critère de communication). Durant le placement et ordonnancement simultanés des tâches, la plus urgente est assignée au processeur auquel est affectée
la tâche avec laquelle elle communique le plus, tout en vérifiant les deadlines hard. L’énergie
de communication dépend 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 traités, ce qui ne permet pas de connaı̂tre le volume de communication par
lien. Le critère de communication est utilisé 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 dépasse pas le volume
moyen global de communication (à partir de tous les arcs dans TG) multiplié par un paramètre
K | (0 ≤ k ≤ 10),coefficient d’arrête donné par l’utilisateur.
D.Shin et al.[[10]] tendent de réduire l’énergie de communication en minimisant le volume
de communication inter-processeur et les distances de communication dans le NOC durant le
placement et l’assignation réseau. L’énergie de communication est la somme des énergies statique et dynamique de tous les liens. L’énergie dynamique des liens dépend du volume total des
communications des arcs partageant le même lien, la vitesse (fréquence) du lien et la capacité
de switching du lien. Le volume de communication de chaque lien est connu après le placement.
J.Hu et al. [[24]] tendent de minimiser la consommation d’énergie totale. Durant le placement
et ordonnancement simultanés, les tâches non critiques avec le plus grand intervalle de consommation d’énergie sont affectées aux processeurs ayant les consommations les plus faibles mais
qui soient assez rapides pour vérifier les deadlines hard. L’intervalle de la consommation d’énergie d’une tâche est la différence entre les deux premières valeur minimales de la consommation
globale d’énergie obtenu à partir des ordonnancements partiaux. Les tâches non critiques sont
celles ayant EFT < BD. La communication est placée et ordonnancée sur le chemin le plus court,
disponible et non saturé dans le NOC. La consommation d’énergie globale est la somme des
énergies de calcul de toutes les tâches plus l’énergie de communication de tous les arcs. L’énergie
de communication d’un arc dépend du volume des communications de cet arc (en bits) et celle
de transfert d’un bit. L’énergie de communication par bit s’obtient par une formule fonction de
la longueur du chemin de routage, l’énergie du lien et l’énergie de switching.
La priorité de la tâche au moment de l’ordonnancement aussi bien que l’assignation des PE
et l’objectif d’optimisation du placement peuvent augmenter la préservation de la consommation
d’énergie dynamique. A cet effet, il est conseillé d’affecter la tâche avec le plus grand intervalle
de consommation d’énergie à son processeur de consommation minimale durant le traitement
du placement et ordonnancement (J.Hu et al. [[24]]). Le modèle d’énergie de communication
dépend du volume de communication et l’énergie de transmission. J.Hu et al.[[24]] introduisent
les informations de routage dans l’énergie de transmission par bit quand D.Shin et al. [[10]]
introduisent des informations pour l’assignation de la vitesse de lien.
En se basant sur ces critères on peut dire que l’approche [[24]] est la meilleure méthode
55
Réf
G.Varatkar
et al.
D.Shin et al.
Priorité
-
Task mapping
affectation PE
La plupart de volume
de communication
-
J.Hu et al.
difference
d’énergie
énergie
dernièrement
But
limité les volumes
de communication
min les volumes
de communication
-
Tab. 3.7 – Placement de tâches avec optimisation de l’énergie
d’optimisation d’énergie pour les NOC car elle minimise la consommation totale d’énergie et
ordonnance les communications sur le plus court chemin disponible en vérifiant le deadlock. La
deuxième meilleure méthode est celle de D.Shin et al.[[10]] qui réduit l’énergie de communication
et la distance de communication. G.Varatkar et al [[17]] minimise uniquement le volume de
communication inter processeur sans traiter le placement de communication.
3.5.3
Contraintes matérielles et de mémoire
Les contraintes matérielles sont relatives à la capacité de la mémoire ou au nombre de tâches
pouvant être exécutées par un élément de calcul. Parmi les approches vue auparavant, seulement
trois traitent ce problème.
D.Shin et al. [[10]] traitent ces contraintes durant le placement de tâches en imposant chaque
élément de calcul qui s’accommode avec la tuile du NOC. Ce qui revient à vérifier que pour
chaque nombre de tâches affectées à un processeur, la taille mémoire et seuil maximal ne dépassent pas les caractéristiques de la tuile du N0C.
M.T.Schmitz et al. [[31],[37]] traitent eux aussi ces contraintes lors du placement de tâches.
Pour eux les contraintes matérielles sont relatives à la taille de la mémoire et la surface de la puce
dépendant du type de matérielle (DSP, ASIC, FPGA). Dans la fonction objectif, ils introduisent
des coefficients permettant de pénaliser la non vérification de ces contraintes. Pour R.Szymanek
et al.[[41]], les contraintes sont vérifiées après le placement en vérifiant pour chaque mémoire si
le code et la quantité des données affectées ne dépassent pas la taille disponible.
56
Conclusion
L’étude de l’état de l’art dans le domaine du placement sur les NOC nous a permis de
tirer quelques constations. La première est que dans ce domaine, par placement, on désigne
Assignation, affectation et ordonnancement (AAS). Effectivement dans les travaux vus, et surtout ceux fait récemment, on ne traite jamais le placement sans ordonnancement ou l’inverse.
Tous les travaux les abordent ensemble. Seule la manière change. Pour certains, ils sont traités
séquentiellement, c’est-à-dire placement ensuite ordonnancement, pour d’autres, ils sont traités ensemble c’est-à-dire simultanément. Pour chacune de ces approches, on a vu qu’il y a des
avantages et des inconvénients, même si la deuxième approche l’emporte. Le deuxième constat
est que ce problème est traité pour atteindre certains objectifs, comme le temps réel, consommation d’énergie, mémoire,. . . etc. Souvent ces objectifs sont recherchés ensembles. Car, on ne
peut minimiser le temps de calcul global sans minimiser le coût de communication global, ou
augmenter les performances du NOC sans penser à minimiser la perte de l’énergie,. . . etc. D’où
notre conviction que ce problème ne peut être solutionner en cherchant des objectifs séparément
mais d’essayer d’au moins d’atteindre quelques objectifs pertinents ensemble. C’est ce qu’on
appelle l’optimisation multi-objectifs. En plus de ce qui a été avancé, du fait des domaines qu’on
aborde où les applications peuvent être hiérarchiques où l’on rencontre des tâches répétitives
et d’autres non, forcément les techniques qu’on va utiliser seront de familles différentes. Si les
métaheuristiques s’imposent pour l’irrégulier dans les problèmes de grande taille, il faut plutôt
penser à des méthodes déterministes pour les applications à tâches répétitives.[18]
57
Chapitre 4
Optimisation Multi-Objectifs
58
4.1. Introduction
4.1
Introduction
La plupart des problèmes réels nécessitent l’optimisation simultanée de plusieurs objectifs.
Dans le cas de l’optimisation mono-objectif, la solution optimale est facilement définie , ce n’est
le cas quand on a plusieurs objectifs. Au lieu d’une solution unique, le résultat d’une proposition
multiobjectifs est généralement un assortiment de solutions, qui se distinguent par différents
compromis réalisés entre les objectifs. Les solutions qui le composent sont optimales, dans le
sens où il n’existe dans l’univers de recherche aucune solution meilleure si tous les objectifs sont
considérés de façon simultanée.
Ainsi, le but de l’Optimisation Multiobjectifs, aussi appelée Vectorielle, consiste à obtenir les
solutions et, par conséquent, à connaı̂tre l’ensemble des compromis possibles entre les objectifs.
Cela fournit à l’ingénieur une meilleure compréhension de son problème.
4.2
Définitions
Def. 1 Un problème d’optimisation générale avec k variable de décision et n fonctions objectif
st définit comme :
(
minimize f (x) = (f1 (x), f2 (x), . . . , fn (x)).
sujet x ∈ Xf .
Où x représente une solution et Xf ⊆ X est l’ensemble de solutions réalisable.Le vecteur
des fonctions objectifs f (x) ordonne le vecteur de decision x=(x1 , x2 , . . . , xn ) dans l’espace de
decision (X) vers vecteur objectif z=(z1 , z2 , . . . , zn ) dans l’espace objectif (Z).
Def. 2 (relation de dominance) Si on a deux vecteur objectifs z 1 , z 2 on a :
– z 1 z 2 (z 1 strictement dominer par z 2 ) si zi1 ≤ zi2 ∀ i ∈ {1, . . . , n}.
– z 1 < z 2 (z 1 dominez 2 ) Si zi1 ≤ zi2 Et z 1 6= z 2 , ∀i ∈ {1, . . . , n}.
– z 1 ≤ z 2 (z 1 partiellement dominer par z 2 ) Si zi1 ≤ zi2 , ∀i ∈ {1, . . . , n}.
– z 1 ∼ z 2 (z 1 incomparable avec z 2 ) Si 6 ∃i 6= j ∈ {1, . . . , n} telque zi1 < zi2 et zj1 < zj2 .
Def. 3 Un vecteur de decision x ∈ A ⊆ Xf et dit non dominer dans A Si
6 ∃ a ∈ A telque f (a) < f (x)
.
59
4.2. Définitions
Fig. 4.1 – Un Front Pareto
Fig. 4.2 – D’un Espace de Recherche Vers Un Front Pareto
60
4.3. les algorithmes d’optimisation
4.3
les algorithmes d’optimisation
Nous avons choisi l’utilisation deux types d’algorithmes d’optimisation pour résoudre notre
problématique. le premier est l’algorithme de Brunch & Bound, qui est une méthode de
recherche exacte,le deuxième est l’algorithme Génétique, qui est une méthode de recherche
heuristique.
Notre choix est justifié par le fait que l’on a trois types de nœuds ( irrégulier, répétitif,
composé ) dans chaque graphe ( application, architecture ), notre travail, consiste à affecter
chaque type de nœud du graphe d’application au même type de nœud du graphe d’architecture
et appliquer une méthode de recherche appropriée pour trouver le bon emplacement des tâches
sur les processeurs. pour cela l’algorithme de Brunch & Bound va s’appliqué sur les nœuds
répétitifs et l’algorithme Génétiqueva s’appliquer au nœuds irréguliers et ceux composés pour
chaque niveau du graphe
.
la figure 4.3 représente un schéma de différentes méthodes de recherches.
Fig. 4.3 – Les Algorithmes d’optimisation
4.3.1
l’algorithme de Brunch & Bound
Pour plusieurs problèmes, en particulier les problèmes d’optimisation, l’ensemble de leur solutions est fini (en tous les cas, il est dénombrable). Il est donc possible, en principe, d’énumérer
toutes ces solutions, et ensuite de prendre celle qui nous arrange. L’inconvénient majeur de cette
approche est le nombre prohibitif du nombre de solutions : il n’est guère évident d’effectuer
cette énumération. La méthode de Branch & Bound (procédure par évaluation et séparation
progressive) consiste à énumérer ces solutions d’une manière intelligente en ce sens que, en utilisant certaines propriétés du problème en question, cette technique arrive à éliminer des solutions
61
partielles qui ne mènent pas à celle que l’on recherche.[3]
De ce fait, on arrive souvent à obtenir la solution recherchée en des temps raisonnables.
Bien entendu, dans le pire des cas, on retombe toujours sur l’élimination explicite de toutes les
solutions du problème. Pour ce faire, cette méthode se dote d’une fonction qui permet de mettre
une borne sur certaines solutions pour soit les exclure soit les maintenir comme des solutions
potentielles. La performance d’une méthode de Branch & Bound dépend, entre autres, de la
qualité de cette fonction (de sa capacité d’exclure des solutions partielles tôt).
Branch & Bound, est une méthode générique de résolution de problèmes d’optimisation,
plus particulièrement d’optimisation combinatoire ou discrète. C’est une méthode d’énumération
implicite : toutes les solutions possibles du problème peuvent être énumérées mais, l’analyse des
propriétés du problème permet d’éviter l’énumération de larges classes de mauvaises solutions.
Dans un bon algorithme par séparation et évaluation, seules les solutions potentiellement bonnes
sont donc énumérées.
a ) Principe Soit S un ensemble fini mais de ”grande” cardinalities qu’on appelle ensemble
(ou espace) des solutions réalisables.
On dispose d’une fonction f qui, pour toute solution réalisable x de S, renvoie un coût f (x).
Le but du problème est de trouver la solution réalisable x de coût minimal.D’un point de vue
purement existentiel, le problème est trivial : une telle solution x existe bien car l’ensemble S
est fini. En revanche, l’approche effective du problème se confronte à deux difficultés.
– La première est qu’il n’existe pas forcément un algorithme simple pour énumérer les éléments de S.
– La seconde est que le nombre de solutions réalisables est très grand, ce qui signifie que le
temps d’énumération de toutes les solutions est prohibitif (la complexité algorithmique est
généralement exponentielle).
Dans les méthodes par séparation et évaluation, la séparation permet d’obtenir une méthode générique pour énumérer toutes les solutions tandis que l’évaluation évite l’énumération
systématique de toutes les solutions.
pour lancer l’algorithme on doit avoir en possession :
1. Un moyen de calcul d’une borne inférieure d’une solution partielle.
2. Une stratégie de subdiviser l’espace de recherche pour créer des espace de recherche de
plus en plus petits.
3. Un moyen de calcul d’une borne supérieure pour au moins une solution.
b ) Parcours de l’arbre Par convenance, on représente l’exécution de la méthode de B&B
à travers une arborescence. l’algorithme utilise le principe de la profondeur d’abord, en parcourant l’arbre de l’espace des solutions.
62
La méthode commence par considérer le problème de départ avec son ensemble de solutions,
appelé la racine. Des procédures de bornes inférieures et supérieures sont appliquées à la racine.[3]
Si ces deux bornes sont égales, alors une solution optimale est trouvée, et on s’arrête là.
Sinon, l’ensemble des solutions est divisé en deux ou plusieurs sous problèmes Séparation, devenait ainsi des enfants de la racine.
La méthode est ensuite appliquée récursivement à ces sous problèmes, engendrant ainsi une
arborescence. Si une solution optimale est trouvée pour un sous problème, elle est réalisable,
mais pas nécessairement optimale, pour le problème départ.
Comme elle est réalisable, elle peut être utilisée pour éliminer toute sa descendance : si la
borne inférieure d’un nœud dépasse la valeur d’une solution déjà connue, alors on peut affirmer que la solution optimale globale ne peut être contenue dans le sous-ensemble de solution
représenté par ce nœud. La recherche continue jusqu’à ce que tous les nœuds soient explorés ou
éliminés.
c ) Pseudo code de l’algorithme Branch & Bound
Initialisation : miel-sol=∝ ; Bi (p0 ) := f (p0 ) ; p := {(p0 , Bi (p0 ))}
Tanque p 6= 0 faire
Sélection : sélectionner un nœud p de P ; p := p/{p}
Séparation : Décomposer p en p1 , p2 , p3 , ...pk ;
pour i := 1 à k faire
Evaluation Bi (pi ) := f (pi ) ;
Si Bi (pi ) == f (x), x réalisable et (f (x) < meil-sol) alors
meil-sol :=f (x) ;
solution=x ;
Sinon si Bi (pi ) > meil-sol Alors
élaguer : élaguer pi ;
Sinon p := p ∪ {(pi , Bi (pi ))}
Fin Si ;
Fin Si ;
Fin Faire ;
Fin Tanque ;
Résultat : SolutionOptimale := solution ; ValeurOptimale := meil-sol ;
63
d ) Organigramme de branch & Bound
tionnement de l’algorithme de B&B.
la figure 4.4 represente un diagramme de fonc-
Fig. 4.4 – Organigramme de Branch & Bound
64
4.3.2
Algorithme génétique (AG)
les algorithmes génétiques peuvent être considérés comme des méthodes d’optimisation stochastique, mais ils ont bien d’autres champs d’applications, comme par exemple en reconnaissance des formes et en intelligence artificielle (systèmes de classeurs ou programmation génétique), en théorie des graphes, en vision et en analyse d’images, en science des matériaux, . . .
etc. L’intérêt d’utiliser un algorithme génétique pour optimiser des fonctions irrégulières est
qu’ils savent effectuer une recherche stochastique dans un large espace de recherche, en faisant
évoluer un ensemble de solutions (appelée population), au lieu d’une seule solution, comme cela
est fait classiquement en optimisation stochastique (exemple : un recuit simulé). Dans l’évolution naturelle, le problème auquel chaque espèce est confrontée est de chercher à s’adapter à un
environnement complexe et généralement non statique.
Très schématiquement, la ”connaissance” acquise par chaque espèce est codée dans les chromosomes de ses membres. Lors des reproductions , les contenus des chromosomes sont mélangés,
modifiés et transmis aux descendants par un certain nombre d’opérateurs génétiques : la mutation, qui se traduit par l’inversion d’une faible partie du matériel génétique, et le croisement (ou
recombinaison) qui échange certaines parties des chromosomes des parents. Cette particularité
de l’évolution naturelle : la capacité d’une population à explorer son environnement en parallèle
et à recombiner les meilleur individus entre eux, est copiée et exploitée au sein d’un algorithme
génétique. Un résultat formel important mis en évidence par Holland (largement reconnu comme
le fondateur du domaine) a été de prouver que, même dans des espaces de recherche larges et
complexes, sous certaines conditions, les algorithmes génétiques convergent vers des solutions
qui sont à peu près globalement optimales.
C’est-à-dire que la population se concentre autour d’un optimum global. Dans toutes les
approches évolutives, les individus représentent des solutions ou des points de l’espace de recherche. Cet espace de recherche est appelé environnement, c’est sur ce dernier que l’on cherche
à maximiser une fonction (positive) appelée fitness. La principale caractéristique des algorithmes
génétiques, par rapport aux autres techniques d’inspiration comportementale, est de travailler
sur des codages et non sur des solutions réelles. Ces codes sont appelés chromosomes et la plupart du temps, en optimisation, ils sont binaires et de longueur fixe. L’algorithme génétique fait
donc évoluer sa population de façon à adapter les individus à l’environnement, cela se traduit au
sens algorithmique du terme par une maximisation de la fonction d’évaluation sur les individus
de la population.
a ) Principe Il est basé sur une procédure itérative durant laquelle un ensemble de solutions
(Génération) est crée, pour chaque itération, en commençant par l’ensemble des solutions initiales (population initial ).L’évolution de ces générations est assurés par des opérations de l’AG
(selection ,mutation, croisement) jusqu’a atteindre la condition d’arrêt.
65
b ) Pseudo code de l’algorithme génétique
Début
Générer population initiale.
Calculer coût.
Faire
tant que Condition arrêt non satisfaite Alors
Sélectionner parents.
Appliquer opérateurs avec probabilités.
Calculer coût.
Renouveler population
Retourner meilleur élément
Fin Tant que
Fin Faire
Fin
c ) Caractéristiques des Algorithmes Génétiques Les AG ont un ensemble de caracterstiques qu’on va les voir par la suite :
1. Le codege les AG n’opère pas directement sur les solutions mais sur leurs codages sous
forme de chromosome, où est codée par une séquence de gènes nommé génotype qui caractérise chaque espace de recherche, d’une manière générale, représentée par un vecteur
binaire ou réel de taille fixe ou variable.La figure 4.5 représente les cinq niveaux d’organisation d’un AG.
Fig. 4.5 – les cinq niveaux d’organisation d’un AG
Il existe trois types de codes dans le AG :
(a) Codage binaire : c’est le plus utilisé, dans chaque gène, on a des valeur binaires sur
une longueur de 32 Bits, comme dans la génétique chaque chromosome est constitué
de deux gènes, dans les AG les chromosomes sont représentés par deux tableaux de
66
gènes,et par analogie les individus sont représentés par des tableaux des chromosomes.
(b) Codage réel :la figure 4.6 donne une idée sur ce codage qui est très utile dans le cas
de la recherche pour maximiser une fonction réelle.
Fig. 4.6 – illustration schématique du codage des variables réelles
(c) Codage de Gray : Un inconvénient dans le codage binaire c’est qu’en utilisant
la ”Distance de Hamming pour mesurer la dissimilarité entre deux éléments de la
population si on trouve qu’ils sont voisins ça ne veut pas dire forcément qu’ils sont
proches dans l’espace de recherche.
Pour éviter cet inconvénient on fait appel au codage de Gray.Il a comme propriété
qu’entre l’élément (n) et l’élément (n + 1), donc voisins dans l’espace de recherche,
un seul bit diffère.
2. Espace de recherche
C’est l’ensemble des générations obtenues par l’application des opérations des AG à partir
de la population initiale, qui est généralement générée aléatoirement pour garantir une
diversification des individus, afin d’avoir plus de chance pour que la convergence de l’algorithme soit la plus rapide vers la solution optimale.
3. La fonction objective
C’est la fonction avec laquelle on sélectionne les parents qui vont être choisis pour la
reproduction, et par conséquent, à la survie de certaines espèces.Cette fonction se base sur
la valeur de l’individu, plus la valeur est élevée plus l’individu a une chance d’être choisi.
4. Opérateurs génétiques Sont des opérations qui s’appliquent a partir de la population
initiale et sur toutes les générations suivantes.
– Reproduction : c’est une réplique d’un processus naturel celui de la sélection naturelle,
la reproduction se fait par accouplement des chaı̂nes d’individus qui ont une valeur élevée
pour leur fonctions objectives, afin de produire une nouvelle génération qui aura la chance
d’être choisie dans la prochaine sélection.
67
– Sélection : cet opérateur est le plus important parmi tous les autres car c’est lui qui
permet aux individus de survivre, pour produire ou bien mourir.D’une manière générale
plus l’individu a une valeur de fonction objectif élevée il aura une chance d’être choisi.
Il existe quatres types de selection, on va les voire par la suite.
(a) La sélection universelle stochastique :cette méthode est basée sur un découpage d’un segment a des sous-segments autant qu’il y a d’individus.Les individus
sélectionnés sont désignés par un ensemble de points équidistants.
(b) La sélection par tournois : grâce à cette méthode, on peut obtenir des résultats
satisfaisantes.Le principe est d’effectuer un tirage avec remise de deux individus de
la population P , puis on va les faire ”Combattre”.celui qui a une fonction objectif
avec une valeur plus élevée il l’emporte avec une probabilité p /(0.5 < p < 1).On
répète ce processus n fois de manière a obtenir les n individus de Ṕ qui serviront de
parents.
(c) La méthode élitiste :Cette méthode consiste à sélectionner les n individus dont
on a besoin pour la nouvelle génération Ṕ en prenant les n meilleur individus de la
population P après l’avoir triée de manière décroissante selon la fonction objectif
de ses individus.
(d) La roulette :Dans cette sélection, chaque individu se voit attribué un secteur dont
l’angle est proportionnel à son adaptation, sa fonction objectif. On fait tourner la
roue et quand elle cesse de tourner on sélectionne l’individu correspondant au secteur
désigné par une sorte de ”curseur”, curseur qui pointe sur un secteur particulier de
celle-ci après qu’elle se soit arrêté de tourner.Cette méthode est la plus connue et
la plus utilisée.
Fig. 4.7 – la méthode de sélection de la roulette
– Croisement :Il sert a crée de nouvelles combinaisons de paramètres portés par les
individus. On applique cet opérateur après avoir appliqué l’opérateur de sélection sur la
population précédente, on se retrouve avec une nouvelle population égale à la moitié de
la population précédente, là vient le tour de l’opérateur de croisement, on doit crée n/4
couples (si on considère que la population actuelle est de n/2 individus) pour avoir les
68
n individus de la nouvelle population
.
Fig. 4.8 – Exemple de croisement en un seul point
Fig. 4.9 – Exemple de croisement en deux points
– Mutation :Cet opérateur consiste à changer la valeur d’un gène avec une probabilité
très faible, généralement comprise entre 0.01 et 0.001.,de façon a avoir toujours une
diversité dans la population.
Fig. 4.10 – Exemple de mutation
69
d ) Organigramme de l’AG Voici l’organigramme de l’AG :
Fig. 4.11 – Organigramme de l’AG
70
Conclusion
Après avoir exposé les concepts qui servent de base pour l’algorithme génétique et de
Brunch & Bound, nous avons réalisé une adaptation de ces algorithmes dans une démarche
de recherche de bonnes solutions à notre problème de placement d’application sur un NOC.
71
Troisième partie
Les Approches pour la Résolution du
Placement Hiérarchique
Multiobjectifs
72
Chapitre 5
Modélisation du Problème de
Placement et Ordonnancement
Hiérarchique
73
5.1. Introduction
5.1
Introduction
Le problème à résoudre dans sa globalité est un problème d’assignation, d’affectation et
d’ordonnancement « AAS ». Les travaux présentés par Lahua [97], Prestana [98] et Benini [66]
présentent des insuffisances car ces travaux considèrent la topologie des communication en Bus.
Les autres tels Hu [63], Mural[19] et Lei [61] présentent des méthodes d’optimisation monoobjectif. C’est-à-dire que ces méthodes ne permettent l’obtention que d’un seul objectif : temps
d’exécution, consommation d’énergie, surface, etc. jamais dans ces travaux nous avons essayé de
trouver ou de se rapprocher d’une solution satisfaisante au moins deux objectifs. En plus tous
les travaux présentés et cités précédemments ,n’ont pas pris en considération des applications de
grandes tailles structurées de façon hiérarchique où le modèle est un graphe hiérarchique dont
les nœuds peuvent être simples, répétitifs ou composés. Par conséquent notre travail sera basé
sur ce dernier problème en proposant une approche de résolution multi-objectif permettant de
trouver le meilleur mapping d’une application de ce type sur une architecture NOC.
5.2
Modèle
Def. 4 Le graphe d’application TG ( Task Graph) est un graphe orienté G(V,E) où chaque
sommet vi ∈ V représente un module (tâche) de l’application, et deux types d’arc (vi ,vj ),la
communication et la precedence.
Fig. 5.1 – Graphe d’application
Def. 5 le graphe d’architecture NT ( NOC Topology graph) est un graphe P(U,F) où chaque
sommet ui ∈ U représente un nœud de la topologie et l’arc (ui , uj ),noté par fij ∈ F représente
74
5.2. Modèle
un lien physique direct entre les éléments de ui et uj de l’architecture. Le poids de l’arc fij noté
par bwij représente la bande passante disponible à travers le lien physique fij .
Fig. 5.2 – Graphe d’architecture
Def. 6 Un graphe d’application hiérarchique HTG (respectivement d’architecture hiérarchique
HNT) est un graphe avec trois types de nœuds :
– Irrégulier : Englobe des tâches ( des processeurs ) élémentaires avec des caractéristiques
différentes. Et l’ensemble de communication ainsi la précédance entre eux.
– Répétitif : Englobe des tâches identique et une tâches particulière nommé diffuseur ( une
unité de E/S )gère les communication avec les autrs nœuds.
– Composé : Est lui même un ensemble de HTG (HNT).
Le mapping du HTG sur HNT consiste à chercher celui des graphes d’un même 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 même au niveau 2 et après le niveau 1.
75
5.2. Modèle
Fig. 5.3 – Graphe Hiérarchique d’application
76
5.2. Modèle
Fig. 5.4 – Graphe Hiérarchique d’architecture
77
5.3. Fonction coût
Def. 7 le mapping consiste à placer une communication entre deux tâches ti et tj représentée
par l’arc eij ∈ E sur le réseau de communication. Ce placement consiste à trouver le chemin qui
est souvent constitué de plusieurs liens physiques contigus, utilisés pour envoyer les données de
ti à tj .
Mais avant de considérer le mapping dans sa globalité on doit tout d’abord proposer une
solution pour un mapping multi-objectif d’un seul graphe TG sur un seul graphe NT dans un
même niveau.
5.3
Fonction coût
le placement qu’on doit trouver c’est la sommes des coûts d’exécution des tâches sur des
processeurs et aussi des coûts de communication entre les tâches.
en général
– on a une fonction f (x) qui est la valeur de la fonction objectif pour la solution x.
– X un ensemble fini des solutions d’un problème (X fini mais très grand).
on peut formaliser cette fonction comme suit :
Opt{f (x)/x ∈ X} où Opt= Min ou Max.
dans notre cas :
f (x) : est le coût.
C :ensemble de contraintes.
F onction objectif



 minimiser f(x).
et


 V erif ier c , c ... ∈ C.
1 2
78
5.4. Contraintes
5.4
Contraintes
En découlant quatre types de contraintes :
5.4.1
Les propriétés de matériel et de logiciel :
Il doit y avoir une compatibilité entre les propriétés des tâches et celles de l’architecture. Par
exemple la quantité de donnée échangé entre deux tâches ne doit pas dépasser la capacité du
canal de communication.
5.4.2
Les types de noœud des deux graphes :
Les graphes ( application / architecture ) contient au maximum trois types de nœuds et au
minimum deux types de nœuds, dans chaque niveau hiérarchique, il doit contenir les même types
de nœuds.
le placement des tâches irrégulières doit se faire sur des SOC irrégulier ,et la même chose
pour les deux autres types.
5.4.3
Le niveau hiérarchique des graphes :
Il faut que les deux graphes (de l’architecture et de l’application) aient le même niveau hiérarchique, pour que le placement soit possible. Dans le cas contraire on passe à une normalisation
pour avoir le même niveau dans les deux graphes.
5.4.4
L’équilibrage des charges :
l’ordonnancement final doit garantir que l’ensemble des tâches est bien réparti sur l’ensemble
des processeurs, où il n’y a pas une concentration des tâches sur un sous ensemble des processeurs
par rapport à l’ensemble global.
79
5.4. Contraintes
Conclusion
Après la modélisation de notre problème, nous allons détailler dans le chapitre suivant notre
approche, Pour résoudre le problème de placement et d’ordonnancement d’une application hiérarchique à calcul intensif sur une architecture hiérarchique hétérogène.
80
Chapitre 6
Contribution
81
6.1. Introduction
6.1
Introduction
Notre contribution est de trouver l’association ( mapping ) d’une application hiérarchique sur
une architecture hiérarchique, en proposant un ensemble de placements qui satisfont différentes
contraintes comme le Temps et l’énergie, pour chaque niveau de l’arbre d’application.
6.2
Modèle Mathématique [18]
Une application est définit comme un ensemble de tâches T = {t1 , t2 , . . . , tn }, et l’architecture
comme un ensemble de processeurs P = {p1 , p2 , . . . , pn } .Comme hypothèse les processeurs
peuvent fonctionnes en plusieurs modes m1 , m2 , . . ..
– On définit les variables :
0
– dijm : la durée d’exécution de la tâche i placée sur pj s’exécutant au mode m (sans
prendre en compte les communications)
.
0
0
0
– dijm = W CNijm /fjm où W CNijm est le nombre de cycles nécessaires à la tâche i pour
s’exécuter sur le processeur j au mode m. et fjm est la fréquence d’horloge du processeur
j au mode m.
– Qij : la quantité de donnée échangée entre la tâche i et la tâche j.
0
– d Qm
ijpq : la durée des communications entre les tâches i et j placées respectivement sur
les processeurs p et q en mode m.
– qij : la durée de communication unitaire ( bit, octet ) entre le processeur p et q.
– epq : l’énergie consommée par une unité de donnée ( bit, octet ) durant le transfert de p
à q.
– µ (p, q) = {(pi , qj )} : le chemin reliant p à q en cas où il n’y a pas de chemin direct.
– bpq : la bande passante de lien directe entre le processeur p et q
–
(
m
Xip
=
1 si la tâches i est executer sur le processeur p au mode m
0 ailleur
– On définit les fonctions :
S’il n’existe pas un lien directe entre p et p alors la consommation d’énergie et le temps
de communication des tâches i et j si elles sont placées sur les processeurs p et q au mode
m en utilisant le même chemin sont :
P
0
– d Qijpq = Qij ∗ qpl pk où (pl , pk ) ∈ µ (p, q)
P
0m
– Eijpq
= Qij ∗ epl pk
82
6.2. Modèle Mathématique [18]
Dans ce modèle la consommation d’énergie, due a la communication intra-processeur est
négligeable, ainsi que la durée de communication.
Sinon
0
– d Qijpq = Qij ∗ qpq ∈ µ (p, q)
0m
– Eijpq
= Qij ∗ epl pk
la durée d’execution totale :
P
0
– DE = nbrtche
dijm
k=1
la durée de communication totale :
P
Pnbrtche 0
– DC = nbrtche
d Qijpq
i=1
j=1
– Les fonctions objectifs :
– La fonction du Temps :
Di =
m
m
X
m=ml
0
dipm +
S
S
N X
X
X
mn
X
m
m
Xip
∗ Xjq
∗ dQm
ijpq . . . j 6= i
i=1 p=1 q=p+1 m=ml
– La fonction d’énergie :
E=
S
N X
X
mn
X
i=1 p=i+1 m=ml
m
m
Xip
∗ ETip
+
S
S
N X
N X
X
X
mn
X
m
m
m
Xip
∗ Xjq
∗ Eijpq
. . . i 6= j
i=1 i=i+1 p=1 q=p+1 m=ml
83
6.3. les Algorithmes Utilisés
6.3
6.3.1
les Algorithmes Utilisés
Graphe potentiel Tâches
C’est une méthode pour déterminer la séquence d’exécution des tâches (la liste scheduling) :
elle détermine le temps de début de chaque tâche, en se basant sur le temps de début du la tâche
precedence (la plus lente) plus le temps d’execution, on obtient le temps de début de la tâche
actuelle. Le résultat de cette méthode est un ensemble des classes d’execution, qui contient des
tâches qui dépendent de la même classe d’execution.
On a utilisé cette méthode pour dégager les classes d’exécution, pour les nœuds irréguliers
et composés de chaque niveau de la hiérarchie, qui seront affectés à des processeurs du même
niveau.
Fig. 6.1 – liste scheduling
6.3.2
ACP(Analyse de Composante Principale)
Cette une méthode de classification des données ,s’applique sur les problèmes représentés
sous la forme d’un tableau Xpn où :
– n : individus (observateurs)
– p : Variable (caractéristique/paramètres)
L’objectif de l’ACP est de classifier les données du tableau initial, en classes d’individus sur
les axes les plus significatifs (qui ont la plus grande valeur propre).
On a utilisé la méthode de l’ACP pour classifier les processeurs de chaque niveau de l’hiérarchie, selon deux critères la vitesse et la consommation d’énergie.
84
6.4. Démarche
Fig. 6.2 – Exemple de classification par ACP
6.3.3
Djiskra multi-Objectifs
Sert à résoudre le problème du plus court chemin entre deux sommets d’un graphe connexe
dont le poids lié aux arêtes est positif ou nul.
L’algorithme porte le nom de son inventeur, l’informaticien néerlandais Edsger Dijkstra et
a été publié en 1959.
Nous avons modifié l’algorithme original pour qu’il fait la comparaison sur deux critères :
la latence et l’énergie consommée, avec priorité au latence, si il trouve deux liens avec la même
latence alors il lance, deux nouvelles recherches sur les deux liens à partie de ces liens vers la
même destination, à la fin il compare les different chemins par rapport la latence puis l’énergie.
Nous avons donné priorité au temps car l’énergie consommée par un bus au moment du
transfer est beaucoup moins importante que l’énergie consommée par le processeur pendant
l’attente.
6.4
Démarche
La démarche que l’on propose pour résoudre le problème du mapping dans sa globalité (c’est à
dire le GILR), est d’affecter un HTG (Hierarchical Task Graph) à un HNT (Hierarchical Network
Graph) avec des niveaux identiques. Dans notre approche on s’impose certaines hypothèses :
– le nombre de niveaux est donné comme entrée.
– Les deux graphes ont les mêmes niveaux.
– Pour chaque type de nœud d’application, on au a moins un équivalant dans l’architecture
dans le même niveau.
– On considère aussi qu’à tous les niveaux nous avons le même nombre de nœuds composés.
85
6.4. Démarche
– Le dernier niveau contient uniquement des nœuds élémentaires représentant des tâches
dans le HTG ou processeurs dans le HNT.
Le mapping est décomposé en deux parcours :
1. Validation(descendant) : Divisée en deux phases :
(a) Validation structurelle(fig6.3) : Vérifier la conformité des deux graphes avec les hypothèses.
(b) détection des anomalies(fig6.4) : Pour chaque tâche (respectivement processeurs)
Composé,répétitif et irrégulié on détecte les inter-blocages (les composantes connexe).
2. Mapping (ascendant)(fig6.5) :L’affectation des tâches aux processeurs et placement de
communication se fait comme suit :
A partir du niveau n − 1 :
(a) on construit les ensembles suivants :
– a partir de HTG :
STNC−1 = {ensemble des tâches composées.}
STNR−1 = {ensemble des tâches répétitifs.}
−1
STNIr
= {ensemble des tâches Irrégulières.}
– a partir de HNT :
SPNC−1 = {ensemble des Processeurs composés.}
SPNR−1 = {ensemble des Processeurs répétitifs.}
−1
= {ensemble des Processeurs Irréguliers.}
SPNIr
(b) On trie par ordre décroissant :
−1
STNIr
selon la taille.
N −1
ST C selon la taille.
STNR−1 selon le nombre des fils.
−1
pour grouper les
(c) Appliquer l’ACP pour chacun des ensembles suivants : SPNC−1 , SPNIr
N −1
processeurs, les plus similaires (vitesse,énergie). Et on trie SP R selon le nombre de
fils dans un ordre décroissant.
(d) Mapping :
– Composé :tantque STNC−1 6= ∅ faire
Heardt ← top de la liste STNC−1
Heardp ← top de la liste SPNC−1
mapping(Heardt ,Heardp ).
SPNC−1 =SPNC−1 - Heardt
STNC−1 =STNC−1 - Heardt
86
6.4. Démarche
finfaire
−1
– Irrégulier :tantque STNIr
6= ∅ faire
−1
Heardt ← top de la liste STNIr
−1
Heardp ← top de la liste SPNIr
ListeM appingIr .add(mapping(Heardt ,Heardp ))
−1
−1
SPNIr
=SPNIr
- Heardt
−1
−1
STNIr
=STNIr
- Heardt
finfaire
– Répétitif :tantque STNR−1 6= ∅ faire
Heardt ← top de la liste STNR−1
Heardp ← le plus similaire (Heardt ) dans SPNR−1 .
ListeM appingR .add(mapping(Heardt ,Heardp ))
STNR−1 =STNR−1 - Heardt
finfaire
† équilibrerCharges(ListeM appingR ).
(e) Pour chaque élément de ListeM appingIr appeler AG.
(f) Pour chaque élément de ListeM appingR appeler B&B.
(g) Pour chaque tâche de STNC−1 :
– établir la liste scheduling des ces fils.
– Calculer le plus court chemin pour tous les messages échangés entre ces fils.
– Combiner les fronts pareto générés par l’application de B&B ou AG sur ces fils.
(h) Si Racine alors Arrêter sinon Remonter dans les niveaux.
87
6.4. Démarche
Fig. 6.3 – Diagramme d’Activité de Validation structurelle
88
6.4. Démarche
Fig. 6.4 – Diagramme d’Activité de Détection des Anomalies
89
6.4. Démarche
Fig. 6.5 – Diagramme d’Activité de Mapping Hiérarchique
90
6.4. Démarche
Conclusion
Dans ce chapitre nous avons présenté notre approche, basée sur l’algorithme Génétique
et l’algorithme de Brunch and Bound, afin de résoudre le problème de placement et d’ordonnancement d’une application hiérarchique sur une architecture hiérarchique.
Afin de fiabiliser notre approche avec les résultats obtenus nous détaillerons la suite de notre
présentation par plus de diagramme et d’algorithmes.
91
Quatrième partie
Implementation & Experimentation
92
Chapitre 7
Implementation
93
7.1. Introduction
7.1
Introduction
Dans notre projet de fin d’étude, nous avons développé un outil qui intervient dans une
phase très important de flot de conception des systèmes embarqués, celle de l’association architecture/application. En adoptant le modèle hiérarchique et en combinant les algorithmes exactes
et heuristiques afin de satisfaire les différents contraintes et atteindre plusieurs objectifs
7.2
Présentation de l’application
L’entrée de notre application est constituée de deux graphes : un pour l’application et un
autre pour l’architecture. Á la sortie, cela donne un front de pareto, qui est un ensemble de
placements réalisables, respectant les contraintes de Temps et d’énergie. Cela par l’utilisation de
l’AG afin de placer les tâches irrégulières sur les processeurs hétérogènes, et l’algorithme de B
& B pour placer les tâches régulières sur des processeurs identiques.
7.3
Spécification des besoins
Partant de la nature d’étude des NOC, nous pouvons dégager quelques fonctionnalités que
doit satisfaire le logiciel :
– Diversifier les possibilité de saisir (Matricielle, Graphique).
– La possibilité d’étendre l’application par l’ajout de tâches ou de niveau. Idem pour l’architecture.
– minimiser le taux d’erreur commis par l’utilisateur.
– minimiser l’occupation de mémoire par l’application.
– Concevoir une application qui peut s’exécuter sur plusieurs systèmes d’exploitations.
– Produire un code source claire.
– Essayer de donner l’exemple en développant totalement l’application qu’avec des outils et
plateformes libres, donc entièrement gratuits.
– Concevoir une application en vue de faciliter la possibilité d’extensions ou d’améliorations
futures.
7.4
Les Outils et Plateformes utilisés
Pour le language de programmation, nous avons opté pour le language JAVA, car il représente un outil de programmation très puissant et multi-plateformes, à condition d’avoir une JVM
(java virtuel machine) appropriée au système. Il est connu que JAVA est un Open Source, d’où
plusieurs environnements de développement, parmi eux nous choisirons Eclips. Du fait qu’il est :
–
–
–
–
Gratuit.
Extensible.
Il existe plusieurs plugin’s qui l’enrichissent.
Standard.
94
7.5. Principales étapes de développement
– Facile à manipuler.
Pour les outils qu’on a utilisés :
– JFormDisigner : est un Plugin pour Eclipse qui permet de dessiner l’interface puis générer le code pour pouvoir l’intégrer dans l’application.
– JFreeChart : est un Plugin pour Eclipse pour dessiner des courbes et les intégrer dans
l’application.
– Entreprise Architecte : est un outil de modélisation UML (Unified Modelisation Model ),
est utilisé pour tester et vérifier notre modèle UML (c’est un plugin pour Eclips).
– Altova UModel : est un outil de modélisation UML, on l’utilisé pour générer les diagrammes de sequence pour les packages de l’interface ,le noyau et l’arbre hiérarchique.
– LaTex : est un formateur de texte d’une très grande puissance et qui produit des documents d’une excellente qualité. rédaction.
7.5
Principales étapes de développement
Pour la conception de l’application, on a utilisé toutes les connaissances qu’on a acquises en :
– Génie Logiciel : Modélisation de notre application.
– Analyse de Données : Classification et tries.
– Recherche Opérationnelle : Manipulation des graphes ( connexité, plus court chemin . . .).
– IHM : Utilisation du modèle MVC pour l’application.
– Système d’exploitation : Compréhension de la problématique de L’ordonnancement.
– Architecture des Ordinateur : Topologies et les types des architectures.
– Systèmes temps réel : Compréhension de la problématique des systèmes embarqués .
Nous résumons ci-dessous les principales étapes suivies pour la conception :
– Initiation au contexte :ce fut la première étape, où nous avons fait des recherches et études
dans le domaine des Systèmes embarqués, ce qui à produit la partie théorique de notre
projet de fin d’étude.
– Analyse des besoins :à cette étape, nos idées étaient un peu plus claire car à l’étape précédente nous nous sommes familiarisés avec le domaine.
– Conception et Modélisation : nous avons à cette étape, à partir du cahier des charges,
modélisé notre application en UML.
95
7.6. Architecture de l’Application
– Développement et implémentation :dans cette phase, nous avons commencé à développer
l’application, à partir bien sûr des modèles et diagrammes UML conçus avec Entreprise
Architecte à l’étape précédente, et l’implémentation s’est faite avec le langage Java en
utilisant l’EDI Eclipse.
– Tests et validation : à cette dernière étape, on a fini par valider l’application avec Altova
UModel et des exemples.
Fig. 7.1 – Les différentes étapes de développement
7.6
Architecture de l’Application
Nous présentons ici l’architecture globale d’application, qui est construite d’après le modèle
MVC qui est un Design Pattern fréquemment utilisé dans la conception d’applications systèmes.
7.6.1
Le Pattern et Modèle (MVC)
Il se base sur trois concepts :
Modèle :Le modèle représente le comportement de l’application : traitements des données,
interactions avec la base de données, etc. Il décrit ou contient les données manipulées par
96
l’application. Il assure la gestion de ces données et garantit leur intégrité. Dans le cas
typique d’une base de données, c’est le modèle qui la contient. Il offre des méthodes pour
mettre à jour ces données (insertion, suppression, changement de valeur). Il offre aussi des
méthodes pour récupérer ces données. Les résultats renvoyés par le modèle sont dénués de
toute présentation. Dans le cas de données importantes, le modèle peut autoriser plusieurs
vues partielles des données. Si par exemple le programme manipule une base de données
pour les emplois du temps, le modèle peut avoir des méthodes pour avoir tous les cours
d’une salle, tous les cours d’une personne ou tous les cours d’un groupe de TD.
Vue :La vue correspond à l’interface avec laquelle l’utilisateur interagit. Sa première tâche est
de présenter les résultats renvoyés par le modèle. Sa seconde est de recevoir toutes les
actions de l’utilisateur (clic de souris, sélection d’une entrée, boutons . . .). Ces différents
événements sont envoyés au contrôleur. La vue n’effectue aucun traitement, elle se contente
d’afficher les résultats des traitements effectués par le modèle. Plusieurs vues, partielles ou
non, peuvent afficher des informations d’un même modèle. Par exemple, une application
de conversion de bases a un entier comme unique donnée. Ce même entier peut être affiché
de multiples façons (en texte dans différentes bases, bit par bit avec des boutons à cocher,
avec des curseurs). La vue peut aussi offrir la possibilité à l’utilisateur de changer de vue.
Elle peut être conçue en html, ou tout autre « langage » de présentation.
Contrôleur :Le contrôleur prend en charge la gestion des événements de synchronisation pour
mettre à jour la vue ou le modèle et les synchroniser. Il reçoit tous les événements de
l’utilisateur et enclenche les actions à effectuer. Si une action nécessite un changement des
données, le contrôleur demande la modification des données au modèle et ensuite avertit la
vue que les données ont changé pour qu’elle se mette à jour. Certains événements de l’utilisateur ne concernent pas les données mais la vue. Dans ce cas, le contrôleur demande à la
vue de se modifier. Le contrôleur n’effectue aucun traitement, ne modifie aucune donnée.
Il analyse la requête du client et se contente d’appeler le modèle adéquat et de renvoyer la
vue correspondant à la demande.
Nous avons opté pour cette méthode car elle a beaucoup d’avantages par exemple :
– Plusieurs vues possibles synchronisées.
– Plusieurs contrôles possibles (exemple : clavier, souris).
– Données isolées (BD, fichiers, etc. . .).
– Nécessité de définir des interfaces communes entre le modèle, la vue et le contrôleur.
– Séparer dans le code le modèle( Data ),la (les) vu(s) et le Contrôle.
97
7.6.2
Architecture en packages de l’application
Elle est construite sur le pattern Model View Controller ; il impose la séparation entre
les données, les traitements et la présentation. C’est pour cette raison que l’application
est divisée en trois composants fondamentaux : le modèle qui contient les données de
l’application, la vue qui est la représentation du modèle à l’écran et le contrôle qui définit
la façon dont l’interface utilisateur réagit à une entrée faite par l’utilisateur. l’architecture
de l’application est constituée des trois principaux packages Voici la description :
– Core : ce package représente le noyau de notre application.
– GUI : est un package dédié a l’IHM ( utilisateur ).
– Observer :il gère l’harmonisation et l’organisation de la communication entre les packages noyau et GUI.
Fig. 7.2 – Architecture en Package de l’Application
98
7.7. l’interface graphique
7.7
l’interface graphique
La conception de l’interface de notre application est basée sur des règles de l’IHM (interface
homme-machine) qui sont :
– la simplicité.
– l’affichage que des informations significatives.
– la décomposition de l’interface en 4 parties (Nord,West ,Est et Sud).
– pas trop de messages.
– minimisé le risque que l’utilisateur commet une erreur de saisi ou de manipulation en
mettons au point des filtres de saisie et des contrôleur.
– pas trop de couleur
– utiliser des bulles de help pour donner à l’utilisateur des informations sur l’objet qui
point au dessus.
– diversifier les moyens de saisir.
– des icons significatives.
la figure 7.3 montre la fenêtre principale de notre application.
Fig. 7.3 – La fenêtre principale de l’application
a. La région Nord est composée de deux parties :
– le barre des menus Contenant les fonctions standards comme Ouvrir, enregistrer, chercher,
copier, coller, . . . etc.
– une barre d’Outils pour des fonctions de la barre des menus.
b. La région West (Fig : 7.5) est composée de deux onglets : un pour l’arbre hiérarchique d’application et l’autre pour l’architecture. Une barre d’outils pour éditer l’arbre (ajou99
Fig. 7.4 – La partie Nord de l’interface
ter,supprimer ou renommer). Le clic sur un bouton ajoutera un nœud à celui sélectionné tout
en respectant les conditions suivantes :
– Un nœud répétitif ne contient que des nœuds élémentaires.
– Un nœud composé peut contenir les nœuds répétitifs, composés et irréguliers.
– Dans chaque niveau hiérarchique il existe un nœud irrégulier contenant tous les nœuds
élémentaires. Initialisé par default en 1.
– Crée un nœud répétitif, engendre la création de deux nœuds élémentaires, et un nœud
diffuseur pour l’application (et E/S pour l’architecture).
– Un nœud élémentaire est une feuille.
– Crée un nœud composé, engendre la création d’un nœud répétitif et d’un nœud irrégulier.
Pour la suppression :
– d’un nœud élémentaire du nœud père répétitif il faut que le père contiennent au moins
trois fils élémentaires.
– D’un nœud composé, il faut que celui-ci contient deux nœuds.
– D’un nœud irrégulié,diffuseur et E/S est impossible.
– D’un nœud élémentaire est possible.
la selection d’un nœud élémentaire revient a sélectionné son père.
Renommer un nœud n’est possible que s’il n’existe pas un frère avec le même nom.
On peut saisir les graphes à l’aide des raccourcis clavier :
– "1": pour ajouter un noeud élémentaire (couleur Vert).
– "2": pour ajouter un noeud répétitif (couleur Orange).
– "3": pour ajouter un noeud composé (couleur Rouge).
– "0": pour supprimer un noeud.
c. La région Est (Fig : 7.6) contient trois interfaces
– Précédence/Maillage :(selon le graphe choisi application/architecture respectivement) :
Saisir la precedence entre les fils du nœud sélectionner, Sauf pour le nœud répétitif et le
nœud élémentaire du graphe d’application .La saisie peut se faire par la matrice ou a
l’aide d’un graphe. Pour la matrice de precedence c’est une matrice complète car les liens
sont orientés ,la matrice de maillage est une matrice supérieurs droite ; les liens sont bidirectionnels.
– Caractéristiques : Saisir les variétés du nœud sélectionner et les tailles des messages de
communication échangés avec ces frères, Sauf pour le nœud répétitif car il n’y a pas de
message entre les fils d’un nœud répétitif.
100
Fig. 7.5 – La partie West de l’interface
– résultat : dans cette zone les résultats de l’application seront affichés.Un front de pareto
pour les scheduling ( ordonnancement) et deux diagrammes de Gantt, un pour l’ordonnancement sélectionné et l’autre pour les E/S du même ordonnancement.
d. La partie Sud (Fig : 7.7) contient les boutons :
– Valider : Pour valider les graphes avant de lancer le processus.
– A.S.S : Pour lancer le processus de recherche des placement de l’application sur l’architecture.
– Réglage : Pour modifier les paramètres de l’algorithme génétique ou les caractéristiques
de l’architecture.
101
Fig. 7.6 – La partie Est de l’interface
102
Fig. 7.7 – La partie Sud de l’interface
103
7.8
Modélisation UML
Fig. 7.8 – Diagramme de class du noyau (architecture) (1/4)
104
7.8.1
Diagramme de class du noyau
Fig. 7.9 – Diagramme de class du noyau (application)(2/4)
105
7.8.2
Fig. 7.10 – Diagramme de class du noyau (structure de données) (3/4)
106
7.8.3
Fig. 7.11 – Diagramme de class du noyau (traitement)(4/4)
107
7.8.4
Diagramme de class de l’interface
Fig. 7.12 – Diagramme de classe de l’interface
108
7.8.5
Diagramme de séquence de l’application
Fig. 7.13 – Diagramme Séquence d’Ouvrir un nouveau projet
109
7.8.6
Diagramme Activité de Saisi de l’Arbre Hiérarchique
Fig. 7.14 – Diagramme Activité de Saisi de L’Arbre Hiérarchique
110
Chapitre 8
Experimentation
111
8.1. introduction
8.1
introduction
Le coté pratique consiste a testé notre logiciel sur une application et une architecture qui
adoptent le même modèle hiérarchique. Le modèle SOC qu’on va présenter est un encodeur
H2.63 placer sur une architecture MPSOC.
8.2
L’application : Encodeur H2.63 [18]
C’est une application gourmande en puissance de calcul effectuant un traitement d’image,
Le standard H2.63 permet de compresser un flux de video.
L’implementation consiste a convertir une video QCIF dans le format compressé H2.63. La
compression ce fait en trois tâches séquentielles :
– La transformée en cosinus discrète (DCT, Discrète Cosine Transform) permet d’éliminer la redondance de données et de transformer les données du domain temporelle au
fréquentielle.
– La quantification consiste à diviser chaque coefficient de la DCT par un pas de quantification et mettre les coefficient négatifs à Zéro.
– Encoder les macro-blocs traités en attribuant à chaque coefficient de DCT quantifié un
mot binaire dont la longueur est d’autant plus courte que le coefficient est fréquent.
La taille d’une image d’une séquence QCIF est de 176x144 pixels. Dans l’algorithme d’encodage, les données manipulées sont structurées sous forme de macro-blocs qui représentent un
espace de 16x16 pixels d’une image vidéo. Le format de données du macro-bloc est le YCbCr
qui contient trois composantes : luminance (Y ), chrominance bleu (Cb), et chrominance rouge
(Cr ). Les blocs de luminance décrivent l’intensité des pixels tandis que les blocs de chrominance
contiennent des informations sur les couleurs des pixels. La couleur verte n’est pas explicitement
codée, elle peut être dérivée à partir des valeurs des trois composantes. Un macro-bloc 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.
Le profil GASPARD vise ce type d’application car il peut représenter les différents niveaux
de l’hiérarchie, en parcourant le modèle du haut en bas. VideoSequnece : est le composant de
base, il contient une répétition de 400 ; Cela permet de traiter 400 images.
– QCIF2H263 : est le composant qui traite l’image. Composé de trois sous tâches :
1. QCIFReader : Il convert une séquence video au format QCIF en trois composantes
YCbCr.
2. H2.63Encoder : C’est une tâche répétitif qui contient réellement tout l’algorithme
pour encoder une image. Elle est composée de H263MacroBlock, qui est lui même
composé de trois sous-tâches.
– DCT (Discrète Cosine Transform).
112
8.2. L’application : Encodeur H2.63 [18]
– Quan2QCIF La quantification.
– Coding Encoder les macro-blocs traités.
3. CompressFileSave : Se charge de sauvegarder le flux compressé.
Fig. 8.1 – Le graphe hiérarchique de l’encodeur H.263.
113
8.2. L’application : Encodeur H2.63 [18]
Fig. 8.2 – L’implémentation de l’encodeur H.263 en profil Gaspard.
114
8.3. L’architecture : MPSOC [18]
8.3
L’architecture : MPSOC [18]
L’architecture matérielle modélisée est relativement simple (figure 8.3). Elle a pour composant principal HardwArchit. Ce composant est composé de deux mémoires, un réseau d’interconnexion et quatre processeurs MIPS. Le réseau d’interconnexion est un crossbar modélisé à l’aide
de deux ports multiples. L’un 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 multiplicité. L’autre port est de type
Out, auquel on peut connecter les composants ayant des ports esclaves lors des transactions.
Fig. 8.3 – Le graphe hiérarchique de l’MPSOC.
115
8.4. L’impact de l’hiérchisation
8.4
L’impact de l’hiérchisation
On a essayé, à travers cette expérimentation de montrer la pertinence de traiter les graphes
hiérarchiques lors d’un placement. Dans une application de 64 tâches et une architecture de 12
processeurs. L’association à plat, a fourni des résultats en 157 µs (fig 8.4) et hiérarchique a deux
niveaux en : 124 µs.
Fig. 8.4 – Résultat d’association à plat.
116
Fig. 8.5 – Résultat d’association à deux niveaux.
117
A partir des résultats obtenus dans l’expérimentation précédente, on a essayé de tester
d’autres exemple ayant de différents nombre de tâches et niveaux. Le tableau8.1 montre les
résultats des experimentations.
Tâches
30
40
50
64
niveau1
115
129
143
157
niveau2
84
96
110
124
niveau3
53
65
89
93
niveau4
22
34
58
62
Tab. 8.1 – Résultats de temps de Placement hiérarchique
Fig. 8.6 – Évolution des temps de recherche du GILR en fonction de la taille des application
et du nombre de niveau
118
conclusion
D’après les résultats obtenus dans les experimentations précédentes, nous avons constater
que le facteur de l’hiérchisation influe positivement sur la vitesse de recherche dans les espaces
de solutions.
Mais l’hiérarchisation à des limite, car si le nombre des niveaux et très important alors le
temps globales de la recherche sera relativement grand, pour cela il faut chercher une marge où
l’hiérchisation sera efficace à 100%.
119
Conclusion Générale
120
La conception des systèmes embarquées impose à respecter certaines contraintes logicielles
et matérielles, contrairement aux systèmes informatiques, ces contraintes doivent être prises en
compte simultanément. Dans ce type de système où l’on fait du logiciel dédié et inversement
pour le matériel, les deux types de contraintes sont vérifiées en même temps. Lors de la phase de
mapping, on doit prendre en considération la contrainte de consommation d’énergie, de temps
réel, de surface, de mémoire. Ce problème est souvent désigné dans la communauté par l’AAS
(Assignation, Affectation et Scheduling). Les contraintes dont on a parlé ne peuvent être traitées séparément. Pour que l’AAS soit réaliste, on doit considérer certaines d’entre elles comme
des objectifs qu’on doit atteindre simultanément. C’est ce qui rend ce problème, un problème
d’optimisation combinatoire multi-objectif .[18]
La plupart des approches proposée pour résoudre ce problème traite un seul objectif a la
fois, la nôtre traite deux objectifs : minimiser le temps globale et minimiser l’énergie consommée. Pour cela on utilisé deux algorithmes d’optimisation. Un algorithme génétique qui est
un algorithme heuristique, et l’algorithme de Brunch & Bound qui est exact. ces deux algorithmes cherchent la bonne solution dans un espace de solution réalisable en respectant les
contraintes de Temps et d’énergie.
notre travail consiste à trouver un placement d’une application hiérarchique sur une architecture hiérarchique de même structure (même niveau de profondeur hiérarchie).C’est ce qu’on
appelle le GILR (Globalement Irrégulier Localement Régulier ).
Le côté pratique nécessite quant a lui une étude plus approfondie en qui doit prendre nécessairement en comptes le vaste domaine des applications.
Enfin, l’idéal serait d’appliquer l’ensemble des résultats obtenus lors de ces travaux à un
NOC dans les conditions réelles d’utilisation.
121
Glossaire
AG :Algorithme Génétique.
ACG :Acyclic Graph
ACP : Analyse de Composantes Principale.
ALAP : As Late As Possible.
ASAP : As Soon As Possible.
ASIC : Application-Specific Integrated Circuit.
ASS : Affectation Assignation Scheduling.
B&B : Brunch and Bound.
BD : Budgeted Deadline.
CLP : Complex linear Programmation.
CMT :Core Mapping Technique
CPU : Central Processing Unit.
CTG : Communication Task Graph.
DMA : Direct Memory Access.
DSP : Digital Signal Processor.
DVS : Dynamique Voltage Scaling.
EAS : Energy Assigning Energy.
EDF : Early Deadline Finish.
EE-CLSA : Energy Efficacient Genetic List
Scheduling Algorithm.
EE-GMA : Energy Efficacient Genetic Mapping Algorithm.
EFT : Early Finish Time.
EST : Earliest Star Time.
ET : Execution Time.
FPGA : Field-Programable Gate Array.
FIFO : First In First Out.
GILR : Globalement Irrégulier Localement Régulier.
GPS : Global Position System.
GSM : Global System of Mobile.
HTG : Hierarchique Task Graph.
HNT : Hierarchique Network Task.
IHM : Interface Homme-Machine.
JVM : Java Virtuel Machine.
LFT : Latest Finish Time.
LOPOCOS : Low Power CO-Synthesis.
LS : List Scheduling.
LST : Latest Star Time.
MIMD : Multiple Instruction Multiple Dada.
MIPS : Million Instruction Par Second.
MISD : Multiple Instruction Single Data.
MPSOC : Multiprocessor System on Chip.
MVC : Modèle Vue Contrôleur.
NOC : Network On Chip.
NT : Network Task.
PDM : plateforme Definition Model.
PIM : plateforme Independent Model.
PPL : plateforme Priority List.
PSM : Platfrom Specific Model.
PV-DVS : Power Variation Dynamique Voltage Scaling.
SAR : Search and Reparation.
SIMD : Single Instruction Multiple Data.
SISD : Single Instruction Single Data.
SRAM : Static Random Aces Memory.
SOC : System On Chip.
SVS : Statique Voltage Sélection.
TDM : Time Devision Multiplexing.
TG : Task Graph.
UML : Unified Modeling Language.
USB : Universal Serial Bus.
WCET : Worst Case Execution Times.
122
Index
élitiste, 68
énergie, xiii, 7, 11, 27, 37, 44, 54
énumérer, 62
DMA, 10
DSP, 10
DVS, 34
Aléatoirement, 67
Analogique, 11
Arbre, 47
ASIC, 5, 13
Assignation, 39
EE-CLSA, 44
EE-GMA, 44
Embarqué, 9
Embarquement, 11
Binaire, 66
Bit, 41, 67
Borne, 63
Boucle, 44
Buffer, 41
Chromosome, 66
CMOS, 12
Co-développement, 25
Co-design, 25
Co-Processeur, 12
Co-simulation, 25
Coût, 78
Codage, 66
Communication, 12
Contrainte, 79
Convertisseur, 11
coordination, 25
CPU, 10
Critère, 34
Croisement, 39, 65, 68
CTG, 39
Cycle, 12, 22
développement, 23
Deadline, 35
Flot, 22
Fonction, 47
FPGA, 5
génération, 65
génératrice, 22
Génotype, 66
gène, 66
GASPARD, 28
Gray, 67
Hétérogénéité, 11
Hard, 46
Hiérarchique, 11
hiérarchique, 16, 74, 75, 79, 85, 110
Hypothèse, 22
IDM, 27
incrementation, 46
Individu, 67
Individuelle, 47
instanciation, 22
inter, 42
Intervalle, 47
itérative, 65
langage, 25
Latence, 11, 41
123
mémoire, 11
Minimisation, 34
Mono-puce, 11
MPSOC, 11
Multi-maitre, 25
Mutation, 39, 65, 69
Nœud, 16
Niveau, 79
NOC, 16, 34
Numérique, 11
Optimale, 63
Optimisation, 12
Optimum, 34
Ordonnancement, 34
Stockage, 41
Switch, 41
Systématique, 62
TDM, 39
Tournoie, 68
transistors, 13
Trivial, 62
Universelle, 68
Vecteur, 66
Y, 28
parallèle, 22
placement, 34
Plateforme, 27
procedure, 65
processeur, 5
Profondeur, 62
Puce, 44
Quadratique, 12
Réalisable, 62
réseau, 39
Racine, 63
Reproduction, 67
Roulette, 68
Sélection, 68
Séparation, 62
séquentialité, 22
Séquentiel, 22
Selection, 65
Seuil, 34
signal, 10
SOC, 10, 11
Soft, 47
Specification, 11
Static, 47
124
Bibliographie
[1] Flot de conception hièrarchique d’un système hétérogène. PhD thesis, 2005.
[2] A.A. Jerraya and W.Wolf. Multiprocessor System-on-Chips. 2004.
[3] Abid Khaled and Benabdallah Saad. Problème de mapping de tâches répétitives sur une
architecture régulière, 2008.
[4] P.Eles Z.Peng B.M.Al-Hashimi Andrei, M.T.Schmitz. In Overhead-Conscious Voltage Selection For Dynamic and Leakage Power Reduction of Time-Constraint Systems. Automation
and Test Europe Conference, 2004. accepted for publication.
[5] ARM. AMBA AXI protocol Specification. 2003.
[6] Youssef Atat. Conception de haut niveau des mpsocs à partir d’une spécification simulink,
2007.
[7] R. A. Bergamaschi. Early and Accurate Analysis of SoCs : Oxymoron or Reality 2004.
[8] Aimen Bouchhima. Modélisation du logiciel embarqués à différents nivaux d’abstraction en
vue de la validation et la synthèse des système monopuce. Master’s thesis, 2006.
[9] C.Wu C.Chou and J.Lee. 4th ieee international symposium on electronic design test application. In Integrated Mapping and Scheduling for Circuit-Switched Networkon-Chip Architectures. IEEE Computer Society, 2008.
[10] J. Kim D. Shin. Power-Aware Communication Optimization for Networks-on-Chips with
Voltage Scalable Links. CODES ISSS, Septembre 2004.
[11] Xavier Delrome. Optimisation combinatoire et problèmes de capacité d’infrastructure ferroviaire. mémoire DEA, 2000.
[12] Bruce ECKEL. Thinking in java, 2nd edition. 2000.
[13] Lens F.Gruian, K.Kuchcinski. In Task Scheduling for Lower-energy Systems Using Variable
Supply Voltage Processors. ASP-DAC, 2001.
[14] GauLovic Gauthier. Conception des logiciels embarqués pour les systèmes monopuce. 2003.
[15] D.E. Goldberg. Genetic Algorithms in Search, Optimization and Machine Learning. 1989.
[16] K. Goosens. Network on Silicom : Combining best effort and guaranteed services. 2002.
[17] R.Marculescu G.Varatkar. Communication, Complexity and Criticaly issue in Designing
Silicon Networks. 2006.
125
BIBLIOGRAPHIE
[18] B. Abou El Hassen. ORDONNANCEMENT HIÉRARCHIQUE MULTI-OBJECTIFS
D’APPLICATIONS EMBARQUÉES INTENSIVES. PhD thesis, 2008.
[19] M. Heath. Synchro-Tokens : Eliminating Nondeterminism to Enable Chip-Level Test of
Globally Asynchronous Locally Synchronous SoC’s. 2004.
[20] Holland. Adaptation in Natural and Artificial System. University of Michigan Press, 1975.
[21] Pham Viet Hung. Linux embarqué et système embarqué. Technical report, 2005.
[22] I. Xu and W. Wolf. Plateform Based Design and hte first generation Dilemma. 2002.
[23] Sonic Inc. Product brief : Siliconbackplane iii micronetwork ip, 2003.
[24] R.Marculescu J.Hu. Design automation and test in europe conf. In Energy-Aware
Communication and Task Scheduling for Network-on-Chip Architectures under Real-Time
Constraints, 2004.
[25] K. Czarnecki and S. Helsen. Feature-based survey of model transformation approaches. 2006.
[26] K. Keutzer, S.Malik andA.R. Newton, J. Rabaey, and A.S Vaincentelli. System Level Design : Orthogonolization of concems and plateform-Based Design. 2000.
[27] Patrice Kadionik. Les systèmes embarqués : une introduction. 2005.
[28] Ivan Kurtev. Adaptability of model transformations. PhD thesis, 2005.
[29] Z.Peng L.A.Cortes, P.Eles. Quasi-static scheduling for multiprocessor real-time systems
with hard and soft tasks. Technical report, Embedded Systems Lab, Dept. of Computer
and Information Science, beDesign, Linkoping University, September 2003.
[30] Z.Peng L.A.Cortes, P.Eles. Design, test and applications. In Static Scheduling of Monoprocessor Real-Time Systems composed of Hard and Soft Tasks, pages 115–120. The IEEE
International Workshop on Electronic, January 2004.
[31] A.Guerri M.Milano L.Benini, D.Bertozzi. Allocation, Scheduling and Voltage Scaling on
Energy aware MPSoC. 2006. pp.44-58.
[32] D. Lyonnard. Approche d’assemblage systématique d’éléments d’interface pour la génération
d’architecture multiprocesseur. PhD thesis, Institut National Polytechnique de Grenoble,
2003.
[33] M. John and S. Smithy. Application specific Integrated circuits. 1997.
[34] A.Khademzadeh M.Armin, S.Saeidi. Spiral A heuristic mapping algorithm for network on
chip, volume 4. Ieice electronics express edition, August 2007.
[35] Mehadji abdelghani kamel and Mesbah mourad. Assignement affectation ordonnancement
d’une architecture de tâches répétitives sur une architecture embarquée régulière, 2007.
[36] P.Eles M.T.Schmitz, B.M.Al-Hashimi. In A Co-Design Methodology for Energy-Efficient
Multi-Mode Embedded Systems with Consideration of Mode Execution Probabilities. Design,
Automation and Test Europe Conference, 2003. Munich, 2003.
[37] P.Eles M.T.Schmitz, B.M.Al-Hashimi. Iterative Schedule Optimization for Voltage Scalable
Distributed Embedded Systems, volume 3. Feb 2004.
126
BIBLIOGRAPHIE
[38] N. Sadowski and A. Bastos. Electromagnetic Modeling by Finite Element Methods. 2003.
[39] S.Kumar P.Ruxandra. A Survey of Techniques for Mapping and Scheduling Applications to
Network on Chip Systems. 2004.
[40] R.Szymanek. Memory aware task assignment and scheduling for multiprocessor embedded
systems. Licentiate Thesis No.13, June 2001. ISSN 1404-1219.
[41] K.Kuchcinski R.Szymanek. In Design Space Exploration in System Level Synthesis under
Memory Constraints. Euromicro 25, Sept 1999.
[42] A. Sangiovanni-Vincentilli. Platform-based Design. 2002.
[43] M. Steven. Service-Oriented architecture introduction. 2004.
[44] El-Ghazali TALBI. Métaheuristiques pour l’Optimisation Combinatoire Multi-objectifs :
Etat de l’art.
[45] S. Kumar T.Lei. A two-step Genetic Algorithm for Mapping Task Graphs to a NoC Architecture. DSD, 2003.
[46] Wikipedia. Algorithme d’optimisation.
[47] W.J Dally, M. Abid, and A.Jerraya. COSMOS : A CoDesign Approch for Communicating
Syetems. 1994.
[48] X.Hu Y.Zhang and D.Chen. Task Scheduling and Voltage Selection for Energy Minimization. 2002.
127

Ordonnancement Hiérarchique d`Application Temps Réel Sur Une

Transcription

Similar documents

Le Syst`eme solaire est-il stable

La cryptographie de lÀntiquité à lÌnternet

Une Nouvelle Technique de Recalage d`Images avec

Courbes intensité-potentiel Applications `a l`électrolyse

Mod`eles physiques particulaires en environnement temps

Rapport d`activité 2003–2006 - Lina

Cartographie avec R

Chapitre 9 La mesure de niveau

Rapport de projet de fin d`étude Développement d - Libre

Schémas numériques pour la résolution de l`équation des ondes

téléchargement - Espace Automobiles Européen

2016 Nissan Juke Owner`s Manual