THESEthesesups.ups-tlse.fr/188/1/Nemer_Fadia.pdf · Fadia NEMER le 27 Février 2008 Titre OPTIMISATION DE L'ESTIMATION DU WCET PAR ANALYSE INTER-TACHE DU CACHE D'INSTRUCTIONS Directeurs

UNIVERSITÉ DE TOULOUSE III – PAUL SABATIER

U.F.R. MATHÉMATIQUES INFORMATIQUE GESTION

THESE

en vue de l'obtention du

DOCTORAT DE L'UNIVERSITÉ DE TOULOUSEdélivré par l'Université Toulouse III – Paul Sabatier

Discipline: Informatique

présentée et soutenue

par

Fadia NEMERle 27 Février 2008

Titre

OPTIMISATION DE L'ESTIMATION DU WCET PAR ANALYSE INTER-TACHE DU CACHE D'INSTRUCTIONS

Directeurs de thèse

Jean-Paul Bahsoun, professeur, Université de Toulouse IIIHugues Cassé, maître de conférence, Université de Toulouse III

JURY

M. Pascal Sainrat, professeur, Université de Toulouse III, ExaminateurM. Ali Awada, maître de conférence, Université Libanaise, ExaminateurM. François Bodin, professeur, Université de Rennes I, RapporteurM. Philippe Clauss, professeur, Université Louis Pasteur Strasbourg , Rapporteur

À ma mère qui m'a soutenue, encouragéeet tout simplement aimée

À mon père qui n'est plus, je t'aime papa... je ne t'oublie pas...

« Fais de ta vie un rêve, et d'un rêve une réalité »Antoine de Saint-Exupéry

REMERCIEMENTS

Je tiens à remercier Jean-Paul Bahsoun mon directeur de thèse. Ma reconnaissance va également à Hugues Cassé, pour son encadrement, son soutien et la disponibilité dont il a fait preuve.

Je remercie aussi Pascal Sainrat, directeur de l'équipe TRACES, pour ses conseils, et Ali Awada pour son aide pendant mon séjour au Liban.

Je tiens aussi à remercier vivement Monsieur François Bodin et Monsieur Philippe Clauss pour m’avoir fait l’honneur d’être les rapporteurs de cette thèse.

Un grand merci à tous les membres de l'équipe TRACES pour la bonne ambiance de travail.

Je remercie ma famille et tous mes amis pour leur support qui m'a permis de continuer mes études dans les meilleures conditions.

Je remercie particulièrement mon fiancé, Hani Kanaan, pour son soutien tout le long de cette thèse et pour la compréhension et la patience dont il a fait preuve.

AUTEUR FADIA NEMERTITRE « Optimisation de l'estimation du WCET par analyse inter-tâche du cache

d'instructions »DIRECTEURS DE THÈSE Jean-Paul Bahsoun, Hugues CasséDATE ET LIEU DE LA SOUTENANCE 27 Février 2008, Université Paul Sabatier

RÉSUMÉLes systèmes temps réel se distinguent des autres systèmes informatiques par la prise en compte de contraintes temporelles dont le respect est aussi important que l'exactitude du résultat. On distingue le temps-réel strict ou dur (de l'anglais hard real-time) et le temps-réel souple ou mou (soft real-time) suivant l'importance accordée aux contraintes temporelles. Théoriquement, le concepteur d'un système temps réel strict doit être capable de prouver que les limites temporelles ne sont jamais dépassées quelle que soit la situation. Cette vérification, appelée analyse de faisabilité, fait appel à la théorie de l'ordonnancement. Elle requiert une connaissance du pire comportement temporel du système. Il est donc nécessaire de connaître en particulier les pires instants d'arrivées des tâches, et les temps d'exécution dans le pire des cas des tâches. C'est sur l'obtention de cette dernière information que porte notre étude. Le temps d'exécution pire cas d'un programme peut être estimé en mesurant son temps d'exécution dans un environnement de test ou par analyse statique du code. Les approches par analyse statique ont l'avantage d'être sûres mais fournissent des estimations parfois pessimistes. Or ces méthodes calculent le WCET d’une tâche seule et non dans le cadre d’une application complète ainsi elles ignorent plusieurs facteurs des systèmes temps-réel multi-tâches, essentiellement l'enchaînement des tâches, qui affectent naturellement la précision du WCET estimé. Nous proposons une nouvelle approche, qui s’applique aux systèmes temps-réel stricts, multi-tâches. Cette méthode étudie le comportement d’un ordonnancement statique des tâches d’une application temps-réel, s'exécutant sur un processeur, pour analyser le comportement inter- et intra- tâche de la mémoire cache. Le but est de remplacer les hypothèses conservatrices qui supposent un état vide ou indéfini du cache par un état bien défini avant l’exécution de chaque tâche de l’ordonnancement. Ceci va nous permettre d’améliorer la précision de l’estimation du WCET de ces tâches en utilisant la trace de l’exécution d’autres tâches dans le cache.Cette thèse propose aussi un benchmark temps-réel, PapaBench, décrivant une application temps-réel complète et réelle pour le pilotage d'un UAV (Unmanned Aerial Vehicle). Ce benchmark a été conçu afin de constituer une base utile pour les expérimentations de calcul de WCET par méthodes statiques ou dynamiques, il peut être aussi utile pour les analyses d'ordonnancement.

MOTS CLÉSWCET, analyse statique, benchmark temps-réel, analyse de flot de données, interprétation abstraite

Discipline Informatique

INTITULÉ ET ADRESSE DU LABORATOIRE D'ACCUEILInstitut de Recherche en Informatique de ToulouseUniversité Paul Sabatier118 route de NarbonneF-31062 Toulouse Cedex 9

TABLE DES MATIÈRES

Introduction.......................................................................................................15

Chapitre 1 – Systèmes embarqués et temps-réel............................................19

1.Définitions...............................................................................................................................191.1.Système Réactif...............................................................................................................191.2.Système distribué et Système embarqué..........................................................................211.3.Spécification des systèmes réactifs embarqués................................................................22

1.3.1.La boucle de contrôle..............................................................................................221.3.2.L'architecture matérielle..........................................................................................231.3.3.Les contraintes temporelles et matérielles...............................................................23

2.Ordonnancement temps-réel....................................................................................................232.1.Stratégies d'ordonnancement...........................................................................................24

2.1.1.Modèle de tâche.......................................................................................................242.1.2.Ordonnancement préemptif, non-préemptif.............................................................252.1.3.Ordonnancement en ligne, hors ligne......................................................................262.1.4.Ordonnanceur à priorités statiques, dynamiques......................................................27

2.2.Algorithmes d'ordonnancement classiques......................................................................272.2.1.Rate Monotonic (RM).............................................................................................272.2.2.Earliest Deadline First (EDF)..................................................................................282.2.3.Deadline Monotonic (DM)......................................................................................292.2.4.Least Laxity First (LLF)..........................................................................................30

3.Modélisation en AADL...........................................................................................................303.1.Choix d'AADL................................................................................................................313.2.AADL : Vue Générale.....................................................................................................313.3.Types de composants.......................................................................................................32

3.3.1.Composants Matériels.............................................................................................343.3.2.Composants Logiciels.............................................................................................343.3.3.Composants Composites..........................................................................................35

3.4.Les modes........................................................................................................................353.5.Les propriétés..................................................................................................................36

4.Conclusion...............................................................................................................................36

Chapitre 2 - PapaBench : un benchmark temps-réel.....................................37

1.Le projet Paparazzi..................................................................................................................381.1.Historique........................................................................................................................381.2.Les composants du système Paparazzi.............................................................................39

viivii

1.2.1.Fonctionnement du microcontrôleur MCU1 (Fly by wire)......................................401.2.2.Fonctionnement du microcontroleur MCU0 (Autopilote).......................................41

2.Papabench1..............................................................................................................................422.1.Modèle aadl.....................................................................................................................432.2.Lien avec le modèle AADL.............................................................................................452.3.Complexité des variables.................................................................................................452.4.Représentation graphique de Paparazzi...........................................................................46

3.Limitations de Papabench1......................................................................................................48

4.Genèse de Papabench2............................................................................................................504.1.Le modèle AADL............................................................................................................504.2.Les règles de précédences................................................................................................51

5.Le benchmark..........................................................................................................................535.1.Détails de la compilation.................................................................................................54

6.Comparaison avec les benchmarks temps-réel.........................................................................546.1.Les Benchmarks temps-réel.............................................................................................546.2.Caractéristiques du code..................................................................................................566.3.Complexité des boucles...................................................................................................58

7.Papabench1 vs Papabench2.....................................................................................................597.1.Outils utilisés...................................................................................................................597.2.Résultats..........................................................................................................................607.3.Conseils de conception des applications temps-réel........................................................63

8.Conclusion...............................................................................................................................64

Chapitre 3 – Calcul standard du temps d'exécution pire cas........................65

1.Estimation du WCET...............................................................................................................65

2.Méthodes dynamiques.............................................................................................................662.1.Caractéristiques...............................................................................................................662.2.Techniques de calcul du wcet par analyse dynamiques....................................................67

3.Méthodes statiques..................................................................................................................683.1.Analyse de flot de contrôle..............................................................................................69

3.1.1. Représentations logiques .......................................................................................693.1.1.1.Blocs de base...................................................................................................693.1.1.2.Ligne Bloc ou L-bloc.......................................................................................703.1.1.3.Graphe de flot de contrôle ..............................................................................713.1.1.4. Arbre Syntaxique ...........................................................................................72

3.1.2. Dépliage des appels de fonctions............................................................................733.1.3. Influence de la compilation sur la représentation logique du programme...............743.1.4. Informations supplémentaires de flot de contrôle...................................................75

3.2. Analyse des propriétés temporelles ................................................................................763.2.1.Le pipeline...............................................................................................................76

3.2.1.1.Simulation plus Delta......................................................................................783.2.1.2.Graphe d'exécution..........................................................................................83

3.2.2. Les mémoires caches..............................................................................................873.2.2.1.Découpage du cache en blocs..........................................................................88

viiiviii

3.2.2.2. Les types de caches........................................................................................893.2.2.3.Les stratégies de remplacement sur un défaut de cache...................................90

3.3. Techniques intra-tâche de calcul du WCET....................................................................923.3.1. Techniques utilisant les algorithmes de graphes.....................................................923.3.2. Techniques IPET.....................................................................................................943.3.3.Techniques basées sur les arbres syntaxiques..........................................................993.3.4. Analyse Symbolique du WCET ...........................................................................104

3.4.Analyses des systèmes multi-tâches .............................................................................1083.4.1.Analyse Edgar & Burns.........................................................................................1093.4.2.Analyse Diaz, Garcia & al.....................................................................................1113.4.3.Analyse Tan & Mooney.........................................................................................1123.4.4.Analyse Staschulat & Ernst...................................................................................114

4.Conclusion.............................................................................................................................116

Chapitre 4 – Analyse d'une application multi-tâches...................................117

1.Définition du problème..........................................................................................................1171.1.Contexte.........................................................................................................................1181.2.Comportement du cache intra-tâche...............................................................................1191.3.Comportement inter-tâche du cache..............................................................................120

2.Les interférences possibles des L-blocs.................................................................................121

3.Analyse de flot de données (dfa)...........................................................................................123

4.Analyses du cache à accès direct...........................................................................................1244.1.Analyse Exit..................................................................................................................1254.2.Construction des états du cache.....................................................................................1284.3.Analyse Entry................................................................................................................1324.4.Amélioration du WCET des tâches................................................................................133

5.Analyse du cache associatif...................................................................................................1345.1.Architecture d'un cache associatif..................................................................................1355.2.Stratégie de remplacement LRU....................................................................................1355.3.Sémantiques du cache....................................................................................................1365.4.Analyse Exit..................................................................................................................1375.5.Calcul du Damage.........................................................................................................1395.6.Analyse Inter-Tâche......................................................................................................1415.7.Analyse Entry................................................................................................................143

6.Injection d'un état du cache et calcul du wcet........................................................................145

7.Choix du meilleur Ordonnancement .....................................................................................147

8.Conclusion.............................................................................................................................150

Chapitre 5 – Expérimentations......................................................................153

1.Benchmarks...........................................................................................................................153

2.Outils.....................................................................................................................................154

3.Résultats................................................................................................................................154

ixix

3.1.Variation des paramètres du cache.................................................................................1553.1.1.Variation de la taille de bloc..................................................................................1553.1.2.Variation de la taille du cache................................................................................1563.1.3.Variation du degré d'associativité..........................................................................158

3.2.Variation de l'ordonnancement......................................................................................1603.3.Comparaison Réinjection Entry.....................................................................................162

3.3.1.Amélioration des WCET des tâches et du WCET global.......................................163

4.Conclusion.............................................................................................................................168

Conclusion........................................................................................................171

xx

INDEX DES FIGURES

Figure 1.1 - Modèle d'un système réactif..............................................................................................20Figure 1.2 - Exemple d'un système réactif............................................................................................20Figure 1.3 - Exemple d'ordonnancement RM.......................................................................................28Figure 1.4 - Exemple d'ordonnancement EDF......................................................................................29Figure 1.5 - Calcul de la laxité d'une tâche Ti.......................................................................................30Figure 1.6 - Type de ports.....................................................................................................................33Figure 1.7 - Représentation graphique des composants AADL............................................................33Figure 2.1 - Le système Paparazzi........................................................................................................40Figure 2.2 - Axes de roulis et de tangage..............................................................................................41Figure 2.3 - Fonctionnement de MCU0 en pilotage manuel assisté et automatique..............................42Figure 2.4 - Tâches et interruptions de MCU1 (a) et MCU0(b)............................................................43Figure 2.5 - Graphe de dépendances Mode Manuel..............................................................................44Figure 2.6 - Dépendances du Mode Automatique.................................................................................44Figure 2.7 - PCG de Fly_by_wire (a) et de l'autopilot (b)....................................................................45Figure 2.8 - Le système embarqué de Paparazzi...................................................................................46Figure 2.9 - Représentation graphique du système MCU1...................................................................47Figure 2.10 - Représentation graphique du système MCU0.................................................................47Figure 2.11: Exemple d'ordonnancement..............................................................................................48Figure 2.12 - Règles de précédences des tâches de PapaBench2..........................................................51Figure 2.13 - PCG de MCU0 dans PapaBench2...................................................................................52Figure 2.14 - Répartition des Instructions.............................................................................................57Figure 2.15 - Analyse de la complexité des boucles.............................................................................58Figure 2.16 - Statistiques du temps d'inactivité.....................................................................................62Figure 2.17 - Comparaison des ordonnancements................................................................................62Figure 3.1 - Code Source d'un programme C........................................................................................70Figure 3.2 - Construction des L-blocs...................................................................................................71Figure 3.3 - Graphes de flot de contrôle ..............................................................................................71Figure 3.4 - T-Graphs du programme analysé.......................................................................................72Figure 3.5 - Arbre syntaxique du programme analysé..........................................................................73Figure 3.6 - Dépliage des appels de fonction dans l'arbre syntaxique (a) et dans le CFG (b)................74Figure 3.7 - Les schémas logiques de deux compilations d'une même structure de boucle...................75Figure 3.8 - Occupation du pipeline d'un processeur MicroSPARC.....................................................77Figure 3.9 - Exemple de LTE................................................................................................................79Figure 3.10 - Modèle de contraintes de l'exécution dans le pipeline.....................................................80Figure 3.11 - Processeur à exécution ordonnée ayant deux pipelines parallèles...................................81Figure 3.12 - Modèle de contraintes pour un processeur multi-pipeline...............................................81Figure 3.13 - Effets temporels calculés par simulation.........................................................................83Figure 3.14 - Exemple d'un processeur.................................................................................................84Figure 3.15 - Exemple d'un graphe d'exécution (pipeline scalaire à exécution ordonnée)....................84Figure 3.16 - Graphe d'exécution (pipeline superscalaire à exécution non-ordonnée)..........................85Figure 3.17 - Le découpage d'une adresse d'un bloc mémoire..............................................................89Figure 3.18 - Cet exemple utilise un cache à 8 blocs et une mémoire de 32 blocs................................90Figure 3.19 - Traduction d'un graphe de flot de contrôle en un système de contraintes........................94Figure 3.20 - (a)Graphe de dépendances inter-modulaires, (b) appel de procédures.............................97Figure 3.21 - Concaténation () de deux représentations wA et wB du pipeline...................................101Figure 3.22 - Exemple........................................................................................................................102Figure 3.23 - Sous arbre test d'une structure conditionnelle................................................................104

xixi

Figure 3.24 - Arbre Syntaxique et l'Arbre de Portée équivalent de la fonction impaire......................106Figure 3.25 - Préemption directe et préemption indirecte...................................................................112Figure 3.26 - Scénario de Préemption.................................................................................................115Figure 4.1 - Exemple d'un ordonnancement statique .........................................................................118Figure 4.2 - Caractéristiques de la tâche.............................................................................................121Figure 4.3 - Comportement des L-blocs d'une tâche T sachant l'état du cache IN..............................122Figure 4.4 - Algorithme itératif de DFA..............................................................................................124Figure 4.5 - Formules GEN, KILL.....................................................................................................126Figure 4.6 - Algorithme MUSTEXIT.................................................................................................127Figure 4.7 - Analyse MAYEXIT.........................................................................................................127Figure 4.8 - Exemple d'un CFG d'une tâche.......................................................................................127Figure 4.9 - Transformation d'un ordonnancement en graphe de flot de contrôle...............................129Figure 4.10 - Formules GEN, KILL analyse inter-tâche.....................................................................130Figure 4.11 - Analyse inter-tâche MUST............................................................................................131Figure 4.12 - Analyse inter-tâche MAY..............................................................................................131Figure 4.13 - Algorithme MUSTENTRY............................................................................................133Figure 4.14 - Analyse MAYEXIT.......................................................................................................133Figure 4.15 - Calcul du nombre de hit minimal et maximal................................................................134Figure 4.16 - Algorithme MUSTEXIT...............................................................................................138Figure 4.17 - Algorithme MAYEXIT..................................................................................................139Figure 4.18 - Algorithme DAMAGEMUST.......................................................................................140Figure 4.19 - Algorithme DAMAGEMAY.........................................................................................141Figure 4.20 - Analyse Inter-tâches MUST..........................................................................................143Figure 4.21 - Analyse Inter-tâches MAY............................................................................................143Figure 4.22 - Analyse MUSTENTRY.................................................................................................144Figure 4.23 - Analyse MAYENTRY...................................................................................................144Figure 4.24 - Exemple1......................................................................................................................146Figure 4.25 - Exemple 2.....................................................................................................................147Figure 5.1 - mcu0 (PapaBench1), nombre de hits total (cache 16 Ko)................................................155Figure 5.2 - mcu0 (PapaBench2), nombre de hits total (cache 16 Ko)................................................155Figure 5.3 - mcu1, nombre de hits total (cache 16 Ko).......................................................................156Figure 5.4 - mcu0(PapaBench1), nombre de hits total (taille bloc 8 octets).......................................156Figure 5.5 - mcu0(PapaBench2), nombre de hits total (taille bloc 8octets).........................................157Figure 5.6 - mcu1, nombre de hits total (taille de bloc 8octets)..........................................................157Figure 5.7 - mcu0 (PapaBench1), variation du nombre de hits total en fonction de A........................158Figure 5.8 - mcu0 (PapaBench2), variation du nombre de hits total en fonction de A........................159Figure 5.9 - mcu1, variation du nombre de hits total en fonction de A...............................................159Figure 5.10 - mcu0 (PapaBench1), impact de la variation de l'ordonnancement................................160Figure 5.11 - mcu0 (PapaBench2), impact de la variation de l'ordonnancement.................................161Figure 5.12- mcu1, impact de la variation de l'ordonnancement........................................................161Figure 5.13- mcu0 (PapaBench1), réinjection / ENTRY.....................................................................162Figure 5.14 - mcu0 (PapaBench2), réinjection / ENTRY...................................................................163Figure 5.15 - mcu1, réinjection / ENTRY..........................................................................................163Figure 5.16 - mcu1, amélioration des WCET des tâches....................................................................164Figure 5.17 - mcu0 (PapaBench1), amélioration des WCET des tâches.............................................165Figure 5.18 - mcu0 (PapaBench2), amélioration des WCET des tâches.............................................166Figure 5.19 - mcu0 (PapaBench1), Pourcentage de réduction du WCET global.................................167Figure 5.20 - mcu0 (PapaBench2), Pourcentage de réduction du WCET global.................................167Figure 5.21 - mcu1, Pourcentage de réduction du WCET global........................................................168

xiixii

INDEX DES TABLES

Tableau 2.1 - Tâches et interruptions de MCU0....................................................................................50Tableau 2.2 - Statistiques sur les Benchmarks temps-réel.....................................................................56Tableau 2.3 - Caractéristiques générales des deux versions..................................................................60Tableau 3.1 - Les différentes catégories des références mémoires........................................................93Tableau 3.2 - Formules de calcul de WCET de [30].............................................................................99Tableau 3.3 - Extension du schéma temporel pour prendre en compte les caches et le pipeline.........100Tableau 3.4 - Calcul du WCET d'une structure sachant son niveau d'imbrication dans une boucle . . .103Tableau 3.5 - Expressions par défaut pour chaque type de portée.......................................................106

INDEX DES FORMULES

Formule 3.1 - Expression de calcul du WCET.....................................................................................95Formule 3.2 - Évaluation du WCET en tenant compte du cache d'instructions.....................................96Formule 3.3 - distribution de Gumbel.................................................................................................110Formule 3.4 - estimation statistique du WCET...................................................................................110Formule 3.5 - relation entre ω et ε....................................................................................................110Formule 3.6 - Calcul récursif du WCRT d'une tâche Ti......................................................................113Formule 3.7 - estimation conservatrice du WCRT..............................................................................115Formule 3.8 - Estimation améliorée du WCRT...................................................................................115Formule 4.1 - Formule générale de DFA itératif.................................................................................123Formule 4.2 - Amélioration du WCET initial.....................................................................................134

xiiixiii

xivxiv

INTRODUCTION

PROBLÉMATIQUE

Du métro sans conducteur au pilote automatique dans les avions, les systèmes temps-réel envahissent notre vie quotidienne. Ce monde du temps-réel est si vaste que ses technologies s'appliquent à divers secteurs tels que le contrôle d’une centrale nucléaire, les systèmes d’aide au pilotage des avions, les téléphones portables, le transport, la télécommunication, …. Les progrès accomplis en électronique et en informatique ont apporté beaucoup à l’augmentation de la puissance de calcul des machines et à l’amélioration de la performance de ces systèmes.

Les systèmes temps-réel se distinguent des autres systèmes informatiques par la prise en compte de contraintes de temps dont le respect est aussi important que l'exactitude du résultat. Autrement dit, le système ne doit pas simplement délivrer des résultats exacts mais il doit les délivrer dans des délais imposés, c'est-à-dire que le système doit réagir à chaque événement de l'environnement externe avant l'échéance imposée par l'environnement pour le prochain événement.

On distingue le temps-réel strict ou dur (de l'anglais hard real-time) et le temps-réel souple ou mou (soft real-time) suivant l'importance accordée aux contraintes temporelles. Les systèmes temps-réel stricts ne tolèrent aucun dépassement de ces contraintes, ce qui est nécessaire si de tels dépassements peuvent conduire à des situations critiques, voire catastrophiques : pilote automatique d'avion, système de surveillance de centrale nucléaire, etc. À l'inverse, le temps-réel souple s'accommode des dépassements de contraintes de temps dans certaines limites au-delà desquelles le système devient inutilisable : visioconférence, jeux en réseau, etc.

On peut ainsi considérer qu'un système temps-réel strict doit respecter des limites temporelles données même dans la pire des situations d'exécution possibles. En revanche un système temps-réel souple doit respecter ses limites pour une moyenne de ses exécutions. On tolère un dépassement exceptionnel, qui sera peut être rattrapé à l'exécution suivante. Théoriquement, le concepteur d'un système temps-réel strict devrait être capable de prouver que les limites temporelles ne sont jamais dépassées quelle que soit la situation. Cette vérification est appelée test d'acceptabilité, analyse de faisabilité ou encore contrôle d'admission ; elle fait appel à la théorie de l'ordonnancement et sa vérification dépend de l'ordonnanceur utilisé et des caractéristiques des tâches du système.

1515

Cette analyse requiert une connaissance du pire comportement temporel du système. Il est nécessaire de connaître en particulier les pires instants d'arrivées des tâches, et les temps d'exécution dans le pire des cas des tâches. C'est sur l'obtention de cette dernière information que porte notre étude.

Le temps d'exécution pire cas d'un programme peut être estimé en mesurant son temps d'exécution dans un environnement de test qui peut être un système réel ou un simulateur. Les mesures doivent être réalisées pour tous les jeux d'entrée possibles ou alors il faut être capable de définir un jeu d'entrée qui conduit certainement au temps d'exécution le plus long. Il existe un autre moyen de mesure du WCET en utilisant des méthodes d'analyse statique de son code sans avoir à l’exécuter sur le matériel cible.

En théorie, le test dynamique est approprié pour l'analyse du WCET du code. En effet, le temps d'exécution du programme est mesuré pour une exécution avec un jeu d'entrée particulier. Un outil de test idéal exécuterait le programme pour chaque ensemble possible de valeurs en entrée et mesurerait le temps d'exécution. Mais ceci n'est pas toujours possible en pratique car la complexité des programmes à analyser conduit à un nombre extrêmement grand de tests possibles. Si pour un programme donné, on a pu définir le jeu d'entrée pire cas, alors ces méthodes permettent d'obtenir une valeur précise du WCET notée « WCET réel ».

En revanche, les approches par analyse statique ont l'avantage d'être sûres. Cette sûreté des estimations a une contrepartie, les estimations obtenues sont parfois pessimistes. Ce pessimisme induit une surestimation des moyens matériels nécessaires au fonctionnement du système. Ces méthodes fournissent alors une borne supérieure du WCET appelée aussi « WCET estimé ». Nous proposons dans ce manuscrit une méthode qui permet de réduire ce pessimisme.

APPROCHE

Les propositions de cette thèse sont classées dans la catégorie des méthodes par analyse statique du code.

La plupart des méthodes d'évaluation du WCET par analyse statique, proposées dans la littérature, calculent le WCET d'une seule tâche en considérant des hypothèses conservatrices sur l’état du matériel qui garantissent la condition nécessaire et suffisante, le WCET estimé est supérieur ou égal au WCET réel, pour qu'il n'y ait pas un risque de violation des contraintes temps-réel. Bien que ces méthodes produisent des approximations sûres sous réserve de certaines hypothèses sur le processeur, elles ignorent plusieurs facteurs des systèmes temps-réel multi-tâches, essentiellement l'enchaînement des tâches qui affectent naturellement la précision du WCET estimé.

Nous proposons une nouvelle approche, qui s’applique aux systèmes temps-réel stricts, multi-tâches. Cette méthode étudie le comportement d’un ordonnancement statique des tâches d’une application temps-réel, s'exécutant sur un processeur, pour analyser le comportement

1616

inter- et intra tâche de la mémoire cache. Le but est de remplacer les hypothèses conservatrices qui supposent un état vide ou indéfini du cache par un état bien défini avant l’exécution de chaque tâche de l’ordonnancement. Ceci va nous permettre d’optimiser l’estimation du WCET de ces tâches en utilisant la trace de l’exécution d’autres tâches dans le cache.

Comme tout logiciel, le calcul du WCET nécessite des expérimentations, des évaluations et des comparaisons d’où la nécessité des benchmarks qui représentent les fonctionnalités des applications temps-réel. Cependant, il est très difficile de se procurer une application réelle pour tester le système avant de le mettre en utilisation vu les critères de confidentialité dont s'entourent les industriels.

En même temps, les benchmarks temps-réel sont très rares et sont constitués généralement d'un ensemble d'algorithmes de base utilisés dans les applications temps-réel. Ces benchmarks sont déconnectés des particularités des applications embarquées telles que la gestion des capteurs et actionneurs. Les fonctions qu'ils fournissent sont exécutées seules et non dans le contexte d'une application complète. Il est ainsi impossible de les utiliser pour expérimenter l’impact de l’enchaînement des tâches sur l’estimation du WCET. Comme solution à ce problème, nous avons conçu un benchmark temps-réel, PapaBench, décrivant une application temps-réel complète pour le pilotage d'un UAV (Unmanned Aerial Vehicle). Il a été conçu afin de constituer une base utile pour les expérimentations de calcul de WCET par méthodes statiques ou dynamiques mais il peut être aussi utile pour les analyses d'ordonnancement.

PLAN

L’organisation du document est la suivante. Le premier chapitre présente les caractéristiques des systèmes temps-réel embarqués à contraintes temps-réel stricts, l'ordonnancement temps-réel et les politiques d'ordonnancement les plus utilisées, et pour terminer, il explique notre choix de la norme AADL pour modéliser les applications temps-réel.

Nous présentons au deuxième chapitre, les deux versions de notre benchmark temps-réel PapaBench1 et 2, leur intérêt, leurs différences et leur utilité pour les expérimentations des approches de calcul de WCET et pour l'étude des ordonnancements.

Le troisième chapitre passe en revue les principales méthodes d'estimation du temps d'exécution pire cas, statiques et dynamiques, intra-tâche et multi-tâches. Le quatrième chapitre décrit notre approche qui permet d'optimiser l'estimation du WCET des tâches en étudiant leurs contextes d'exécution. Nous nous intéressons surtout à l'analyse du comportement de l'ordonnancement de ces tâches sur le cache d'instructions pour construire les états du cache à l'entrée de chaque tâche. Ces états remplacent les hypothèses conservatrices utilisées par les méthodes d'analyse statique usuelles pour fournir des estimations sûres mais pessimistes du temps d'exécution pire cas. Ainsi chaque tâche

1717

bénéficie des traces d'exécutions des tâches précédentes, ce qui va nous permettre de détecter les faux défauts de cache induits par les hypothèses conservatrices, et ainsi d'optimiser l'estimation du WCET de la tâche. Nous introduisons à la fin de ce chapitre un algorithme itératif basé sur notre approche qui permet de choisir le meilleur ordonnancement des tâches d'une application temps-réel pour une politique d'ordonnancement fixée au départ.

Les résultats expérimentaux présentés au cinquième chapitre prouvent l'intérêt de notre approche. Ces expérimentations sont effectuées sur les deux versions de PapaBench pour plusieurs configurations du cache et pour plusieurs ordonnancements. Nous montrons la variation du WCET global de l'application en fonction de la taille du cache, de la taille du bloc de cache, du degré d'associativité et de la politique d'ordonnancement. Enfin nous concluons cette étude en mettant en avant les apports de notre travail et les perspectives ouvertes par ce dernier.

1818

CHAPITRE 1

SYSTÈMES EMBARQUÉS ET TEMPS-RÉEL

Les systèmes temps-réel sont de plus en plus présents dans de nombreux secteurs d'activités comme l'aéronautique, l'automobile, l'énergie, les télécommunications, le contrôle de processus industriel et le secteur militaire. Ces systèmes réalisent souvent des tâches complexes qui sont souvent critiques. Ils sont soumis aux contraintes temporelles de l'environnement qu'ils doivent respecter. En effet, pour qu'une application temps-réel soit valide, elle doit non seulement fournir un résultat correct, mais elle doit le délivrer en respectant certaines contraintes temporelles qui sont le plus souvent des échéances de terminaison au plus tard. En d'autres termes un système temps-réel se distingue d'un système traditionnel par sa capacité à garantir l'exécution des tâches en respectant certaines échéances.

Un système temps-réel est un système réactif qui réagit avec son environnement à un rythme imposé par cet environnement. Il peut être distribué ou embarqué ou embarqué/distribué. Comme notre étude s'intéresse essentiellement au systèmes embarqués temps-réel qui sont le plus souvent distribués, ce chapitre présente la particularité de chacune de ces catégories. Nous définissons aussi l'ordonnancement temps-réel et nous présenterons une vue générale des politiques d'ordonnancement utilisées par la suite.

1. DÉFINITIONS

1.1. SYSTÈME RÉACTIF

Le concept de système réactif a été défini dans la littérature, par plusieurs travaux. La définition suivante est donnée par [1]:

Définition 1 (Système réactif) Un système réactif est un système qui réagit continûment avec son environnement à un rythme imposé par cet environnement. Il reçoit, par l'intermédiaire de capteurs, des entrées provenant de l'environnement, appelées stimuli, réagit à tous ces stimuli en effectuant un certains nombre d'opérations et produit, grâce à des actionneurs, des sorties utilisables par l'environnement, appelées réactions ou commandes

1919

Chapitre 1 - Systèmes embarqués et temps-réel 1.Définitions

(voir figure 1.1). Dans un système réactif, la validité d'une commande ne dépend pas uniquement de la

validité de la valeur de son résultat, mais aussi de son instant de délivrance. Parfois, dans la littérature, le système réactif est appelé système de contrôle, et l'environnement système contrôlé [2].

Un exemple très simple d'un système réactif est celui de la régulation de niveau d'eau dans un réservoir (figure 1.2). Dans cet exemple, l'environnement est constitué d'un réservoir d'eau, d'une vanne et de deux capteurs sensibles à la présence d'eau. Supposons qu'à l'instant t=0 le niveau d'eau dans le réservoir soit le niveau du capteur 1 et que la vanne soit ouverte. Le rôle de ce système est de maintenir le niveau d'eau entre les deux capteurs 1 et 2: si le capteur 2 est mouillé le système doit envoyer une commande de fermeture de la vanne avant que le réservoir déborde, et si le capteur 1 est sec le système doit envoyer une commande d'ouverture de la vanne.

Les exigences fonctionnelles et temporelles sont donc deux caractéristiques essentielles des

2020

Figure 1.2 - Exemple d'un système réactif

Figure 1.1 - Modèle d'un système réactif

Chapitre 1- Systèmes embarqués et temps-réel 1.Définitions

systèmes réactifs. D'une part, Les exigences fonctionnelles imposent au système de produire des résultats corrects du point de vue des valeurs du domaine. D'autre part, les exigences temporelles imposent au système de produire ces résultats à temps, c'est-à-dire que le système doit réagir à chaque événement de l'environnement externe avant l'échéance imposée par l'environnement pour le prochain événement.

Suivant les exigences temporelles d'un système réactif, nous distinguons deux classes de systèmes:

➢ Systèmes réactifs temps-réel stricts – ces systèmes doivent impérativement garantir le respect des contraintes de temps imposées par l'environnement. Ces contraintes sont cruciales pour de tels systèmes car une erreur temporelle peut avoir des conséquences catastrophiques (humaines, matérielles, financières, écologiques, etc.). Les systèmes de contrôle de trafic aérien et de conduite de missile sont deux exemples de ces systèmes.

➢ Systèmes réactifs temps-réel souples - les contraintes temporelles de ces systèmes sont définies pour assurer une qualité de service mais peuvent exceptionnellement être violées sans mettre en cause la sécurité du matériel et des personnes impliquées. Il s'agit d'exécuter les fonctions dans les meilleurs délais. Par exemple, le traitement vidéo d'un système multimédia peut omettre quelques images sans que la qualité visuelle ne soit détériorée.

1.2. SYSTÈME DISTRIBUÉ ET SYSTÈME EMBARQUÉ

Notre étude porte essentiellement sur les systèmes temps-réel embarqués. Comme ces systèmes possèdent le plus souvent une architecture distribuée surtout pour des raisons de sécurités et de performance, ce paragraphe fournit la définition d'un système distribué et d'un système embarqué.

Définition 2 (Système distribué) Un système distribué est tel que son architecture matérielle est composée de plusieurs machines multiprocesseurs ou monoprocesseur reliées entre elles par un ensemble de moyens de communication (mémoire partagée, bus, liaisons point-à-point ...). En général, cette architecture distribuée est hétérogène – les processeurs respectivement moyens de communication ont des caractéristiques physiques différentes.Définition 3 (Système embarqué) Lorsqu'un système temps-réel est physiquement intégré à l'environnement qu'il contrôle et qu'il est soumis aux mêmes contraintes physiques (température, pression, ...) que son environnement, il est dit embarqué. Un système embarqué est un système réactif ayant des ressources limitées, telles que la mémoire, la consommation d'énergie, la taille, le poids, la puissance de calcul ...

Un système temps-réel intégré dans un robot mobile est un système embarqué, alors qu'un système de contrôle de bras de robot n'en est pas un. Dans le premier cas, le système temps-réel fait partie intégrante du robot, il se déplace avec lui et il est ainsi soumis aux mêmes contraintes physiques externes. Dans le deuxième cas, le système peut être dans une

2121

Chapitre 1 - Systèmes embarqués et temps-réel 1.Définitions

armoire électrique placée dans une pièce différente de celle où se situe le robot. Ce système temps-réel est donc indépendant du bras manipulateur, il n'est pas intégré à son environnement (bras + objets manipulés).

Les systèmes embarqués sont généralement soumis à des contraintes spécifiques de coûts pris au sens large du terme. Ces contraintes sont dues, d'une part, au type d'applications couvertes par ce type de système et, d'autre part, à l'intégration du système à son environnement. Ces contraintes particulières de coût sont de plusieurs types : encombrement, consommation d'énergie, prix, etc. Un système possède souvent des ressources limitées, telles que sa taille (un avion, PDA – Personal Digital Assistant).

1.3. SPÉCIFICATION DES SYSTÈMES RÉACTIFS EMBARQUÉS

Nous nous intéressons dans la suite de ce document aux systèmes réactifs embarqués à contraintes temps-réel strictes. Pour des raisons de lisibilité, nous écrivons « système temps-réel strict » au lieu de « système réactif embarqué à contraintes temps-réel strictes ».

La spécification de ces systèmes est réalisée en trois phases complémentaires et dépendantes :

➢ La spécification fonctionnelle – consiste à définir la boucle de contrôle avec ses exigences fonctionnelles

➢ La spécification architecturale – consiste à définir l'architecture matérielle qui doit implanter cette spécification

➢ La spécification des contraintes – consiste à attribuer des propriétés temporelles et matérielles à l'exécution de la boucle de contrôle sur l'architecture.

1.3.1. La boucle de contrôleLa boucle de contrôle d'un système réactif représente les fonctions nécessaires au contrôle

et à la commande de l'environnement. Elle est composée d'un ensemble de composants logiciels, que nous appelons tâches. Chacun assure une fonctionnalité spécifique du système – telle que la commande d'une vanne de régulation.

Définition 4 (Tâche) – On définit une tâche comme une séquence ordonnée indivisible d'instructions à laquelle on peut associer des propriétés temporelles devant être respectées à l'exécution.

La boucle de contrôle peut être modélisée par un graphe de dépendances. Les sommets représentent les tâches et les arcs représentent les dépendances de données et de contrôle entre ces tâches. Une dépendance de données entre deux tâches T1 et T2, est telle que T1 apparaît avant T2 dans le graphe de dépendances, signifie que T2 commencera son exécution après avoir reçu les données de sortie de T1. Tandis qu'une dépendance de contrôle, signifie que T1

s'exécute avant T2 suite à une contrainte imposée par l'environnement sans qu'il y ait un

2222

Chapitre 1- Systèmes embarqués et temps-réel 1.Définitions

échange de données entre ces deux tâches. Nous utilisons la notation T1 < T2 pour représenter cette dépendance de donnée, ainsi T2 dépendant des résultats de T1.

1.3.2. L'architecture matérielleCette étape consiste à caractériser tous les composants de l'architecture et à choisir la

topologie du réseau de communication:

➢ Processeurs – la spécification de la boucle de contrôle ne peut être complètement indépendante de l'architecture, puisque les attributs temporels des tâches sont en relation directe avec le type de processeurs utilisé. Ainsi la durée d'exécution d'une tâche est différente d'un processeur à un autre dans le cas d'une architecture hétérogène.

➢ Capteurs et actionneurs – les systèmes réactifs utilisent des capteurs et des actionneurs pour interagir avec l'environnement extérieur qu'ils contrôlent. Dans le cas d'une architecture distribuée, le choix de l'emplacement physique de ces capteurs / actionneurs sur l'architecture est important dans la conception de ces systèmes.

➢ Moyen de communication – les processeurs de l'architecture distribuée communiquent en utilisant deux types de communication : envoi de messages ou partage de données. Pour gérer les communications inter-processeurs entre des tâches dépendantes, placées sur des processeurs distincts, il est donc nécessaire de connaître le type des communications et le type de média de communication (mémoire partagée, bus, lien point-à-point, ...).

1.3.3. Les contraintes temporelles et matériellesLes contraintes temporelles s'expriment, pour chaque tâche de la boucle de contrôle, en

termes de sa date début d'exécution, sa période, et sa date d'échéance. La date de début d'exécution est liée à l'occurrence de certains événements ou à la satisfaction de certaines conditions (i.e. la réception de données), tandis que l'échéance est liée au comportement exigé par l'environnement.

La spécification de la boucle de contrôle n'est pas complètement indépendante de l'architecture : par exemple, afin de réduire le câblage, certains capteurs et actionneurs doivent être gérés par des processeurs spécifiques de l'application. Il est donc nécessaire de spécifier des contraintes matérielles pour chaque composant de cette boucle de contrôle. Cela conduit à attribuer à chacun, un ou plusieurs processeurs de l'architecture matérielle qui peuvent l'exécuter.

2. ORDONNANCEMENT TEMPS-RÉEL

Lors de la conception d'un système temps-réel, la phase d'implantation est la plus délicate :

2323

Chapitre 1 - Systèmes embarqués et temps-réel 2.Ordonnancement temps-réel

elle consiste à distribuer et à ordonnancer les tâches sur l'ensemble des composants de l'architecture matérielle (processeurs, bus, ...). La distribution est une allocation spatiale d'une tâche à une ressource, alors que l'ordonnancement est une allocation temporelle d'une tâche sur une ressource. Le but est de distribuer et d'ordonnancer toutes les tâches pour former un programme. Ces questions d'ordonnancement ont donné lieu à de nombreux travaux [3 à 12].

Définition 5 (Ordonnancement temps-réel) – L'ordonnancement est le terme informatique désignant le mécanisme permettant de réaliser la sélection, parmi plusieurs composants de la boucle de contrôle, de celui qui va obtenir l'utilisation d'un composant de l'architecture pour s'exécuter de manière à optimiser un ou plusieurs critères. L'ordonnancement temps-réel a une particularité qui nécessite de respecter des contraintes temps-réel. Le processus qui réalise une telle sélection, et donc qui définit un ordre d'exécution entre les composants de la boucle de contrôle, est appelé algorithme d'ordonnancement.

Il existe, pour une architecture donnée, un grand nombre de possibilités d'ordonnancement et de distribution mais seulement un certain nombre d'entre elles permet de satisfaire à la fois aux contraintes liées à la boucle de contrôle (dépendances de données) et aux contraintes temps-réel (aspect temporel) mais aussi aux contraintes de l'architecture (aspect matériel). Cet espace de solutions valides est d'autant plus restreint que les contraintes sont fortes. C'est le cas des systèmes temps-réel embarqués qui sont des applications souvent complexes et dont les contraintes de coût se traduisent généralement par de fortes contraintes matérielles.

2.1. STRATÉGIES D'ORDONNANCEMENT

Un système temps-réel strict doit impérativement garantir le respect des échéances fixées pour l'exécution des tâches. Le dépassement de l'échéance par au moins une tâche temps-réel stricte peut conduire à une défaillance générale du système. Pour cette raison, on cherche à avoir la certitude absolue, avant exécution, que toutes les échéances seront toujours respectées lors de l'exécution de l'application.

Une politique d'ordonnancement est appliquée pour vérifier le respect des échéances des tâches, des contraintes matérielles et des dépendances de données. Cette politique est constituée d'une part de l'algorithme d'ordonnancement et d'autre part du test d'ordonnançabilité. L'algorithme d'ordonnancement est chargé de décider de l'ordre d'exécution des tâches. Tandis que, le test d'ordonnançabilité (appelé aussi analyse d'ordonnançabilité, ou analyse de faisabilité) permet de vérifier que l'algorithme choisi permettra à toutes les tâches de respecter toutes le contraintes énumérées ci-dessus en toutes circonstances (voir § 2.2).

2.1.1. Modèle de tâcheLa majorité des stratégies d’ordonnancement fait appel à la notion de tâche. On trouve

dans la littérature les définitions de plusieurs modèles de tâche [3], [4], [5]. Les tâches sont

2424

Chapitre 1- Systèmes embarqués et temps-réel 2.Ordonnancement temps-réel

indépendantes mais elles peuvent partager des variables globales.

Définition 6 (Tâche périodique) – Une tâche périodique, comme son nom l’indique, doit être exécutée à des intervalles de temps fixés (ou périodes). Dans sa version la plus générale, une tâche périodique est définie par le quadruplet Ti (Φi; Ci ; Pi ;Di) où Φi ≥ 0, Ci > 0 et Ci ≤ min(Pi, Di), Pi > 0, et Di > 0. La phase Φi de la tâche dénote la date de son premier réveil, Ci son temps d’exécution pire cas ou WCET(Worst Case Execution Time), Pi sa période d’exécution, et Di son échéance relative, c’est-à-dire le temps maximal dont on dispose pour exécuter la tâche. La période d’exécution de la tâche correspond à la contrainte de cadence qui est imposée à la tâche [4], [5].Définition 7 (Tâche apériodique, sporadique) – Les tâches apériodiques et sporadiques sont des tâches exécutées à des instants à priori non connus. L’exécution de ces tâches est généralement déclenchée par un événement provoqué par le processus contrôlé. Les tâches apériodiques ont aussi des contraintes temporelles, par exemple après le déclenchement de son exécution, une tâche apériodique doit se terminer dans un temps prédéfini. Cependant les tâches apériodiques n'ont pas d'échéance stricte, elles ont des échéances particulièrement importantes pour tenir compte des événements critiques du système [4]. La période d’exécution n’intervient donc pas dans le modèle de ces tâches. On distingue une tâche sporadique d’une tâche apériodique par la connaissance d’un intervalle de temps minimum entre deux exécutions de la tâche sporadique.

2.1.2. Ordonnancement préemptif, non-préemptifLorsque l’exécution d’une tâche active peut être interrompue à tout moment pour allouer le

processeur à une autre tâche jugée plus prioritaire, l’ordonnancement est dit préemptif. Un ordonnancement est non-préemptif si chaque tâche s'exécute de son démarrage à sa terminaison sans interruption [6].

Un ordonnancement préemptif apporte un sur-coût sur le temps de calcul. En effet, au moment de la préemption, le contexte de la tâche préemptée doit être sauvegardé. Ce contexte doit être restauré lorsque la préemption s’achève, c’est-à-dire au moment où l’exécution de la tâche préemptée doit reprendre. Par contre, un ordonnancement préemptif permet, dans certains cas, de garantir des contraintes temporelles impossibles à garantir avec un ordonnancement non-préemptif. On peut distinguer deux types de préemption, celle déclenchée par des interruptions matérielles (événement extérieur) et celle déclenchée par les algorithmes d’ordonnancement (tâche prioritaire, synchronisation).

Dans le cadre d’un ordonnancement préemptif, il est nécessaire de garantir qu’une ressource n’est accédée que par une seule tâche à la fois. L’accès en exclusion mutuelle à une ressource peut engendrer un phénomène d’inversion de priorité au cours duquel l’exécution d’une tâche de haute priorité voulant accéder à une ressource est retardée par l’exécution de tâches de plus basse priorité, dont l’une est rendue non-préemptible pendant l’accès à cette même ressource [7], [8].

2525


2.1.3. Ordonnancement en ligne, hors ligneL’ordonnancement peut être calculé lors de la conception du logiciel, dans ce cas,

l’ordonnancement est dit hors ligne. Il consiste à analyser la boucle de contrôle du système et ses contraintes temporelles afin de définir la séquence d’exécution des tâches qui permet de respecter ses contraintes, temporelles et matérielles (cf. §2.2). Dans ce cas, l’exécutable qui gère l’application est simple car le code à exécuter est composé d’une séquence d’opérations insérées dans une boucle principale qui représente la boucle de contrôle.

Cette approche de l’ordonnancement nécessite une spécification rigoureuse de la boucle de contrôle afin de le calculer automatiquement par des outils logiciels. C’est généralement celle qui est utilisée quand cette boucle est spécifiée avec des langages synchrones car la réalisation d’une séquence d’exécution des opérations a l’avantage de permettre de facilement conserver et de s’assurer que l’ordre des événements, défini par la spécification, est conservé à l’exécution et donc que les propriétés mises en évidence par la vérification sont conservées par l’implantation.

Lorsque l’ordonnancement est calculé pendant l’exécution, on parle d’ordonnancement en ligne. Dans ce type d’approche, l’exécutable est construit autour d’un ordonnanceur chargé de gérer l’activation, la mise en attente et l’arrêt des tâches [8], [9]. Un ordonnancement en ligne est plus coûteux à l’exécution qu’un ordonnancement hors ligne car, en plus des calculs liés la boucle de contrôle de l’application, le calculateur doit aussi réaliser les calculs liés à l’ordonnanceur. De plus, un ordonnancement hors ligne est prédictible car la séquence de calcul est connue avant l’exécution alors que dans un ordonnancement en ligne, l’ordre d’exécution est déterminé par l’ordonnanceur, il n’est donc pas toujours possible de connaître à l’avance l’ordre précis d’exécution des tâches. Un ordonnancement en ligne sera par contre plus flexible qu’un ordonnancement hors ligne, en ce sens qu’il pourra plus facilement prendre en compte les événements dont l’occurrence est imprévisible (tâches apériodiques ou sporadiques).

D'une manière générale, un ordonnancement est dit statique s'il possède les caractéristiques suivantes :

➢ Construction hors ligne d'une séquence complète de planification sur la base de tous les paramètres temporels des tâches. Cette séquence est un procédé défini par l'utilisateur

➢ Régularité temporelle du monde externe – les événements asynchrones sont observés à des dates précises.

➢ L'ordonnancement des tâches est régi par un calendrier. C'est une table spécifiant la liste des différents processus à activer qui est exploitée cycliquement.

➢ L'ordonnancement est ainsi périodique.➢ Le temps est découpé en unité de base insécable appelé cycle de base.

D'autre part un ordonnancement est dit dynamique s'il est caractérisé par :

2626


➢ Un ordonnanceur en ligne qui ré-évalue à chaque nouvelle demande la tâche qui doit être exécutée.

➢ Il permet de tenir compte des tâches apériodiques et sporadiques

2.1.4. Ordonnanceur à priorités statiques, dynamiquesL’ordonnanceur est la fonction de l’exécutable chargée de choisir l’ordre d’exécution des

tâches dans un ordonnancement en ligne. Différentes hypothèses simplificatrices sont généralement faites :

➢ les propriétés temporelles d’une tâche sont constantes tout au long de la durée de vie de l’application ;

➢ les tâches sont indépendantes, le découpage de l’application en un ensemble de tâches doit donc être judicieux.

Le choix de l’ordonnancement est basé sur des priorités affectées aux tâches. A des intervalles de temps réguliers, l’ordonnanceur détermine la tâche à exécuter parmi une liste. Ce choix est réalisé en comparant la priorité d’exécution de la tâche en cours à la priorité de chacune des tâches de la liste. Généralement les priorités des tâches sont déterminées à la compilation et sont invariantes pendant l’exécution de l’application, on parle d'ordonnancement à priorités statiques. Dans certains exécutables, les priorités peuvent varier pendant l’exécution. Dans ce cas l’ordonnancement est dit ordonnancement à priorités dynamiques. L’assignation des priorités aux tâches est parfois empirique, elle repose sur le savoir-faire des programmeurs de l’application. Généralement, elle repose sur des règles définies par la politique d’ordonnancement (cf §2.2).

2.2. ALGORITHMES D'ORDONNANCEMENT CLASSIQUES

Dans cette section, nous donnons une idée générale de quelques politiques d'ordonnancements que nous avons utilisées pour effectuer nos expérimentations.

2.2.1. Rate Monotonic (RM)Dans cette approche, l'échéance D de la tâche est toujours égale à sa période P et la priorité

associée à l'exécution de la tâche est inversement proportionnelle à sa période d'exécution P. C'est un ordonnancement à priorités statiques. Les tâches sont périodiques et indépendantes.

Il a été démontré qu'avec ce type d'ordonnancement pour qu'une implantation soit acceptable (pour que les échéances de toutes les tâches soient satisfaites), il suffit que l'ensemble des tâches respecte la condition suivante (test d'ordonnançabilité) [10], [11]:

U = ∑i=1

n C i

P i≤ n 21 /n−1 , U étant le taux d'utilisation du processeur.

2727


La limite de ce test d'ordonnançabilité est fonction du nombre de tâches du système. Notons que :

limn∞

n 21 /n−1=ln2≈0.69

Ceci implique qu'un ensemble de tâches est ordonnançable si U ≤ 0.69, mais il se peut qu'il ne soit pas ordonnançable si 0.69 < U ≤ 1.

Cette politique d'ordonnancement est beaucoup utilisée étant donné qu'elle utilise des priorités fixes et qu'elle est donc simple à mettre en œuvre.

La figure 1.3 montre l'ordonnancement de trois tâches périodiques T1, T2

et T3 d'un système temps-réel, caractérisées par une phase = 0 et, des WCET, des échéances et des périodes spécifiques. L'ordonnancement Rate Monotonic autorise la préemption des tâches. La jième activation d'une tâche Ti est notée par Ti,j. Comme la tâche T2 possède la plus grande priorité, elle est exécutée en premier. Elle est suivie par les tâches T3 puis T1. Comme T2 possède une priorité supérieure à celle de T1, elle interrompt l'exécution de celle-ci à l'instant t = 5 correspondant à sa période d'exécution. Les flèches vertes correspondent au temps d'activation des tâches – la tâche est prête à être exécutée (comme la phase est nulle, ces flèches sont marquées à la fin de la période des tâches sauf pour la première activation car on suppose que toutes les tâches sont prête à t = 0).

2.2.2. Earliest Deadline First (EDF)La priorité est ici déterminée en fonction de l'échéance relative D de la tâche et c'est la

tâche qui a la plus petite échéance absolue di = nPi + Di qui est la plus prioritaire, où n est le nombre d'exécutions antérieures de la tâche [12]. Dans le cas où il existe deux tâches qui ont la même échéance absolue, l'une d'elles est choisie d'une manière arbitraire. Comme les échéances relatives des instances de tâches changent, EDF est un ordonnancement à priorités

2828

Figure 1.3 - Exemple d'ordonnancement RM


dynamiques.

Quand les tâches sont à échéances sur requête (Pi = Di), on dispose de la condition

nécessaire et suffisante d'ordonnançabilité U = ∑i=1

n C i

P i≤ 1 . Pour des tâches à échéances

quelconques, cette condition est seulement nécessaire et une condition suffisante est alors

∑i=1

n C i

Di≤ 1 .

Cette politique d'ordonnancement est plus difficile à mettre en oeuvre que celle du Rate Monotonic, car il est parfois difficile de fixer les échéances des tâches. Par contre, grâce à l'exploitation de l'échéance, paramètre commun à tous les types de tâches, la prise en compte des tâches sporadiques et apériodiques est facilitée [11].

EDF est plus avantageux que RM vu qu'on n'a pas besoin d'attribuer des priorités aux tâches. De plus, c'est un algorithme optimal car si un ensemble de tâches est ordonnançable, U ≤ 1, donc il est sûrement ordonnançable par EDF, ce n'est pas un cas général pour RM (voir §2.5.1). Ensuite, EDF peut ordonnancer n'importe quel ensemble de tâches ordonnançables par RM mais la réciproque n'est pas correcte. Enfin, EDF utilise le processeur avec un temps d'inactivité inférieur ou égal à celui fournit par RM [13].

La figure 1.4 montre l'ordonnancement EDF des tâches T1(0,3,7,20), T2(0,2,4,5) et T3(0,1,8,10). T2 est la tâche prioritaire car elle possède la plus petite échéance relative. Elle est ensuite suivie de T1 puis de T3. Notons que les flèches vertes indiquent la date d'activation de la tâche tandis que les rouges montrent la date d'échéance relative de chaque tâche. On peut également remarquer que si on garde les mêmes échéances que dans l'exemple de la figure 1.3, nous obtiendrons le même ordonnancement avec EDF.

2.2.3. Deadline Monotonic (DM)C'est un algorithme d'ordonnancement à priorité fixe tel que la priorité d'une tâche est

2929

Figure 1.4 - Exemple d'ordonnancement EDF


inversement proportionnelle à son échéance relative. Pour cet algorithme, l'échéance relative d'une tâche peut être inférieure ou égale à sa période – D ≤ P [11]. Si l'échéance des tâches est égale à leur période, l'algorithme est équivalent au Rate Monotonic.

Si nous considérons l'ensemble des tâches de la figure 1.4, nous obtiendrons le même ordonnancement qu'avec EDF.

2.2.4. Least Laxity First (LLF)Cet algorithme est une variante d'EDF, il est donc basé sur le calcul dynamique des

priorités des tâches. A chaque décision d'ordonnancement, on augmente la priorité de chaque tâche en fonction de leur marge temporelle (Laxity). Celle dont la laxité est la plus petite sera alors la plus prioritaire.

La laxité li d'une tâche T (Pi, Ci, Di) est définie comme suit:

l i= Di− t c i'

où t, temps courant et c'i , temps de calcul restant (cf figure 1.5).

3. MODÉLISATION EN AADLLes systèmes temps-réel offrent de plus en plus de fonctionnalités et ont des domaines

d'application toujours plus nombreux que ce soit dans le monde industriel, ou sous forme embarquée dans l'automobile et l'aviation. Les langages de conception doivent permettre de maîtriser la complexité de tels systèmes, d'améliorer leur qualité et de minimiser les coûts de développement. Ces langages de description d'architecture sont très utiles car ils permettent l'introduction des méthodes formelles et des modèles de technologie dans l'analyse des architectures de logiciel et de système [14].

3030

Figure 1.5 - Calcul de la laxité d'une tâche Ti

Chapitre 1- Systèmes embarqués et temps-réel 3.Modélisation en AADL

La norme AADL, Architecture Analysis & Design Language a été développée pour les systèmes embarqués temps-réel de sûreté critique. Ces systèmes supportent l'utilisation de diverses approches formelles pour analyser l'impact de la composition des systèmes matériels et logiciels et pour réaliser la génération du code de système répondant aux normes de qualités et de performance prévues. AADL, est basée sur le langage MetaH [15]. Il inclut des profils UML utilisés pour l'avionique, l'espace, les véhicules à moteur, la robotique et d'autres domaines en temps-réel de traitements concurrents comprenant des applications de sûreté critique.

Le standard international d'AADL a été développé par la SAE (Society of Automotive Engineers) depuis 2001. La version 1.0 a paru en 2004. Le comité de standardisation comporte les principaux acteurs de l'industrie avionique et aérospatiale, en Europe comme aux USA (Honeywell, ESA, Airbus, Rockwell Collins, EADS, AMCOM, NIST, Boeing, etc).

3.1. CHOIX D'AADLLe modèle AADL [16], [17] décrit entièrement un système embarqué. Comme AADL

possède une description graphique et textuelle, il permet de comprendre plus facilement le fonctionnement de l'application.

De plus, le langage AADL peut être utilisé pour réaliser des traitements automatiques. Par exemple, on peut générer plusieurs ordonnancements à partir de la description. Nous utilisons CHEDDAR [18] pour accomplir cette tâche. CHEDDAR est un outil qui permet de générer des ordonnancements d'une liste de tâches bien définie. Il est développé et maintenu au LISYC de l'université de Brest. Nous allons utiliser cet outil pour expérimenter notre approche de calcul du WCET sur l'application complète

Dans le cadre de l'analyse statique, bien que le modèle AADL soit basé sur une application réelle et vu que nous ne réalisons pas de simulations fonctionnelles, nous pouvons le changer librement selon nos besoins expérimentaux. Nous pouvons ajouter / supprimer des composants, changer des propriétés et / ou ajouter de nouvelles propriétés pour évaluer les paramètres de l'application. Comme nous sommes spécifiquement intéressés par les contraintes temporelles pour le calcul du WCET et pour l'analyse d'ordonnancement, AADL peut être très utile pour évaluer ces propriétés sans avoir à changer la structure de l'application.

3.2. AADL : VUE GÉNÉRALE

Le SAE-AADL a été développé pour les systèmes temps-réel embarqués qui ont des contraintes critiques de ressources (taille, poids, puissance), des contraintes de réponse en temps-réel, de tolérance des fautes, et de matériel spécialisé d'entrée-sortie, et qui doivent être certifiés à des niveaux élevés de fiabilité. AADL a été conçu pour servir de base à l'analyse et à la génération des systèmes embarqués basés sur des modèles. La notation a été conçue

3131

Chapitre 1 - Systèmes embarqués et temps-réel 3.Modélisation en AADL

comme un noyau de langage extensible avec des sémantiques bien définies et des présentations graphiques et textuelles.

Le langage est employé pour décrire la structure d'un système temps-réel embarqué comme un ensemble de composants logiciels et matériels. Il supporte les spécifications des interfaces fonctionnelles (tels que des entrées et des sorties de données) et les aspects non fonctionnels (tels que la synchronisation des composants). AADL décrit la composition et l'interaction entre les composants de l'application, et comment ces composants sont assignés aux processeurs dans la plate-forme d'exécution. Les mécanismes d’extension permettent d’introduire des propriétés spécifiques aux analyses supplémentaires d'architecture comme des attributs de qualité tels que la fiabilité, la sécurité, etc.

AADL peut être employé de deux manières : analyse légère des patrons d'architecture identifiés dans les systèmes temps-réel pour découvrir les enjeux systémiques potentiels ( sécurité, sûreté, inversion de priorité, connexions requises,etc.), et l'analyse complète d'un modèle complet de systèmes avec des valeurs quantifiées de ses propriétés.

3.3. TYPES DE COMPOSANTS

Le but d'AADL est de modéliser l'architecture des systèmes logiciels qui sont des systèmes d'application liés à une plate-forme d'exécution. L'architecture est modélisée en hiérarchie de composants, dont l'interaction est représentée par des connexions. Un composant possède un type de composant et une ou plusieurs implémentation(s) de composant.

Définition 8 (Type de Composant) – décrit une interface fonctionnelle en termes de caractéristiques, spécification de flot, et propriétés. Il représente la spécification du composant avec laquelle d'autres composants peuvent fonctionner, c-à-d son interface extérieure visible. Des implémentations du composant sont exigées pour satisfaire ces spécifications.Définition 9 (Implémentation de Composant) – spécifie une structure interne en termes de sous-composants, de connexions entre les dispositifs de ces sous-composants, de flots à travers un ordonnancement des sous-composants, de modes (cf. § 2.4) pour représenter les états opérationnels, et des propriétés. À la différence de beaucoup d'autres langages, AADL permet la déclaration de multiples implémentations avec la même interface fonctionnelle (type).

La généralisation des composants est possible du fait que les types de composants et les composants d’implémentation peuvent être exprimés comme des prolongements d'autres types de composants et implémentations de composants [14].

3232


L'interface d'un composant est formée de ports de connexions représentant : le flot directionnel de données et/ou de contrôle à partir des données, des événements, et des données d'événement (figure1.6), des appels synchrones de sous-programme entre les threads, potentiellement situés sur différents processeurs et des accès concurrents aux données.

Des connexions de ports de données peuvent être indiquées pour exécuter des communications immédiates au cours de la même période d'activation, ou des communications retardées pour que les données soient disponibles après la date limite du thread initial. Ces sémantiques assurent le transfert déterministe des flux de données entre les threads périodiques : c’est une caractéristique importante pour les systèmes de contrôle embarqués. Le transfert déterministe signifie qu'un thread reçoit toujours des données avec le même temps de retard [14].

Cette norme définit les types de composants suivants : données, sous-programmes, threads, groupe de threads, processus, paquets, mémoires, bus, processeurs, dispositifs, et système.

Ces types sont répartis en trois sous-catégories : Logicielle, Matérielle et Composite (figure1.7). Ils forment le noyau du vocabulaire de modélisation d'AADL.

3333

Figure 1.6 - Type de ports

Figure 1.7 - Représentation graphique des composants AADL.


3.3.1. Composants MatérielsPour modéliser les plate-formes d'exécution, quatre catégories de composants sont

proposées :

➢ processeur : abstraction du matériel et du logiciel qui est responsable d’ordonnancer et d'exécuter des unités d'exécution concurrentes (thread) selon un protocole d’ordonnancement spécifique et peut permettre la partition de l’espace par des espaces d’adresse protégés.

➢ mémoire : une abstraction du stockage physique accessible aléatoirement (RAM, ROM) qui peut contenir des données et / ou du code.

➢ bus : une abstraction de connecteur entre les composants de la plate-forme d’exécution.

➢ dispositif (device) : une abstraction d'un composant actif (tels que capteur, actionneur, caméra, ...) avec lequel un système d'application peut interagir et auquel un processeur peut accéder via un bus.

Les composants de la plate-forme d'exécution peuvent représenter des composants de matériel ou des composants abstraits de plate-forme d'exécution, dont l’implantation peut être réalisée par des machines virtuelles qui sont représentées par d'autres plate-formes d'exécution, avec des liens au matériel réel.

Chaque catégorie de plate-forme d'exécution a un certain nombre de propriétés prédéfinies telles que le temps de changement de thread et de processus ou le protocole d’ordonnancement des processeurs. Le noyau AADL prédéfinit de telles propriétés et un ensemble initial de valeurs de propriétés acceptables qui peut être étendu. Par exemple, de nouveaux protocoles d’ordonnancement peuvent être présentés par un mécanisme d’extension de propriété.

3.3.2. Composants LogicielsLa modélisation du système d'application est réalisée à partir de deux groupes de

catégories de composants.

Le premier groupe se concentre sur le comportement de l'exécution d'un système et est composé de :

➢ threads : unité de base d'exécution concurrente.➢ groupes de threads : groupement structurel des threads dans un processus. Un groupe

de threads peut contenir des données, des threads, et des sous-composants de groupe de threads. Il peut exiger et permettre d'accéder aux sous-composants de données.

➢ processus : unité d'espace d'adresse protégée. Il modélise des partitions de l'espace en termes d'espaces d’adresses virtuelles contenant le texte source qui forme le programme complet comme défini dans un langage de programmation standard.

3434


Des threads sont contenus dans les processus et ont un ensemble de valeurs de propriétés prédéfinies de protocole d'activation ou un ensemble présenté par le mécanisme d’extension de propriété. Les protocoles prédéfinis incluent des comportements périodiques, apériodiques, sporadiques, serveurs, et arrière-plan.

Le deuxième groupe se concentre sur le texte source d'un système et se compose de:

➢ paquets : ils fournissent une structure de bibliothèque, un espace de nommage, pour organiser les composants d'implémentation et de type en espaces de noms séparés et les combiner dans des spécifications du système. En dehors de son paquet, un composant doit être qualifié par le nom du paquet qui le contient.

➢ composant données : données passives d'application qui représentent des types de données et les abstractions de classe dans le texte source nécessaire pour des modèles d'architecture.

Le type de données est employé pour typer les ports, pour indiquer les types des paramètres des sous-programmes, et pour typer des instances de composants données. Le mécanisme d’extension du type de composant peut modéliser le type héritage.

Les caractéristiques des sous-programmes dans les types de composants peuvent représenter des méthodes de classe et ceux qui accèdent aux composants données déclarés partagés par un protocole spécifique de gestion des conflits. Les points d’entrée d’un sous-programme sont définis dans l'interface du composant en tant que points d’entrée « requis » ou « fourni ».

3.3.3. Composants CompositesUne dernière catégorie de composant permet la composition hiérarchique et se compose

de : système, unité dont les implémentations peuvent contenir des composants des plate-formes d'exécution, des composants logiciels et d'autres instances de système.

3.4. LES MODES

Les modes représentent des configurations alternatives de l’implémentation du composant avec seulement un mode actif à la fois. Au niveau du système et du processus, un mode représente les recouvrements probables des (sous)-ensembles des threads actifs et des ports de connexions et des configurations alternatives des composants de la plate-forme d'exécution, aussi bien que les liens alternatifs des composants d'application aux composants de plate-forme d'exécution.

Le comportement du changement de mode est représenté par un diagramme d’état / transition dont les états sont les modes et les transitions sont déclenchées par des événements. Ainsi, AADL peut modéliser le comportement changeant dynamiquement des topologies statiquement connues, des ports de communication et des threads, liées aux topologies statiquement connues des plate-formes d'exécution.

3535


Des modes peuvent également être déclarés pour des composants de texte source. Ceci permet à des valeurs de propriétés spécifiques à des modes d'être déclarées dans les situations où l'architecture de thread et de raccordement ne change pas, mais le comportement interne du thread change. Par exemple, il peut y avoir des différents temps d'exécution pour le pire cas sous différents modes. Une modélisation plus détaillée des systèmes d'application permet des analyses moins conservatrices telle que l'analyse de l’ordonnancement [14].

3.5. LES PROPRIÉTÉS

Les composants, les modes, et les connexions peuvent avoir des propriétés. Une propriété a un nom, un type et une valeur. Des propriétés sont employées pour représenter des attributs et d'autres caractéristiques, telles que la période et la date limite des threads.

Quand des propriétés sont associées aux déclarations des types de composants, des composants d’implémentation, des sous-composants, des connexions, des flots, et des modes, elles s'appliquent à toutes les instances respectives dans une instance système. Les propriétés peuvent avoir des valeurs spécifiques mode et spécifiques lien.

Cette norme définit un ensemble de propriétés pré-déclarées et des types de propriétés. Des propriétés et des types de propriétés supplémentaires peuvent être introduits à travers les ensembles de propriétés pour soutenir de nouvelles formes d'analyse du système. Des valeurs de propriétés peuvent être associées aux types de composants, aux composants d’implémentation, aux sous-composants, aux flots, aux connexions, aux modes, et aux appels de sous-programme. Par exemple, une propriété est employée pour identifier les fichiers de code source liés à un composant logiciel. Des propriétés sont également employées pour indiquer le nombre et la taille des endroits de stockage accessibles dans un composant mémoire.

4. CONCLUSION

Nous avons défini dans ce chapitre un système temps-réel embarqué et nous avons expliqué ses différentes caractéristiques. Nous avons aussi introduit la notion d'ordonnancement temps-réel et la génération d'ordonnancement suivant les algorithmes d'ordonnancements les plus utilisés.

Pour mieux comprendre ces notions nous, présenterons dans le chapitre suivant une application temps-réel embarquée et les différentes caractéristiques temps-réel de ces tâches qui vont nous permettre de la modéliser en AADL et utiliser ce modèle pour générer des ordonnancements de ces tâches.

3636

CHAPITRE 2

PAPABENCH : UN BENCHMARK TEMPS-RÉEL

Les systèmes temps-réel embarqués sont largement utilisés dans la société moderne. Ces systèmes sont formés essentiellement de tâches temps-réel qui doivent respecter des contraintes temporelles.

Pour évaluer le respect des contraintes temporelles, il est nécessaire de connaître le WCET d'un programme s'exécutant sur un système matériel donné. La connaissance du WCET des tâches peut être utile dans la conception d’un système temps-réel que ce soit au niveau matériel ou au niveau de l’application.

Comme tout logiciel, le calcul du WCET nécessite des expérimentations, des évaluations et des comparaisons. Pour réaliser cet objectif, nous introduisons dans ce chapitre un benchmark temps-réel, PapaBench, décrivant une application temps-réel complète pour le pilotage d'un drone ou UAV (Unmanned Aerial Vehicles). Il a été conçu afin de constituer une base utile pour les expérimentations de calcul de WCET par méthodes statiques ou dynamiques, il peut être aussi utile pour les analyses d'ordonnancement.

Ce benchmark fournit des tâches et des interruptions concrètes avec des contraintes temporelles et des règles de précédence. L'utilisation de ce benchmark va contribuer à l'obtention de résultats expérimentaux plus réalistes que ceux obtenus avec les benchmarks courants [19], [20], [21] vu que les tâches à analyser sont proches de celles s'exécutant dans les systèmes-réels de l'avionique.

Nous commençons ce chapitre par une brève description du projet de drone léger Paparazzi où nous présentons l'architecture et le fonctionnement de ces différents composants. Nous introduisons dans la deuxième section la première version PapaBench1, créée en gardant la même liste de tâches que Paparazzi. Nous fournissons une description AADL de PapaBench1 qui énumère les différentes tâches, leurs contraintes temps-réel et leurs règles de précédence. Les limitations de cette version sont expliquées à la section 3 et la deuxième version PapaBench2 est présentée à la section 4. Nous comparons notre benchmark aux autres benchmark temps-réel et nous fournissons des indications pour son utilisation dans les sections restantes.

3737

Chapitre 2 - Papabench : un benchmark temps-réel 1.Le projet Paparazzi

1. LE PROJET PAPARAZZI

Le terme "drone" est aujourd'hui largement utilisé pour désigner un "aéronef sans pilote", quelles que soient sa taille, sa forme, sa fonction et ses caractéristiques. Les engins non récupérables comme les fusées et les missiles ne sont pas, en général, classés parmi les drones.

Définition 14 (Drone) – On retiendra la définition anglo-saxonne qui désigne par drone un aéronef sans pilote opéré par radio-commande. On peut ainsi noter qu'un drone est contrôlé et donc pas complètement autonome, il n'est pas nécessairement contrôlé du sol et peut transporter des passagers.

Le projet Paparazzi [22], conçu en 2003 par P. Brisset et A. Drouin, est une tentative de réalisation d'un mini-drone à bas coût, avec les objectifs principaux suivants :

➢ utilisation des technologies d'aéromodélisme, en particulier en utilisant du matériel grand public ;

➢ développement d'un pilote automatique, logiciel et matériel, permettant au drone d'être complètement autonome, pour se maintenir en vol et pour effectuer une « mission » prédéterminée ;

➢ réalisation d'un environnement de développement complet permettant d'installer simplement le système sur des aéronefs variés ;

➢ développement d'une station sol de contrôle et de suivi de vol.

Ce projet propose du code ouvert. L'ensemble des travaux est livré avec la licence GNU qui permet la réutilisation tout en protégeant les auteurs originaux.

1.1. HISTORIQUE

L’objectif initial du système Paparazzi était de participer au concours de vol autonome des journées Micro-Drones Supaéro / Ensica. L’épreuve consistait à réaliser une mission: « repérer une cible au sol et en donner la position ».

La fonction initiale d’un drone est le vol. Le premier objectif était de choisir un aéronef qui vole bien, naturellement stable et facile à piloter. Le choix s’est porté sur le Twinstar Multiplex, un bimoteur à ailes hautes, de vitesse 10m /s et de poids 1.4 Kg, destiné aux débutants en aéromodélisme.

Le contrôle du drone nécessite un lien bidirectionnel avec le pilote. Le lien descendant est donc très important pour assurer la surveillance des systèmes embarqués. La mise au point de ce lien descendant était l’une des premières tâches du projet. Le lien montant est constitué de la radio-commande.

3838

Chapitre 2- Papabench : un benchmark temps-réel 1.Le projet Paparazzi

La première idée était d’utiliser un GPS, avec le Twinstar, comme unique capteur pour naviguer et d’un module de stabilisation qui permet de conserver l’avion dans le plan de l’horizon grâce à des capteurs infrarouges.

Pour simplifier au maximum le système embarqué, l’idée était de transmettre les informations de positions au sol, d’effectuer les calculs de navigation dans le calculateur (ordinateur portable) au sol et piloter en connectant cet ordinateur à la radio-commande.

Une deuxième étape a consisté à développer le matériel embarqué pour le pilotage embarqué. Une architecture à deux processeurs a été adoptée pour séparer la partie gérant la réception de la radio-commande de la partie pilote automatique.

En implémentant différents processus de contrôle, les trajectoires obtenues étaient autonomes et correctes tout en conservant un décollage et un atterrissage manuels.

Une mini caméra vidéo couleur a été ajoutée et le Twinstar ainsi équipé a remporté en septembre 2003 le trophée vol autonome des Journées MicroDrones.

Des outils de configuration ont été développés. Le logiciel, de la station au sol et la radio-commande ont été largement ré-écrits pour les rendre paramétrables. Les configurations ont été simplifiées à travers l’usage d’interfaces graphiques. Ces efforts ont été faits pour des utilisateurs sans connaissance importante en informatique.

L’étape suivante du projet était de choisir un drone plus petit tout en respectant les contraintes : facilité de mise en œuvre et qualité de vol. Le Microjet de Multiplex a été choisi et, à cette occasion, la carte de contrôle a été aussi miniaturisée. Cette configuration a remportée en juillet 2004 l’épreuve de vol autonome d'EMAV en 2004.

Aujourd’hui la fiabilité du système Paparazzi permet de réaliser des missions de plusieurs kilomètres complètement automatiquement, la mission étant spécifiée par un langage de haut niveau. Le décollage est dorénavant entièrement automatique.

1.2. LES COMPOSANTS DU SYSTÈME PAPARAZZI

Le système Paparazzi actuel permet de développer un système complet, matériel et logiciel, qui peut être embarqué sur plusieurs aéronefs. Un tel système a une autonomie limitée de 2 à 5 Kg de poids total, une distance de vol maximale de 25 km, une durée de vol d'une heure, une vitesse maximale de 50 Km/h et 500g maximum de charge utile. Paparazzi est constitué d’un système embarqué et d’une station de contrôle (voir figure2.1).

Le système embarqué comporte, en plus des éléments classiques d'un aéro-modèle (récepteur, servo-commandes et batterie), une carte de contrôle avec son alimentation, un récepteur GPS, un quadruple capteur infrarouge et un émetteur radio. La carte de contrôle regroupe deux microcontrôleur RISC ATMEL AVR [23]. MCU1 (microcontrôleur ATMega8, appelé Fly_by_wire) est caractérisé par un processeur à 16 Mhz / 16 MIPS, d'une RAM statique de 1 KO, d'une mémoire flash de 8KO et d'une mémoire EEPROM de 512 octets. Il

3939


gère la radio-commande et les commandes de vols. MCU0 (microcontrôleur ATMega128, appelé Autopilot) est doté d'un processeur 16 MHz / 16 MIPS, d'une RAM statique de 4 KO, d'une mémoire flash de 128 KO et d'une EEPROM de 4 KO. Il gère la stabilisation, la navigation, le lien descendant, et un modem connecté au canal radio de l'émetteur pour le lien descendant. Les deux microcontrôleurs communiquent via un lien SPI série dans un mode Maître (MCU0) / Esclave (MCU1). MCU0 demande à MCU1 les informations reçues de la radio-commande et envoie en retour les commandes de vol stabilisées.

La station de contrôle est constituée d'une radio-commande traditionnelle, d'un récepteur radio et d'un ordinateur. Les canaux audio et vidéo du récepteur sont respectivement connectés à l'ordinateur (via un modem) et à un magnétoscope. L'ordinateur reçoit les informations du lien descendant et diverses interfaces permettent de les afficher. Tous les messages envoyés par le drone sont stockés dans un journal qui peut être rejoué ultérieurement.

1.2.1. Fonctionnement du microcontrôleur MCU1 (Fly by wire)

Le code de MCU1 est très réduit et évolue très peu. MCU1 a trois modes de fonctionnement :

➢ Manuel : les ordres reçus de la radio-commande sont interprétés directement comme des commandes de vol. C'est le fonctionnement d'un aéro-modèle standard.

4040

Figure 2.1 - Le système Paparazzi.

Chapitre 2- Papabench : un benchmark temps-réel 1.Le projet Paparazzi

➢ Automatique : Les commandes de vol sont envoyées par MCU0. Ce mode est enclenché sur ordre de la radio-commande et persiste uniquement si MCU0 envoie régulièrement des consignes. Il y a également passage du mode Manuel au mode Automatique si la réception de la radio-commande est rompue.

➢ Failsafe : MCU1 commute dans ce mode si aucun ordre n'est reçu ni de la radio-commande, ni de MCU0. Les gouvernes sont alors mises au neutre (pour planer) et le moteur arrêté.

1.2.2. Fonctionnement du microcontroleur MCU0 (Autopilote)Le cœur du pilote automatique réside dans le microcontrôleur MCU0. Celui-ci gère trois

modes de fonctionnement principaux (figure 2.3) :

➢ Manuel : les ordres reçus de la radio-commande sont utilisés comme entrées pour la boucle de stabilisation. Ainsi le pilote ne commande pas les ailerons et la gouverne de profondeur mais les angles de roulis et de tangage. Ce mode permet de tester le contrôleur d’attitude seul, l'attitude étant l'orientation autour du centre de gravité autrement dit ses coordonnées. Le contrôleur assure que l’avion reste dans son domaine de vol.

La figure 2.2 montre les trois axes de repère pour le pilotage d'un avion qui se coupent en son centre de gravité (axe de roulis en rouge, axe de tangage en bleu et l'axe de lacet en vert). Le tangage est le mouvement de rotation autour de l'axe de tangage et le roulis représente l'oscillation autour de l'axe de roulis.

➢ Automatique : les consignes envoyées au contrôleur d’attitude et à la propulsion sont calculées à partir de la route et de l’altitude voulues. La route et l’altitude sont

4141

Figure 2.2 - Axes de roulis et de tangage


elles mêmes calculées pour suivre la mission (essentiellement une suite de points de report). Dans ce mode, trois boucles de contrôle sont donc empilées. La stabilisation est réalisée à 20Hz et la navigation à la fréquence des informations délivrées par le GPS (4Hz). La mission est également contrôlée à 20Hz car elle doit pouvoir prendre en compte des événements exceptionnels (ordre de la radio-commande, temps de vol, tension de la batterie, ...)

➢ Home (retour à la maison) : il s’agit d’un mode de navigation basique où l’avion doit revenir à la balise HOME de la mission (son point de départ sauf exception) en visant une altitude de sécurité. Ce mode est enclenché si le lien montant est rompu en mode Manuel ou dans tous les cas si une distance de sécurité au point de route HOME est dépassée.

La stabilisation est assurée grâce aux capteurs infrarouges. Le contrôle de la trajectoire repose uniquement sur les informations fournies par le GPS, en taux de montée et en route. Pour le contrôle latéral, une consigne d'inclinaison est calculée à partir de l'erreur de route. La même solution est utilisée pour le contrôle longitudinal, avec une consigne constante. Le contrôle du taux de montée s'effectue uniquement avec le gaz.

2. PAPABENCH1Cette section introduit la première version du benchmark [24]. Elle décrit la liste des tâches

du modèle ainsi que leurs contraintes temporelles et fournit un graphe d'appel de fonctions pour lier le modèle aux sources C.

4242

Figure 2.3 - Fonctionnement de MCU0 en pilotage manuel assisté et automatique

Chapitre 2- Papabench : un benchmark temps-réel 2.Papabench1

2.1. MODÈLE AADL

Le document [22] contient un rapport complet du projet paparazzi décrivant plusieurs niveaux de contrôle et les contraintes temporelles correspondantes. En se basant sur cette référence et, après avoir analysé les sources C, nous avons identifié une liste de tâches ainsi que leurs règles de précédences. Nous avons aussi défini une liste d'interruptions générées par les transmissions d'information entre les différents dispositifs du système. Les tables (a) et (b) de la figure 2.4 affichent les tâches et les interruptions exécutées par MCU1 et MCU0 respectivement. Elles fournissent, pour chaque tâche, un identificateur utilisé dans les paragraphes suivants, une description et la fréquence d'exécution.

Les graphes des figures 2.5 et 2.6 montrent les règles de précédence qui induisent un certain ordre d'exécution entre les tâches pour le mode manuel et le mode automatique respectivement. Cet ordre est dû à des dépendances de données (flèches marquées 1) ou à des dépendances de contrôle (flèches marquées 2). Ces règles de précédences sont les contraintes minimales pour la génération d'un ordonnancement correct de l'application. Ces règles sont dues au fait que les tâches s'exécutent à la même fréquence. Il faut noter que les sources C originales introduisent un ensemble de dépendances de contrôles trop fortes par rapport aux besoins réels de l'application. Nous avons pu supprimer les fausses dépendances de contrôle grâce à une fructueuse collaboration avec les auteurs de Paparazzi.

Dans chaque graphe, est indiqué pour chaque microcontrôleur la liste des tâches qui s'exécutent dans chaque mode de fonctionnement. L'ajout et la suppression des règles de précédence est possible en AADL car nous pouvons ainsi redéfinir ces ensembles de règles selon nos besoins expérimentaux.

4343

Figure 2.4 - Tâches et interruptions de MCU1 (a) et MCU0(b)

ID Description

T6 40Hz

ID Description T7 20Hz

T1 40Hz T8 20Hz

T2 40Hz T9 4Hz

T3 20Hz T10 Navigation 4Hz

T4 Transmission Servos 20Hz T11 4Hz

T5 Check Failsafe 20Hz T12 4Hz

I1 Interruption Servos 20Hz T13 10Hz

I2 Interruption SPI 20Hz I4 Interruption SPI 20Hz

I3 Interruption Radio 40Hz I5 Interruption Modem 10Hz

I6 Interruption GPS 4Hz

Fréquence

Gestion des Ordres de la Radio

Fréquence Stabilisation

Réception Ordres de la Radio-Commande Envoi Données à MCU1

Envoi Données à MCU0 Réception Données GPS

Reception Données de MCU0

Contrôle Altitude

Contrôle de Montée

Envoi Rapport au sol

Chapitre 2 - Papabench : un benchmark temps-réel 2.Papabench1

Alors que MCU1 reçoit les ordres de la radio et transmet ces données à MCU0, nous pouvons par exemple imaginer un scénario en mode manuel où nous ajoutons les dépendances suivantes à celles indiquées dans le graphe 2.5 pour les couples de tâches [(I3, T1), (T2, I2), (T4, I1)]. D'autre part, pour MCU0 nous ajoutons d'autres dépendances pour les couples [(T6, T7),(T7, T8)].

Le mode automatique est activé sur ordre de la radio-commande ou quand cette dernière n'est plus accessible. AADL fournit les « modes » pour décrire le mode opérationnel du système. La variation du mode opérationnel est déclenchée par l'arrivée d'un événement.

D'autre part, comme en mode automatique, T9 , T10 , T11 et T12 s'exécutent à la même fréquence et accèdent aux mêmes variables globales du code, ces tâches s'exécutent avec les dépendances fournies dans le graphe 2.6. Nous pouvons aussi ajouter une dépendance de contrôle entre I6 et T9 pour la même raison. Nous pouvons même changer l'ordre des dépendances et avoir ainsi plusieurs cas possibles [T9,T11, T12, T10], [T11, T12, T10, T9] ...

Au niveau matériel, le système Paparazzi possède deux sous-systèmes, un pour chaque microcontrôleur. Chaque sous-système décrit le processus d'exécution comme un ensemble de threads et de dispositifs ainsi que leurs interactions.

4444

Figure 2.6 - Dépendances du Mode Automatique

Figure 2.5 - Graphe de dépendances Mode Manuel


2.2. LIEN AVEC LE MODÈLE AADLDans le cadre du projet OTAWA [25], [26], un framework pour expérimenter le calcul du

WCET et les analyses statiques du code binaire, nous avons développé un programme permettant de générer le graphe d'appel (Program Call Graph ou PCG) d'un fichier exécutable et d'autres statistiques du binaire. Le PCG fournit une idée générale de la complexité de l'application et permet de connaître l'enchaînement des appels de fonctions sans se référer aux sources.

Il fournit aussi un lien entre les tâches de l'analyse et le code correspondant dans les sources. Le PCG de Fly_By_Wire et d'Autopilot sont présentés dans les figures 2.7.a et 2.7.b respectivement. Les ellipses colorées représentent les implantations des tâches dans le code source. Le nom de la tâche est marqué dans les étiquettes noires. Dans Autopilot, T7 est formée de la fonction course_pid_run et de nav_home si le système est en mode failsafe, ou bien course_pid_run et nav_update s'il est en mode automatique. Les ellipses pointillées indiquent les interruptions se produisant lors de l'exécution des tâches. On peut remarquer des sous programmes n'appartenant à aucune tâche : en effet, ils sont exécutés au démarrage et ils n'interviennent plus dans le fonctionnement du système pendant toute la durée du vol.

2.3. COMPLEXITÉ DES VARIABLES

En AADL, chaque type de composant peut être détaillé par un ensemble de propriétés. Pour inclure les contraintes temporelles dans notre modèle, nous avons ajouté pour chaque thread les propriétés period et Dispatch_Protocol qui peuvent être périodique, apériodique ou

4545

Figure 2.7 - PCG de Fly_by_wire (a) et de l'autopilot (b).


sporadique. Une tâche apériodique survient à des intervalles de temps arbitraires et peut être retardée pour un laps de temps limité. Au contraire, une tâche sporadique s'exécute à des intervalles de temps arbitraires mais avec une période minimum ou maximum entre deux exécutions consécutives.

Pour Paparazzi, les entrées / sorties sont gérées comme des interruptions apériodiques. Généralement, les logiciels avioniques ne supportent pas des interruptions car leur WCET ne peut être calculé de manière précise avec les techniques actuelles. Toutefois, nous ne sommes pas obligés de suivre l'ordonnancement statique fourni par le code C de Paparazzi. On peut considérer le modèle AADL, ses tâches (y compris les interruptions) et le code correspondant dans les sources C, mais plusieurs ordonnancements et contraintes temporelles peuvent être expérimentées selon nos besoins. Ceci permet de définir plusieurs modèles AADL du plus simple au plus réaliste.

On peut commencer l'analyse du WCET du système en considérant que les tâches et les interruptions sont périodiques, ce qui est le cas le plus simple pour le calcul du WCET. On peut ensuite considérer toutes les valeurs possibles de la propriété Dispatch_Protocol pour considérer des cas plus complexes et peut-être même analyser le cas de l'application réelle où les interruptions sont apériodiques et les tâches ne sont pas forcément périodiques.

Il est également possible d'étudier la préemption entre les tâches. Pour cela, nous avons ajouté une nouvelle propriété Preemption applicable seulement aux threads qui précise la nature de la préemption qui peut être «System_Preemption» ou « Time_Sharing_Preemption ». On dispose aussi de la valeur « Non_Preemptive » pour distinguer les tâches préemptives des non préemptives. Avec cette propriété, il est encore possible d'augmenter la complexité du modèle à analyser.

2.4. REPRÉSENTATION GRAPHIQUE DE PAPARAZZI

Dans ce paragraphe, nous montrons la représentation graphique de Paparazzi, suivant la notation graphique d'AADL.

Ce modèle graphique contient toutes les tâches et les interruptions, définies par des

4646

Figure 2.8 - Le système embarqué de Paparazzi.


threads, ainsi que les composants matériels du système.

Les ports et leurs connexions sont visibles sur les schémas avec distinction des connexions spécifiques caractérisant certains modes de fonctionnement du système.

Le système embarqué Paparazzi est formé de deux sous-systèmes Fly_By_Wire (MCU1) et Autopilot (MCU0) reliés par un lien série SPI et communiquant à travers des ports données événements (figure 2.8). Les composants des systèmes MCU1 et MCU0, ainsi que leurs connexions sont indiqués dans les figures 2.9 et 2.10 respectivement.

4747

Figure 2.9 - Représentation graphique du système MCU1

Figure 2.10 - Représentation graphique du système MCU0


Cette visualisation permet d’identifier la répartition des tâches et les interruptions entre les deux systèmes ainsi que leurs connexions, pour mieux comprendre le fonctionnement de l’application.

3. LIMITATIONS DE PAPABENCH1Les benchmarks temps-réel utilisés pour les expérimentations des approches de calcul du

WCET sont constitués d'une collection de fonctions. Ils ne possèdent donc pas les caractéristiques d'une application temps-réel complète et réaliste. Ainsi l'utilisation de ces benchmarks ne permet pas l'analyse des effets d'enchaînement des tâches.

Cela a été la principale motivation pour la création de la première version de ce benchmark baptisée PapaBench1. Ce benchmark étant basé sur le système Paparazzi, présente toutes les caractéristiques d'une application complète et permet d'effectuer des analyses inter-tâches pour modéliser l'état des composants matériels dont le comportement dépend de l'ordre d'exécution des tâches, comme la mémoire cache, le pipeline, le prédicateur de branchement, etc.

Nous avons utilisé PapaBench1 pour tester plusieurs approches de calcul du WCET, essentiellement dans le mode automatique qui illustre le comportement critique de l'application. Il a été aussi utilisé pour la génération de différents ordonnancements selon les politiques d'ordonnancements les plus utilisées. L'idée principale était de tester l'impact de la variation de l'estimation du WCET des tâches, suite à la prise en compte la trace des instructions dans la mémoire cache, sur l'ordre d'exécution des tâches pour une politique d'ordonnancement donnée. Nous avons noté que les ordonnancements générés sont très similaires ce qui ne permet pas d'effectuer cette analyse. Ceci est dû au manque de flexibilité des ordonnancements de PapaBench1. En effet, en analysant les tâches, le plus grand défi était de générer des ordonnancements différents malgré la présence de grosses tâches ayant des WCET très élevés.

4848

Figure 2.11: Exemple d'ordonnancement

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

sous cycle 1 sous cycle 2 sous cycle 3 sous cycle 4

IdleT4T3T2T1

Chapitre 2- Papabench : un benchmark temps-réel 3.Limitations de Papabench1

Pour mieux comprendre ce problème, la figure 2.11 illustre l'exemple d'un ordonnancement de quatre tâches d'une application temps-réel. Les périodes des tâches de l'ordonnancement sont réparties en quatre sous-cycles1. Chaque sous-cycle est représenté par les proportions des WCET de tâches ; par exemple le premier sous-cycle est plein à 90% bien que le second le soit à 20%. Le temps d'inactivité est représenté par l'espace blanc. Nous pouvons noter que la tâche T3 possède le plus grand WCET et occupe la majorité des sous-cycles 1 et 3. Quand l'analyse inter-tâche expliquée ci-dessus s'applique à cet ordonnancement, son impact est négligeable à cause de ce grand WCET.

En effet, si on veut observer la trace des instructions dans le cache pour réduire l'estimation du WCET des tâches : T3, qui contient un très grand nombre d'instructions, occupe le cache, ce qui nécessite la suppression du cache d'un nombre non négligeable d'adresses provenant de la trace laissée par l'exécution des autres tâches. Cela empêche les tâches qui s'exécutent après T3 de profiter de la trace des tâches précédentes. En supposant que les tâches T1 et T4 ne profitent pas des traces de T3, la nouvelle estimation de leur WCET, sera très proches ou même égale à l'ancienne estimation. D'autre part, même si l'analyse inter-tâche réduit l'estimation de l'ancien WCET de T3, ceci n'a aucun effet sur l'ordonnancement car le WCET de T3 est très large comparé au gain obtenu grâce à l'analyse inter-tâche. Ainsi, le nouvel ordonnancement généré en fonction des nouvelles estimations du WCET est identique au précédent.

PapaBench1 possède trois grandes tâches ayant des WCET très larges comparés aux WCET des autres tâches. Les ordonnancements que nous avons générés avec cette version montrent que ces tâches occupent la majorité des sous-cycles où elles s'exécutent ce qui rend l'inactivité dans ces sous-cycles proche de 0 et très large dans les autres sous-cycles . Ainsi la charge des processeurs n'est pas distribuée d'une manière homogène sur les sous-cycles de l'ordonnancement. Nous avons aussi remarqué que l'analyse inter-tâche n'affecte pas l'ordre d'exécution des tâches à cause de ces grandes tâches comme nous l'avons expliqué sur l'exemple de la figure 2.11.

Nous avons donc envisagé de créer PapaBench2, une nouvelle version de ce benchmark qui répartit les grandes tâches en un ensemble de tâches plus petites pour augmenter la flexibilité des ordonnancements générés et pour répartir la charge du processeur sur l'ensemble des sous-cycles. Cette flexibilité va permettre à l'analyse inter-tâche d'avoir un impact plus important sur la génération des ordonnancements.

Dans la section suivante, nous présentons la nouvelle liste des tâches ainsi que leurs contraintes temporelles et les nouvelles règles de précédence. Nous comparerons aussi les deux versions du benchmark afin de prouver que l'organisation de PapaBench2 est plus flexible que celle de PapaBench1.

1 La durée d'un sous cycle est égale à la plus petite période des tâches de l'application.

4949

Chapitre 2 - Papabench : un benchmark temps-réel 4.Genèse de Papabench2

4. GENÈSE DE PAPABENCH2Comme nous l'avons expliqué dans la section précédente, le but de PapaBench2 est de

répartir les grandes tâches de PapaBench1 en un ensemble de petites tâches pour gagner en flexibilité dans la génération des ordonnancements. Nous expliquons dans cette section les modifications réalisées pour la création de PapaBench2.

4.1. LE MODÈLE AADLEn se basant sur le modèle AADL de PapaBench1 et après avoir analysé les sources C,

nous avons identifié trois grandes tâches, en terme de nombre d'instructions et de WCET. Ces trois tâches sont T9, T10 et T13 dans le modèle de PapaBench1. La liste des tâches de MCU1 étant inchangée, nous présentons uniquement le nouvelle liste des tâches de MCU0 dans le tableau 2.1.

Chaque tâche est caractérisée par un identificateur, une description et une fréquence d'exécution. La différence avec la liste des tâches de MCU0 dans PapaBench1 est indiquée par des cases colorées. La tâche T9 de PapaBench1 qui gère les informations fournies par le GPS est répartie en quatre sous-tâches T9, T10, T11 et T12 qui s'exécutent à la même fréquence que leur tâche mère. De même, navigation_task est répartie en trois sous-tâches T13, T14 et T15 qui s'exécutent aussi à la même fréquence. Pour terminer, la plus grande tâche T13 de PapaBench1 qui envoie des rapports à la station sol à une fréquence de 10Hz est répartie en dix tâches de T18 jusqu'à T27. En effet, en analysant le code de T13 dans PapaBench1, nous avons remarqué que l'implémentation de cette fonction consiste en une liste de tests imbriqués. Ces imbrications testent la valeur d'une variable globale, représentant

5050

Tableau 2.1 - Tâches et interruptions de MCU0.

ID Description Fréquence ID Description Fréquence

T6 radio_control_task 40Hz T17 climb_control_task 4Hz

T7 stabilization_task 20Hz T18 send_boot 10Hz

T8 link_fbw_send 20Hz T19 send_attitude 2Hz

T9 parse_gps_msg 4Hz T20 send_adc 2Hz

T10 send_gps_pos 4Hz T21 send_settings 2Hz

T11 send_radIR 4Hz T22 send_desired 1Hz

T12 send_takeOff 4Hz T23 send_bat 0.5Hz

T13 navigation_update 4Hz T24 send_climb 0.5Hz

T14 course_run 4Hz T25 send_mode 0.2Hz

T15 send_nav_values 4Hz T26 send_debug 0.2Hz

T16 altitude_control_task 4Hz T27 send_nav_ref 0.1HzI4 Interruption SPI 1 20Hz I6 Interruption Modem 10HzI5 Interruption SPI 2 20Hz I7 Interruption GPS 4Hz

Chapitre 2- Papabench : un benchmark temps-réel 4.Genèse de Papabench2

un chronomètre qui est incrémenté à chaque invocation (donc avec une fréquence de 10Hz). En fonction de sa valeur, une ou plusieurs fonctions sont activées ce qui fait que le corps de cette tâche n'est pas exécuté en entier à chacune de ces activations dans l'ordonnancement. Notons que seule T18 s'exécute à la même fréquence que T13 tandis que les autres tâches s'exécutent à des fréquences plus petites. Ces fréquences sont fournies dans le code source.

En réalité, l'ordonnanceur initial de Paparazzi peut être vu comme un ordonnanceur hiérarchique où certaines tâches contiennent des sous-ordonnanceurs pour les sous tâches ayant des périodes plus élevées multiples de la période de la tâche qui les contient. C'est aussi une preuve que les programmeurs des applications temps-réel doivent être prudents dans l'implémentation des ordonnanceurs des tâches de l'application, ou n'importe quel automate temporel. La plupart des outils de calcul du WCET comprennent ces tests comme une alternative indépendante du temps et fournissent le WCET de la tâche englobante en considérant que cette tâche est constituée de la somme de ses sous tâches. Cela implique une surestimation du WCET de la tâche englobante et, par conséquent, cause un sur-dimensionnement du matériel cible.

4.2. LES RÈGLES DE PRÉCÉDENCES

Le graphe de la figure 2.12 montre les nouvelles règles de précédences entre les tâches de PapaBench2. Certaines précédences provenant de la première version sont maintenues et d'autres sont ajoutées entre les nouvelles tâches et les anciennes tâches pour maintenir un fonctionnement correct de l'application. Nous n'avons pas ajouté beaucoup de dépendances entre les tâches filles de la tâche T13 de PapaBench1 pour rendre la génération d'ordonnancement plus flexible. Cependant l'utilisateur peut ajouter des précédences entre les tâches selon ses besoins expérimentaux car la figure 2.12 montre les précédences de base pour être le plus proche possible des caractéristiques du système Paparazzi.

Les flèches pointillées illustrent les dépendances requises pour le mode manuel, les flèches pleines pour le mode automatique et finalement les flèches épaisses montrent les précédences valables pour les deux modes de fonctionnement de l'application. Ces précédences sont

5151

Figure 2.12 - Règles de précédences des tâches de PapaBench2

Chapitre 2 - Papabench : un benchmark temps-réel 4.Genèse de Papabench2

essentiellement dues aux dépendances de données entre les tâches. Les dépendances de contrôle sont gérées plus tard par l'ordonnanceur en fonction des périodes des tâches. Un exemple de dépendances de contrôle est l'exécution de T20 avant T24 étant donné que la période de la première est inférieure à celle de la deuxième quand on ordonnance les tâches selon la politique du Rate Monotonic (RM).

Finalement, il est important de mentionner que les précédences entre les tâches de MCU1 et celles de MCU0 comme c'est le cas pour (T8, T3) et (T2, T6) ne sont valables que si on a besoin d'ordonnancer les tâches sur un seul processeur. En effet quand les tâches s'exécutent sur des processeurs différents, les composants matériels de ces deux processeurs sont indépendants ce qui fait que l'ordonnancement des tâches de l'un est indépendant de l'ordonnancement des tâches de l'autre.

Le scénario du mode manuel étant inchangé entre les deux versions du benchmark, nous nous intéressons au fonctionnement du mode automatique. Ce mode peut être déclenché par un ordre de la radio-commande ou quand le lien ascendant entre la radio-commande et l'avion est rompu quand ce dernier est hors de portée. Le mode automatique consiste à recevoir et à

5252

Figure 2.13 - PCG de MCU0 dans PapaBench2

Chapitre 2- Papabench : un benchmark temps-réel 4.Genèse de Papabench2

analyser les informations du GPS (T9, T10, T11, T12) pour gérer la navigation et la stabilisation de l'avion. Le contrôle de la navigation calcule la prochaine position de l'avion, selon le plan de vol prédéfini dans la mission initiale. Ce contrôle est géré par (T13, T14 et T15) à la même fréquence de réception des informations que le GPS. Ensuite T16, T17 et T7 assurent, respectivement, le contrôle de l'altitude, de la montée et la stabilisation de l'avion. Les commandes de vols sont transmises par T8 à MCU1 qui contrôle les servo-commandes. L'avion envoie des rapports continus à la station sol en utilisant les tâches (T18 à T27) qui s'exécutent suivant les fréquences enregistrées dans le tableau 2.1.

Pour terminer, la figure 2.13 (page précédente) montre le graphe d'appel des fonctions de MCU0 dans PapaBench2 ; le PCG de MCU1 étant inchangé n'est pas présenté. Les ellipses colorées représentent les tâches qui contiennent l'identificateur ainsi que la fonction C correspondant au corps de chaque tâche. Les ellipses pointillées représentent les interruptions et les ellipses blanches référencent le code qui n'appartient à aucune tâche et qui est appelé à l'initialisation. La tâche T13 correspond à nav_home quand le système est en mode failsafe et à nav_update en mode automatique.

Le terme de PapaBench est utilisé par la suite quand la distinction entre les deux versions ne sera pas nécessaire.

5. LE BENCHMARK

Les sources et documentation de Paparazzi ainsi que celles des deux versions de Papabench sont diffusées gratuitement selon la licence GPL.

La distribution de Paparazzi est seulement compatible sur les environnements Linux mais il peut être configuré pour plusieurs aéronefs. Comme nous ne sommes pas intéressés par les détails matériels, PapaBench est restreint à la configuration par défaut d'un aéronef. Elle est composée d'une radio-commande MC3030, d'un aéronef Twinstar3, du plan de vol utilisé pour MAV, la première compétition de vol européenne réalisée par Papparazzi, et d'une station de contrôle classique décrite dans la section 2.

La première génération du système embarqué nous a permis de sauvegarder les fichiers d'en-tête C générés à partir des sources XML. Ces fichiers XML contiennent les différentes configurations de la radio-commande et du plan de vol qui constitue la mission, permettant ainsi l'application de Paparazzi à plusieurs modèles d'aéronefs. Nous avons inclus ces fichiers en-tête dans notre benchmark sans conserver les sources XML.

Nous avons ensuite analysé les sources statiques et ces en-têtes générées pour créer PapaBench. Nous avons exclu les sources, relatives à la station de contrôle, qui sont chargées du contrôle du vol, de la visualisation des statistiques du vol et de la programmation de la mission. En effet, elles sont formées d'un ensemble de programmes OCAML et Perl non impliqués dans le système embarqué temps-réel.

5353

Chapitre 2 - Papabench : un benchmark temps-réel 5.Le benchmark

5.1. DÉTAILS DE LA COMPILATION

Nous avions pour objectif de permettre aux utilisateurs de compiler le benchmark sans avoir besoin de l'environnement de compilation de Paparazzi. PapaBench est compilable pour plusieurs architectures. Nous avons expérimenté pour le moment la compilation pour PowerPC, ARM, x86 et TriCore en utilisant le compilateur GCC mais il peut être facilement adapté pour d'autres configurations.

Pour compiler le benchmark, l'utilisateur doit extraire l'archive et éditer les fichiers de configurations du répertoire conf/ pour changer le nom du répertoire source et la commande de compilation de l'architecture utilisée pour la compilation. Un make dans le répertoire source suffit pour assurer la compilation du benchmark.

PapaBench contient des fichiers en-tête de la libc pour AVR définissant des macros qui permettent d'accéder aux registres du matériel de l'AVR. Vu que le benchmark ne vise pas la simulation matérielle, les appels à ces macros seront considérés comme de simples accès à la mémoire. Cependant, les adresses de ces registres se trouvent dans l'intervalle 0x20 à 0x100. Ceci peut poser des problèmes pour certaines plate-formes qui utilisent ces adresses pour placer les vecteurs d'interruptions. Heureusement, on peut simplement résoudre ce problème en attribuant une valeur convenable à la variable SFR_OFFSET qui fournit l'adresse de base des registres matériels.

PapaBench2 fournit également une implémentation des fonctions de la bibliothèque mathématique utilisées par les tâches de l'application. La ré-écriture de ces fonctions nous était nécessaire car nous avons eu des problèmes de compilation et d'analyse dûs l'utilisation de ces fonctions de la bibliothèque standard libc. Nous avons donc compilé le benchmark sans ajouter le lien à la librairie mathématique pour le compilateur en remplaçant ces fonctions par des versions plus adaptées au temps-réel. Nous avons aussi transformé les switch utilisés abondamment dans Paparazzi en des imbrications de conditions. En effet ces switchs engendraient des problèmes lors de l'analyse statique effectuée sur l'exécutable.

6. COMPARAISON AVEC LES BENCHMARKS TEMPS-RÉEL

L'utilisation d'un Benchmark est cruciale pour le processus de développement d'un système temps-réel parce que les applications réelles ne sont pas facilement accessibles vu les critères de confidentialité dont s'entourent les industriels. Les Benchmarks temps-réel sont rares et sont déconnectés des particularités des systèmes temps-réel. Dans cette section nous décrivons d'une manière générale ces benchmarks pour les comparer à PapaBench.

6.1. LES BENCHMARKS TEMPS-RÉEL

Les benchmarks temps-réel sont très rares et sont constitués généralement d'un ensemble

5454

Chapitre 2- Papabench : un benchmark temps-réel 6.Comparaison avec les benchmarks temps-réel

d'algorithmes de base utilisés dans les systèmes embarqués.

MiBench [19]], par exemple contient 35 fonctions embarquées réparties sur dix ensembles, caractérisant les différentes catégories de systèmes embarqués. Ces catégories sont: 1) contrôle automobile et industriel, 2) multimédia, 3) bureautique, 4) réseau, 5) sécurité et 6) télécommunications. Des modifications ont été réalisées pour assurer la portabilité de cet ensemble de benchmarks ainsi que l'extensibilité de l'ensemble des données. Selon les besoins expérimentaux, MiBench fournit un ensemble de données large ou réduit. L'ensemble réduit représente un cas particulier de l'application, tandis que l'ensemble large présente le cas d'une application réelle. MiBench est similaire au benchmark EEMBC [27], à la seule différence que MiBench est composé de codes source accessibles gratuitement. Nous avons analysé la partie contrôle automobile et industriel pour la comparaison avec les deux versions de PapaBench car les autres catégories n'ont pas les caractéristiques des systèmes temps-réel stricts.

SNU Real-Time [20] est un ensemble de sources C représentant des calculs numériques et des algorithmes DSP (Digital Signal Processor) tel que la recherche binaire, la transformation de Fourrier, la fonction des séries Fibonacci, l'insertion avec tri, le calcul de la racine carré, multiplication de matrices, etc. Ces benchmarks sont caractérisés par les contraintes suivantes de structures :

✗ Pas de branchements inconditionnels (Goto, ...).✗ Pas d'instructions exit() dans le corps des boucles.✗ Pas de switch, ni de do ... While.✗ Les opérandes d'une condition ne peuvent pas être combinées par des opérations or

et/ou and.

Ces restrictions sont imposées par les capacités limitées du compilateur utilisé par les concepteurs dans le cadre de leurs travaux expérimentaux.

Le groupe de recherche de l'université de Mälardalan [21] a collectionné une liste de benchmarks temps-réel à partir des ensembles de benchmarks fournis par d'autres groupes de recherche ou de vendeurs d'outils. Chaque benchmark est implanté par une fonction C qui définit ses fonctionnalités. Cette liste inclut les benchmarks SNU-RT auxquels sont ajoutés de nouveaux programmes qui ne présentent pas les restrictions structurelles de SNU-RT.

De manière générale, ces benchmarks sont déconnectés des particularités des applications embarquées telles que les contraintes temporelles. Les fonctions qu'ils fournissent sont exécutées seules et non dans le contexte d'une application complète. Au contraire, les tâches de PapaBench s'exécutent dans une application réaliste et ont des contraintes temporelles strictes. De plus, PapaBench permet d'analyser les effets d'enchaînement des tâches tel que l'effet sur la mémoire cache. Il est très utile d'utiliser cette application vu ses ressemblances avec les applications industrielles temps-réel.

5555

Chapitre 2 - Papabench : un benchmark temps-réel 6.Comparaison avec les benchmarks temps-réel

6.2. CARACTÉRISTIQUES DU CODE

Nous avons analysé les caractéristiques du code de PapaBench dans le cadre du framework OTAWA ainsi que les codes des benchmarks de SNU-RT, de Mälardalan et de MiBench-Automotive. Le graphe de la figure 2.14 (page suivante) fournit pour chacune des tâches de ces benchmarks le taux d'instruction d'accès à la mémoire (partie noire), le taux d'instruction de branchement (partie grise) et le taux des autres instructions. D'autre part quelques statistiques sur les blocs de base des tâches sont fournies dans le tableau 2.2 telles que, en nombre d'instructions, la moyenne des branchement (MBBB), la moyenne d'accès à la mémoire (MMBB), la taille moyenne TMOYBB et la taille maximale TMAXBB d'un bloc de base.

PapaBench1 et PapaBench2 possèdent généralement de petits blocs de base sauf pour les tâches T1, T10 dans PapaBench1 et T1, T9 dans PapaBench2 où la taille maximum des blocs de base est de 137 et 110 respectivement : il semble que la gestion des ordres de la radio commande et la gestion des données du GPS nécessitent beaucoup de calculs. SNU-RT et Mälardalan ont aussi de petits blocs de base sauf pour la fonction jdfcint (dans les deux ensembles) et admpc, edn, statemate de Mälardalan. Par contre, les programmes de MiBench-Automotive possèdent de gros blocs de base. Il semble que MiBench est plus orienté vers le calcul contrairement aux autres benchmarks.

Nous pouvons déduire de la figure 2.14 et du tableau 2.2 que tous les benchmarks sont dotés d'un taux élevé d'accès à la mémoire ce qui souligne l'importance de l'analyse de la hiérarchie mémoire pour le calcul du WCET. Bien que pour PapaBench ce taux soit dû à l'accès aux périphériques, les autres benchmarks ont des accès mémoire plus fréquents. Les accès aux périphériques ne sont pas cachés donc les accès mémoires de ces benchmarks sont traités différemment mais, dans le cas de PapaBench, ils sont traités d'une manière similaire aux applications industrielles ce qui rend notre benchmark très utile pour les expérimentations.

On peut conclure que PapaBench a quelques ressemblances avec les benchmarks existants vu les taux proches de branchements et d'accès à la mémoire. Ceci confirme que ces

5656

MBBB MMBB TMOYBB TMAXBB

PapaBench1 0,77 2,45 6,86 137

PapaBench2 0,74 2,77 7,41 137

MiBench-Automotive

0,86 1,55 5,48 150

Mälardalen 0,83 4,37 9,54 319

SNU RT 0,81 4,6 9,86 216

Tableau 2.2 - Statistiques sur les Benchmarks temps-réel


5757

Figure 2.14 - Répartition des Instructions

0% 20% 40% 60% 80% 100%

bscrcfft1fft1k

fibcallfir

insertsortjfdctint

lmsludcmpmatmulminver

qurtselectadmpc

bsbsort100

cntcompress

covercrc

duffedn

expintfacfdctfft1

fibcallfir

insertsortjanne_complex

jfdctintlcdnum

lmsloop3

ludcmpmatmultminmaxminver

nsnsichneu

qsort-examqurt

selectsqrt

statemateI1I2I3I4I5I6I7T1T2T3T4T5T6T7T8T9T10T11T12T13T14T15T16T17T18T19T20T21T22T23T24T25T26T27

basicmath_smallbasicmath_large

bitcountqsort_smallqsort_large

susanI1I2I3I4I5I6T1T2T3T4T5T6T7T8T9T10T11T12T13

Snu-RT

Mälardalen

PapaBenchV2

automotive

PapaBenchV1

IM(Instruction Mémoire) IB(Instruction Branchement) Autres

Chapitre 2 - Papabench : un benchmark temps-réel 6.Comparaison avec les benchmarks temps-réel

benchmarks sont tout de même relativement proches des applications réelles. Dans la section suivante, nous montreront que des différences existent et que les statistiques fournies dans cette section ne sont pas suffisantes pour caractériser une application temps-réel.

6.3. COMPLEXITÉ DES BOUCLES

Les représentations des programmes en CFG et en arbres syntaxiques ne sont pas suffisantes pour calculer le WCET par méthodes statiques vu qu'elles n'identifient pas des chemins d'exécution bornés. En effet, ces représentations doivent être complétées par quelques informations pour limiter le nombre des chemins d'exécution à analyser. Dans ce paragraphe nous discutons de la complexité des boucles de PapaBench et nous la comparons à celles des autres benchmarks.

Le graphe (a) de la figure 2.15 affiche pour chaque benchmark la répartition des boucles sur cinq niveaux d'imbrication. La colonne noire montre le nombre de boucles de niveau 1. La couleur des colonnes devient plus claire quand on passe à un niveau plus profond.

D'autre part, le graphe (b) expose pour chaque benchmark la répartition des boucles suivant le degré de variation de leur nombre maximal d'itérations. On distingue trois niveaux: 1) pour les boucles à bornes fixes, 2) pour les boucles dont la borne est peu variable et 3) pour les boucles de grande variabilité. Cette variabilité est due aux imbrications des boucles où la borne de la boucle interne dépend d'une ou plusieurs variables d'induction des boucles du niveau d'imbrication supérieur.

PapaBench contient en majorité des boucles for ayant un nombre d'itérations fixe et quelques boucles while. Notre analyse des boucles while garantit leur exécution au plus une fois pour PapaBench. Ainsi, nous notons une très faible variabilité des bornes de boucles.

5858

a) Profondeur des boucles b) Variabilité du nombre d'itérations

Figure 2.15 - Analyse de la complexité des boucles

0

20

40

60

80

100

120

PapaBench1 PapaBench2 MiBench Mälardalen SnuRT

level 1 level 2 level 3 level 4 level 5

0

10

20

30

40

50

60

70

80

PapaBench1 PapaBench2 MiBench Malardalen SnuRT

Fixe Low High


D'autre part, ces boucles sont simples comme le montre le graphe de la figure 2.15.a. Ce n'est pas le cas pour les autres benchmarks qui contiennent des imbrications profondes de boucles avec une variabilité non négligeable de leur nombre maximal d'itérations. Cette variabilité rend le calcul du WCET plus compliqué et augmente le degré de pessimisme des approximations des bornes de boucles fournies par l'utilisateur. Si les bornes de boucles ne sont pas précises, l'estimation du WCET sera supérieure à la réalité vu les profonds niveaux d'imbrications et la variabilité de ces bornes.

Or, notre expérience dans le domaine des logiciels de l'avionique montre que nous avons souvent des boucles simples avec un nombre fixe d'itérations d'où l'intérêt de l'utilisation de PapaBench qui contient des boucles simples de bornes fixes. Ceci permet de calculer un WCET plus précis et plus proche du WCET réel et, également, plus réaliste. Contrairement à l'évaluation précédente, la comparaison réalisée dans cette section montre que les autres benchmarks présentent des structures de programmes complexes et non réalistes.

7. PAPABENCH1 VS PAPABENCH2Nous avons expliqué dans la section précédente les limitations de PapaBench1 et la

nécessité de PapaBench2. Nous avons aussi comparé ces deux versions aux benchmarks temps-réel utilisés actuellement. Cette section est consacrée à la comparaison des deux versions du benchmark pour prouver l'utilité de PapaBench2 notamment pour la génération et l'analyse des ordonnancements. Le but est de montrer que les ordonnancements de PapaBench2 sont plus flexibles que ceux de PapaBench1.

7.1. OUTILS UTILISÉS

Nous avons utilisé OTAWA [25], [26], un environnement « open source » dédié à l'analyse statique d'un code exécutable développé dans l'équipe, pour calculer les WCET des tâches de PapaBench1 et PapaBench2. Dans cet environnement, le calcul du WCET consiste à réaliser une chaîne d'analyses qui utilisent et produisent des annotations accrochées au code jusqu'à l'obtention du WCET. Nous avons choisi la technique d'énumération implicite des chemins IPET (Implicit Path Enumeration Technique) [28] et l'approche CAT pour estimer les effets du cache d'instructions sur l'évaluation du WCET. CAT est l'adaptation de la méthode par catégorisation de Muller et al [29] à la technique IPET2. La chaîne d'analyses effectuée sur le code génère un ensemble de n équations à n inconnues. La solution de ce système est obtenue par le solveur ILP (Integer Linear Programming ) lp_solve, et fournit la valeur du WCET de chaque tâche.

La méthode IPET utilise un simulateur de processeur pour effectuer les calculs nécessaires. Nous avons choisi un modèle de processeur générique doté d'un pipeline de 4 étages avec une politique d'exécution ordonnée des instructions. Chaque étage du pipeline traite deux

2 Pour plus de détails concernant ces deux techniques, voir le chapitre 3.

5959

Chapitre 2 - Papabench : un benchmark temps-réel 7.Papabench1 vs Papabench2

instructions par cycle et possède deux ALU (Arithmetic Logical Unit) et deux unités de calcul des flottants3. Nous avons choisi un cache d'instruction à accès direct de taille 16Ko et dont la taille de bloc est de 8 octets. Le binaire utilisé est généré par un compilateur PowerPC. Les WCET ainsi calculés sont utilisés pour générer des ordonnancements dans l'outil des générations d'ordonnancement temps-réel CHEDDAR [18]. Chaque tâche est caractérisée par une période, un WCET et une date d'échéance supposée être à la fin de la période. Pour chaque version du benchmark, nous avons généré quatre ordonnancements différents, suivant les politiques, RM, DM, EDF et LLF. Comme, nous supposons que la date d'échéance est égale à la période, DM est identique à RM, nous utilisons uniquement RM pour la comparaison des deux versions.

7.2. RÉSULTATS

Les applications PapaBench1 et PapaBench2 sont modélisées en AADL comme un système à double processeur : MCU1qui gère la radio et les servo-commandes, et MCU0 qui s'occupe de la navigation et de la stabilisation de l'avion. Nous avons noté précédemment que le modèle AADL peut être manipulé pour satisfaire nos besoins expérimentaux. Ainsi nous avons choisi pour chaque version un deuxième modèle AADL qui décrit une architecture mono-processeur.

Le système embarqué possède deux modes de fonctionnement. Le mode automatique implique 30 tâches sur 34 dans PapaBench2 et 15 tâches sur 19 pour PapaBench1, ainsi ce mode présente le fonctionnement le plus critique du système. Nous avons choisi de comparer les deux versions pour le mode automatique uniquement. Par ailleurs, le fonctionnement de MCU1 est identique pour les deux versions, ainsi nous comparons uniquement le fonctionnement de MCU0 pour une architecture double-processeurs.

Nous avons choisi de comparer les ordonnancements générés pour les deux versions à la fréquence minimale des processeurs. En effet, quand un processeur tourne à une fréquence

3 Pour plus de détails sur les pipeline, voir chapitre 3.

6060

PapaBench1 PapaBench2

MCU1 MCU0 Un Processeur MCU1 MCU0Un

Processeur

Fréquence Min (Khz) 120 265 380 120 155 275

Cycle global (s) 0,05 0,5 0,5 0,05 10 10

Nombre de sous cycles 1 10 10 1 200 200

Tableau 2.3 - Caractéristiques générales des deux versions

Chapitre 2- Papabench : un benchmark temps-réel 7.Papabench1 vs Papabench2

supérieure, les tâches sont ordonnancées plus tôt par rapport à leur date d'échéance, car les WCET des tâches sont inférieurs à ceux calculés à la fréquence minimale. Ainsi, le processeur qui tourne à sa fréquence minimale doit gérer des scénarios plus complexes car les WCET atteignent leur valeur maximale et les tâches doivent être ordonnancées en respectant les contraintes temps-réel.

Nous commençons par une comparaison d'ordre général des deux versions. Le tableau 2.3 fournit, pour chaque modèle d'architecture et par processeur, la fréquence minimale, la durée du cycle globale en secondes, et le nombres de sous-cycles. La durée du cycle est égale au plus petit commun multiple des périodes des tâches à ordonnancer, et la durée d'un sous-cycle est égale à la plus petite période et, pour terminer, le nombre de sous-cycles et la division du cycle global par la durée d'un sous-cycle. La fréquence minimale fournie dans ce tableau est la plus petite fréquence du processeur pour laquelle les tâches sont ordonnançables suivant, RM, LLF et EDF. Cette fréquence minimale est valable pour la configuration du cache utilisée. En effet, elle peut varier en fonction de la taille du bloc de cache. Comme MCU1 est identique pour les deux versions, quel que soit le modèle d'architecture, les mesures sont identiques pour PapaBench1 et PapaBench2.

Au contraire, la répartition des tâches de MCU0 qui a fractionné les grandes tâches en un ensemble de petites tâches ayant une période supérieure ou égale à la période de la tâche parente, induit une augmentation de la durée du cycle globale dans PapaBench2 pour les deux modèles d'architecture. De même, le nombre de sous cycles passe de 10 pour Papabench1 à 200 pour Papabench2. Ceci est une première preuve de la flexibilité des ordonnancements de PapaBench2, car les grandes tâches seront remplacées par l'exécution d'au plus deux de ces tâches filles à cause des nouvelles dépendances et des périodes des tâches. Cela favorise le changement de l'ordre d'exécution des tâches en fonction de la politique d'ordonnancement utilisée : pour RM les priorités sont fonction des périodes, pour EDF et LLF, l'échéance relative et les laxités sont fonction des échéances et des périodes des tâches.

D'autre part, la répartition contribue à la distribution de la charge du processeur sur l'ensemble des sous-cycles de l'ordonnancement. Ceci diminue la valeur de la fréquence minimale des processeurs pour les deux modèles d'architecture de PapaBench2. Ainsi, la fréquence minimale pour une architecture mono-processeur est de 275Khz pour 380Khz dans PapaBench1, et pour une architecture à double processeur la fréquence de MCU0 est de 155Khz pour 265Khz dans PapaBench1.

Nous avons aussi comparé le temps d'inactivité global entre les ordonnancements des deux versions générés à la fréquence minimale. Le temps d'inactivité est le temps que passe le processeur lorsqu'il ne reste plus de tâche à exécuter durant un sous-cycle. Nous avons remarqué que pour RM, LLF et EDF le temps d'inactivité est identique pour PapaBench1 et pour PapaBench2. Cependant, cette valeur est différente entre les deux versions.

La figure 2.16, fournit le pourcentage minimum, moyen et maximum d'inactivité par sous-cycle de l'ordonnancement. Ces valeurs sont fournies pour les deux modèles d'architecture de Papabench1 et Papabench2. Le pourcentage minimum est de 0% car, quand le processeur

6161


tourne à une fréquence minimale, certains sous-cycles sont pleins. Notons que la valeur moyenne et maximale d'inactivité sont inférieures pour PapaBench2. Ceci est induit par une meilleure répartition de la charge du processeur due aux fractionnements des tâches.

La figure 2.17 montre le pourcentage de ressemblance et de différence entre les trois ordonnancements de chaque version, pour les deux modèles d'architecture. Ces taux sont calculés en nombre de sous-cycles. Le calcul est effectué en observant le changement, pour les trois ordonnancements, de liste de tâches qui s'exécutent dans chaque sous-cycles de l'ordonnancement. Nous en avons déduit que EDF / RM / LLF de PapaBench1 sont identiques à 60% pour une architecture double-processeur et que cette ressemblance atteint les 80% pour une architecture mono-processeur. De plus, en comparant les ordonnancements entre eux nous avons remarqué que RM et LLF sont identiques car le taux de différence est de 0% pour les deux modèles d'architecture. D'autre part les couples RM / EDF et EDF / LLF présentent un taux de différence de 20% en double-processeurs et de 40% en mono-processeur.

6262

Figure 2.17 - Comparaison des ordonnancements

Figure 2.16 - Statistiques du temps d'inactivité

Chapitre 2- Papabench : un benchmark temps-réel 7.Papabench1 vs Papabench2

Dans le cas de PapaBench2, le taux de ressemblance entre les trois ordonnancements est très faible. Il est de 7,5% en double-processeur et atteint les 0,5% en mono-processeur. En outre, les trois ordonnancements présentent un taux de différence très élevé : RM et LLF sont différents à 59,5% pour les deux modèles d'architecture ; EDF et RM le sont à 92,5% en double-processeur et 99,5% en mono-processeur ; finalement, la différence entre EDF et LLF est de 80% à 85%. Quoique cette différence pour PapaBench1 soit due à l'exécution ou non-exécution d'une seule tâche entre les sous-cycles des trois ordonnancements, dans le cas de PapaBench2, cette différence est induite par la grande variabilité de la liste des tâches exécutées entre les sous-cycles des trois ordonnancements.

Toutes ces mesures prouvent que les ordonnancements de PapaBench2 sont plus flexibles que ceux de PapaBench1 et que la charge du processeur, avec cette nouvelle version, est distribuée d'une manière plus homogène sur l'ensemble des sous-cycles des ordonnancements.

Cette flexibilité nous permet de réaliser un analyse sur les différents ordonnancements. Un exemple est l'analyse de l'impact du cache sur l'estimation du WCET en fonction de la variation de l'ordonnancement. Avec PapaBench1, RM, EDF et LLF sont très similaires, ce qui rend cette analyse impossible. En effet, nos expérimentations montrent que la variation de l'ordonnancement a le même impact sur l'estimation du WCET.

Un deuxième exemple d'analyse d'ordonnancement est l'utilisation des résultats des traces des tâches dans le cache pour choisir le meilleur ordonnancement de l'application. L'idée est de calculer les WCET initiaux des tâches pour générer un premier ordonnancement en utilisant une politique d'ordonnancement donnée. Ensuite, nous utilisons cet ordonnancement pour définir les états du cache inter-tâche en fonction des traces laissées par l'exécution des tâches. Une dernière étape est de calculer une nouvelle estimation des WCET des tâches en tenant compte de l'analyse inter-tâche du cache et d'observer la sensibilité de la politique d'ordonnancement utilisée par rapport à ces nouvelles valeurs des WCET.

Les tests réalisées sur PapaBench1 ont fourni le même ordre d'exécution des tâches en dépit de l'effet de l'analyse inter-tâche sur le calcul du WCET. Ceci est dû à la présence des grosses tâches qui ont un WCET énorme par rapport au temps du sous-cycle. Ainsi, même si la nouvelle estimation de son WCET est inférieure à la précédente, cette réduction n'est pas suffisante pour changer l'ordre d'exécution des tâches. Ceci n'est plus un problème avec la nouvelle version PapaBench2.

7.3. CONSEILS DE CONCEPTION DES APPLICATIONS TEMPS-RÉEL

La comparaison de ces deux benchmarks nous permet de donner quelques conseils pour la conception des application temps-réel. Il est important de substituer les grosses tâches par des tâches plus petites permettant de distribuer la charge du processeur sur les sous-cycles de l'ordonnancement. Cette distribution permet d'utiliser un processeur moins puissant ce qui réduit le coût de développement de l'application. De plus, l'utilisation de tâches de taille réduite augmente la flexibilité des ordonnancements ce qui permet au concepteur de choisir le

6363


meilleur ordonnancement des tâches de l'application en fonction de son cahier de charge, comme par exemple des contraintes de coût, de dépense d'énergie, d'optimisation du WCET, etc.

Finalement, nous conseillons aussi d'éviter d'implémenter l'ordonnanceur comme un ordonnanceur hiérarchique où certaines tâches contiennent un sous-ordonnanceur de sous tâches ayant des périodes plus élevées multiples de la période de la tâche qui les contienne, et où la tâche englobante active les sous tâches moyennant des tests. Car La plupart des outils de calcul du WCET comprennent ces tests comme une alternative indépendante du temps et fournissent le WCET de la tâche englobante en considérant que cette tâche est constituée de la somme de ses sous-tâches. Cela implique une surestimation du WCET de la tâche englobante et par conséquent provoque un sur-dimensionnement du matériel cible.

8. CONCLUSION

L'utilisation d'un benchmark est cruciale pour le processus de développement d'un système de calcul de WCET. Cependant, il est souvent impossible de se procurer une application réelle pour tester le système avant de le mettre en utilisation vu les critères de confidentialité dont s'entourent les industriels. Dans ce chapitre, nous avons introduit PapaBench, un benchmark dérivé d'une application temps-réel embarquée, qui est d'une grande utilité pour le calcul du WCET et pour les analyses d'ordonnancement.

Sa caractéristique principale, par rapport aux benchmarks temps-réel existants, dérive du fait qu'il fournit une application temps-réel embarquée réelle et complète. Il permet ainsi d'effectuer des analyses sur l'application entière pour dépasser les études réalisées pour chaque tâche séparément : en effet, on peut analyser les effets d'une tâche sur l'exécution des autres tâches.

Nous avons fourni un modèle AADL constituant une description globale de l'application. Nous avons également comparé ce benchmark avec les benchmarks temps-réel classiques pour évaluer ses similarités et ses avantages qui le rendent utile et unique dans le domaine du calcul du WCET mais aussi pour l'analyse d'ordonnancement.

Ce benchmark étant le seul à fournir les caractéristiques d'une application complète, il a été utilisé dans nos expérimentations pour démontrer l'intérêt de notre approche. Les tests ne tiendront pas compte des autres benchmarks vu que ces derniers ne permettent pas la génération d'ordonnancements qui représentent un scénario réel d'exécution, car ils sont formés de fonctions indépendantes et ne fournissent pas des caractéristiques temps-réel (période, échéance) pour ces fonctions.

Avant d'expliquer en détails notre approche d'optimisation du WCET d'une tâche, nous exposons au chapitre suivant les différentes techniques de calcul du WCET, intra-tâche ou multi-tâches.

6464

CHAPITRE 3

CALCUL STANDARD DU TEMPS D'EXÉCUTION PIRE CAS

La connaissance du WCET des tâches peut servir à choisir une politique d'ordonnancement, mais elle peut aussi aider à dimensionner le matériel, que ce soit pour déterminer si un système donné est suffisamment puissant pour que les contraintes temps-réel d'une application puissent être garanties, ou bien pour estimer le nombre de tâches qu'un système donné peut supporter en assurant le respect de leurs échéances.

De plus, des informations sur le temps d'exécution des différentes parties d'un programme (boucles ou chemins critiques) peuvent être exploitées dans une démarche d'optimisation du code.

Nous désignons la valeur du WCET d'une tâche, fournie au système, par « WCET estimé » ou plus simplement « WCET » de cette tâche, et nous employons le terme « WCET réel » pour référencer le temps d'exécution réellement nécessaire au processeur pour exécuter une tâche sans interruption. La condition nécessaire et suffisante pour qu'il n'y ait pas un risque de violation des contraintes temps-réel, est d'obtenir un WCET supérieur ou égal au WCET réel. Toutefois, pour être utile, il ne doit pas être trop surestimé pour qu'il ne conduise pas à un sur-dimensionnement inutile du système. Ce chapitre introduit les différentes techniques de calcul du WCET statiques ou dynamiques, intra-tâche ou inter-tâches.

1. ESTIMATION DU WCETBien que la connaissance sûre du WCET soit très importante, la recherche d'une méthode

d'estimation sûre de ce WCET n'a débutée que depuis une vingtaine d'années [30],[31]. Mon travail de thèse se situe dans le cadre de l'optimisation du WCET local et global d'une application donnée en étudiant l'ordonnancement statique de ses tâches.

Les méthodes habituelles de calcul du WCET se divisent en deux grandes catégories, les méthodes dynamiques et les méthodes statiques.

Les méthodes dynamiques consistent à mesurer le temps d'exécution d'un programme dans un environnement de test qui peut être un système réel ou un simulateur. Ces mesures doivent

6565

Chapitre 3 - Calcul standard du temps d'exécution pire cas 1.Estimation du WCET

être réalisées pour tous les jeux d'entrée possibles ou alors il faut être capable de définir un jeu d'entrée qui conduit certainement au temps d'exécution le plus long.

Les méthodes statiques analysent le code du programme dans le but de s'affranchir des jeux d'entrée. Elles comportent en général deux phases : l'analyse de flot détermine tous les chemins possibles, et l'analyse temporelle évalue le temps d'exécution de chacun de ces chemins.

En théorie, le test dynamique est approprié pour l'analyse du WCET du code. Le temps d'exécution du programme est mesuré pour une exécution avec un jeu d'entrée particulier. Un outil de test idéal exécuterait le programme pour chaque ensemble possible de valeurs en entrée et mesurerait le temps d'exécution. Mais ceci n'est pas toujours possible en pratique car la complexité des programmes à analyser conduit à un nombre extrêmement grand de tests possibles. Si pour un programme donné, on a pu définir le jeu d'entrée pire cas, alors ces méthodes permettent d'obtenir une valeur précise du WCET. Cependant, comme les tâches sont appelées dans une boucle de contrôle, il faudrait également prendre en compte tous les états possibles du processeur avant le démarrage de la tâche.

Au contraire, les méthodes statiques conduisent à poser des hypothèses conservatrices pour des informations qui ne peuvent pas être connues précisément lors de l'analyse et calculent alors une borne supérieure du WCET.

2. MÉTHODES DYNAMIQUES

2.1. CARACTÉRISTIQUES

La méthode directe consiste à exécuter un programme sur le système matériel cible et de mesurer la durée de son exécution. Cette mesure peut être réalisée par des équipements externes (analyseur logique) ou en exploitant des compteurs internes disponibles dans certains processeurs (comme le Pentium). Parfois on ne dispose pas de système matériel et / ou des moyens de mesure adéquats. C'est le cas, par exemple, pendant la phase de conception si le matériel prévu n'est pas encore disponible. On peut alors disposer d'un simulateur logiciel qui modélise un système matériel pour effectuer ces mesures. Le problème majeur est de vérifier la précision et la fiabilité de ce simulateur, ce qui induit un coût de développement non négligeable.

Quel que soit l'environnement de mesure (système réel ou simulateur), nous devons fournir un code exécutable et un jeu de donnée en entrée de ce programme. Plusieurs méthodes sont envisageables pour mesurer le temps d'exécution pire cas :

➢ Mesurer le temps d'exécution de tous les jeux d'entrée possibles. Ceci n'est pas toujours possible en pratique car la complexité des programmes à analyser conduit à

6666

Chapitre 3- Calcul standard du temps d'exécution pire cas 2.Méthodes dynamiques

un nombre extrêmement grand de tests possibles. Cependant, cette solution peut être retenue pour des programmes simples, admettant peu de jeux de donnée en entrée et pour lesquels le domaine de variation des entrées est limité.

➢ Demander à l'utilisateur de fournir le jeu d'entrée pire cas vu sa parfaite connaissance du programme. Cette solution est encore limitée au cas des applications simples.

➢ Générer automatiquement un (des) jeu(x) de test qui doit (vent) conduire au temps d'exécution pire cas [32], [33].

➢ Utiliser un jeu de test symbolique si on ne peut pas définir un jeu de test explicite. Le principe de cette méthode est de poser l'hypothèse que les données en entrée sont inconnues et d'étendre le jeu d'instruction du processeur cible pour qu'il puisse réaliser des calculs à partir d'un ou plusieurs opérandes de valeur inconnue. Lorsqu'un branchement conditionnel est exécuté avec une condition de valeur inconnue, les deux branches doivent être explorées. Une telle extension ne peut être réalisée par un simulateur logique. Une solution proposée pour réaliser une simulation logique est présentée dans [34].

2.2. TECHNIQUES DE CALCUL DU WCET PAR ANALYSE DYNAMIQUES

Plusieurs méthodes effectuent le calcul du WCET par analyse dynamique du programme. [35] combine les approches de mesures et les approches analytiques dans un modèle pour calculer d'une manière probabiliste les bornes du temps d'exécution d'un chemin pire cas d'une section de code.

Le principe de cette méthode est de combiner les effets de pire cas rencontrés dans les blocs de base analysés séparément pour construire le modèle de temps d'exécution pire cas du programme. Le modèle tient compte des sources de variation du temps d'exécution qui peuvent être classées en deux catégories : les dépendances de données (un exemple est la multiplication et la division) et les dépendances d'historique (dues aux caches, pipelines et à la prédiction de branchement). On tient compte de cette complexité en attribuant aux petites unités du programme (blocs de base) un profil temporel d'exécution ETP. Pour calculer ces ETP, on peut utiliser:

➢ Les mesures d'exécution réelles sur des processeurs réels.➢ Une simulation de processeur qui va exécuter le segment de code et fournir les

informations demandées.➢ Une méthode analytique.

L'algorithme utilisé consiste à calculer les ETP pour les séquences de blocs de base selon les informations de dépendance fournies. Puis calculer les ETP de la combinaison des blocs de base qui ne sont pas des feuilles de l'arbre syntaxique (§ 3.1.1.4) après avoir appliqué un test d'indépendance qui sert à choisir l'opérateur convenable de combinaison pour obtenir à la

6767

Chapitre 3 - Calcul standard du temps d'exécution pire cas 2.Méthodes dynamiques

fin l'ETP de la racine. Cette méthode réduit les surestimations du WCET mais elle est utilisable seulement pour les systèmes temps-réel stricts probabilistes où la garantie des contraintes temporelles est exprimée sous forme probabiliste.

[36] et [37] proposent une approche hybride composée d'une analyse statique et d'une analyse dynamique, pour calculer le WCET d'un programme. La partie dynamique consiste à mesurer les temps d'exécution sur la plate-forme cible. D'autre part, l'analyse statique du code considère le code source du programme pour générer des informations qui vont permettre la génération des jeux de données et des information sur les chemins d'exécution nécessaires pour le calcul du WCET dans l'étape finale.

Cette méthode utilise des méthodes basées sur des heuristiques et la vérification de modèle pour générer des jeux de test en forçant l'exécution des chemins sélectionnés du CFG (graphe de flot de contrôle, §3.1.1.3) pour effectuer des mesures dynamiques du temps d'exécution. Les temps d'exécution fournis sont ensuite utilisés pour calculer statiquement le WCET du programme complet.

On commence par la répartition du CFG du code source en segments de programme PS (Program Segment). Un PS est un sous graphe du CFG qui peut être accessible via une transition d'une seule flèche mais plusieurs transitions de sortie sont possibles. On distingue aussi les SPS (Single Progam Segment) qui ont une seule transition de sortie. La répartition du CFG en PS est effectuée en se servant de l'arbre syntaxique du programme et en parcourant le CFG de la racine.

Ensuite, on introduit des points d'instrumentations avant et après les PS. Les chemins d'exécution possibles du CFG sont ainsi identifiés. Pour mesurer leurs temps d'exécution, des jeux de test sont nécessaires. Ils sont générés en se basant sur des heuristiques et la vérification de modèle pour chaque chemin d'exécution possible car les heuristiques sont capables de générer plus de 90% des données, le reste étant fourni par la vérification de modèle.

Le calcul du WCET du programme complet est basé sur la technique IPET qui combine les temps d'exécution des différents PS du CFG, mesurés dynamiquement.

3. MÉTHODES STATIQUES

Les méthodes par analyse statique ou techniques d'estimation analytique ont pour but de s'affranchir du test global (les jeux d'entrées) pour l'estimation du WCET. Elles opèrent par analyse de la structure du programme, au niveau de leur code source et / ou objet. Une analyse statique peut être réalisée en deux étapes:

➢ L'analyse du flot de contrôle détermine les chemins d'exécution possibles du programme. Cette analyse s'appuie sur une représentation du flot de contrôle du programme.

6868

Chapitre 3- Calcul standard du temps d'exécution pire cas 3.Méthodes statiques

➢ L'analyse temporelle évalue l'impact de l'architecture sur le pire temps d'exécution.

Les résultats de ces deux analyses sont ensuite combinés pour calculer le WCET du programme.

3.1. ANALYSE DE FLOT DE CONTRÔLE

Nous présentons dans ce paragraphe les différentes représentations du flot de contrôle les plus souvent utilisées par les analyses statiques de calcul du WCET (§ 3.3).

3.1.1. Représentations logiques Afin de construire une représentation logique du programme à analyser, le code objet est

tout d'abord scindé en unités plus petites, les blocs de base (§3.1.1.1) qui sont partagés en L-Blocs nécessaires pour modéliser le comportement des mémoires cache (§3.1.1.2). Puis, suivant le niveau du langage et les informations souhaitées, nous allons représenter les fonctions du programme par des graphes de flots de contrôle (§3.1.1.3) ou des arbres syntaxiques (§3.1.1.4) ou des arbres de portées (§3.3.4). Enfin, les représentations des fonctions du programme sont assemblées pour ne former qu'une unique représentation logique du programme (§3.1.1.6).

3.1.1.1. Blocs de baseLa plupart des méthodes d'analyse statique utilisent le découpage du code objet du

programme en Blocs de Base.

Définition 10 (Bloc de Base) – Un bloc de base est une suite d'instructions purement séquentielle qui possède un seul point d'entrée et un seul point de sortie. Un seul point d'entrée signifie que si une instruction de branchement en dehors du bloc de base pointe vers le bloc de base, ce ne peut être que vers la première instruction. Un seul point de sortie signifie que le flot de contrôle doit s'effectuer en séquence sauf pour la dernière instruction qui peut être un branchement, conditionnel ou inconditionnel.

L'exemple de la figure 3.1 présente le code C d'un programme constitué d'une fonction principale main et d'une fonction impaire. La fonction main contient une boucle, et pour chaque itération de la boucle, il y a deux appels à la fonction impaire. La fonction impaire comporte une structure conditionnelle. Les CFG des ces fonctions (voir figure 3.3) montrent que ce programme est constitué de onze blocs de base notés BB1

à BB11. Ce sont les éléments de base des représentations décrites dans les paragraphes suivants.

6969

Chapitre 3 - Calcul standard du temps d'exécution pire cas 3.Méthodes statiques

3.1.1.2. Ligne Bloc ou L-blocUn nouveau type de structure atomique est défini pour analyser le comportement du cache

d'instruction.

Définition 11 (L-bloc) – est une séquence d'instructions d'un même bloc de base qui sera chargée dans une même ligne du cache d'instructions. Ainsi les instructions d'un même L-bloc ont toujours le même nombre de succès / défauts et le même nombre d'exécutions.

Un bloc de base est formé d'un ou plusieurs L-bloc. Un L-bloc j d'un bloc de base Bi est noté Bi,j et les nombres de succès d'accès au cache, de défauts, sont notés x i , j

hit et x i , jmiss ,

respectivement. On a ainsi le nombre d'exécutions xi de Bi égal à x i , jhit x i , j

miss pour tout L-bloc j de Bi.

Un bloc de base est formé d'un ou plusieurs L-bloc(s) chacun appartenant à un bloc mémoire différent. Un bloc mémoire peut être réparti en plusieurs L-blocs appartenant à des blocs de base différents. Dans ce cas, ces L-blocs seront chargés dans la même ligne du cache d'instruction mais ne rentrent pas en conflit. C'est le cas de B1.3 et B2.1 de la figure 3.2. Pour terminer, notons que la taille d'un bloc mémoire est égale à la taille d'une ligne du cache instruction.

Deux L-blocs rentrent en conflit si ils sont chargés dans la même ligne du cache d'instructions et n'appartiennent pas au même bloc mémoire. Le chargement de l'un d'eux peut supprimer les autres du cache selon le degré d'associativité du cache (§ 3.2.2.1).

La figure 3.2 montre l'exemple d'un CFG constitué de 3 blocs de base et leur répartition en L-blocs. Les L-blocs de même couleur sont chargés dans la même ligne du cache et sont donc conflictuels à l'exception de B1.3 et B2.1 pour les raisons évoquées précédemment.

7070

int impaire (int x) { void main() {

int result int tab[4] = {34, 45, 12, 5}

if (x % 2) { int nb_impaires = 0;

result= 1; int nb_paires = 4;

} else { int i;

result = 0; for (i=0;i<4;i++) {

} nb_impaires += impaire(tab[i]);

return (result) nb_paires - = impaire(tab[i]);}

} }Figure 3.1 - Code Source d'un programme C


3.1.1.3. Graphe de flot de contrôle Un graphe de flot de contrôle décrit tous les enchaînements de blocs de base possibles pour

chaque fonction du programme. Il y a un graphe de flot de contrôle par fonction. Il est obtenu soit par analyse statique du code bas niveau en utilisant un compilateur modifié [38], soit par un outil dédié à la manipulation de code bas niveau comme par exemple SALTO [39] ou OTAWA [25], [26].

On distingue deux types de graphes équivalents et couramment utilisés. La première catégorie (cf. figure 3.3) est celle des graphes dont les noeuds sont des blocs de base et où les arcs représentent les relations de précédences entre ces blocs. On peut alors distinguer deux types d'arc : les arcs pas de saut qui représentent l'exécution de deux blocs qui se suivent sans saut (absence de branchement, ou branchement non pris) et les arcs saut qui représentent les branchements pris (e.g. arc de BB10 à BB6). Cette première catégorie de graphe de flot de contrôle est utilisée dans de nombreux travaux d'analyse statique basés sur les graphes [28], [40], [41].

La deuxième catégorie de graphe (cf. figure 3.4), baptisée T-graph par P. Puschner [42], est

7171

Figure 3.3 - Graphes de flot de contrôle

Figure 3.2 - Construction des L-blocs


une représentation duale de la première. Les arcs y représentent les blocs de base et sont valués par le WCET de ces blocs, et les noeuds du graphe représentent les points dans le code où le flot de contrôle du programme converge et / ou diverge. Cette représentation est utilisée dans les travaux [42] et [43].

Le graphe de flot de contrôle est le plus souvent construit par analyse statique de code de bas niveau : du code assembleur le plus souvent, mais aussi du byte-code [44], [45]. P. Puschner envisage aussi dans [46] l'obtention de T-graphs à partir du code de haut niveau du programme.

3.1.1.4. Arbre Syntaxique Un arbre syntaxique (cf. figure 3.5) est un arbre dont les noeuds représentent les structures

du langage de haut niveau et dont les feuilles sont des séquences d'instructions. Une représentation simple du programme par un arbre syntaxique peut être basée sur trois types de noeuds et deux types de feuilles.

➢ Les noeuds de type SEQ possèdent au moins un fils. Ils représentent la mise en séquence de leurs sous-arbres fils.

➢ Les noeuds de type LOOP ont deux fils : le sous-arbre test et le corps de la boucle.➢ Les noeuds de type IF sont constitués d'un sous-arbre test et de deux sous-arbres then

et else. ➢ Les feuilles de type CALL représentent des appels de fonctions. ➢ Enfin, les autres feuilles de l'arbre syntaxique sont les blocs de base du programme.

On peut imaginer d'autres types de noeuds pour représenter par exemple différents types de boucles.

7272

Figure 3.4 - T-Graphs du programme analysé


L'arbre syntaxique est obtenu par analyse statique d'un langage de haut niveau. Ses feuilles coïncident avec les noeuds du graphe de flot de contrôle décrit au paragraphe précédent. Les structures du langage (séquence, conditionnelle, boucles) représentées dans l'arbre syntaxique induisent des relations de précédence entre leurs fils. Par exemple, si on suppose que A1 à An

sont les sous-arbres d'un noeud séquence. Alors, dans un chemin d'exécution, la feuille la plus à droite du sous-arbre Am sera suivie de la feuille la plus à gauche de Am+1.

L'arbre syntaxique apporte plus d'informations par rapport au graphe de flot de contrôle (les structures du langage) tout en comportant les mêmes informations concernant le flot de contrôle entre les blocs de base (de façon moins directe toutefois). En pratique, les deux représentations sont utilisées conjointement, ce qui impose quelques restrictions sur le langage source (pas de GOTO et assimilés) afin d'avoir une correspondance directe entre les deux représentations.

3.1.2. Dépliage des appels de fonctionsChaque fonction est représentée séparément et en un seul exemplaire dans les

représentations précédentes. Si on prend en compte l'effet de certains éléments de l'architecture matérielle comme par exemple les caches, le WCET d'un bloc de base va dépendre de l'état interne du cache au moment de son exécution.

Si une fonction est appelée plusieurs fois et à des endroits différents, les blocs de base qui la composent seront exécutés dans de différents contextes. Cela fait que leur WCET peut varier en fonction du site d'appel. Cette observation a mené F. Mueller à déplier les appels de fonctions [29] afin d'obtenir : (i) une seule représentation (arbre ou graphe) contenant tout le code à analyser, et (ii) autant d'instances de fonctions que de « sites » d'appels différents.

7373

Figure 3.5 - Arbre syntaxique du programme analysé


Pour transformer les appels de fonctions en instances de fonctions, les fonctions sont dupliquées et incluses dans l'arbre principal à la place des feuilles de type CALL (cf. figure 3.6). On fait de même en ce qui concerne le graphe de flot de contrôle et le T-graph (cf. figure 3.6). Dans ces figures, la fonction impaire est dupliquée une fois, les blocs de base qui la composent (BB1 à BB4) ont donc été également dupliqués (les duplicata sont BB12 à BB15). Ainsi, BB1 et BB12 sont en tout point identiques (même contenu, adresse, etc.) mais pourront se voir attribuer des résultats d'analyse différents. L'absence de récursivité, ou la limitation statique de la récursivité permet d'assurer un nombre fini de duplications de fonctions.

3.1.3. Influence de la compilation sur la représentation logique du programme

La manière dont le code source est compilé en assembleur a une grande influence sur la construction des représentations logiques du programme décrites dans les paragraphes précédents. Le schéma de compilation détermine le type de mise en séquence des blocs de base. Un exemple de résultat possible de la compilation d'une structure de boucle simple est présenté par la figure 3.7.

Ainsi, la correspondance entre l'arbre et le graphe de la figure 3.6 n'est valable que pour un

7474

Figure 3.6 - Dépliage des appels de fonction dans l'arbre syntaxique (a) et dans le CFG (b).


schéma de compilation particulier. De même, les relations de précédence implicites entre les feuilles de l'arbre syntaxique ainsi que le type de ces relations de précédence dans les deux représentations (branchement saut ou pas de saut) dépendent du schéma de compilation mis en oeuvre par le compilateur choisi.

3.1.4. Informations supplémentaires de flot de contrôleLes représentations en graphe de flot de contrôle ou en arbre syntaxique ne sont pas

suffisantes pour le calcul du WCET d'un programme donné. En particulier, ces représentations n'indiquent pas si les chemins d'exécution sont bornés. Ainsi, il faut les compléter par des informations supplémentaires sur le comportement dynamique du programme de manière à restreindre le nombre de chemins à analyser et donc limiter l'analyse. Ces informations sont le plus souvent utilisées pour :

➢ borner le nombre d'itérations des boucles car le WCET d'une boucle ne dépend pas seulement de la structure du code qu'elle contient mais aussi de son nombre d'itérations. Cette information doit donc être associée aux boucles, le plus souvent sous forme d'une constante [30], [47].

➢ contraindre le choix d'une branche dans une structure conditionnelle quand ce choix dépend d'un paramètre constant.

➢ restreindre le nombre de chemins d'exécution possibles en indiquant les chemins infaisables qui apparaissent dans le graphe de contrôle mais qui ne sont jamais exécutés comme pour le cas d'une exclusion mutuelle entre deux branches.

Ces informations peuvent être obtenues de deux manières. La première fait appel à l'utilisateur qui doit fournir ces informations en les ajoutant au code sous forme d'annotations

7575

Figure 3.7 - Les schémas logiques de deux compilations d'une même structure de boucle.


[30], ou interactivement [48]. La plupart des travaux concernant l'analyse statique de WCET utilisent la méthode basée sur les annotations.

[47] et [49] permettent dans certains cas d'obtenir automatiquement les bornes sur les nombres d'itérations des boucles en analysant le code et les données manipulées. Bien que ces techniques soient efficaces pour des boucles relativement simples, l'annotation des boucles les plus complexes reste à la charge du programmeur.

3.2. ANALYSE DES PROPRIÉTÉS TEMPORELLES Plusieurs caractéristiques architecturales, comme le pipeline et les caches, posent de

nombreux problèmes pour l'analyse des systèmes temps-réel. Leur utilisation peut fournir une amélioration significative des performances mais la modélisation de leur comportement n'est pas triviale, et leur prise en compte pour le calcul du WCET introduit une dépendance au contexte. Par exemple, la durée de l'exécution d'une instruction dans le pipeline dépend des instructions précédentes, et les durées des accès mémoire en lecture et écriture dépendent de l'état des caches et donc de l'historique de l'exécution.

Malgré ces difficultés, l'intégration de ces éléments dans l'estimation du WCET permet d'améliorer considérablement sa précision tout en garantissant la sûreté des estimations.

On peut classer les effets de l'architecture matérielle sur le temps d'exécution en deux catégories : les effets locaux et les effets globaux.

L'effet d'un composant d'architecture est local lorsque le comportement temporel d'une instruction ne peut affecter que les instructions proches dans le flot d'instructions. C'est le cas du pipeline où le comportement temporel d'une instruction n'affecte que les instructions suivantes. L'effet est dit global si le composant d'architecture permet à une instruction d'affecter le comportement temporel d'une autre instruction qui se trouve à n'importe quelle distance dans le flot d'exécution. C'est par exemple le cas du cache d'instructions pour lequel le chargement d'une instruction peut remplacer une autre instruction et ainsi affecter le temps d'exécution de cette dernière même si elle ne sera exécutée que bien plus tard.

Dans ce paragraphe nous allons décrire les caractéristiques et le fonctionnement de ces deux composants d'architecture et nous expliquerons leur prise en compte dans les techniques de calcul du WCET au paragraphe suivant.

3.2.1. Le pipelineLe pipeline est une technique d'implémentation de processeur dans laquelle plusieurs

instructions se recouvrent au cours de leur exécution. Aujourd'hui, c'est la technique d'implémentation fondamentale utilisée pour la réalisation des processeurs rapides.

Un pipeline est semblable à une chaîne d'assemblage. Dans une chaîne d'assemblage d'automobile par exemple, il y a beaucoup d'étapes chacune contribuant à la réalisation d'une

7676


partie de la construction de l'automobile. Chaque étape opère en parallèle avec les autres étapes, mais sur une autre voiture. Dans un pipeline d'ordinateur, chaque étape du pipeline, appelée aussi étage du pipeline ou segment du pipeline, réalise l'exécution d'une partie d'une instruction. Comme dans une chaîne d'assemblage, chacune de ces étapes réalise différentes parties de différentes instructions en parallèle. Les étages sont connectés les uns aux autres pour former un pipeline – les instructions entrent par un même bout, avancent à travers les étages, et sortent à l'autre extrémité, tout comme les automobiles le feraient dans une chaîne d'assemblage.

Par exemple un cycle d'exécution d'une instruction peut être décomposé en : lecture d'instruction IF (Instruction Fetch), décodage d'instruction ID (Instruction Decode), exécution EX ou FEX (Execution, Floating Execution), accès mémoire MEM (MEMory access), écriture du résultat WB ou FWB (Write Back, Floating Write Back). La figure 3.8 montre l'occupation d'un pipeline pour une séquence de trois instructions dans un processeurs MicroSPARC [50].

Donc, le but du pipeline est d'introduire du parallélisme entre le traitement des instructions. En conséquence, le temps d'exécution des instructions n'est pas la somme de leurs temps d'exécution unitaires, car le traitement d'une instruction peut débuter avant la fin du traitement de l'instruction précédente.

Le parallélisme d'instruction n'est pas maximum car l'occupation du pipeline par une séquence d'instructions peut être perturbée par des aléas (hazard) :

➢ dépendance de donnée (data hazards) quand une instruction utilise le résultat d'une

7777

Figure 3.8 - Occupation du pipeline d'un processeur MicroSPARC


instruction précédente dont l'exécution n'est pas encore terminée,➢ dépendance de contrôle (control hazards) lorsque le résultat d'une instruction est un

branchement pris (rupture de séquence par un saut). ➢ dépendance de structure (structural hazards) lorsqu'il y a un conflit d'accès à une

ressource entre plusieurs instructions dans différents étages du pipeline.

Les effets du pipeline sur le calcul du temps d'exécution interviennent à deux niveaux : (i) intra-blocs de base pour la prise en compte du chevauchement des instructions et des aléas de données, (ii) inter-blocs de base pour la prise en compte des aléas de contrôle.

3.2.1.1. Simulation plus DeltaAucun aléa de contrôle ne peut avoir lieu pendant l'exécution d'un bloc de base (pas de

rupture de séquence), mais la présence des aléas de données (dépendances de données) et de structure (conflit dans les étages du pipeline, file d'attente, etc.) est possible. De plus, pour calculer le temps d'exécution d'une séquence de blocs de base, il faut tenir compte des effets temporels dûs aux chevauchements des blocs adjacents.

Pour considérer tous ces aspects, le calcul du WCET d'une séquence de blocs de base présenté par [51] considère que le temps d'exécution d'une séquence de blocs de base T(B1,...,Bm) est donné par la formule suivante :

T B1...Bm=∑j=1

m

t B j∑

i , k=1ik

m

B i ... Bk(1)

ou t B j=T B j est le temps d'exécution d'un bloc à part

et B1... Bm=T B1 ...Bm−T B2 ...Bm−T B1... Bm−1T B2 ...Bm−1 m≥2

(2)

B1... Bm calcule les effets du pipeline sur le temps d'exécution d'une séquence

d'instructions. Elle tient compte des effets dûs aux chevauchements d'une paire de blocs de base adjacents PTE (pairwise timing effects) accélèrent l'exécution de la séquence, mais aussi des effets temporels longs pour une longue séquence d'instructions LTE (long timing effects). Normalement, les PTE sont négatifs, mais il se peut que les LTE soient non nuls. Quand B1... Bm

≠ 0, ceci est dû au fait que l'exécution du bloc B1 perturbe l'exécution du bloc Bm

(à travers la séquence B2... Bm ). Précisément, le temps exécution de la séquence B2... Bm dans la séquence B1 ... Bm est différent du temps d'exécution de la séquence B2 ... Bm à partir du bloc B2 .

La figure 3.9 montre un exemple de trois blocs de base A, B et C ; pour des raisons de simplicité, nous considérons que chaque bloc est formé d'une seule instruction. Le temps d'exécution de chaque bloc seul est fourni ainsi que le temps d'exécution des paires AB et BC

7878


et enfin le temps d'exécution de la séquence ABC. Nous observons les effets temporels dûs au chevauchement des blocs adjacentes ainsi que l'effet temporel long dû à l'exécution de C à partir de A en passant par B. Pour illustrer l'exécution des blocs dans le pipeline nous utilisons des diagrammes similaires aux tables de réservations [52] utilisées normalement pour illustrer le comportement des processeurs ayant des pipelines. Le pipeline est représenté verticalement en quatre étages IF (Instruction Fetch), E (Execution), M (Memory access) et F (Floating write back). Le temps d'exécution est indiqué horizontalement par des carreaux colorés pour illustrer le temps que passe le bloc dans chaque étage. Chaque carreau représente un cycle d'horloge du processeur.

Dans cet exemple, le LTE est négatif. On gagne donc du temps si on exécute BC à partir de A au lieu de commencer l'exécution par B. Si on néglige un LTE négatif, ce n'est pas grave mais on risque seulement de fournir un WCET plus pessimiste. Mais il se peut que dans d'autres cas les LTE soient positifs donc il faut à tout prix les prendre en compte pour fournir des WCET sûrs.

Le pipeline est modélisé par des contraintes temporelles simples. L'approche peut analyser le comportement temporel d'un pipeline à exécution ordonnée qui n'autorise pas les renvois dynamiques. Pour un tel processeur à n étages, un bloc Bi est représenté par un vecteur r i

1 ... rin où r i

j correspond au temps que passe le bloc dans l'étage j du pipeline. Les blocs sont

7979

Figure 3.9 - Exemple de LTE


numérotés de 1 à m. Pour chaque bloc de base, pij représente le point d'entrée dans l'étage j,

par convention pin1 représente le temps de sortie de Bi du pipeline.

Les contraintes temporelles qui modélise l'exécution de la séquence B1 ...Bm sont les suivantes :

pij1≥ pi

jrij 1≤i≤m ,1≤ j≤n 3

pi1j ≥ pi

j1 1≤i≤m ,1≤ j≤n 4

L'exécution d'une séquence de blocs de base peut être représentée par un graphe acyclique où les étages du pipeline sont représentés verticalement, les noeuds correspondent aux pi

j et les arrêtes aux contraintes entre ces points. Les contraintes fournies par l'équation (4) sont représentées verticalement et celles de l'équation (5) diagonalement.

De nouvelles contraintes sont ajoutées pour tenir compte des dépendances de données, ces contraintes sont fournies par l'équation (5). Ces contraintes impliques qu'un bloc Bi ne peut pénétrer dans un étage j avant qu'un certain bloc B k ne soit sorti d'un certain étage l.

pij≥ pk

l1 5

La figure 3.10 montre le graphe représentant l'exécution de trois blocs A, B et C en tenant compte des contraintes fournies par les inéquations (3), (4) et (5). La flèche rouge montre la dépendance de données entre l'étage W de A et l'étage E de C.

Pour un processeur ayant plusieurs pipelines parallèles, comme celui de la figure 3.11, les blocs de base n'ont pas toujours besoin de tous les étages du pipeline. En effet, on considère pour chaque bloc seulement les points d'entrée aux étages qu'il utilise pour son exécution.

8080

Figure 3.10 - Modèle de contraintes de l'exécution dans le pipeline


Ainsi les contraintes temporelles fournies par les inéquation (3) et (4) sont reformulées par les inéquations (6) et (7) pour utiliser previ(i,j), nexti(i,j), prevs(i,j) et nexts(i,j). Previ(i,j) et nexti(i,j) indique respectivement pour chaque instruction Bi le bloc précédent et suivant qui utilisent l'étage j du pipeline. D'autre part prevs(i,j) et nexts(i,j) indiquent respectivement pour chaque bloc Bi et un étage du pipeline j, l'étage du pipeline précédent et suivant utilisés par Bi .

pinexts i , j ≥ pi

jrij 6

pnexti i , prevs i , j prevs i , j ≥p i

j 7

La figure 3.12 montre un exemple de modèle de contraintes pour un processeur multi-pipeline. L'exemple consiste en 6 blocs de base A, B, C, D, E et F. Pour des raisons de simplicité, on considère que ces blocs de base sont formés d'une seule instruction. Les digrammes de pipeline de chaque bloc est montré à gauche et le graphe de contraintes entre ces blocs est montré à droite.

Les dépendances de branchements n'existent pas entre les instructions d'un seul bloc de base mais elle peuvent exister entre les blocs de base. Le branchement a lieu à la fin de l'étage ou le branchement est décidé et l'étage IF du bloc de base cible. Un branchement généré par un étage j d'un bloc de base Bi implique l'inéquation suivante

8181

Figure 3.12 - Modèle de contraintes pour un processeur multi-pipeline

Figure 3.11 - Processeur à exécution ordonnée ayant deux pipelines parallèles.


pi11 ≥ pi

j1 8

On définit un chemin de pij à pk

l comme une séquence de flèches de pij à pk

l dans le graphes de contraintes. La longueur d'un chemin P est la somme des poids des flèches dans P. La distance D pi

j , pkl entre deux points pi

j et pkl est définie comme étant la longueur

maximale parmi les chemins possibles entre ces deux points. Notons que cette distance ne peut être construite que s'il existe au moins un chemin qui relie ces deux points dans le graphe de contraintes.

Ainsi le temps d'exécution d'une séquence d'instruction T B1 ... Bm est la distance maximale entre p1

1 et un point donné dans le système de contraintes.

T B1...Bm= max D p11 , pi

j1≤i≤m ,1≤ j≤n1

Il existe plusieurs approches pour tenir compte des effets du pipeline sur le temps d'exécution des blocs de base. Nous fournirons des références avec les détails sur les approches par analyse statique du calcul du WCET au paragraphe 3.3. Comme notre approche présentée dans le chapitre suivant ne modélise pas les effets du pipeline nous utilisons cette méthode implémentée dans OTAWA pour estimer les WCET des tâches dans nos expérimentations.

Une deuxième méthode [53] permet de calculer le temps d'exécution d'une séquence de blocs de base T(B1, ..., Bm) par simulation. Cette technique génère les temps d'exécution de chaque bloc de base ainsi que les valeurs des effets temporels . L'algorithme qui implémente cette technique utilise une base de données, TimeDB, qui contient les temps d'exécution des séquences de bloc de base. Si le temps d'exécution d'une séquence n'est pas dans TimeDB, cette séquence est passée au simulateur qui l'exécute et sauvegarde son temps d'exécution dans la base.

L'algorithme commence par calculer les temps d'exécution des blocs de base seuls. Ensuite il calcule le temps d'exécution des séquences de blocs de base dont la longueur est supérieure ou égale à deux et détermine pour chacune de ces séquences si un effet temporel est constaté. Finalement, il teste si la séquence doit être étendue pour tenir compte d'autres effets temporels, si oui toutes ses extensions possibles sont simulées et leurs temps d'exécution et leurs effets temporels sont calculés et sauvegardés dans TimeDB.

Une fois la simulation terminée le CFG du programme peut être valué comme le montre l'exemple de la figure 3.13. L'exemple montre un CFG de deux blocs de base et fournit les résultats de la simulation effectuée par l'algorithme décrit précédemment pour obtenir le CFG valué. Ainsi nous pouvons constater sur cet exemple que la séquence QP possède un temps d'exécution inférieur à la somme des temps d'exécution de chaque bloc de base à part.

8282


3.2.1.2. Graphe d'exécutionCe paragraphe introduit un modèle [54], [55] et [56] qui permet d'estimer le temps

d'exécution d'un bloc de base comme fonction de son contexte d'exécution. Le contexte est spécifié par une liste de paramètres qui représentent le temps de libération de toutes les ressources nécessaires pour l'exécution d'un bloc de base (étages du pipeline, unités fonctionnelles, valeur de registre, etc.). Ensuite, le patron d'exécution du bloc de base est exprimé comme une fonction de ces paramètres. Ce parton est ensuite analysé pour calculer une borne supérieure de son temps d'exécution.

L'exécution du bloc de base dans le pipeline est représentée par un graphe d'exécution dont les noeuds symbolisent l'exécution d'une instruction dans un étage du pipeline ou dans une unité fonctionnelle. Les flèches directes expriment les règles de précédence entre les noeuds qui sont engendrées par 1) l'ordre d'exécution des instructions du programme (tel que l'ordre de chargement des instructions), 2) la structure du pipeline (exemple : l'instruction doit être chargée avant d'être décodée), 3) la longueur souvent limitée des files d'attente, et 4) les dépendances de données.

Le graphe d'exécution est initialement fourni par l'approche de Li et al. [54], mais une extension qui optimise l'estimation des temps d'exécution est fournie par [55] et [56]. Nous décrivons dans ce paragraphe la méthode introduite dans [55] et [56] qui contient le modèle initial et les nouvelles extensions.

Nous considérons dans ce paragraphe un processeur simple contenant un pipeline scalaire de trois étages fetch (IF), exécution et commit (CM) avec exécution ordonnée. Ce processeur inclut deux unités fonctionnelles ayant une latence d'un cycle et un tampon de quatre entrées qui stocke les instructions activées simultanément par le processeur. Il est illustré par la figure 3.14.

8383

Figure 3.13 - Effets temporels calculés par simulation


Le graphe d'exécution d'un bloc de base, de cinq instructions, par ce processeur est montré dans la figure 3.15. Les flèches horizontales représentent les contraintes engendrées par la structure du pipeline et les flèches verticales illustrent les dépendances de données et l'ordre d'exécution des instructions du programme. La capacité du tampon d'instructions (quatre entrées) est prise en compte par la flèche CM(i0) → IF(i4).

Ce modèle est étendu pour modéliser le temps d'exécution d'un bloc de base dans un pipeline superscalaire. Les flèches barrées sont utilisées pour représenter l'exécution parallèle des instructions. Ainsi deux noeuds du graphe d'exécution qui peuvent être exécutés en parallèle mais en suivant l'ordre d'exécution des instructions du programme sont liés par ces flèches. Par exemple, deux instructions adjacentes peuvent être décodées dans le même cycle du processeur, ou bien la deuxième peut être décodée après la première mais elle ne peut jamais être décodée avant la première car les instructions sont exécutées en ordre. La figure 3.16 montre le graphe d'exécution du même bloc de base de la figure 3.15 dans un pipeline superscalaire qui peut exécuter au plus deux instructions en parallèle. On suppose que quatre instructions sont chargées à chaque cycle, et que i0 et i3 peuvent être chargées en parallèle. Les flèches barrées et pleines entre les CM montrent aussi que deux instructions adjacentes peuvent être sauvegardées en un même cycle.

8484

Figure 3.14 - Exemple d'un processeur

Figure 3.15 - Exemple d'un graphe d'exécution (pipeline scalaire à exécution ordonnée)

i0 : r0 ← MEM(@x)i1 : r1 ← r0 + 8i2 : r2 ← MEM(@y)i3 : r3 ← r10 + 12i4 : r4 ← r2 + r3


Il est aussi adapté pour tenir compte de l'exécution non-ordonnée des instructions dans les étages du pipeline. Ainsi quand les instructions sont ordonnancées d'une manière dynamique pour une certaine ressource, les noeuds du graphe d'exécution représentant cette ressource sont liées par des flèches pointillées marquées par la capacité de cette ressource. Dans la figure 3.16, on suppose que le processeur est doté de trois unités fonctionnelles pour lesquelles les instructions sont ordonnancées dynamiquement (deux ALU et une unité MEM). Les flèches pointillées montrent que i1, i3 et i4 peuvent utiliser les ALU dans n'importe quel ordre sachant que deux d'entre elles peuvent être exécutées en parallèle dans le même cycle. Cependant, la dépendance de données entre i3 et i4 limite les possibilités d'ordonnancement de ces instructions.

Le but principal est d'exprimer et de définir un modèle paramétrique du contexte d'exécution d'une séquence d'instructions. Ce modèle doit être capable d'exprimer toutes les informations concernant le contexte d'exécution. Ainsi l'objectif est de déterminer le temps d'exécution de chaque noeud du graphe d'exécution en respectant les paramètres du contexte.

Le pipeline d'un processeur superscalaire de degré n est représenté par n ressources différentes, R représente l'ensemble de ces ressources. Une ressource virtuelle est ajoutée à cet ensemble pour représenter le temps auquel la séquence d'instruction pénètre dans le pipeline. Le contexte est spécifié par un vecteur de paramètres, A, où chaque paramètre représente le temps de libération d'une ressource de R. A est noté par A={ar | r∈R } .

Les contraintes sur le temps pour lequel chaque noeud du graphe d'exécution est prêt sont exprimées par :

➢ un vecteur N de booléens qui indiquent les dépendances du temps pour lequel le noeud est prêt, aux paramètres du contexte :

8585

Figure 3.16 - Graphe d'exécution (pipeline superscalaire à exécution non-ordonnée)


N={e Nr ∈{0,1} | r∈R }

➢ un vecteur DN de délais qui représentent la distance minimale entre le temps de libération de la ressource et le temps pour lequel le noeud est prêt :DN={ d N

r | r∈R }

Ainsi le temps pour lequel un noeud N est prêt est exprimé par

N=maxe Nr . d N

r ar (1)

Ayant calculé le temps d'exécution des noeuds du graphe d'exécution, le temps d'exécution du bloc de base peut être exprimé en fonction des paramètres du contexte du vecteur A. Si LB est le dernier noeud du bloc de base, le temps d'exécution du bloc de base est donné par :

t B=LBl LB

Le coût d'un bloc de base est le temps entre la fin de l'exécution de la dernière instruction précédant son exécution et le temps de terminaison de sa dernière instruction si les instructions sont exécutées en ordre. Sinon le coût du bloc de base dépend de ce qui à été exécuté avant (préfixe) et ce qui a été exécuté après (suffixe).

Si le graphe d'exécution est étendu pour couvrir l'exécution du bloc de base avec un préfixe contenant au moins une instruction, le modèle permet d'évaluer le coût d'un bloc base en utilisant la formule suivante, sachant que LP est le dernier noeud du préfixe.

C B=LBl LB

−LP−l LP

(2)

Quand le contexte d'exécution est connu, les temps de libération des ressources ar sont connues, ainsi il est possible de déterminer le temps d'exécution exact du bloc de base en utilisant l'équation (2). De plus, cette même expression est utilisée pour déterminer une borne supérieur du temps d'exécution du bloc même si son contexte n'est pas ou partiellement connu.

Pour tenir compte de l'ordonnancement dynamique des instructions sur les ressources, une ressource fonctionnelle utilisée par n instructions est représentée par n temps de libération. L'ensemble S est utilisé pour déterminer les noeuds du graphe d'exécution qui utilisent des ressources fonctionnelles, pour lesquelles les instructions sont ordonnancées dynamiquement, et qui peuvent être retardées par des conflits. Notons que des instructions du même bloc de base peuvent être concurrentes pour une même ressource, c'est ce qu'on appelle des conflits internes.

A cause de ces conflits internes, le temps de début d'exécution (N ) d'un noeud N peut être supérieur à N (le temps pour lequel le noeud est prêt). Le délai induit par les conflits qui affectent directement le noeud N est noté par N , et ainsi N est égal à NN .

Pour tenir compte de la propagation des délais induits par les conflits internes sur N , on

8686


utilise :

➢ N , vecteur de booléens qui indiquent les dépendances entre le temps pour lequel le noeud est prêt avec chaque noeud de S.

N={ eN∈{ 0,1} | s∈S }

➢ DN , vecteur de délais qui représentent la distance minimale entre les temps-réels de début d'exécution des noeuds de S et le temps pour lequel le noeud N est prêtDN={ d N

s | s∈S }

Ainsi le temps pour lequel le noeud N du graphe d'exécution est prêt est donné par l'équation (3)

N=maxe Nr d N

r a (3)

où e Nr =e N

r et d Nr =max d N

r , max e Ns .e s

r d Ns d s

rs

Soit la ressource qui représente le dernier étage du pipeline (dans notre exemple a est le temps de libération de l'étage CM). Chaque noeud du graphe d'exécution relié au dernier

étage (exemple LB et LP ) possède une dépendance (eLB

=eLP

=1 ) car on suppose que les

instructions sont sauvegardées dans leur ordre d'apparition dans le programme. Un point important est que chaque ressource de R est libérée avant , donc ∀ r∈R , ara . On peut aussi déterminer à combien de cycles avant chaque ressource de R a été libérée, selon l'étage du pipeline où elle a été utilisée (ce délai est noté par r ). Dans notre exemple, le pipeline contient trois étages, une ressource utilisée par une unité fonctionnelle doit être libérée avant l'étage CM( ), ainsi ∀ r∈R , arr≤a . l LB

et l LP étant connues, il suffit de

maximiser B−P (formule (5) ) pour calculer une borne maximale du coût d'exécution d'un bloc de base donné par la formule (2). Cette borne maximale est le coût d'exécution pire cas du bloc de base.

B−P≤max r LB , LP (5)

où

rLB , LP=e LB

r . d LB

r −e LP

r .d LP

r – 1 – e LP

r .d LP

r (6)

3.2.2. Les mémoires cachesLes évolutions techniques récentes ont eu pour effet une augmentation considérable de la

différence entre les vitesses des processeurs et celles des mémoires. La mémoire est devenue un élément limitant les performances de l'architecture. Comme les mémoires rapides sont trop chères pour que l'on puisse en disposer d'une quantité importante, une hiérarchie mémoire est organisée en plusieurs niveaux. Chaque niveau, en partant du plus haut niveau, étant plus

8787


petit, plus rapide et ayant un coût par octet plus élevé que le suivant. Les niveaux de la hiérarchie sont généralement imbriqués. Toute donnée d'un niveau se trouve dans le niveau inférieur, et toute donnée de ce niveau inférieur se trouve dans le niveau en dessous, et ainsi de suite jusqu'en bas de la hiérarchie. Notez que chaque niveau fait correspondre les adresses d'une mémoire plus grande vers une mémoire plus petite mais plus rapide à un niveau supérieur dans la hiérarchie.

Généralement, on appelle Cache la mémoire correspondant au premier niveau de la hiérarchie mémoire que l'on rencontre lorsque les adresses quittent l'Unité Centrale (UC). Le cache est une petite mémoire proche de l'UC qui contient les données et les instructions les plus récemment utilisées.

Ainsi, la mémoire cache sert à stocker les données auxquelles le système fait le plus souvent appel pour réduire les états d'attente du processeur. Quand l'UC trouve l'élément demandé dans le cache, c'est un succès cache ou hit. Quand elle ne le trouve pas, c'est un défaut de cache ou miss. Dans ce dernier cas l'élément est copié depuis le niveau inférieur.

L'usage d'une mémoire cache introduit de l'indéterminisme dans l'architecture car, en ajoutant cet intermédiaire entre la mémoire centrale et le processeur, la durée des accès mémoire n'est plus constante. En effet, deux durées correspondant à deux cas d'accès au cache sont à considérer. Une première durée correspond à l'accès hit et une deuxième correspond à l'accès miss. La durée d'un accès miss est évidemment bien plus importante que celle d'un accès hit.

Il faut donc pouvoir prédire de façon sûre le résultat des accès au cache pour connaître le pire comportement des accès mémoire vis à vis du cache lors de l'exécution d'un programme. Si on peut assurer qu'un accès mémoire sera un succès, il sera estimé comme un hit mais s'il y a un doute, on garde l'estimation la plus pessimiste : un miss.

Le cache d'instructions est un cas particulier pour deux raisons. D'une part, les seuls accès qui le concernent sont les accès en lecture car ils ne contiennent que des instructions. D'autre part, toutes les références mémoires – adresses des instructions – peuvent être connues statiquement, il suffit pour cela de connaître l'adresse d'implantation du programme en mémoire (cf. § 3.2.2.2).

On s'intéressera particulièrement à ce type de cache dans la suite de ce document, mais dans le paragraphe §3.3, on énumérera des méthodes de calcul de WCET qui s'appliqueront aussi aux caches de données et aux caches unifiés – instructions + données.

3.2.2.1. Découpage du cache en blocs La mémoire et le cache sont découpés en cellules de taille égales qu'on appelle aussi blocs.

Un bloc mémoire possède la même taille qu'un bloc de cache. Chaque bloc, mémoire ou cache, possède un numéro qui nous permet de le référencer et de le localiser. Ce numéro est son adresse. Avec une adresse de n bits, il est possible de référencer directement au plus 2n

8888


blocs. La taille d'une mémoire est le nombre total de blocs qu'elle contient. Elle s'exprime en nombre de bits ou d'octets. Compte tenu de l'adressage binaire, les capacités des mémoires s'expriment en puissances de deux.

Quand un programme a besoin d'une donnée il cherche tout d'abord si elle existe dans le cache sinon il procède à son chargement de la mémoire centrale.

La figure 3.17 montre le découpage de l'adresse d'une instruction ou d'une donnée. Le premier découpage sépare le numéro du bloc de l'adresse dans le bloc. Le numéro du bloc peut être divisé en un champ étiquette et un champ index. Le déplacement dans le bloc sélectionne la donnée dans le bloc, le champ index est utilisé pour sélectionner l'ensemble du cache qui doit contenir le bloc et le champ étiquette est utilisé pour la comparaison. Ainsi quand cette donnée est requise, les étiquettes des blocs du cache présents dans l'ensemble du cache dont le numéro est indiqué dans le champ index sont examinées pour voir si l'une d'elles correspond au numéro de bloc de la donnée.

La comparaison pourrait être faite sur une partie plus grande que l'étiquette mais cela n'est pas nécessaire pour deux raisons. La première est que le test sur l'index serait redondant puisqu'il a servi au choix de l'ensemble à tester (une adresse rangée dans l'ensemble 0, par exemple, doit avoir 0 dans son champ index). La deuxième est due au fait que l'adresse dans le bloc est inutile pour le test car le bloc est en entièrement chargé dans le cache.

3.2.2.2. Les types de cachesLa figure 3.18 montre que les restrictions sur l'endroit ou placer un bloc créent trois types

d'organisation du cache :

➢ Cache à correspondance ou accès direct pour lequel un bloc de base a uniquement une place possible dans le cache. La correspondance est généralement la suivante :

(numéro de bloc) modulo (nombre de blocs dans le cache).

➢ Si un bloc de cache peut être placé n'importe où dans le cache, celui-ci est appelé totalement associatif.

➢ Si un bloc peut être placé dans un ensemble restreint de places dans le cache, le cache est associatif par ensembles de blocs. Un ensemble est un groupe de blocs dans le cache. Un bloc est d'abord affecté à un ensemble, puis ce bloc est placé n'importe où dans cet ensemble. L'ensemble est habituellement choisi par sélection de bits :

8989

Numéro du bloc

Étiquette Index

Déplacement dans le bloc

Figure 3.17 - Le découpage d'une adresse d'un bloc mémoire


(numéro de bloc) modulo (nombre d'ensembles dans le cache)

S'il y a n blocs dans un ensemble, la correspondance est appelée associative par ensemble de n blocs.

Notons que la correspondance directe est équivalent à l'associativité avec un bloc par ensemble, et un cache totalement associatif de m blocs peut être appelé associatif par ensemble de m blocs. Ainsi, on peut voir la correspondance directe comme le fait de disposer de m ensembles et l'associativité totale comme disposer d'un seul ensemble. La majorité des caches de processeurs sont soit à correspondance directe, soit associatifs par ensemble.

Pour terminer, il faut noter que si la taille du cache reste la même, l'augmentation de l'associativité augmente le nombre de blocs par ensemble du cache et diminue ainsi la taille de l'index et augmente la taille de l'étiquette. Cela veut dire que la frontière étiquette / index de la figure 3.17 se déplace vers la droite avec l'augmentation du degré d'associativité, avec le cas limite des caches totalement associatifs qui n'ont pas de champ index.

3.2.2.3. Les stratégies de remplacement sur un défaut de cacheQuand un échec intervient, le contrôleur du cache doit choisir un bloc à remplacer par la

9090

Figure 3.18 - Cet exemple utilise un cache à 8 blocs et une mémoire de 32 blocs

0 1 2 3 4 5 6 7

N° bloc

Numéro de bloc mémoire

Mémoire

N° bloc

Cache

Totalement associatif :Le bloc 12 peut aller n'importe où

Associatif par ensemble :Le bloc 12 peut aller n'importe où dans l'ens-emble 0 (12 mod 4)

Correspondance directe :Le bloc 12 peut aller seulement dans le bloc 4 (12 mod 8)

0 1 2 3 4 5 6 7

ens0 ens1 ens2 ens3

0 1 2 3 4 5 6 7

0

1 2 3 4 5 6 7 8 9 10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31


donnée désirée. Un avantage de la correspondance directe est que les décisions matérielles sont simplifiées au point qu'il n'y a pas de choix : un seul bloc est testé pour déterminer s'il y a succès, et seul ce bloc peut être remplacé. Avec l'associativité totale ou le placement associatif par ensembles, il faut choisir parmi plusieurs blocs lors d'un échec. Il y a plusieurs stratégies employées pour choisir le bloc à remplacer :

➢ Au hasard – Pour répartir l'allocation uniformément, les blocs candidats sont choisis de façon aléatoire. Certains systèmes génèrent des numéros de blocs pseudo aléatoires pour obtenir un comportement reproductible, ce qui est particulièrement utile pendant la mise au point du matériel.

➢ Le plus ancien (LRU pour Least Recently Used) – Pour réduire la probabilité de rejeter des informations qui seront nécessaires dans un avenir proche, les accès aux blocs sont enregistrés. Le bloc remplacé est celui qui n'a pas été utilisé depuis le plus longtemps. Ceci utilise un corollaire de la localité temporelle : si les blocs utilisés récemment sont susceptibles d'être utilisés à nouveau, alors le meilleur candidat au remplacement est le plus ancien.

➢ FIFO – modélise les ensembles du cache en files de bloc de cache et utilise un compteur qui sera incrémenté quand un nouveau bloc est chargé. Ainsi quand un bloc qui n'existe pas dans le cache est référencé et que la file de son ensemble de cache est remplie, cet élément est chargé dans la file et supprime l'élément qui se trouve à la fin supposé être le plus ancien selon l'algorithme « First In First Out ». Contrairement à LRU, un hit ne change pas la position des éléments dans la file.

➢ MRU – associe à chaque ligne du cache un bit qui indique son statut. La valeur 1 de ce bit indique que la ligne est récemment utilisée. La mise à jour de ces bits ce fait comme suit: en cas de hit, si le statut de la ligne est 1 l'état du cache ne change pas, sinon le bit est mis à 1 ; quand le dernier bit 0 d'un ensemble des lignes du cache est mis à 1, tous les autres bits sont remis à 0. Quand un cache miss se produit dans un ensemble du cache, la ligne ayant un statut 0 est remplacée. En cas où plusieurs lignes ont un statut 0, selon la modélisation du cache, on choisit la ligne la plus à gauche ou la plus à droite.

La stratégie du hasard n'est ni facile à implémenter, ni possible à analyser. D'autre part, le contenu d'un cache LRU est facile à prédire mais le seul inconvénient est que le coût de l'analyse croît avec le nombre de blocs à observer, et il est souvent seulement approximé [57].

Wilhelm et al. ont utilisé deux mesures evict et fill dans [58] pour comparer la prédicitibilité de ces stratégies de remplacement. Ces mesures sont fonction du degré d'associativité du cache noté A. Evict est le nombre d'accès distincts qui suppriment tous les L-blocs non référencées d'un ensemble du cache arbitraire de taille A. D'autre part fill, est le nombre d'accès distincts pour atteindre un état bien défini d'un ensemble du cache. Ces deux mesures sont évaluées en distinguant les accès miss des autres accès aux caches. Pour LRU, quel que soit le degré A evict est égal à fill et les deux sont égales à A. En effet, le degré d'associativité du cache noté par A est la borne inférieure. Les mesures ont aussi démontré que le nombre d'accès miss (evict) nécessaires pour FIFO est MRU croît d'une manière linéaire en

9191


fonction de A de même pour FIFO fill. Cependant, il est impossible de prédire le nombre de remplacements nécessaires pour atteindre un état du cache bien défini (fill) pour MRU, en effet fill = ∞. Ainsi FIFO, MRU et Hasard ne sont pas intéressantes pour notre études.

3.3. TECHNIQUES INTRA-TÂCHE DE CALCUL DU WCETLe calcul du WCET d'un programme par analyse statique se fait comme susmentionné en

deux étapes. On débute par une analyse de flot de contrôle (§3.1) pour déterminer les différents chemins d'exécution, suivie d'une analyse temporelle pour modéliser l'architecture matérielle (§ 3.2).

Une fois les informations de flot de contrôle obtenues, il faut chercher le pire chemin d'exécution à partir de la représentation. La méthode utilisée pour la recherche du plus long chemin permet de distinguer les différentes méthodes d'analyses statiques du WCET. On peut répartir les méthodes usuelles en cinq classes : techniques utilisant les algorithmes de graphes, les techniques IPET, les techniques se basant sur les arbres syntaxiques et l'analyse symbolique du WCET.

3.3.1. Techniques utilisant les algorithmes de graphes[41] et [42] utilisent les algorithmes traditionnels de l'algorithmique des graphes pour

rechercher le plus long chemin d'un programme. Ces méthodes sont appliquées à des graphes de flot de contrôle où on associe à chaque bloc de base son WCET individuel. On obtient ainsi un graphe valué avec un seul point d'entrée et un seul point de sortie.

La méthode consiste à vérifier que le chemin trouvé, à partir des algorithmes de parcours de graphes, est un chemin d'exécution possible et, si ce n'et est pas le cas, on l'exclut du graphe et on recommence la recherche jusqu'à l'obtention du pire chemin d'exécution. Les informations de nombre maximum d'itérations limitent le nombre d'occurrences d'un bloc de base ou d'un arc dans un chemin d'exécution.

[41] et [50] utilisent l'analyse temporelle pour modéliser le comportement du cache (unifié, de données ou d'instructions) à accès direct ou associatif et du pipeline.

[41] considère des programmes qui ne contiennent pas de boucles et d'appels récursifs de fonction et procède par une analyse temporelle du programme PTA (Program Timing Analyser) sur le code assembleur et sur le code de haut niveau. Le PTA procède par construction du CFG de la tâche à analyser, le transforme ensuite en code assembleur qui sera traduit en code objet.

La méthode est divisée en deux étapes : une analyse de bas niveau pour tenir compte des effets des composants matériels, et une analyse de haut niveau qui utilise les résultats de la première étape pour calculer l'estimation finale du WCET. Un état indéterminé de ces composants matériels est supposé avant l'exécution du programme. L'analyse du cache et du

9292


pipeline utilise le CFG et le code assembleur pour effectuer une analyse de flot de données qui prédit la performance des instructions et des références de données. Ces résultats sont utilisés pour chaque bloc de base pour fournir un état abstrait du pipeline après son exécution. Les résultats de ces analyses sont sauvegardés dans le CFG qui devient un CFG annoté, sur lequel on applique la recherche du plus long chemin d'exécution possible. La longueur du chemin est calculée en concaténant les états abstraits du pipeline de ces blocs de base (cf figure 3.12.a), incorporant ainsi le comportement du cache et du pipeline. La longueur de ce chemin représente le WCET de la tâche.

L'analyse présentée dans [50] modélise le comportement du cache en associant à chaque instruction une catégorie (always hit, always miss, first hit et first miss) (voir tableau 3.1), ainsi le comportement des instructions dans le pipeline pour fournir une estimation du WCET et du BCET (Best Case Execution Time). Cette approche peut tenir compte des boucles simples et des boucles imbriquées. Elle est plus complexe que [41] par conséquent, elle a besoin d'une annotation du programme de la part de l'utilisateur.

Cette approche commence par sauvegarder les informations de flot de contrôle obtenues de l'analyse du code assembleur et du code objet. Ces informations sont ensuite passées au simulateur statique du cache qui construit le CFG du programme qui contient les dépendances de données et les appels de fonctions. Ce CFG est analysé pour une configuration donnée du cache pour fournir une catégorisation des instructions. Ensuite, ces catégorisations sont utilisées dans l'analyse du comportement dans le pipeline des segments d'instructions qui représentent les chemins d'exécution du programme. Un analyseur temporel utilise l'analyse du pipeline de ces chemins d'exécution pour estimer la meilleur et la pire performance de chaque boucle et fonction du programme. Enfin, une interface utilisateur est invoquée pour permettre à l'utilisateur de demander la prédiction du WCET ou BCET d'un segment de programme. Le programme est représenté par un arbre d'analyse temporelle dont l'entrée est la

9393

Catégorie Abréviation Description

always hit ah La référence mémoire résulte toujours en un succès dans le cache

always miss am La référence mémoire résulte toujours en un échec dans le cache

First miss FmLa première référence mémoire résulte en un échec et les références suivantes en un succès

First hit FhLa première référence mémoire résulte en un succès et les références suivantes en un échec

not classified nc La référence mémoire ne peut être classée ni

ah ni am.Tableau 3.1 - Les différentes catégories des références mémoires


fonction « main » et les noeuds sont les boucles et les fonctions considérées toutes comme des boucles naturelles4. Les instances externes des appels de fonctions sont aussi considérées comme des boucles naturelles. L'analyse temporelle d'une boucle est effectuée d'une manière ascendante. Ainsi, le WCET et le BCET d'une boucle reste inconnus tant que ceux de ces fils direct ne sont pas calculés, les temps des feuilles étant connus.

Ces approches ne peuvent hélas être utilisées que pour des processeurs très simples avec un pipeline très déterministe et non-superscalaire où le profil d'exécution d'une instruction change peu en fonction du contexte.

3.3.2. Techniques IPETCette classe de méthode, dite d'énumération implicite des chemins (ou IPET – Implicit

Path Enumeration Technique) est employée dans de nombreux travaux d'analyse statique de WCET [28], [43], [59] et [60]. Elle consiste à représenter un programme sous forme de graphe de flot de contrôle et à le transformer en un ensemble de contraintes devant être respectées. Un premier jeu de contraintes décrit la structure du graphe, et un deuxième permet de prendre en compte les informations supplémentaires sur le flot de contrôle, vues au paragraphe 3.1.4. Ensuite on ajoutera de nouvelles contraintes pour tenir compte du cache – instructions, données, unifié. Le WCET est alors exprimé comme une fonction linéaire à optimiser en tenant compte des contraintes définies précédemment.

La figure 3.19 montre le système de contraintes généré pour l'exemple de la figure 3.3. Chaque noeud du graphe de flot de contrôle est valué par ni, son nombre d'occurrences dans le

4 Une boucle naturelle est une boucle qui a un seul bloc d'entrée. L'analyseur temporel analyse uniquement des boucles naturelles, car il serait difficile à l'utilisateur et à l'analyseur temporel de prédire le nombre de blocs associés à chaque itération de la boucle non naturelle.

9494

Figure 3.19 - Traduction d'un graphe de flot de contrôle en un système de contraintes


pire chemin d'exécution. À chaque noeud du graphe, la somme des nombres d'occurrences des noeuds prédécesseurs doit être égale à la somme des nombres d'occurrences des noeuds successeurs. On obtient ainsi un premier système de contraintes qui décrit la structure du graphe (figure 3.19.a). Les contraintes (figure 3.19.b) regroupent les informations supplémentaires. Pour cet exemple, c'est le nombre d'itérations de la boucle.

Étant donnés ces deux jeux de contraintes, on cherche à maximiser l'expression du WCET :

où wi est le WCET d'un bloc de base BBi.

Des adaptations de la technique IPET pour la prise en compte du cache d'instruction et du pipeline ont été proposées dans [28], [43], [60] et [61].

La prise en compte du pipeline se fait par l'utilisation de tables de réservation, et l'effet inter-bloc de base (cf. § 3.2.1.2) peut être pris en compte [43], ou non [28]. Les valeurs de wi

représentant les WCET des blocs de base dans le système de contraintes sont modifiées pour prendre en compte l'effet du pipeline. Les temps d'exécution des blocs de base dans le pipeline peuvent être obtenus par simulation [53] ou par analyse statique. L'analyse statique fournit un système de contraintes généré à parti des graphes de pipeline comme c'est le cas pour l'approche d'Engblom et Jonsson [51] ou à partir des graphes d'exécution comme c'est le cas pour l'approche de Rochange et al. dans [55]. Cette analyse statique calcule un temps d'exécution en tenant compte des dépendances entre les blocs de base et des effets temporels longs ainsi que l'effet de chevauchement des instructions adjacentes. [51] modélise les pipelines scalaire parallèles à exécution ordonnée et sans diffusion dynamique bien que [55], permet de plus, de modéliser le contexte d'exécution d'un bloc de base dans un pipeline à exécution spéculative.

Pour prendre en compte l'effet du cache d'instruction, l'expression du WCET à maximiser (cf. formule 3.1) est modifiée pour refléter (i) le fractionnement des blocs de base dans le cache et (ii) les deux temps d'exécutions possibles de ces fragments de blocs de base (hit et miss). Dans [28], un bloc de base BBi donne Ni fragments correspondants aux lignes de cache occupées. Ces fragments sont appelées L-blocs (cf §3.1.1.2).

À chaque L-bloc j d'un bloc de base BBi sont associés deux WCET, w i , jhit et w i , j

miss . Le nombre d'occurrences du bloc de base ni devient n i=n i , j

hitni , jmiss . En d'autres termes, la somme

du nombre de hit et du nombre de miss de n'importe quel L-bloc j de BBi est égal au nombre d'occurrences de BBi. La nouvelle expression du WCET à maximiser est alors :

9595

WCET=∑i

n

ni×wi

Formule 3.1 - Expression de calcul du WCET


Un nouveau jeu de contraintes est généré et ajouté au système existant pour le calcul des valeurs des n i , j

hit et n i , jmiss . Ces nouvelles contraintes représentent le comportement des L-blocs

vis-à-vis du cache d'instructions. Par exemple, un L-bloc qui cause un miss lors de sa première exécution puis qui reste toujours dans le cache est représenté par : n i , j

miss1 .

Dans [60], on peut considérer aussi le degré d'associativité du cache d'instruction qui consiste à définir pour chaque ligne du cache le graphe de conflit CCG (Cache Conflict graph) entre les L-Blocs de base qui seront chargés dans cette ligne du cache. Puis nous déduisons de ce CCG, le graphe d'états de transition CSTG (Cache State Transition Graph) qui va être traduit par un nouvel ensemble de contraintes. La technique peut aussi être adaptée pour modéliser le cache de données et le cache unifié.

Les résolution du système de contraintes obtenu utilise des moteurs de résolution de programmation linéaire ILP (Integer Linear Programming) ou de satisfaction de contraintes. Le temps d'analyse est fonction de la complexité du système et peut donc être important [60].

Une deuxième analyse présentée dans [42], représente un programme par un graphe temporel (T-graph §3.1.1.3) et calcule son temps d'exécution maximal en considérant tous les chemins d'exécution possibles de ce graphe. Les T-graph reflètent la structure et le comportement temporel du code. Les arcs représentent les blocs de base et sont valués par le WCET de ces blocs, et les noeuds du graphe représentent les points dans le code où le flot de contrôle du programme converge et / ou diverge.

Des contraintes de capacités sont utilisées pour exprimer les informations fournies par l'utilisateur sur les chemins impossibles du graphe. L'utilisation de ces contraintes permet de caractériser les chemins du T-graph en possible ou impossible. Ainsi, ayant défini tous les chemins d'exécution possibles le temps d'exécution de chaque chemin est calculé et le temps d'exécution maximal du programme est calculé comme étant le maximum de ces temps d'exécution. Pour calculer les temps d'exécution des chemins possibles, le problème qui relève de la théorie des graphes, qui consiste à calculer le coût maximal de circulation dans le graphe, est transformé en un problème linéaire. Ainsi, les informations fournies par les T-graph et les contraintes de capacités sont transformées en un problème de programmation linéaire et un moteur de résolution ILP est utilisé pour le résoudre.

Une autre technique est proposée par Ferdinand et al. dans [61] pour modéliser le comportement du cache par interprétation abstraite. Cette technique est inspirée de la méthode par catégorie de Muller [29]. Cette approche est conçue spécialement pour analyser le matériel avec des états. Ceci permet une classification statique du comportement du cache

9696

WCET=∑i∑

j

N i

ni , jhit ×w i , j

hitni , jmiss×w i , j

miss≤∑i

ni×w i

Formule 3.2 - Évaluation du WCET en tenant compte du cache d'instructions


pour les références mémoire des programmes. L’information calculée peut être utilisée pour améliorer l’estimation du temps d’exécution pire cas. Il est possible d’analyser les caches d’instruction, les caches de données et les caches unifiés en tenant compte des stratégies de (rem)placement et d’écriture. Cette méthode est capable d'analyser les boucles et les appels récursifs.

L'approche présente deux analyses : l'analyse MUST qui détermine l'ensemble des L-blocs qui sont dans le cache à un point donné du programme en toutes circonstances, et l'analyse MAY qui détermine l'ensemble des L-blocs qui sont peut être dans le cache à un point donné du programme. Cette dernière analyse est utilisée pour garantir l'absence d'un L-bloc du cache à un point donné. L'analyse est utilisée pour définir une catégorie qui décrit le comportement du cache, pour chaque référence mémoire. Les catégories sont énumérées dans le tableau 3.1.

La technique proposée par Rakib et al. [62] est très proche de l'analyse de Ferdinand. Cependant elle étudie le comportement du cache pour des modules compilés qui n'ont pas été liés au lieu de travailler sur un exécutable complet comme c'est le cas pour Ferdinand et les autres approches intra-tâche. Elle se base sur la notion d'équivalence dans le cache entre les allocations mémoires au niveau module et celles effectuées pour un exécutable complet. Cette équivalence est exploitée pour influencer l'éditeur de lien.

L'idée générale se résume par :

➢ étant donnée une liste de modules qui forment le programme temps-réel complet, on suppose que les dépendances cycliques d'appel existent uniquement entre les fonctions du même module et ne sont pas autorisées entre les modules. Ainsi le graphes de

9797

Figure 3.20 - (a)Graphe de dépendances inter-modulaires, (b) appel de procédures


dépendances qui représentent les appels inter-modulaires sont acycliques. Ils ressemblent au graphe de la figure 3.20(a).

➢ l'analyse du comportement du cache est effectuée d'une manière ascendante sur le graphe des dépendances des modules en partant des feuilles qui ne possèdent pas de dépendances pour remonter jusqu'à la racine. Cette analyse tient compte du nombre de remplacements qu'il y a eu dans le cache en dépliant les appels inter-modulaires.

➢ Les résultats de cette analyse sont conservateurs par rapport à une analyse sur un exécutable complet qui est en général plus précise.

La méthode fournit une analyse MUST est une analyse MAY intra- et inter- modulaire pour moduler le comportement du cache d'instructions LRU associatif de degré A.

L'analyse intra-module fournit les ensembles EXIT, MUST ou MAY ainsi que le nombre de remplacements qui ont eu lieu dans le cache suite à l'exécution de chaque procédure. L'ensemble EXIT MUST contient la liste des L-blocs qui seront dans le cache suite à l'exécution de la procédure tandis que l'ensemble EXIT MAY contient les L-blocs qui peuvent être dans le cache au point de sortie de la procédure.

Une fois l'analyse intra- modulaire terminée, une analyse inter-modulaire est effectuée pour combiner ces informations aux points d'appels du graphe de dépendances des modules. Ce processus est effectué d'une manière ascendante en partant des modules qui n'ont pas de dépendances vis-à-vis des autres modules pour modéliser d'une manière itérative le comportement du cache du module racine. Un module possède une liste de procédures et le comportement d'une procédure dans le cache peut être utilisé pour la procédure appelante au point de retour. Chaque procédure est analysée séparément. La méthode considère les deux contextes d'appels suivants :

➢ Appel local: c'est un appel entre les procédures d'un même module. La figure 3.20(b) montre un exemple d'appel local dans le module Mj où fooj() appelle la procédure foo'j().Supposons qu'on analyse le comportement du cache de fooj(). Durant l'exécution de fooj(), le contrôle est passé à foo'j() et les instructions de ce dernier sont cachées selon le flot de contrôle de la procédure. Dans ce cas, nous n'avons pas besoin des informations sur le comportement de foo'j() dans le cache. Ceci est dû au fait que les procédures du même module sont cachées d'une manière séquentielle ce qui fait que les instructions de l'une seront projetées dans des lignes différentes, du cache d'instruction, des autres et ainsi les instructions des procédures du même module ne sont pas concurrentes dans le cache.

➢ Appel externe : c'est un appel entre les procédures appartenant à des modules différents, comme l'appel de fooj() de Mj dans la procédure fooi() du module Mi dans l'exemple de la figure 3.20(b). Dans ce cas nous avons besoin des informations concernant le comportement de fooj() dans le cache au point de retour dans fooi(),

notamment le nombre de remplacements qui ont eu lieu dans le cache suite à l'exécution de fooj() et les L-blocs qui sont dans le cache au point de sortie de fooj().

9898


C'est ce qu'on appelle l'ensemble EXIT.

A la fin de l'analyse les instructions du programme peuvent être catégorisées (am, ah, nc) selon le tableau 3.1 pour prédire le WCET.

3.3.3. Techniques basées sur les arbres syntaxiquesCette classe de méthodes s'appuie sur la représentation du programme en arbre syntaxique

pour calculer récursivement son WCET. Elle a été initialement proposée par P. Pushner et C. Koza dans [30] et Shaw dans [31]. L'approche fournit un ensemble de formules (cf. tableau 3.2) nommées schéma temporel (timing schema). Ces formules permettent d'associer à chaque noeud de l'arbre, correspondant à une structure syntaxique du langage source, un WCET calculé en fonction des WCET des sous-arbres qui le composent (les fils de ce noeud). Ensuite, le WCET de chacun de ces fils est exprimé en fonction des WCET de ses fils et ainsi de suite pour atteindre les feuilles de l'arbre qui sont les blocs de base dont on suppose les WCET connus. On effectue ensuite un parcours ascendant de l'arbre (bottom-up) en partant des feuilles pour obtenir le WCET de la racine.

On distingue trois formules de calcul correspondant à trois types de structures syntaxiques. Le WCET d'une séquence est tout simplement la somme des WCET des structures qui la composent. Pour une structure de sélection, le WCET correspondant est le maximum des WCET des noeuds fils, ajouté au WCET de la condition. Enfin, pour les boucles, on associe à la structure les informations décrites au §3.1.4 et on énumère tous les chemins d'exécution possibles en appliquant récursivement les équations le long de toute la structure arborescente du programme. Par exemple, pour l'arbre syntaxique représenté dans la figure 3.5, où le nombre maximum d'itérations de la boucle est 4, on obtient le système d'équations suivant :

9999

Formules de calcul du WCET

S = S1; ... ; Sn WCET(S) = ∑i=1

n

WCET(Si )

S = if(test) then S1

else S2WCET(S) = WCET(Test)+ max(WCET(S1) + WCET(S2))

S = loop(test) S1WCET(S) = N × (WCET(test)+WCET(S1))+ WCET(test)où N est le nombre maximal d'itérations

S = f(exp1,..., expn) WCET(S) = ∑i=1

n

WCET(expi ) WCET(f)

S = bloc de base BBx WCET(S) = WCET du bloc de base BBx

Tableau 3.2 - Formules de calcul de WCET de [30]


WCET(main) = WCET(BB5) + WCET(LOOP) + WCET(BB7) +WCET(BB11)

WCET(LOOP) = 4 x (WCET(BB6) + WCET(SEQ1) )+ WCET(BB6)WCET(SEQ1) = WCET(BB8) + WCET(SEQ2) + WCET(BB9) + WCET(SEQ3) + WCET(BB10)WCET(SEQ2) = WCET(IF1) + WCET(BB4)WCET(SEQ3) = WCET(IF2) + WCET(BB15)WCET(IF1) = WCET(BB1) + (WCET(BB2) , WCET(BB3))WCET(IF2) = WCET(BB12) + max(WCET(BB13) , WCET(BB14))

On obtient ainsi un arbre temporel [46] qui contient les WCET calculés aux différents noeuds de l'arbre.

Pour prendre en compte les effets temporels (cache, pipeline) sur le calcul du WCET, l'ensemble de ces formules de calcul récursif du WCET doit être modifié. Une modification présentée dans [63], consiste à ne pas manipuler directement les WCET des structures de données mais des ensembles de WCTA (Worst Case Timing Abstraction). Les WCTA sont plus complexes que les temps bruts représentés par les WCET car ils combinent les représentations de l'occupation du pipeline et de l'état du cache.

Ils comportent ainsi deux ensembles – le premier contient les adresses des instructions dont les références causeront un hit ou un miss, dans le cache, en fonction du contenu du cache avant l'exécution du code, auquel est associé le WCTA. Le deuxième ensemble contient les adresses des instructions qui resteront dans le cache après l'exécution du code associé au WCTA.

Le tableau 3.3 présente l'adaptation du schéma temporel du tableau 3.2 aux WCTA. On définit deux opérateurs ensemblistes ( ⊕ et ∪ ) qui permettent le calcul des WCTA des structures de contrôle dans un contexte d'exécution et, à partir de ces WCTA, de calculer le WCET à la racine de l'arbre.

Pour illustrer le fonctionnement de ces opérateurs ensemblistes, prenons le cas du pipeline. Supposons deux sous-arbres, A et B dont les WCTA sont WA et WB ( figure 3.21). Le WCTA

100100

Formules de calcul du WCTA : W(S)S = S1;...;Sn W(S) =W(S1)⊕W(S2 )

S = if(test) then S1

else S2W(S)=W(Test)⊕W(S1 )∪ W(test)⊕W(S2 )

S = loop(test) S1 W(S) = [⊕i=1NW(test)⊕W(S1 )]⊕W(test)

S = f(exp1, ..., expn) W(S) = ⊕i=1N

W(exp i ) ⊕ WCET(f)

S = bloc de base BBx W(S) = WCET du bloc de base BBx

Tableau 3.3 - Extension du schéma temporel pour prendre en compte les caches et le pipeline


de la séquence S composée de A et B est W(S) = WA⊕WB. Chaque WCTA peut comporter plusieurs représentations différentes d'occupation du pipeline. Pour l'exemple de La figure 3.21, on suppose que A et B possèdent une seule représentation du pipeline.

L'opérateur⊕ sur les ensembles de représentation de pipeline est défini en utilisant l'opérateur⊕ de concaténation de deux représentations différentes de pipeline :

W A⊕W B={ wA⊕wB | wA∈W A ,wB∈W B }

[64] présente une autre méthode qui modifie les formules du tableau 3.2 pour tenir compte des effets du cache et du prédicteur de branchements. Elle utilise la représentation du programme en CFG et en arbre syntaxique. Le CFG est formé de blocs de base reliés par des flèches de deux types jmp ou seq. Seq implique que le bloc de base à exécuter après le bloc courant est le bloc suivant et jmp représente un branchement.

On associe à chaque boucle de l'arbre syntaxique un niveau noté par ln-level. Les boucles les plus externes (qui ne sont pas englobées par aucune autre boucle) on associe les ln-level [0], [1], etc. Les boucles immédiatement englobées par [0] sont les boucles [0.1], [0.2], etc. le niveau zéro d'emboîtement est représenté par une boucle fictive, dont le ln-level est [], qui englobe entièrement l'arbre syntaxique. Par exemple, la boucle dont le ln-level est [2.3.1] (appelée boucle [2.3.1]) est emboîtée dans les boucles [2.3], [2] et [] et englobe la boucle [2.3.1.1]. Une fonction Ψ est utilisée pour déterminer le niveau de boucle commun le plus bas entre deux ln-level : par exemple Ψ ([2.3.1],[2.3.4]=[2.3]).

Le comportement de chaque bloc de base dans le cache est étudié en associant à chaque L-bloc d'un bloc de base un niveau d'imbrication de boucle ln-level pour identifier à quel niveau de boucle il y a un conflit qui génère un miss dans le cache.

101101

Figure 3.21 - Concaténation ( ⊕ ) de deux représentations wA et wB du pipeline


Considérons l'exemple de la figure 3.22 qui montre deux L-blocs, L-blocβ

et L-blocα qui rentrent en conflit dans une ligne du cache. Ces deux L-blocs sont contenus dans des boucles qui possèdent des ln-level, [0.1] et [0.2.0.4] respectivement. Comme Ψ([0.1],[0.2.0.4]) = [0] donc le ln-level de L-blocα est [0] ce qui veut dire qu'à chaque exécution de la boucle [0] L-blocα génère un miss.

Comme un bloc de base peut contenir plusieurs L-blocs, le résultat de cette première étape fournit un ensemble de couples <L-bloc, ln-level> pour chaque bloc de base. Cet ensemble est noté par LB-est (L-blocs behavior estimation)

Ensuite, on analyse le mécanisme du prédicteur de branchement. Cette étape est nécessaire pour améliorer l'estimation du WCET quand on rencontre une instruction de branchement notée par CT-instruction (Control Transfer Instruction). Quand une CT-instruction est exécutée, une rupture du flot d'exécution peut se produire dans le pipeline car le processeur ne connaît pas l'instruction à exécuter avant la fin de l'exécution de la CT-instruction. Cette analyse permet de prédire si une CT-instruction est prise ou non. Ces informations sont stockées dans une structure appelée BHS (branch history storage). Comme le bloc de base contient au plus une CT-instruction, la prédiction statique de branchement consiste à estimer quelles sont les CT-instructions qui seront mal prédites. Ces estimations dépendent des ln-level. En considérant deux possibilités pour une CT-intruction (jmp ou seq), chaque CT-instruction, par suite chaque bloc de base, est associée à deux éventuels résultats. Pour caractériser les deux possibilités, le résultat de cette étape fournit pour chaque bloc de base BB, l'ensemble suivant CTI-est = { <BBn

seq, ln-level>, <BBnjmp, ln-level>}

La dernière étape consiste à analyser le comportement des instructions dans le pipeline. Cette étape est paramétrée par : i) la description du bloc de base (liste de ses instructions), ii) les informations sur la décomposition de ces instructions dans les étages du pipeline (ressources utilisées, temps d'exécution, etc) et iii) les résultats de la simulation du cache d'instructions ainsi que les résultats de l'analyse du prédicteur de branchement CTI-est. Ainsi la simulation du pipeline fournit le WCET du bloc de base en considérant un ln-level et le

102102

Figure 3.22 - Exemple


branchement x du BB exécuté. Ce WCET est un ensemble défini comme suit :

WCET_BBx = {<wceti, lnlevi> / pour tous les ln-level possibles de BB}

Comme chaque bloc de base contient deux branchements possibles seq ou jmp, on associe à chaque bloc de base deux WCET, WCET_BBjmp et WCET_BBseq pour tenir compte des deux prédictions possibles. Ces deux entités sont égales quand un bloc de base a un seul branchement possible.

Ayant calculé les WCET des blocs de base, l'arbre syntaxique est parcouru de bas en haut pour calculer les WCET des branches et générer le WCET de la racine. Les équations de calcul du WCET des différentes structures de l'arbre fournies initialement par Puschner et Koza (cf. tableau 3.2) sont modifiées pour tenir compte des WCET des blocs de base calculés par cette méthode comme le montre le tableau 3.4.

Le calcul du WCET d'une structure du langage est pondéré par son ln-level. Ainsi, ce paramètre est ajouté aux équations initiales. Les structures de données sauvegardées durant les différentes étapes de l'analyse nécessitent la définition de nouveaux opérateurs pour effectuer l'analyse temporelle. Les opérateurs ⊕L et ⊗L remplacent respectivement les opérateurs + et × du jeu de formules du tableau 3.2.

L'opérateur ⊕L est l'opérateur d'addition de WCET. Deux WCET sont additionnés par ⊕L

103103

Structure S WCET(S,L)S1;...;Sn WCET S , L = WCET S 1 , L1 ⊕

L...⊕L WCET S n , LnWCET seqS ,L = WCET S1, L1 ⊕

L ...⊕L WCET S n−1 , Ln−1 ⊕L WCET seqS n , Ln

WCET jmpS , L =WCET S 1, L1 ⊕L ...⊕L WCET S n−1 , Ln−1 ⊕

L WCET jmpS n , Ln

if(test)then S1 else S2

WCET S ,L = max (WCET seq test , L ⊕LWCET S 1, L ,WCET jmptest , L⊕L WCET S 2, L )

for(;test;inc) S1

WCET S , L =maxiter ⊗L ( WCET jmptest , L⊕L WCET S1, L⊕L WCET inc ,L )⊕L WCET seq test , L ⊕L WCET exit ,L

bloc de base BBx

WCET BB ,L = WCET _ BB?

WCET seqBB , L =WCET _ BBseq

WCET jmpBB , L = WCET _ BB jmp

WCET_BB? Est le WCET d'un bloc de base BB qui a une seule sortie (seq ou jmp)maxiter est le nombre maximal d'itérations de la boucle

Tableau 3.4 - Calcul du WCET d'une structure sachant son niveau d'imbrication dans une boucle


en réalisant l'union des deux ensembles les représentant puis en regroupant les éléments de l'ensemble dont les ln-levels sont égaux, enfin en regroupant les éléments dont le ln-level est plus petit ou égal à L. L'opérateur ⊗L est l'opérateur de multiplication d'un WCET par un scalaire. Il applique le coefficient multiplicateur à tous les éléments de l'ensemble représentant un WCET dont le ln-level est plus petit ou égal à L et les regroupe.

Un exemple de l'application de ces deux opérateurs est le suivant :

{< ,[ ]>,< ,[0]>}⊕0 {< ,[]>,< ,[0.0.2]>}={<,[]>,< ,[0]>}M⊗0{< ,[]>,< ,[0]>,< ,[0.0.2]>}={< ,[]>,< M×,[0]>}

Lors du calcul des WCET des boucles et des structures conditionnelles, deux types d'exécution (seq et jmp) du bloc test doivent être considérés. Le sous-arbre test de ces structures peut être soit un bloc de base soit une séquence de sous-arbres. Dans ce deuxième cas, c'est le bloc de base le plus à droite qui réalise le test (cf. figure 3.23). C'est pourquoi les formules de calcul de WCET des blocs de base et des séquences sont différenciées WCET seq et WCET jmp .

3.3.4. Analyse Symbolique du WCET De nombreuses méthodes d'obtention de WCET par analyse statique calculent le WCET

sous la forme d'une constante, indépendante des entrées du programme analysé. Cette approche, bien que sûre, peut se révéler très pessimiste, dans les cas où le WCET d'un code est très variable selon le contexte.

Définition 12 (Contexte) – Un contexte est défini par un ensemble de données en entrée et / ou un sous-ensemble possible des états des processus du système.

Par exemple, une fonction peut avoir des temps d'exécution différents selon ses paramètres d'entrée [45], la valeur de certaines variables locales (indices de boucle englobantes), la configuration globale du système (par exemple, il a été observé lors de l'analyse statique de WCET du noyau du système RTEMS que le WCET de certains appels dépendent du nombre

104104

Figure 3.23 - Sous arbre test d'une structure conditionnelle


de tâches [65]), ou encore du type du matériel cible. Le WCET est exprimé par une expression qui ne sera évaluée que lorsque toutes les variables la composant seront connues ou évaluées par un intervalle de valeurs.

[66] propose une approche basée sur la représentation d'un programme en arbre de portée pour le calcul du WCET sous forme d'une expression symbolique. Avant de décrire la méthode nous commençons par introduire la structure d'un arbre de portée.

L'arbre de portée [66] est une généralisation de la représentation classique d'un programme en arbre syntaxique. Elle est très utile pour l'analyse symbolique du WCET. Elle représente la structure de la syntaxe du code analysé, le WCET des blocs de base, les informations fournies par l'utilisateur et le schéma temporel – le schéma temporel est un ensemble de contraintes traduisant toutes ces données en un système qui, une fois résolu, fournit le WCET.

Un arbre syntaxique peut être vu comme un ensemble de noeuds et d'arcs ou comme une hiérarchie de sous arbres. Cette deuxième vue est la plus compatible avec la représentation en arbre de portée. Une portée représente un sous-arbre d'un arbre syntaxique, son comportement et sa valeur (i.e., le WCET). Formellement une portée S est définie comme un ensemble constitué d'une expression symbolique du WCET ωS, d'une expression de la fréquence d'exécution φS

R, d'un ensemble des variables définies DS et d'un ensemble des variables utilisées US.

L'expression ω d'une portée S décrit comment on calcule le WCET de S en fonction du WCET de ses fils, et combien de fois ses fils sont exécutés. Les variables définies de l'ensemble DS peuvent être toutes utilisées dans l'expression ωS. Ainsi le WCET obtenu peut être paramétrique.

L'expression de la fréquence d'exécution exprime la fréquence d'exécution d'une portée par rapport à une autre portée employant un nombre de variables de portée. Par exemple φS

R

représente le nombre d'exécutions d'une portée S pour chaque exécution d'une portée englobante R (appelée portée de référence).

Un programme ou une section de programme à analyser peut être vu comme une hiérarchie de portées : arbre de portée. Un arbre de portée est défini par sa portée racine et uniquement les variables définies par cette portée peuvent apparaître à la fin dans l'expression du WCET de cet arbre. Il peut arriver qu'une partie de l'arbre de portée soit inconnue à la construction de cet arbre. C'est le cas d'un appel de fonction pour lequel le code et l'arbre de portée ne sont pas fournis (e.g., les fonctions des librairies). Ainsi l'appel de fonction peut être représenté par une portée sans fils. Ces portées peuvent déclarer des variables et leur attribuer des valeurs : les paramètres de la fonction appelée. Pour évaluer le WCET d'un programme contenant des appels à de telles fonctions, une représentation de ces fonctions doit être fournie soit sous forme d'un arbre de portée, soit sous forme d'une expression ω représentant le WCET de cette fonction ; ω peut être paramétrée par les paramètres de la fonction.

Le type d'une portée est défini par ses expressions ω et φ. Pour représenter l'arbre

105105


syntaxique et le schéma temporel, on fournit trois types d'expressions ω ( ωS+

pour représenter les boucles et les séquences ; ωS

◊ pour représenter les conditions ; ωS

■ utilisé quand le bloc considéré est un bloc de base ou un sous-arbre vide) et deux types d'expressions φ ( φS

= qui indique que le nombre d'exécutions de la portée S est égale au nombre d'exécutions de la portée externe ; φS

× qui indique que le nombre d'exécutions de la portée S et égale au nombre d'exécutions de la portée externe multiplié par un certain nombre n).

La figure 3.24 montre la traduction de l'arbre syntaxique et du schéma temporel de la fonction impaire (figure 3.1) en un arbre de portée. Pour simplifier la représentation graphique, on peut omettre les expressions φS

= vu qu'il s'agit de l'expression par défaut. D'autre part, le tableau 3.5 montre les expressions de portée par défaut correspondant à chaque type de noeud.

Cet ensemble d'expressions est suffisant pour représenter un arbre syntaxique traditionnel en un arbre de portée. Mais on peut aussi ajouter de nouvelles expressions et des définitions de variables pour représenter des situations plus complexes [66].

Le WCET d'un bloc de base ωS■ peut être considéré comme une constante ou bien

106106

Figure 3.24 - Arbre Syntaxique et l'Arbre de Portée équivalent de la fonction impaire

Séquence

S: S0, ..., Sn

Boucle

S: While(T) do B

Condition

if() then T else F

bloc de Base

ωS=ω+

D S=D S

US = ∪i U S i

∀ i , φS i=φ=

ωS=ω+

D S=D S

U S=U T∪U B

φBS=φ×

φTS α =φB

S α α

ωS=ω◊

DS=D S

U S=U T∪U F

φTS=φ=

φFS=φ=

ωS=ω■

D S=D S

U S=Ø

Tableau 3.5 - Expressions par défaut pour chaque type de portée


représenté sous forme d'une expression tenant compte des composants matériels (cache, pipeline, prédiction de branchement). Cette approche extrait les portées à partir du code source en utilisant les annotations fournies par l'utilisateur. Quand aucune expression particulière n'est fournie pour spécifier une portée, les expressions par défaut ω et φ sont utilisées (tableau 3.5).

Dans la définition de φ, on a évoqué le fait que la fréquence d'exécution d'une portée S peut être définie relativement par rapport à une portée externe R qui n'est pas un parent direct. Pour prendre en considération cette dépendance, l'arbre de portée doit être modifié avant l'évaluation du WCET. La portée S est déplacée pour être un fils direct de R. Autrement dit, on enlève l'arc de l'arbre de portée allant du parent direct P de S vers S en mettant φS

P à zéro, et on crée une copie de S appelée S' avec un arc liant S' à R et φS '

R sera calculée. Cette dépendance entre deux portées est due à une exclusion mutuelle ou à une dépendance de donnée. Notons que pour certains cas d'exclusion mutuelle, il est impossible de déplacer les portées.

L'évaluation du WCET se fait en parcourant l'arbre de portée modifié de bas en haut pour extraire un système d'équations. Ce système relie les expressions ω et φ des différentes portées de l'arbre. Ainsi l'expression ω de la racine est exprimée en fonction des expressions ω et φ de ses fils. La solution ωracine peut contenir des variables définies par la portée racine.

Une autre analyse symbolique présentée par [67], [68], [69], [70] et [71] propose une approche en deux niveaux (processus, système) pour l'évaluation des propriétés non-fonctionnelles d'un système donné, en particulier le temps d'exécution et la consommation d'énergie, par des intervalles appelés intervalles de comportement. Au niveau du processus, l'analyse de ces intervalles de comportement est effectuée pour chaque processus séparément. Vu que ces propriétés peuvent dépendre de l'architecture cible, l'implantation doit être considérée à ce niveau. Au niveau système, la première étape consiste à construire un modèle homogène du système complet. On commence par construire une représentation intermédiaire appelée modèle SPI (System Property Intervals) qui représente le système comme un ensemble de processus concurrents communiquant via des canaux unidirectionnels ordonnés FIFO (pile ou registres). Les propriétés des processus et des canaux sont capturées par des paramètres qui sont annotés aux éléments correspondants. Ceci permet l'adaptation du modèle pour inclure toutes les informations requises afin d'établir une optimisation ou de considérer le coût d'exécution (taux de données communiquées, temps d'exécution ou consommation d'énergie). Les valeurs de ces paramètres sont les intervalles de comportement obtenus par l'analyse au niveau processus. Le modèle SPI supporte explicitement la spécification du comportement dépendant du contexte en terme de modes. Ce modèle servira de point d'entrée pour l'analyse du système.

Cette approche s'appuie sur la représentation du programme en arbre syntaxique et en graphe de flot de contrôle. L'arbre syntaxique est choisi car il contient la hiérarchie des structures de contrôle, et le graphe de flot de contrôle pour déterminer la dépendance de données entre ces structures [68]. Le concept de bloc de base est étendu au segment de

107107


processus PrS (Process Segment).

Définition 13 (Process Segment PrS) – défini comme une séquence de blocs de base ayant une seule entrée est une seule sortie, ceci rejoint la définition des blocs de base.

On distingue deux types de PrS : Les SFP-PrS (Single Feasable Path Process Segment) qui ont des structures de contrôle indépendantes du contexte, les MFP-PrS (Multiple Feasable Path Process Segment) constitués d'une structure dépendante du contexte. Un MFP-PrS fournit une seule séquence de blocs de base pour chaque contexte qui sera traitée comme un SFP-PrS. Ces séquences sont appelées chemins dépendant du contexte CDP (Context Dependant Paths).

Contrairement aux approches usuelles, cette approche calcule le temps d'exécution pour un PrS. Ainsi les comportements du cache et du pipeline entre les blocs de base d'une telle séquence sont modélisés exactement sans avoir à faire des suppositions pessimistes, les suppositions sont faites uniquement pour le premier bloc de base [68]. L'analyse est effectuée en trois étapes :

➢ L'identification des chemins d'exécution possibles, la classification de ces chemins en SFP-PrS et MFP-PrS et la transformation de ces derniers en CDP.

➢ La détermination des intervalles du coût d'exécution pour chaque Segment. Là on peut utiliser l'approche ICA (Instruction Cost Addition) ou l'approche PSS (Process Segment Simulation). ICA est une généralisation de l'approche [60] pour calculer le coût d'exécution d'un PrS. Le PrS doit seulement être exécuté sur un système hôte pour déduire le nombre d'exécution de ses blocs de base. Cette approche fournit le nombre total d'exécution d'un PrS. PSS consiste à simuler le coût d'exécution d'un SFP-PrS avec un simulateur de processeur pour choisir le chemin d'exécution correct et exploiter la séquence de blocs de base sans interaction avec le concepteur.

➢ La combinaison des coûts d'exécution des segments de processus en utilisant les intervalles de nombre d'exécutions obtenus par une approche ILP. Le coût d'exécution d'un processus est un intervalle déduit de la multiplication des intervalles de coût d'exécution des SFP-PrS par l'intervalle de leur nombre d'exécutions. Vu que le problème ILP traite le coût d'exécution des SFP-PrS comme celui des blocs de base, il doit être résolu uniquement pour les structures de contrôle dépendantes des données en entrée, entre les SFP-PrS. On n'a pas besoin de définir des équations ILP pour obtenir les coûts d'exécution des CDP-PrS car ces intervalles sont calculés par simulation.

Cette approche est implantée d'une manière modulaire dans l'outil SYMTA (SYMbolic Timing Analysis) pour qu'elle soit flexible et adaptable quel que soit le langage en entrée, l'architecture cible et la méthode d'évaluation des coûts d'exécution.

3.4. ANALYSES DES SYSTÈMES MULTI-TÂCHES Les approches qui analysent les systèmes multi-tâches sont rares et modélisent

108108


généralement le contexte d'exécution d'une tâche pour calculer son temps de réponse pire cas WCRT (pour Worst Case Response Time).

Contrairement au WCET, qui est le temps d'exécution pire cas d'une tâche qui s'exécute sans préemption, le WCRT est le temps d'exécution pire cas d'une tâche entre sa date d'activation et sa date d'achèvement en tenant compte de tous les retards possibles dûs aux préemptions par des tâches plus prioritaires, aux interruptions systèmes, etc. Le WCRT n'est pas utilisé pour les systèmes temps-réel stricts dans la vérification des contraintes temporelles pour deux raisons : 1) ces systèmes n'autorisent pas la préemption entre les tâches, 2) si la préemption n'est pas autorisée le WCRT serait égale au WCET.

Ces approches sont plus orientées vers les applications temps-réel souples et se limitent à la modélisation des processeurs simples. Pour réaliser cet objectif, elles considèrent un ordonnancement de tâches qui autorise la préemption.

3.4.1. Analyse Edgar & Burns[72] propose une approche qui échantillonne le temps d'exécution d'une tâche pour

construire une estimation de son WCET. Cette valeur du WCET dépend soit de la valeur du taux de confiance susceptible de le produire, soit du temps assigné à chaque tâche pour terminer son exécution. On suppose que le calcul du WCET de chaque tâche considérée individuellement est très utile. Mais comme dans un système temps-réel, il n'est pas suffisant d'être sûr que chaque tâche respecte son échéance mais il faut garantir un bon fonctionnement du système entier. En d'autre terme, il faut garantir un bon ordonnancement des tâches de ce système.

L'approche considère un système temps-réel de n tâches {T1, ..., Tn}. Chaque tâche est caractérisée par les paramètres suivants T (D, max, θ, ω, ε) où D est l'échéance, max est la valeur maximale des temps d'exécution de la tâche T, θ une fonction statistique représentant le WCET de T qui sera utilisée pour le calcul du WCET, ω le WCET de T fourni par cette approche et ε est le taux de confiance pour lequel on obtient cette valeur de ω.

Le problème de cette approche se résume au fait de pouvoir calculer le WCET de chaque tâche avec un taux de confiance approprié pour lesquels on garantit que le système en entier garantit son échéance.

Le processus est constitué de trois étapes appliquées dans l'ordre suivant :

➢ Considérer des échantillons de données pour chaque tâche et fournir une estimation du WCET avec un taux de confiance.

➢ Construire un ordonnancement du système en se servant de ces WCET. Si le test d'ordonnançabilité indique que le système est non ordonnançable, il faut recalculer les WCET pour des taux de confiances plus petits.

➢ Se servir des échantillons de données et de l'ordonnancement pour calculer le taux de confiance total du système ξ pour lequel on garantit que le système respecte don

109109


échéance.

Quand les échantillons de données sont analysés, on calcule les temps d'exécution possibles pour chaque tâche avec leur taux de confiances qui garantissent leur obtention. Pour le moment, la seule garantie est que le WCET d'une tâche Ti est au moins égal à maxi, la valeur maximale du temps d'exécution calculée pour cette tâche. Il faut donc construire une estimation du WCET pour laquelle la valeur maxi sera la borne inférieure. Le modèle de la distribution de Gumbel est utilisé (formule 3.3) pour générer un modèle du coût d'exécution pour un échantillon de donnée (x1, ..., xn).

La valeur estimée du WCET θ est donnée par la formule 3.4

Pour terminer, la relation entre le WCET et son taux de confiance est donnée par la formule 3.5

La troisième étape de cette méthode n'est pas discutée dans ce paragraphe, [72] fournit plus de détails là-dessus. Le taux de confiance du système complet ξ est égal au produit des taux

de confiances des tâches du système, ∏i=1

n

i , si on ignore les interférences entre les tâches.

Par exemple si chaque tâche à un degré de confiance égale à 1 – 10k le taux de confiance du système sera (1 – 10k)n. Cette valeur est très pessimiste et vu que le WCET peut être surestimé et jamais sous-estimé, l'approche permet de garantir dans un tel cas un taux de confiance égal à 1 – 10k.

Cette approche est basée sur les échantillons des données en entrée qui sont transformés en modèles pour déterminer les WCET des tâches avec des degrés de confiance pour chaque tâche et pour le système en entier, qui garantissent que toutes les tâches se terminent avant leurs échéances. Ceci n'est pas toujours possible en pratique car la complexité des

110110

G0, , x = exp −exp −x − / , x

= x − ,x =1n∑i=1

n

x i , ≃ 0.5772

= 6 , 2= 1

n−1∑i=1

n

x i−x2

Formule 3.3 - distribution de Gumbel

ix =G xmax i−G max i

1−G max i, G = G0, ,

Formule 3.4 - estimation statistique du WCET

G0, , maxi = 1−i

Formule 3.5 - relation entre ω et ε


programmes à analyser conduit à un nombre extrêmement grand d'échantillons possibles de données en entrée. Cependant, cette solution peut être retenue pour des programmes simples, admettant peu de jeux de donnée en entrée et pour lesquels le domaine de variation des entrées est limité. De plus la méthode est testée sur un ensemble restreint de tâches. Même avec des échantillons de données réels ces simulations ne prouvent pas que cette méthode peut être appliquée aux systèmes plus complexes qui contiennent un nombre plus grand de tâches et dont le domaine des données en entrée en parfois très large. Les WCET sont calculés avec des degrés de confiance que la tâche termine son exécution avant son échéance. Or ces degrés de confiance ne sont pas suffisants pour les systèmes temps-réel critiques pour lesquels nous devons garantir cette condition. Ce qui rend cette méthode plutôt applicable pour les systèmes temps-réel souples.

3.4.2. Analyse Diaz, Garcia & al[73] décrit une approche par analyse stochastique des systèmes temps-réel pour lesquels les

priorités des tâches sont connues. Cette méthode calcule le WCRT de chaque tâche du système qui permettra, par la suite, de fournir une probabilité de dépassement de l'échéance pour chaque tâche même pour des systèmes ayant des taux d'utilisation supérieur à 1. Cette méthode permet d'analyser les ordonnancements à priorités fixes (comme le Rate Monotonic) ou à priorités dynamiques (comme le Earliest Deadline First). Elle peut aussi tenir compte des échéances relatives arbitraires ainsi que d'une distribution du temps d'exécution au lieu d'une valeur exacte pour ces deux entités.

L'analyse se base sur la modélisation de Markov des processus qui permet de raisonner sur les probabilités du comportement du système. Elle fournit une solution analytique et une autre numérique pour calculer les probabilités de dépassement de l'échéance de chaque tâche en calculant la fonction de probabilité complète du WCRT de chaque tâche notée par PF (Probability function).

Le système est modélisé comme un ensemble de N tâches périodiques indépendantes, caractérisées par une période, une échéance relative, une phase initiale et un temps d'exécution. Chaque tâche Ti génère plusieurs instances dans l'ordonnancement notées par Ti,j. La politique d'ordonnancement utilisée attribut à chaque instance Ti,j une priorité et ordonnance les instances des tâches suivant les valeurs de leurs priorités. Le WCRT de chaque instance Ti,j est une variable aléatoire qui peut avoir des valeurs différentes pour des probabilités différentes.

La fonction de probabilité PF est calculée pour chaque instance Ti,j d'une tâche. Ainsi le PF du WCRT de la tâche Ti sera la valeur moyenne des PF de ses instances.

Les informations statistiques fournies par cette analyse peuvent être combinées aux échéances pour calculer la probabilité de dépassement de l'échéance pour chaque tâche. Si cette probabilité est nulle, alors la date d'échéance est garantie. Ainsi cette étude inclut l'analyse classique du WCRT mais elle permet aussi d'analyser les systèmes ayant des taux

111111


d'utilisation du processeur supérieurs à 1.

Cette méthode est surtout utile pour les systèmes temps-réels souples mais elle peut aussi être utile pour des systèmes temps-réels durs probabilistes où une probabilité de garantie de sa faisabilité est acceptée si sa valeur est proche de 100%.

3.4.3. Analyse Tan & Mooney[74] et [75] proposent une approche pour l'analyse temporelle des systèmes temps-réel

préemptifs multi-tâches. L'approche se concentre sur le rechargement du cache suite aux préemptions. Le WCRT de chaque tâche est estimé en tenant compte du rechargement du cache. Après avoir obtenu le WCRT de chaque tâche, on peut analyser l'ordonnançabilité du système. Elle cible les systèmes temps-réel mono-processeur, multi-tâches préemptifs avec mémoire cache et utilise aussi un algorithme d'ordonnancement à priorité fixe tel que le RMA (Rate Monotonic Algorithm).

On considère un système de n tâches représentées par T0 , T1 , ......., Tn-1. Chaque tâche Ti

possède une priorité fixe pi. Les tâches sont ordonnées dans l’ordre descendant de leurs priorités p0 < p1 < .............< pn-1. Si pa< pb, Ta a une priorité plus grande que Tb. Les tâches s’exécutent périodiquement. Chaque tâche possède un période Pi. Ti arrive au début de sa période et doit être complétée avant la fin de sa période. Le WCET de Ti est noté par Ci, estimé avec un outil d’analyse du WCET existants SYMTA [67]. Ti,j représente la jième

exécution de la tâche Ti. Le WCET d’une tâche est le temps d’exécution dans le cas pire sans interruption, ni préemption. Le WCRT d’une tâche est le temps mis par la tâche depuis le début jusqu’à la fin de son exécution dans le cas pire. On note le WCRT par Ri.

Dans un système multi-tâches préemptif, une tâche ayant une priorité réduite peut être préemptée par une tâche de priorité plus grande. Durant la préemption, la tâche qui préempte peut évacuer des lignes de cache utilisées par la tâche préemptée. Quand cette dernière reprend son exécution et désire accéder à ces lignes de cache, elle doit les recharger à partir de la mémoire principale. Ce rechargement dû aux évictions inter-tâche augmente le temps de réponse de la tâche préemptée.

Il faut tenir compte de deux types de préemptions : préemption directe et préemption indirecte.

112112

Figure 3.25 - Préemption directe et préemption indirecte


Pour mieux comprendre la différence, considérons un système de trois tâches T1, T2 et T3 [53, 75]. T1 est une application de contrôle d'un robot mobile (RM). Le robot met à jour son comportement toutes les 3.5 ms. La tâche T2 est invoquée toutes les 6.5ms pour analyser les images des obstacles détectés par le robot. La tâche T3 communique avec les autres robots toutes les 40ms. La figure 3.25 montre cet exemple où les trois tâches sont activées à la date t = 0. Cependant la tâche T3 ne peut s'exécuter qu'après l'exécution des instances T1.1 et T2.1 des tâches T1 et T2 respectivement. T3 peut être préemptée par T1 et T2. La préemption de T3.1 par T2.2 est directe tandis que la préemption de T3.1

par T1.3 est indirecte vue que cette préemption est engendrée par la préemption de T2.2 par T1.3. Notons que les rectangles noirs indiquent le coup de la préemption.

On effectue l’analyse du chemin pour la tâche préemptée et celle qui préempte pour analyser l'impact de la préemption sur le comportement de la tâche préemptée dans le cache. L’analyse du chemin est basée sur la représentation d'une tâche par un graphe de flot de contrôle ayant pour noeuds les SFP-PrS (Définition 13).

Définition 14 (Blocs utiles) – Un bloc mémoire est dit utile pour une tâche T préemptée par une tâche T ' si ce bloc est évacué du cache par la tâche T ' et doit être rechargé dans le cache par ce qu'il est utilisé par T après la préemption.

L'approche comporte quatre étapes:

1. On dérive la trace mémoire de chaque tâche avec la méthode de simulation de SYMTA. On suppose qu’il n’y a pas d’allocations dynamiques de données dans les tâches et que les adresses des structures de données sont fixes.

2. On effectue l’analyse intra-tâche de l’accès au cache pour la tâche préemptée pour trouver l’ensemble des blocs utiles accédés par cette tâche.

3. On utilise cet ensemble de blocs de la tâche préemptée pour effectuer l’analyse inter- tâche de l’éviction du cache avec les tâches qui la préemptent (c.à.d toutes les tâches de priorité supérieures). Une analyse du chemin est appliquée à chacune de ces tâches pour réduire l’estimation du chargement du cache à cette étape. Dans cette étape, on obtient un nombre estimé des lignes de cache qui nécessitent d’être rechargées après la préemption.

4. On effectue l’analyse du WCRT pour toutes les tâches en se basant sur les résultats de la troisième étape.

L'approche applique la formule récursive suivante pour évaluer le WCRT de chaque tâche.

Formule 3.6 - Calcul récursif du WCRT d'une tâche Ti

113113

Rik = C i ∑

j∈hp i ⌈ Rik−1

P j ⌉×C j C pre T i , T j 2Ccs


où hp(i) – ensemble des tâches de priorité supérieure à Ti ; Ccs – coût de changement de contexte (supposé constant); Ci , Cj – WCET(Ti) , WCET(Tj) respectivement; Pj – période de Tj.

L'itération de cette formule se termine s'il y a une convergence Rik = R i

k−1 pour une itération k. On compare ensuite la valeur Ri obtenue à l'échéance Di de la tâche. Si Ri < Di

donc les tâches sont ordonnançables sinon elles ne sont pas ordonnançables. On a besoin d'effectuer ce calcul pour toutes les tâches du système à l'exception de la tâche qui possède la plus grande priorité. Ainsi le problème a une complexité proportionnelle au nombre de tâches du système.

Le WCRT est calculé suite à une analyse intra- et inter- tâche du cache d'instructions qui exigent le calcul d'une liste d'ensembles de L-blocs pour chaque instance des tâches dans l'ordonnancement. Ces ensembles sont utilisés dans la phase finale pour le calcul du WCRT d'une manière itérative. Cette méthode est testée sur des configurations simples de tâches qui 1) ne représentent pas les caractéristiques d'une application temps-réel complète et 2) ne fournissent aucune preuve que cette méthode peut être appliquée aux systèmes réels plus complexes vu la complexité du calcul effectué. Cette approche est applicable pour des caches d'instructions à accès direct ou associatif, mais pour l'appliquer aux caches de données les références lecture / écriture doivent être statiques pour connaître à l'avance leurs adresses. La connaissance de l'adresse des instructions et des données est une hypothèse nécessaire pour l'application de cette approche.

3.4.4. Analyse Staschulat & Ernst[76] propose des résultats expérimentaux pour quantifier l'impact du cache sur le temps

d'exécution des tâches d'un système temps-réel en considérant des ordonnancements préemptifs de ces tâches. Le WCRT de chaque tâche est mesuré pour effectuer une comparaison avec les autres approches.

Une tâche est représentée par un graphe de flot de contrôle. Cette approche calcule le nombre de défauts dans le cache induits par les préemptions inter-tâche. Elle calcule le nombre de blocs utiles du cache pour un nombre donné de préemptions d'une tâche T par d'autres tâches du système sans additionner le nombre de blocs utiles pour chaque préemption. Ainsi, cette approche permet d'optimiser le nombre de miss dans le cache induit par les préemptions.

La figure 3.26 montre l'exemple d'un CFG de 4 noeuds préempté avant et après l'exécution du bloc de base 2. Le noeud 1 charge dans le cache les blocs m1 et m2 qui seront utiles pour l'exécution du noeud 4. Si on applique une approche conservatrice qui calcule le nombre de défauts dans le cache induits par les préemptions, le nombre de défauts pour cet exemple sera égal à 4, deux défauts pour chaque préemption de la tâche. Tandis que l'approche présentée dans [76] compte un nombre de défauts égal à 2 pour les 2 préemptions car les blocs m1 et m2 sont

114114


uniquement utilisés au niveau du noeud 4.

Considérons deux processus p1 et p2, tels que p2 possède une priorité supérieure à celle de p1, ainsi l'exécution de ce dernier peut être préemptée par p2. Le calcul du WCRT de p1 suivant les approches conservatrices, t anl

p1 , est décrit par la formule 3.7.

où t corep1 t core

p2 est le temps d'exécution de p1 respectivement p2 mesurés sans préemption ; k le nombre de préemptions de p1 par p2 et twcpi

p1 p 2 est le temps de retard induit par la préemption de p1 par p2 et qui représente la pénalité des défauts dans le cache induite par le remplacement de tous les blocs utiles pour l'exécution de p1.

Pour tenir compte des exécutions successives de p2 qui ne nécessitent pas le rechargement dans le cache des blocs utiles comme le montre l'exemple de la figure 3.26, la nouvelle estimation du WCRT du processus p1, t sim

p1 devient:

où t sim , xp1 est le temps d'exécution du processus p1 sans préemption en tenant compte du

comportement du rechargement des blocs utiles dans le cache quand c'est nécessaire et t sim , ip2

est le temps d'exécution de la iéme activation du processus p2 . Les valeurs de ces variables sont

115115

Figure 3.26 - Scénario de Préemption

Formule 3.7 - estimation conservatrice du WCRT.

t simp1 =∑

i=1

k

tsim ,ip2 t sim , x

P1

Formule 3.8 - Estimation améliorée du WCRT

t anlp1 =t core

p1 k×tcorep2 k×t wcpi

p1 p2


fournies par simulation.

Cette méthode analyse le comportement du cache pour un ordonnancement statique des tâches dans un contexte multi-tâches qui autorise la préemption pour calculer une estimation du WCRT de chaque tâche. Ils mènent des expérimentations pour quantifier l'effet du cache et utilise le WCRT pour la comparaison des résultats.

L'exécution de chaque processus est simulée en supposant un état vide du cache au point d'entrée pour fournir des résultats sûrs. Ensuite, le WCRT est calculé pour n préemptions du processus. Pour réduire la complexité du calcul, on fait la supposition non-réalisable et impraticable que la préemption ait lieu aux bornes des blocs de base et ne peut jamais se produire dans le corps d'un bloc de base. Ainsi, le WCRT est calculé en ignorant l'effet du chevauchement des blocs de base. Le WCRT calculé est une valeur très approximative si on considère des pipelines modernes est des processeurs superscalaires. De plus, cette méthode est testée sur des configurations simples de tâches (deux tâches) qui 1) ne représentent pas les caractéristiques d'une application temps réel complète et 2) ne fournissent aucune preuve que cette méthode peut être appliquée aux systèmes réels plus complexes.

4. CONCLUSION

Ce chapitre fournit un état de l'art qui expose des différentes techniques de calcul du WCET. Nous nous intéressons dans la suite aux méthodes de calcul du WCET par analyse statique et nous utiliserons la représentation des tâches en graphe de flot de contrôle.

Les méthodes multi-tâches présentées dans ce chapitre calculent le WCRT des tâches de l'application et non le WCET. Elles sont plus orientées vers les applications temps-réel souples et se limitent à la modélisation des processeurs simples. De plus, ces méthodes ont été testées sur des configurations simples de tâches qui ne représentent pas des caractéristiques propres aux application temps-réelles. Donc elles semblent difficilement applicables aux systèmes réels beaucoup plus complexes.

Nous proposerons dans le chapitre suivant une nouvelle approche d'analyse statique multi-tâches qui permet d'optimiser l'estimation du WCET en analysant un ordonnancement statique des tâches et en modélisant le comportement du cache intra- et inter-tâches.

Cette nouvelle méthode permet de remplacer les hypothèses conservatrices qui supposent un état du cache vide avant l'exécution de chaque tâche par un état bien défini construit à partir des traces laissées par l'exécution des tâches qui ont précédé l'exécution de chaque tâche dans l'ordonnancement de départ. Ainsi la nouvelle estimation du WCET d'une tâche sera au pire égale à l'estimation initiale.

116116

CHAPITRE 4

ANALYSE D'UNE APPLICATION MULTI-TÂCHES

La plupart des méthodes d'évaluation du WCET par analyse statique (chapitre 3 § 3.3) calculent le WCET d'une tâche en considérant un état vide ou indéfini du matériel notamment du cache d'instruction assurant ainsi une surestimation du WCET qui garantit que le WCET estimé est supérieur ou égal au WCET réel.

Bien que ces méthodes produisent des approximations sûres sous réserve de certaines hypothèses sur le processeur, elles ignorent plusieurs facteurs des systèmes temps-réel multi-tâches, essentiellement l'enchaînement des tâches, qui affectent naturellement la précision du WCET estimé. Plusieurs techniques modélisent le comportement du cache intra-tâche (chapitre 3 § 3.4) et rares sont celles qui traitent l'état du cache inter-tâche.

Dans ce chapitre, nous présentons une nouvelle approche qui analyse le comportement du cache intra- et inter-tâches pour optimiser la valeur du WCET estimé en identifiant des succès d'accès au cache induits par l'enchaînement des tâches qui ont été considérés comme des défauts par les approches conservatrices.

1. DÉFINITION DU PROBLÈME

La plupart des méthodes d'analyse statique calculent le WCET d'une tâche en considérant des hypothèses conservatrices sur l'état du système notamment sur le comportement du cache et du pipeline.

L'état de ces composants matériels affecte énormément l'estimation du WCET. Nous proposons une solution [77] qui permet de réduire le pessimisme des analyses intra-tâche en étudiant l'ordonnancement des tâches du système pour modéliser le comportement du cache entre les tâches. Nous nous intéressons essentiellement au cache d'instruction vu que le cache de données génère plus de pessimisme et est généralement géré par des contrôles directs du programme [78].

Cependant l'approche peut être adaptée pour modéliser le comportement des composants matériels dont l'état dépend de l'ordre d'exécution des tâches comme le cache de données et le

117117

Chapitre 4 - Analyse d'une application multi-tâches 1.Définition du problème

prédicteur de branchements.

1.1. CONTEXTE

Nous considérons un système temps-réel strict de t tâches non préemptives notées par T1,T2, ... Tt. Chaque tâche est caractérisée par une période P, un temps d'exécution C et une date d'échéance D. D est fixée à la fin de la période P et C est le temps d'exécution pire cas qui peut être calculé par n'importe quelle analyse statique intra-tâche (cf chapitre 3 §3.3). Une tâche est donc caractérisée par le triplet (P, C, D).

Nous représentons une tâche par un graphe de flot de contrôle dont les noeuds sont les blocs de base et les arcs représentent les dépendances de contrôle. Les blocs de base du CFG d'une tâche Ti sont représentés comme étant une collection BBT i

={ B0, ... , Bm} . Nous utilisons la répartition d'un bloc de base en L-blocs pour la modélisation du comportement du cache. Ainsi un bloc de base est lui aussi une collection de L-blocs représentée par Gen [Bi ]={ Bi ,0 , ... , Bi , r } .

L'ensemble des L-blocs d'une tâche Ti étant l'union des Gen de ses blocs de base est représenté par LT i

=∪Gen[B j] , B j ∈ BBT i. Nous utilisons LB=∪LT i

, i = {0, ... ,t } pour représenter l'ensemble de tous les L-blocs des tâches de l'application. Cet ensemble est utilisé par l'analyse inter-tâches.

Nous analysons un ordonnancement statique des tâches du système. Cet ordonnancement produit une table contenant l'ordre et la date d'activation des tâches. L'ordonnancement est statique donc il est connu avant le lancement du système. Il est constitué d'une séquence de tâches qui forment le corps de la boucle principale de l'application appelée aussi cycle global. Cette boucle s'exécute indéfiniment tant que le système tourne, donc le cycle global se répète durant le fonctionnement du système. Le cycle global est divisé en sc sous-cycles, où un sous-cycle a une durée égale à la plus petite période des tâches.

La figure 4.1 montre l'ordonnancement de 6 tâches T1(4,1,4), T2(8,1,8), T3(16,1,16), T4(16,1,16), T5(16,1,16), T6(16,1,16). Le cycle global a une durée de 16 unités temps (ut). La plus petite période étant de 4 ut, le

118118

Figure 4.1 - Exemple d'un ordonnancement statique

Chapitre 4- Analyse d'une application multi-tâches 1.Définition du problème

cycle global est ainsi réparti en 4 sous-cycles de 4 ut chacun.Dans un ordonnancement donné, une tâche peut avoir une ou plusieurs instances

d'activation selon la valeur de sa période. Nous notons par Ti,j la j ième instance de la tâche Ti. Les WCET, Ci,j, de toutes les instances d'une tâche Ti dans l'ordonnancement sont toutes égales. Pour améliorer ces WCET, nous procédons par l'analyse des instances d'une façon indépendante en exploitant l'influence du contexte de chacune. Nous calculons ainsi une nouvelle estimation C i , j

' de leurs WCET. La somme de ces WCET vérifie l'équation

suivante, ∑j =1

j = k

C i , j' ≤∑

j = 1

j = k

C i , j .

Notre objectif étant l'amélioration de l'estimation du WCET des tâches, nous avons besoin d'analyser le comportement du cache intra- et inter-tâche.

1.2. COMPORTEMENT DU CACHE INTRA-TÂCHE

Les approches usuelles qui procèdent par analyse statique d'une tâche gèrent le comportement de cette tâche dans le cache d'instruction. Notre but est de transformer les défauts induits par les hypothèses conservatrices en succès et d'utiliser le comportement du cache intra-tâche pour modéliser le comportement du cache tout le long de l'exécution de la boucle principale de l'application.

Notre approche intra-tâche se base sur la méthode MUST / MAY de Ferdinand [61]. Cette approche est basée sur une représentation en graphe de flot de contrôle qui décrit la structure de contrôle de la tâche. Comme des fonctions peuvent être appelées à des endroits différents dans le CFG, ce dernier est construit avec un dépliage des appels de fonctions. Cette étape est utile pour tenir compte du contexte d'exécution de chaque appel et pour faciliter l'implémentation de l'analyse.

Le temps d'exécution d'une instruction dépend de son comportement vis à vis du cache d'instruction. Si elle a été exécutée récemment, il se peut qu'elle se trouve encore dans le cache induisant ainsi un cache hit, ou peut avoir été supprimée du cache ou même ne pas être chargée dans le cache générant ainsi un cache miss.

Généralement une mémoire cache contient des blocs de tailles égales. Ces blocs sont appelés bloc mémoire ou ligne-bloc ou tout simplement L-bloc. Chaque L-bloc peut être chargé dans une ligne du cache. Quand un L-bloc est référencé durant l'exécution d'une tâche, nous avons deux possibilités : il est déjà dans le cache, ou bien, il doit être chargé depuis la mémoire principale.

Pour réaliser notre analyse intra-tâche, nous utilisons l'approche de Ferdinand [61] qui est composée de deux sous-analyses :

➢ l'analyse MUST détermine l'ensemble des L-blocs qui sont dans le cache à un point donné du programme en toutes circonstances

119119

Chapitre 4 - Analyse d'une application multi-tâches 1.Définition du problème

➢ l'analyse MAY fournit l'ensemble des L-blocs qui sont peut être dans le cache à un point donné du programme. Cette analyse est utilisée pour garantir l'absence d'un L-bloc du cache à un point donné.

Ces ensembles sont utilisés pour définir une catégorie (always hit, always miss et not classified) qui décrit le comportement du cache, pour chaque référence mémoire.

Les analyses MUST et MAY calculent pour chaque bloc de base deux états abstraits du cache, un avant (IN) et un autre après (OUT) son exécution pour construire à la fin l'ensemble OUT du bloc exit du CFG. Un algorithme d'analyse de flot de contrôle est appliqué pour calculer ces états à n'importe quel point d'exécution du programme. Cet algorithme itère tant que les ensembles OUT changent jusqu'à atteindre un point fixe. Notons que, à un point de jonction (entrée d'un bloc de base), l'état du cache IN est calculé en appliquant l'intersection (respectivement l'union) des OUT des prédécesseurs de ce bloc de base pour l'analyse MUST (respectivement pour l'analyse MAY). Les catégories attribuées aux L-blocs permettent de déterminer le nombre de hits et le nombre de miss de chaque L-bloc et de résoudre le systèmes de contraintes IPET pour déterminer le temps d'exécution du chemin pire cas.

Comme Ferdinand, nous proposons deux analyses MUST et MAY mais pour construire l'ensemble des L-blocs qui sont dans le cache après l'exécution de chaque tâche, ainsi nous ne fournissons pas des prédictions en tout point d'exécution donné du programme. Cet ensemble est appelé « Exit » dans la suite. Il ne sert pas seulement à calculer le WCET comme c'est le cas pour les ensembles construits par Ferdinand, mais sa construction est également utile pour notre approche inter-tâche. Les détails sont expliqués dans les paragraphe suivants.

1.3. COMPORTEMENT INTER-TÂCHE DU CACHE

Les hypothèses conservatrices des approches par analyses statiques supposent généralement un état vide ou indéterminé du cache avant l'exécution de la tâche et procèdent au calcul d'une borne supérieure surestimée de son WCET. Cependant, si l'état du cache avant l'exécution de la tâche est bien défini, nous pouvons identifier des hits qui ont été considérés comme miss et améliorer l'estimation du WCET.

Notre approche nous permet de calculer un intervalle de ce nombre de hits. La borne supérieure est le nombre maximal possible de hits, elle est fonction du flot de contrôle de la tâche. D'autre part, la borne inférieure fournit une sous-estimation conservatrice des hits qui ont été ignorés par les approches intra-tâche, et ce quel que soit le chemin d'exécution de la tâche.

Pour obtenir ce résultat, nous avons besoin de définir l'état du cache avant l'exécution de la tâche, l'ensemble des L-blocs susceptibles de générer des hits et l'ensemble des L-blocs qui seront dans le cache à la fin de l'exécution de la tâche.

Nous proposons de caractériser une tâche par quatre ensembles comme le montre la figure 4.2 où :

120120

Chapitre 4- Analyse d'une application multi-tâches 1.Définition du problème

➢ IN, est l'état du cache avant l'exécution de la tâche,➢ OUT, est l'état du cache à la fin de l'exécution de la tâche,➢ Entry, est l'ensemble des L-blocs qui seront les premiers à être chargés dans le cache

durant l'exécution de la tâche,➢ Exit, est l'ensemble des L-blocs qui seront dans le cache à la fin de l'exécution de la

tâche

Entry et Exit sont construits en ignorant l'état du cache inter-tâche et en supposant un état du cache vide à l'entrée de la tâche. Ces deux ensembles sont ainsi indépendants de l'ordonnancement des tâches et restent invariants avec le changement de l'ordre d'exécution des tâches pour une configuration du cache donnée.

Cependant, IN et OUT dépendent directement de l'ordre d'exécution des tâches. Notons que l'état du cache OUT sera l'état du cache IN de la tâche suivante dans l'ordonnancement. OUT est une fonction de IN et de Exit, car OUT est l'ensemble des L-blocs générés par la tâche (Exit) plus les L-blocs qui étaient dans l'état IN et qui n'ont pas été supprimés par les L-blocs de la tâche.

Entry et Exit sont fournis par l'analyse intra-tâche tandis que IN et OUT sont produits par l'analyse inter-tâche. Nous avons besoin de calculer l'ensemble Entry et l'ensemble Exit séparément car Entry est utilisé pour déterminer les hits ignorés qui sont les éléments de l'ensemble Entry ∩ IN et Exit est utile pour la construction de l'état OUT.

Nous analysons l'Entry d'une tâche car ses éléments sont les seuls L-blocs susceptibles de générer des hits car les autres L-blocs de la tâche sont influencés par ceux qui sont chargés dans le cache durant l'exécution de la tâche (voir les différentes interférences de L-blocs dans le § 4).

Les détails des analyses Entry et Exit ainsi que l'analyse inter-tâche sont exposés dans les paragraphes suivants.

2. LES INTERFÉRENCES POSSIBLES DES L-BLOCS

Pour mieux comprendre l'intérêt de l'analyse Entry et de l'analyse inter-tâche, ce

121121

Figure 4.2 - Caractéristiques de la tâche

Chapitre 4 - Analyse d'une application multi-tâches 2.Les interférences possibles des L-blocs

paragraphe montre les différents comportements des L-blocs de la tâche vis à vis des L-blocs d'un état IN bien défini à l'entrée de la tâche.

La figure 4.3 montre l'exemple d'un ordonnancement de tâche et se concentre sur le CFG de la tâche Ti tracé horizontalement. Nous construisons l'état OUT du cache en fonction de IN et de Exit de la tâche. Le CFG est un ensemble de blocs de base formés d'un seul L-bloc chacun. Nous considérons un cache d'instruction à accès direct. Les L-blocs ayant la même couleur appartiennent à la même ligne du cache et par conséquent sont conflictuels.

Les L-blocs affectés par les effets de l'enchaînement des tâches sont les L-blocs {f, c, g, r, e, h} qui sont les premiers à être chargés dans les lignes du cache (Entry). Nous distinguons 6 cas possibles de comportements de L-blocs. Le cas (4) est très simple car r et t ne sont pas dans l'état IN donc ils provoquent toujours un miss et vu qu'il n'existe pas de L-bloc de même couleur qui leur succède ils apparaîtront dans l'état OUT, mais selon le chemin d'exécution de la tâche OUT contiendra l'un ou l'autre L-bloc. Notons que la ligne qui contient a (1) reste inchangée comme si l'exécution de la tâche était transparente pour cette ligne du cache. Le cas (6) est aussi trivial, h apparaît dans OUT car il remplit une ligne non utilisée du cache.

f et c sont les premiers L-blocs de leur ligne de cache qui seront référencés. Ainsi i et b ne seront jamais affectés par l'état du cache IN. f supprime b du cache. Contrairement à d et c, b apparaît dans OUT vu qu'il est référencé plus tard dans le CFG et n'est supprimé par aucun autre L-bloc (2). c et e appartiennent à IN, ils génèrent des hits dans le cache lors de leur référence (3, 5) : ce sont des hits qui ont été ignorés par les approches conservatrices et capturés par notre approche pour améliorer l'estimation du WCET initial des tâches.

122122

Figure 4.3 - Comportement des L-blocs d'une tâche T sachant l'état du cache IN

1-Traverse 4-supprimé et ∉ OUT2-supprimée mais ∈ à OUT 5-Hit et ∈ OUT3-Hit et ∉ OUT 6-généré par la tâche

Chapitre 4- Analyse d'une application multi-tâches 3.Analyse de flot de données (dfa)

3. ANALYSE DE FLOT DE DONNÉES (DFA)Notre approche utilise un algorithme d'analyse de flot de données pour l'implémentation de

ces analyses. Ce paragraphe introduit les principes généraux d'une analyse de flot de donnée DFA itératif (Data Flow Analyse) ainsi que celles d'un algorithme de DFA.

Une analyse de flot de données est un processus qui collecte des informations sur des composants données d'un programme sans avoir à l'exécuter. Un algorithme de DFA est généralement défini comme un ensemble d'opérations sur les noeuds d'un CFG (bloc de base) qui utilisent des équations qui combinent des informations attachées à un noeud avec les informations attachées aux noeuds voisins.

Une analyse de DFA itérative utilise quatre ensembles qui contiennent les informations à manipuler :

➢ IN[x] – ensemble à l'entrée du noeud x➢ OUT[x] – ensemble à la sortie du noeud x➢ GEN[x] – ensemble des informations générées par le noeud x➢ KILL[x] – ensemble des informations supprimées par le noeud x.

Généralement, l'ensemble IN est construit en appliquant une opération de jonction (i.e. intersection, union) aux ensembles d'informations collectées des noeuds voisins qui peuvent être les prédécesseurs ou les successeurs de ce noeud.

Une équation typique est donnée par la formule 4.1

Cette équation peut être lue comme suit : « les informations à la sortie d'un noeud sont soient générées par ce noeud ou bien appartiennent à l'entrée et ne sont pas supprimées par les éléments du noeud ».

Une DFA est une analyse statique du programme. Elle effectue ainsi des approximations sur le comportement de ce programme et effectue un calcul de point fixe sur les opérations qui se répètent. Ce point fixe existe pour deux raisons :

➢ Les équations de DFA construisent les ensembles d'une manière monotone.➢ L'ensemble des éléments manipulés est fini vu que l'analyse s'effectue sur des

programmes ayant un nombre fini d'instructions.

Ainsi il existe une borne supérieure au nombre d'éléments des ensembles construits ce qui implique que le point fixe existe.

La figure 4.4 montre un algorithme itératif de DFA. Cet algorithme est partagé en deux

123123

OUT[x] = IN[x] - KILL[x] ∪ GEN[x]

Formule 4.1 - Formule générale de DFA itératif

Chapitre 4 - Analyse d'une application multi-tâches 3.Analyse de flot de données (dfa)

parties : l'initialisation des ensembles IN et OUT est effectuée dans la première partie en supposant que les ensembles GEN et KILL sont construits d'avance vu qu'ils sont indépendants du flot d'exécution du CFG ; dans la boucle principale, on calcule à chaque itération les ensembles IN et OUT de chaque bloc de base jusqu'à atteindre le point fixe. Une variable booléenne est utilisée pour indiquer si ce point fixe et atteint. L'ensemble IN est construit dans cet exemple en effectuant la jointure des OUT des prédécesseurs. Le nouveau OUT du noeud est construit en fonction du IN calculé.

La formule 4.1 est un exemple de la fonction Update(IN[Bi]). Cet algorithme est appliqué d'une manière descendante (utilisation des prédécesseurs). Pour appliquer cet algorithme d'une manière ascendante, on utilise l'ensemble des successeurs des noeuds du CFG. L'ordre d'évaluation des blocs de base n'a aucun effet sur le résultat final mais, la convergence du traitement est accélérée si le bon ordre est suivi.

4. ANALYSES DU CACHE À ACCÈS DIRECT

Notre analyse consiste à étudier le comportement du cache intra- et inter-tâche pour identifier les hits considérés comme miss par les approches conservatrices afin d'améliorer l'estimation du WCET initial des tâches. Nous nous intéressons dans ce paragraphe à l'analyse du cache à accès direct. Nous expliquerons par la suite les modifications nécessaires pour adapter cette approche aux caches associatifs.

L'analyse est effectuée en quatre étapes :

➢ Construction des ensembles EXIT des tâches de l'application.

Cette étape consiste en une analyse intra-tâche qui détermine l'ensemble des L-blocs qui seront dans le cache à la fin de l'exécution de la tâche en partant d'un cache vide en entrée.

124124

Figure 4.4 - Algorithme itératif de DFA

/* Initialisation */In [B i]=∅ ; /∀ B i

Out [Bn]=∅ ;/* Main Loop */

do { convergence = true ;for Bi do {

In[Bi] = Join Out [ s] ; // s∈Predecessor [B i]OldOut=Out [Bi];Out [B i]=Update In[Bi] ;if Out [Bi] ≠OldOut then convergence= faux ;

}} while! convergence

Chapitre 4- Analyse d'une application multi-tâches 4.Analyses du cache à accès direct

➢ Construction des états du cache à l'entrée de chaque tâche de l'ordonnancement

Cette deuxième étape est une analyse inter-tâche qui étudie un ordonnancement de tâches pour construire les états du cache inter-tâche en se servant des ensembles EXIT de l'étape précédente.

➢ Construction de l'ensemble Entry

Cette étape effectue une analyse intra-tâche pour construire l'ensemble des L-blocs dont l'accès peut être affecté par l'enchaînement de tâches.

➢ Amélioration des WCET initiaux des tâches

Les ensembles ENTRY vont être combinés aux états du cache construits durant la deuxième étape pour identifier les faux miss ce qui permet l'amélioration de l'estimation des WCET initiaux.

4.1. ANALYSE EXIT

L'analyse EXIT est inspirée de la méthode Ferdinand [61] qui modélise le comportement du cache à chaque point d'exécution du programme. Ferdinand propose des analyses MUST et MAY qui permettent de connaître la liste des L-blocs qui sont dans le cache avant et après le point d'exécution analysé.

Or, notre analyse EXIT est identique à l'approche proposée dans [61] mais se limite au point de sortie de la tâche. Elle nous permet ainsi de construire l'ensemble des L-blocs qui seront dans le cache après la fin de l'exécution de la tâche en supposant un état du cache vide en l'entrée.

Cet ensemble est ainsi dépendant du CFG de la tâche mais reste invariant par rapport au contexte d'exécution de la tâche (i.e état du cache IN). Nous construisons cet ensemble pour chaque tâche et nous utilisons ce même ensemble pour toutes les instances de la tâche dans l'ordonnancement que nous allons analyser dans la deuxième étape.

Comme Ferdinand, nous proposons une analyse MUST et MAY mais, contrairement à son approche [61] qui utilise l'interprétation abstraite, nous avons utilisé un algorithme itératif d'analyse de flot de données [79] que nous appliquons au CFG de la tâche. En effet, dans la cadre du cache à accès direct, une telle technique d'analyse statique est suffisante pour les calculs réalisés.

La notation de DFA expliquée au paragraphe précédent est utilisée. Nous manipulons ainsi les ensembles suivants pour chaque bloc de base Bi :

➢ IN[Bi] – ensemble des L-blocs présents dans le cache à l'entrée de Bi

➢ OUT[Bi] – ensemble des L-blocs présents dans le cache à la sortie de Bi

➢ GEN[Bi] – ensemble des L-blocs générés par Bi

➢ KILL[Bi] – ensemble des L-blocs supprimés par les L-blocs du GENi

125125

Chapitre 4 - Analyse d'une application multi-tâches 4.Analyses du cache à accès direct

Nous ajoutons la définition de la fonction line, qui retourne le numéro de la ligne d'un L-bloc. Si on considère un cache à accès direct ayant m lignes 0 ≤ line(Bx,y) <m. Ainsi la notation mathématiques de l'ensemble KILL est donnée dans la figure 4.5.

où LT est l'ensemble toutes les L-blocs de cette tâche T.

KILL est l'ensemble de tous les L-blocs concurrents avec les L-blocs du GEN. Comme nous étudions le comportement des L-blocs dans un cache à accès direct, il suffit de connaître pour chaque L-bloc du GEN quels sont les L-blocs de la tâche susceptibles d'être chargés dans la même ligne du cache, d'où la nécessité de la fonction line. L'application du KILL supprime ainsi de l'ensemble IN les L-blocs concurrents avec les L-blocs du GEN.

L'analyse MUSTEXIT[T], fournit la liste des L-blocs qui seront certainement dans le cache après l'exécution de la tâche T. Cependant MAYEXIT[T] contient les L-blocs qui pourront être dans le cache à la fin de T. MUSTEXIT est indépendant du chemin d'exécution ainsi quel que soit le flot de contrôle de T, le résultat est correct. Tandis que le MAYEXIT est l'union des résultats obtenus en appliquant l'analyse EXIT à chaque chemin d'exécution du CFG.

Formellement

L'algorithme de la figure 4.6 montre l'analyse MUSTEXIT. Le CFG est parcouru d'une manière descendante en partant de l'entrée. La fonction de jointure à l'entrée de chaque bloc de base est l'intersection des OUT de ses Prédécesseurs P. L'algorithme est itéré tant que le point fixe n'est pas atteint. Nous initialisons les OUT et les IN à LT sauf pour B0.

L'analyse MAYEXIT utilise le même algorithme de la figure 4.6 mais avec les modifications fournies dans la figure 4.7. Contrairement au MUST, les OUT et les IN sont initialisés à l'ensemble vide, et l'opération de jointure est l'union des OUT des prédécesseurs.

126126

KILL[ Bi ]= { Bx , y∈LT / i≠x ∧∃Bi , s∈GEN [B i] , line Bi , s= line B x , y }

Figure 4.5 - Formules GEN, KILL

MAY EXIT [T ]={ Bx , y ∈LT / ∃ Chemin Possible ∈ CFGT , B x , y ∈ EXITChemin Possible }

=∪EXITChemin Possible

MUST EXIT [T ]={ B x , y ∈LT / ∀ Chemin Possible ∈ CFGT , Bx , y ∈ EXITChemin Possible}

=∩EXITChemin Possible


Notre analyse est convergente car l'intersection (respectivement l'union) est appliquée à des ensembles décroissants (respectivement croissants) et le nombre de L-blocs, qui seront chargés dans chaque ligne du cache, est limité.

127127

/* Initialisation*/ for Bi∈BBT do { OUT [Bi ] = IN[Bi ] =∅ ;}/*Main Loop*/ IN [Bi ] =∪OUT[ p ]; p ∈ Predecessor [Bi ]

Figure 4.7 - Analyse MAYEXIT

Figure 4.8 - Exemple d'un CFG d'une tâche

/* Initialisation */for Bi∈BBT , Bi≠B0 do { IN [Bi]= OUT [Bi]= LT ;}OUT [B0]=GEN [B0];IN [B0] =∅ ;

/* Main Loop */do {

convergence= true ;for Bi∈BBT do {

IN [Bi] =∩ OUT[ p ]; // p∈Predecessor [Bi ]OldOut=OUT [B i];OUT[Bi]= In[Bi ]−KILL [Bi]∪GEN [Bi] ;if ( OUT [B i]≠OldOut )

then convergence= faux ;}

} while! convergence

Figure 4.6 - Algorithme MUSTEXIT


Nous utilisons l'exemple de la figure 4.8 pour montrer l'application de notre analyse sur ce CFG pour le MUSTEXIT et MAYEXIT.

Analyse MUSTLes IN et OUT des blocs de Base sont initialisés à l'ensemble L sauf OUT[B1] = GEN[B1] et IN[B1] = Ø.La première itération de la boucle donne les résultats suivants :B1 : IN = Ø ; OUT = [B1.1, B1.2]B2 : IN = OUT1 ∩ OUT6 = [B1.1, B1.2]; OUT = [B1.1, B1.2, B2.1, B2.2];B3 : IN = OUT2 ; OUT = [B1.1, B2.1, B2.2, B3.1, B3.2]B4 : IN = OUT3 ; OUT = [B1.1, B2.1, B2.2, B3.1, B3.2, B4.1]B5 : IN = OUT3 ; OUT = [B1.1, B2.1, B3.1, B3.2, B5.1]B6 : IN = OUT4 ∩ OUT5 = [B1.1, B2.1, B3.1, B3.2]; OUT = [B1.1, B2.1, B3.2, B6.1, B6.2]B7 : IN = OUT6 ∩ OUT2 = [B1.1, B2.1]; OUT = [B1.1, B2.1, B7.1 ]Les résultats sont identiques pour la deuxième itération donc la convergence est atteinte : MUSTEXIT[T] = OUT7 = [B1.1, B2.1, B7.1].

Analyse MAYLes IN et OUT des blocs de base sont initialisés à Ø.La première itération de la boucle donne les résultats suivants:B1 : IN = Ø ; OUT = [B1.1, B1.2]B2 : IN = OUT1 U OUT6 = [B1.1, B1.2]; OUT = [B1.1, B1.2, B2.1, B2.2];B3 : IN = OUT2 ; OUT = [B1.1, B2.1, B2.2, B3.1, B3.2]B4 : IN = OUT3 ; OUT = [B1.1, B2.1, B2.2, B3.1, B3.2, B4.1]B5 : IN = OUT3 ; OUT = [B1.1, B2.1, B3.1, B3.2, B5.1]B6 : IN = OUT4 U OUT5 = [B1.1, B2.1, B3.1, B3.2, B4.1, B5.1]; OUT = [B1.1, B2.1, B3.2,B5.1 B6.1, B6.2]B7 : IN = OUT2 U OUT6 = [B1.1, B1.2, B2.1, B2.2, B3.2, B5.1, B6.1, B6.2]; OUT = [B1.1, B1.2, B2.1, B2.2, B3.2, B5.1, B6.1, B6.2, B7.1] = MAYEXIT[T]car la deuxième itération produit un résultat identique.

4.2. CONSTRUCTION DES ÉTATS DU CACHE

La première originalité de notre approche vient de l'étude de l'ordonnancement des tâches pour construire les états du cache inter-tâche. Ceci est une différence majeure avec les approches conservatrices vu que l'effet de l'enchaînement des tâches ignoré par ces dernières est pris en compte par notre approche.

Dans le paragraphe précédent, nous avons proposé une analyse pour la construction de

128128


l'ensemble EXIT de chaque tâche en partant d'un état vide du cache en entrée. Cet ensemble va nous permettre de construire nos états inter-tâche. Ainsi, en partant d'un état IN du cache, l'état OUT est fonction de ce IN et de l'ensemble EXIT. Le OUT contient les L-blocs générés par la tâche (EXIT) et les L-blocs présents dans le IN et qui ne sont pas supprimés par les L-blocs de la tâche ce qui constitue un sous ensemble du IN.

Nous proposons aussi une analyse MUST et MAY pour le calcul des états du cache MUST et MAY. L'algorithme itératif de DFA est appliqué à l'ordonnancement des tâches. Or l'ordonnancement est une séquence de tâches qui s'exécutent tant que le système est fonctionnel. Donc, l'ordonnancement peut être représenté par un CFG où les noeuds sont les instances de tâches et les flèches indiquent l'ordre d'exécution (voir figure 4.9).

Chaque instance d'une tâche est considérée car le contexte d'exécution (i.e. état cache IN) peut être différent du contexte des autres instances. L'ordonnancement est construit pour des tâches définies par (Période (P) , WCET (C) , Echéance (D) ). Le WCET est calculé par n'importe quelle approche conservatrice intra-tâche supportant la modélisation du cache d'instruction à accès direct. Enfin, l'échéance de la tâche est supposée être à la fin de la période.

La notation de DFA est aussi utilisée pour cette analyse sachant que les ensembles manipulés sont les suivants, définis pour une tâche Ti,j :

➢ IN[Ti,j] – ensemble des L-blocs présents dans le cache à l'entrée de Ti,j .

129129

Figure 4.9 - Transformation d'un ordonnancement en graphe de flot de contrôle


➢ OUT[Ti,j] – ensemble des L-blocs présents dans le cache à la sortie de Ti,j , c'est l'ensemble des L-blocs générés par la tâche et les L-blocs de IN qui n'ont pas été supprimés du cache par Ti,j .

➢ GEN[Ti,j] – ensemble des L-blocs générés par Ti,j .➢ KILL[Ti,j] – ensemble des L-blocs supprimés par les L-blocs de Ti,j .

Nous définissons la fonction lines qui s'applique à un ensemble de L-blocs F comme suit:

lines [F ] = { l∈LB / ∃ l ' ∈ F , line l = linel ' }

où LB est la liste des L-blocs de l'application défini au §1.1.

L'écriture formelle des ensembles GEN et KILL est donnée dans la figure 4.10.

L'ensemble EXIT sera remplacé par le MUSTEXIT ou MAYEXIT en fonction de l'analyse appliquée. GEN sera égal au MUSTEXIT (respectivement MAYEXIT) pour l'analyse MUST (respectivement l'analyse MAY).

L'analyse MUST fournit en sortie les L-blocs qui seront dans le cache quel que soit le chemin d'exécution de la tâche. Il faut donc tenir compte des conflits de L-blocs dans chaque chemin d'exécution possible du CFG de la tâche. Le KILL s'écrit donc :

KILL [T i , j]= {l∈LB / ∃ l'∈LB∧∃Chemin possible du CFGT i tel que

l ' ∈ EXIT Chemin Possible∧ line l =line l' }= lines[MAY EXIT [T i] ]

D'autre part, l'analyse MAY fournit la liste des L-blocs tels qu'il existe un chemin d'exécution possible du CFG pour lequel ils seront dans l'état du cache en sortie de la tâche. Donc il faut uniquement tenir compte des conflits de L-blocs communs à tous les chemins possibles du CFG.

KILL [T i , j]= { l∈LB / ∃l '∈LB∧∀chemin Possible du CFGT itel que

l '∈EXIT Chemin Possible∧ line l =line l ' }= lines[MUST EXIT [T i]]

130130

Figure 4.10 - Formules GEN, KILL analyse inter-tâche

GEN [T i , j] = EXIT [T i , j]KILL [T i , j ]= linesEXIT[T i , j ]


L'algorithme de DFA de la figure 4.11 montre l'analyse complète MUST appliquée au graphe des tâches (i.e figure 4.9). Ce graphe est parcouru de manière descendante en partant de la première instance de la tâche T1. Nous utilisons ainsi l'ensemble des prédécesseurs de la tâche. Le graphe étant linéaire, cet ensemble se limite pour chaque tâche à la tâche précédente. L'intersection est utilisé pour le MUST et l'union pour le MAY, mais les deux sont appliquées sur un seul et même ensemble OUT de la tâche précédente.

L'analyse MAY utilise le même algorithme de la figure 4.11 mais avec les changements montrés dans la figure 4.12.

L'analyse est convergente pour trois raisons :

➢ Le nombre de tâches d'une application est fixe, donc le nombre de tâches du graphe est connu il est égal au nombre d'instances des tâches de l'application. Par exemple dans l'exemple de la figure 4.9. le nombre de tâches est 6 et le nombre de noeuds du

131131

/* Initialisation */for T i , j do { IN [T i , j]=∅ ; OUT[T i , j]= MUST EXIT [T i];

GEN [T i , j]= MUST EXIT [T i ];KILL[T i , j]= lines MAY EXIT [T i] ;}

/* Main Loop */do {

convergence= true ;for T i , j do {

IN [T i , j]=∩ OUT[ p ]; // p∈Predecessor [T i , j]OldOut=OUT[T i , j ];OUT[T i , j]= In[T i , j]−KILL [T i , j]∪GEN [T i , j];if ( OUT [T i , j ]≠OldOut )



Figure 4.11 - Analyse inter-tâche MUST

Figure 4.12 - Analyse inter-tâche MAY

/* Initialisation */for T i , j do { IN [T i , j]= ∅ ; OUT[T i , j]= MAY EXIT [T i ];

GEN [T i , j ]= MAY EXIT [T i];KILL [T i , j]= lines MUST EXIT [T i ]; }

/* Main Loop */IN [T i , j]=∪ OUT[ p ]; // p∈Predecessor [T i , j]


graphe est 9.➢ Le nombre de L-blocs de chaque tâche est connu et fixe.➢ La fonction de mise à jour à chaque instance de tâche est monotone (décroissante

pour les ensembles MUST, croissante pour les ensembles MAY).

Une fois les états du cache inter-tâche construits, nous pouvons passer à la troisième étape où nous utilisons ces ensembles pour améliorer le WCET des tâches de l'application.

4.3. ANALYSE ENTRY

Cette partie explique les détails de l'analyse ENTRY qui consiste à construire la liste des L-blocs d'une tâche qui seront les premiers à être chargés dans les lignes du cache. Nous avons montré dans le paragraphe §2 figure 4.3 que ces L-blocs sont les seuls à être affectés par l'enchaînement des tâches.

L'analyse ENTRY n'a pas été considérée plus avant vu que la plupart des approches conservatrices sont intra-tâche et les approches multi-tâches proposent d'autres méthodes pour calculer le WCRT des tâches.

L'ensemble ENTRY, comme l'ensemble EXIT, est construit pour chaque tâche et est utilisé pour toutes les instances de cette tâche vu que cet ensemble dépend uniquement du CFG de la tâche et reste invariant avec le changement de son contexte d'exécution.

Une fois de plus, nous proposons une analyse MUST et une analyse MAY pour construire cet ensemble. Ces analyses utilisent un algorithme DFA itératif appliqué sur le CFG d'une tâche. Cet algorithme utilise la même notation (IN, OUT, GEN, KILL) que pour l'analyse EXIT. Nous utilisons la même définition de LT et de line.

MUSTENTRY[T] contient la liste des L-blocs qui seront les premiers à être chargés dans le cache durant l'exécution de la tâche T, alors que MAYENTRY[T] contient les L-blocs qui pourront être les premiers chargés dans le cache durant l'exécution de T. MUSTENTRY est indépendant du chemin d'exécution. Ainsi quel que soit le flot de contrôle de T, le résultat est correct. Par contre MAYENTRY est l'union des résultats obtenus en appliquant l'analyse ENTRY à chaque chemin possible du CFG.

Formellement

L'algorithme de la figure 4.13 montre l'analyse MUSTENTRY. Le CFG est parcouru d'une manière ascendante en partant du bloc exit. La fonction de jointure à l'entrée de chaque bloc

132132

MAY ENTRY [T ]={ l ∈LT / ∃ Chemin Possible ∈ CFGT , l ∈ ENTRYChemin Possible}

=∪ENTRYChemin Possible

MUST ENTRY [T ]={ l ∈LT / ∀ Chemin Possible ∈ CFGT , l ∈ ENTRYChemin Possible}

=∩ENTRYChemin Possible


de base est l'intersection des OUT des successeurs. L'algorithme est itéré tant que le point fixe n'est pas atteint. Nous initialisons les OUT et les IN à L sauf pour Bm.

L'analyse MAYENTRY utilise le même algorithme de la figure 4.13 mais avec les modifications fournies dans la figure 4.14. Contrairement au MUST, les OUT et les IN sont initialisés à l'ensemble vide, et l'opération de jointure est l'union des OUT des successeurs.

L'intersection (respectivement l'union) est appliquée à des ensembles décroissants (respectivement croissants) et vu que pour chaque ligne du cache, on a un nombre limité de L-blocs qui y seront chargés, notre analyse est convergente.

Ainsi si on considère l'exemple de la figure 4.8, les résultats de l'analyse ENTRY sont :MUSTENTRY = {B1.1, B1.2, B2.1, B2.2, B7.1}MAYENTRY = {B1.1, B1.2, B2.1, B2.2, B3.1, B4.1, B6.2, B7.1}

4.4. AMÉLIORATION DU WCET DES TÂCHES

Cette dernière étape est réalisée une fois les ensembles ENTRY et les états du cache inter-tâche construits. Nous considérons chaque instance j d'une tâche Ti notée par Ti , j.

133133

Figure 4.13 - Algorithme MUSTENTRY

Figure 4.14 - Analyse MAYEXIT

/* Initialisation */for Bi∈BBT , Bi≠Bm do { IN [Bi] =OUT [Bi]=LT ;}OUT [Bm]=GEN [Bm]; IN[Bm]= ∅ ;

/* Main Loop */do {

convergence= true ;for Bi∈BBT do {

IN [Bi] =∩ OUT [ s] ; // s∈Successor [B i]OldOut=OUT [B i];OUT [Bi]= In[Bi ]−KILL [Bi]∪GEN [Bi] ;if ( OUT [B i]≠OldOut )



/* Initialisation*/ for Bi∈BBT do { OUT[Bi] = IN[Bi ] =∅ ;}/*Main Loop*/ IN [Bi] =∪OUT[ s]; s ∈ Successor [Bi]


L'analyse MUST (respectivement MAY) utilise le MUSTENTRY (MAYENTRY) et l'état du cache MUST (MAY) avant l'exécution de la tâche obtenu une fois la convergence de l'algorithme MUST (MAY), du paragraphe §4.2, atteinte. Ces ensembles sont notés par INMUST et INMAY. Les approches conservatrices ont considéré un état indéfini ou vide de ces ensembles pour construire une borne maximale sûre mais pessimiste du WCET de la tâche. Mais notre approche connaissant l'ordonnancement permis de définir le contexte d'exécution de chaque instance de tâche (l'état du cache avant son exécution). Cet ensemble combiné à l'ENTRY permet d'identifier les faux miss induits par les hypothèses conservatrices et ainsi améliorer l'estimation du WCET. L'ensemble ENTRY est utilisé car nous avons montré dans une section précédente que seuls les éléments de cet ensemble sont affectés par l'enchaînement des tâches.

Nous aurons ainsi un intervalle du nombre de hits [minHit, MaxHit]. La borne inférieure est déduite de l'analyse MUST et la borne supérieure de l'analyse MAY (figure 4.15).

Si on considère une tâche T de l'application, les résultats du MUST sont valables quel que soit son chemin d'exécution. Tandis que le résultat du MAY est une borne supérieure, car si nous connaissons son chemin d'exécution, nous aurons un résultat inférieur à MaxHit et supérieur ou égal à MinHit.

Donc le résultat du MUST est un résultat minimal mais sûr de l'approche indépendamment du chemin d'exécution des tâches.

Le WCET initial étant donné, la pénalité du miss et le coût du hit connus, et le nombre de hits calculé, le nouveau WCET noté par WCETNEW est donné par la formule 4.2 :

nbHit représente le nombre de hit qu'on considère pour l'amélioration du WCET comme notre approche MUST est sûre, nous utiliserons cette formule avec le MinHit pour optimiser le WCET. Cependant, nous gardons cette notation générale dans la formule, car si on connaît le nombre exact de hits sachant le flot d'exécution de la tâche, ce nombre peut être utilisé à la place du MinHit pour une meilleure estimation du WCET NEW sachant que nbHit exact est supérieur ou égal à MinHit.

5. ANALYSE DU CACHE ASSOCIATIF

La gestion du cache à accès direct est très simple car la référence d'un nouveau L-bloc peut

134134

MinHit = Cardinal MUSTENTRY∩ INMUST

MaxHit = Cardinal MAYENTRY∩ INMAY

Figure 4.15 - Calcul du nombre de hit minimal et maximal

WCETNEW =WCETINITIAL −nbHit × missPenality nbHit ×HitCost

Formule 4.2 - Amélioration du WCET initial

Chapitre 4- Analyse d'une application multi-tâches 5.Analyse du cache associatif

soit occuper une ligne vide, soit ne pas changer l'état du cache si elle y est déjà, soit au pire supprimer le contenu d'une ligne pour le remplacer.

Ce paragraphe est consacré à l'extension de notre approche décrite dans la section précédente pour l'adapter au cache associatif. Ce genre de cache introduit plus de complication dans le calcul du WCET car son comportement est plus difficile à prédire qu'un cache à accès direct.

Nous nous intéressons uniquement à un cache associatif LRU. En effet l'état d'un cache LRU est facile à prédire tandis que la stratégie du hasard n'est ni facile à implémenter, ni possible à analyser, et pour MRU et FIFO, il est très difficile de prédire le nombre de remplacements nécessaires pour atteindre un état bien défini du cache [58] même pour une approche intra-tâche.

Dans un cache LRU, la référence d'une L-bloc peut : soit occuper une ligne vide, soit vieillir les L-blocs qui existent déjà dans deux cas : si il est déjà dans le cache ou si il est ajouté au cache dans une ligne non vide. Donc le problème est de trouver un moyen pour identifier à chaque point d'exécution les L-blocs qui sont dans le cache et ceux qui en ont été supprimés.

5.1. ARCHITECTURE D'UN CACHE ASSOCIATIF

Nous rappelons dans ce paragraphe les paramètres qui déterminent l'architecture d'un cache associatif :

➢ La taille Z : c'est le nombre d'octets qu'il peut contenir.➢ la taille d'une ligne b : c'est le nombre d'octets adjacents transférés de la mémoire

principale en cas de miss. C'est la taille d'un bloc mémoire.➢ Le nombre de lignes n : Z/b.➢ Le degré d'Associativité A : c'est le nombre de lignes du cache où un L-bloc peut être

chargé.

L'architecture du cache la plus générale est le cache associative de degré A où un L-bloc peut être chargé dans A lignes différentes. Ces lignes forment ce qu'on appelle un ensemble du cache. Le nombre d'ensembles est égal à n/A. Le cache à accès direct est un cas particulier pour A=1. Un autre cas particulier est le cache totalement associatif pour A=n. Il contient un seul ensemble contenant n lignes et un L-bloc peut être chargé dans n'importe quelle ligne.

5.2. STRATÉGIE DE REMPLACEMENT LRUNotre approche modélise le comportement d'un cache associatif, avec la méthode de

remplacement LRU (Least Recently Used) pour gérer la mise à jour de son état. Cette méthode de [62] profite de la localisation temporelle d'utilisation des blocs de cache. Elle réduit la probabilité de perte des informations qui seront nécessaires prochainement en

135135

Chapitre 4 - Analyse d'une application multi-tâches 5.Analyse du cache associatif

enregistrant les accès aux blocs de cache. Le bloc remplacé est celui qui n'a pas été utilisé depuis le plus longtemps.

L'enregistrement des accès aux blocs peut être modélisé en attribuant à chacun un âge relatif. Pour un cache associatif de degré A, cet âge varie entre 0 et A-1. Nous ajoutons l'âge A à cet ensemble qui sera attribué aux blocs qui ne sont plus dans le cache. Ainsi, un bloc est dans le cache si son âge est inférieur ou égal à A-1 et A sinon.

Nous utilisons l'algorithme suivant pour mettre à jour l'état du cache quand un nouveau L-bloc lb est référencé dans un ensemble du cache.

➢ Si cet ensemble est plein et lb n'est pas dans le cache, lb est chargé dans la première ligne et l'âge de toutes les L-blocs de cet ensemble est incrémenté de 1. Ainsi celui qui est le plus ancien (âge=A-1) sera supprimée du cache.

➢ Si lb existe déjà dans le cache, les l-blocs ayant un âge inférieur ou égal à son âge vieillissent de 1 tandis que l'âge des l-blocs supérieurs au sien ne change pas. Ensuite lb est déplacé dans la première ligne et devient âgé de 0.

➢ Si l'ensemble du cache est vide, lb est directement chargé dans la première ligne et son âge est mis à 0.

5.3. SÉMANTIQUES DU CACHE

Nous utiliserons les sémantiques expliquées dans ce paragraphe pour modéliser le comportement du cache d'instruction associatif de degré A.

Un cache associatif est vu comme une collection d'ensembles E={ e0, e1, ... , en /A−1} où chaque ensemble contient A lignes F= {l 0, l 1,... , lA−1 } . LT i

étant la liste des L-blocs de la

tâche Ti, nous utilisons l'ensemble LB=∪LT i pour décrire l'ensemble de tous les L-blocs de

l'application, cet ensemble étant utile pour l'analyse inter-tâche. L'ensemble des L-blocs de l'application qui sont en concurrence dans un ensemble ei du cache est noté par LBi , où :

LBi⊂LB ,LBi∩LB j≠∅ i= j ,LB=∪LBi / i={ 0,... ,n / A−1 }

Nous utilisons des sémantiques similaires à celles introduites dans [62] pour modéliser le comportement du cache d'instruction dans notre algorithme de DFA itératif.

Nous utilisons la fonction set : LB { 0, ... ,n / A−1 } qui fournit pour chaque L-bloc l'indice de l'ensemble du cache où il sera chargé. L'état d'un ensemble du cache est une fonction s : F 2LB , c'est l'ensemble des L-blocs présents dans cet ensemble à un point d'exécution donné. Cette fonction est définie par :

∀ l a , lb ∈ ei : ∀ l c ∈ LB : if l c∈s l a ∩ s lb a=b , on note par si l'état de l'ensemble ei et S est l'ensemble de tous les états possibles des (n/A)-1 ensembles du cache

136136


pour une liste de tâches données.

Un état du cache est une fonction c : E S , C représente l'ensemble de tous les états possibles du cache. La fonction de mise à jour d'un ensemble du cache suite à la référence d'un L-bloc est une fonction U s : S × LB S . Nous fournissons de même une fonction de mise à jour d'un état du cache, pour un état du cache donné et un L-bloc U c : C × LB C . Pour terminer, l'opération de jointure d'une suite d'états du cache en un point d'exécution donné est une fonction J : Cm C , avec m > 1.

Ces fonctions sont utilisées dans notre algorithme de DFA, la définition de chacune d'elles est définie pour chaque étape de notre analyse. Pour terminer, notons que l'âge d'un L-bloc chargé dans un ensemble ei ne peut être affecté que par une référence à un L-bloc de l'ensemble LBi autrement dit par une référence à un L-bloc concurrent.

5.4. ANALYSE EXIT

L'analyse EXIT est effectuée en se basant sur l'algorithme général de DFA fourni à la figure 4.4. Elle est effectuée sur le CFG de la tâche d'une manière descendante en partant du bloc B0. Chaque bloc de base est caractérisé par trois ensembles : IN, OUT et GEN comme définis précédemment dans l'analyse du cache à accès direct. L'ensemble KILL n'est plus utilisé car la fonction de mise à jour des ensembles OUT dans la boucle principale de l'algorithme de DFA utilisé n'est plus IN−KILL∪GEN . Une nouvelle définition est fournie pour tenir compte du vieillissement des L-blocs dans un cache associatif de degré A.

La fonction de mise à jour d'un ensemble du cache quand un nouveau L-bloc est référencé est une fonction U S

∩ : S∩× LT i S∩ pour l'analyse MUST et U S

∪ : S∪× LT i S∪ pour

l'analyse MAY, où S∩ , respectivement S∪ , représentent tous les états MUST (respectivement MAY) possibles des ensembles du cache, LT i

étant l'ensemble des L-blocs de la tâche Ti à analyser.

U S∩s j

∩ , Bx , y=si ∃ l h∈e j : Bx , y∈s j∩l h

[ l 0 { B x , y }l x s j

∩l x−1 , x=1,2 ,... , hl h1 s j

∩l h1∪ s j∩l h−Bx , y

l i s j∩li , i=h2,... , A−1 ]

sinon[ l 0 { B x , y }l i s j

∩l i−1 , i=1, ... , A−1 ]

La même définition est utilisée pour U S∪ en remplaçant s j

∩ par s j∪ . La mise à jour d'un

état du cache est une fonction U C∩ : C∩× LT i

C∩qui pour un état du cache donné et une

référence à un nouveau L-bloc construit le nouvel état du cache. U C∩ est utilisée pour

l'analyse MUST et U C∪ pour l'analyse MAY. Ces deux fonctions sont définies comme suit :

137137


U C∩c∩ , B x , y = c∩[eset B x ,y

U S∩c∩eset Bx , y

,B x , y ]= c∩ [eset B x, y

U S∩ sset B x ,y

∩ , Bx , y ]

et

U C∪c∪ , B x , y = c∪[eset B x ,y

U S∪ sset Bx , y

∪ , Bx , y]

Nous définissons aussi une opération de jointure utilisée pour combiner des états du cache en un point de jointure donné. Cette opération est décrite par J∩ : C∩m C∩ qui peut être assimilée à l'opération d'intersections des ensembles. J∩ est utilisée pour l'analyse MUST, elle fournit comme résultat l'intersection de ces opérandes. Les L-blocs appartenant à cet ensemble posséderont l'âge maximal de leurs âges dans les ensembles traités.

J∪ : C∪m C∪ est utilisée pour l'analyse MAY. Cette fonction effectue l'union des ensembles pour construire l'ensemble final. Elle attribut à chaque L-bloc membre de l'ensemble final le plus petit âge parmi les âges qu'elle a eu dans les ensembles de départ.

L'algorithme de l'analyse MUSTEXIT est illustré dans la figure 4.16. L'analyse MAYEXIT

utilise le même algorithme mais avec les modifications fournies dans la figure 4.17.

138138

Figure 4.16 - Algorithme MUSTEXIT

/* Initialisation */for Bk∈BBT do{ IN [Bk ] =OUT [B k ]=LT ; }

/* Main Loop */do {

convergence= true ;for Bk∈BBT do {

IN [Bk ] = J∩ OUT[ p ]; // p∈Predecessor [Bk ]OldOut=OUT[B k ];temp=IN [Bk ] ;for Bk , x ∈ GEN [B k ]

temp=UC∩temp , Bk , x ;

OUT[B k ]=temp ;if ( OUT [Bk ] ≠OldOut )




5.5. CALCUL DU DAMAGE

L'objectif principal de cette analyse est de fournir une information correcte sur le nombre de remplacements qu'il y a eu dans un état donné du cache suite à l'exécution d'une tâche. Cette analyse a été introduite par [62]. Pour calculer ce DAMAGE, nous utilisons aussi un algorithme de flot de données comme pour les autres étapes de notre approche. Une analyse MUST et une analyse MAY sont fournies.

L'idée c'est de calculer une borne maximale du nombre de remplacements qui ont eu lieu dans un ensemble donné du cache pour l'analyse MUST et une borne minimale de ce nombre de remplacements pour l'analyse MAY. Avant de montrer le fonctionnement de l'algorithme, nous introduisons les sémantiques utilisées.

Le domaine du nombre remplacements de l'analyse Damage est l'ensemble D ,≤ ,∪ ,∩ , où D={0,1 ,... , A}⊂ℕ ,≤ est la relation d'ordre des entiers naturels, ∪x , y = maxx , y et ∩x , y = minx , y pour x , y∈D . L'opération ⊕ est définie sur les éléments de D comme suit :

x ⊕ y = A , si x y≥Ax y , sinon

Soit = { a | a : E D } , tel a(ei) est le nombre de remplacements qui ont eu lieu dans l'ensemble ei du cache dans un état du cache bien défini. La mise à jour du nombre de remplacements d'un ensemble ei du cache quand un nouveau L-bloc est référencé est une fonction DU : × LB , telle que DU a , B x , y=a ' , où

∀ ei∈E : a ' e i= a e i⊕1 , si set B x , y=i∧age Bx , y=Aa e i , sinon

Cette définition est lue comme suit : quand un nouveau L-bloc est référencé, s'il n'est pas

139139

Figure 4.17 - Algorithme MAYEXIT

/* Initialisation */for Bk∈BBT do { IN [B k ] = OUT[B k ]=∅ ; }/* Main Loop */

IN [Bk ] = J∪ OUT[ p ]; // p∈Predecessor [Bk ]temp=IN [Bk ] ;for Bk , x ∈ GEN [B k ]

temp=UC∪temp , Bk , x ;

OUT[B k ]=temp ;


dans le cache (âge=A), il sera chargé dans un ensemble ei et le nombre de remplacements de ei sera incrémenté de 1.

L'analyse MUST fournie une valeur maximale et l'analyse MAY, une borne minimale. Nous utilisons ∪ définie sur les éléments de en un point de jointure donné pour l'analyse MUST et ∩ pour l'analyse MAY, tel que :

∀ ei∈E : ∪a1, ... , a pe i=∪a1 ei , ... , a pe i∩a1, ... , a pe i=∩a1e i ,... , a pei

L'algorithme de l'analyse MUST est fourni dans la figure 4.19 . L'algorithme est appliqué au CFG d'une tâche, ce CFG étant parcouru d'une manière descendante en partant de B0. Chaque bloc de base est caractérisé par trois ensembles :

➢ IN[Bi] : est le nombre de remplacements qui ont eu lieu avant l'exécution de Bi.➢ OUT[Bi] : est le nombre de remplacements après l'exécution de Bi.➢ GEN[Bi] : est l'ensemble des L-blocs de Bi.

Les ensembles IN et OUT sont initialisés à 0 car c'est l'élément neutre de l'opération ∪ . 0 signifie que le nombre de remplacements dans chaque ensemble ei du cache est nul.

A chaque itération, l'ensemble IN est calculé pour être égal au maximum des remplacements des prédécesseurs. Le OUT est calculé en incrémentant le nombre de remplacements pour l'ensemble du cache susceptible de contenir chaque L-bloc du bloc de base courant.

140140

Figure 4.18 - Algorithme DAMAGEMUST

/* Initialisation */for B k∈BBT do{ IN [B k ]= OUT[Bk ]=0 ;}

/* Main Loop */do {

convergence= true ;for Bk∈BBT do {

IN [Bk ] =∪ OUT[ p] ; // p∈Predecessor [Bk ]OldOut=OUT[Bk ] ;temp=IN [Bk ] ;for B k , x ∈ GEN [Bk ]

temp=DU temp , B k , x ;OUT [Bk ]=temp ;if ( OUT [B k ] ≠OldOut )




D'autre part, l'analyse MAY utilise le même algorithme de la figure 4.19 mais avec les changements indiqués dans la figure 4.19. En effet, les IN et les OUT sont initialisés à l'élément neutre de l'opération ∩ qui calcule la valeur minimale de ces opérandes. Nous avons seulement besoin de corriger la valeur du IN de chaque bloc de base uniquement pour la première itération de l'algorithme au cas où tous les opérandes de ∩ sont égaux à A. C'est la représentation du cas réel où le nombre de remplacements dans les ensembles du cache est nul. Mais, comme l'initialisation à 0 est impossible, cette correction doit être effectuée à la première itération pour mettre cet IN à 0. L'initialisation des IN et des OUT à 0 est impossible car 0 est l'élément absorbant de ∩ . Nous assisterions ainsi à une perte d'informations et nous aurions à la convergence tous les IN et les OUT égaux à 0.

Les résultats de l'analyse DAMAGE sont utilisés par la suite pour la construction des états du cache inter-tâche.

5.6. ANALYSE INTER-TÂCHE

L'analyse inter-tâche étudie un ordonnancement statique des tâches de l'application pour construire les états du cache avant et après l'exécution de chaque tâche. Ces ensembles sont utilisés pour déterminer les faux miss induits par les hypothèses conservatrices des analyses intra-tâche. Ceci va nous permettre d'améliorer la précision du WCET des tâches.

Cette analyse est triviale pour un cache à accès direct car, quand une L-bloc de l'ensemble EXIT de la tâche est référencée, il supprime du cache tous les L-blocs conflictuels. Cependant, pour un cache associatif de degré A, la gestion du chargements des L-blocs dans le cache respecte la politique de remplacement utilisée, LRU dans le cadre de notre approche. Ainsi, pour construire l'état du cache après l'exécution de la tâche, il faut tenir compte du nombre de remplacements qu'il y a eu pendant l'exécution avant de procéder à la suppression d'un L-bloc de l'état IN du cache.

Nous avons ainsi besoin de l'ordonnancement des tâches, des ensembles EXIT et des DAMAGE de chacune de ces tâches. Une analyse MUST fournit les états sûrs et une analyse MAY fournit les états du cache probables suite à l'étude des paramètres susmentionnés. Notons que les résultats fournis par MUST sont indépendants du chemin d'exécution des tâches, c'est le résultat minimal qu'on aura quel que soit le chemin d'exécution des tâches

141141

/* Initialisation */for Bk∈BBT do { IN[Bk ]= OUT [B k ]=A ; }/* Main Loop */

IN [Bk ] =∩ OUT[ p] ; // p∈Predecessor [Bk ]

Figure 4.19 - Algorithme DAMAGEMAY


tandis que l'analyse MAY fournit une borne supérieure qui est l'union de tous les cas possibles d'états du cache en entrée et en sortie de chaque tâche de l'ordonnancement.

L'ordonnancement est transformé en un graphe linéaire, avec une boucle principale. Il est parcouru d'une manière descendante en commençant par la tâche T1 sachant que l'ensemble IN d'une tâche est l'ensemble OUT de celle qui la précède dans l'ordonnancement

Nous définissons une fonction G de mise à jour d'un état du cache en fonction du nombre de remplacements et d'un état donné du cache. G∩ : C∩× C∩× ∪ C∩ est utilisée pour l'analyse MUST et G∪ : C∪×C∪× ∩ C∪ pour l'analyse MAY.

La fonction de mise à jour MUST, OUT∩=G∩ IN MUST ,MUST EXIT , DAMAGEMUST et la fonction MAY, OUT∪=G∪ IN MAY ,MAY EXIT , DAMAGEMAY sont définies tel que :

l h MUST EXIT e il h , h ∈ [0, j−1]∀ ei ∈ E : OUT∩e i = l h IN∩eil h- MUST EXIT ei , h ∈ [ j , A−1]

j = DAMAGE MUST ei

l h MAY EXIT eil h , h ∈ [0, j−1]∀ ei ∈ E : OUT∪e i= l h IN MAY eil h- MAY EXIT e i∪MAY EXIT e il h , h∈[ j , A−1]

j = DAMAGEMAY e i

L'algorithme de DFA construit pour chaque tâche l'état du cache à la fin de son exécution en se basant sur l'ensemble IN, l'ensemble EXIT et le nombre de remplacements. L'ensemble EXIT et le nombre de remplacements sont inchangés quel que soit le contexte d'exécution de la tâche. L'analyse MUST construit l'état du cache sûr donc vrai quel que soit le flot de contrôle de la tâche. Donc elle se base sur l'ensemble MUST EXIT et tient compte du nombre maximal de remplacements qui auront lieu dans le cache durant l'exécution de la tâche, DAMAGE MUST , pour construire l'état OUT. Ainsi G∩ vieillit les L-blocs du IN du nombre maximal de remplacements, et ensuite copie les éléments du MUST EXIT dans l'ensemble obtenu avec leurs âges respectifs dans le MUST EXIT . Nous obtenons ainsi l'état du cache OUT∩ . L'algorithme de l'analyse MUST est fourni dans la figure 4.20.

142142


En revanche, l'analyse MAY construit l'état du cache probable après l'exécution de chaque tâche. Cet ensemble est construit en fonction du MAY EXIT et du nombre minimal de remplacements qui auront lieu dans le cache pour tout chemin d'exécution de la tâche. En effet, OUT∪ contient la liste des L-blocs qui peuvent être dans le cache après l'exécution de la tâche donc il ne faut tenir compte que du nombre minimal de remplacements. Ainsi G∪ construit OUT∪ en deux étapes: 1) elle vieillit les L-blocs du IN du nombre de remplacements minimal DAMAGE MAY et 2) copie les L-blocs du MAY EXIT dans l'ensemble obtenu avec leurs âges respectifs dans le MAY EXIT . L'analyse MAY utilise le même algorithme de la figure 4.20 mais avec les modifications indiquées dans la figure 4.21.

5.7. ANALYSE ENTRY

Cette analyse consiste à fournir la liste des L-blocs qui seront les premiers à être chargés dans le cache durant l'exécution d'une tâche. En effet, comme nous avons expliqué

143143

/* Initialisation */IN [T i , j]=∅ ;OUT [T i , j ]=MUST EXIT [T i];GEN [T i , j]=MUST EXIT [T i];

/* Main Loop */do {

convergence= true ;for T i do {

IN [T i , j]= OUT [ p]; / p∈Predecessor [T i , j]OldOut=OUT[T i , j ];OUT[T i , j]=G∩ IN [T i , j] ,GEN [T i , j] , DAMAGE MUST [T i] ;if ( OUT [T i , j ]≠OldOut )



Figure 4.20 - Analyse Inter-tâches MUST

/* Initialisation */OUT [T i , j ]=MAY EXIT [T i];GEN [T i , j]=MAY EXIT [T i] ;/* Main Loop */

OUT[T i , j]=G∪ IN [T i , j] ,GEN [T i , j ] , DAMAGE MAY [T i];

Figure 4.21 - Analyse Inter-tâches MAY


précédemment, ces L-blocs sont les seuls qui peuvent être affectés par l'enchaînement des tâches. Nous fournissons une analyse MUST qui fournit la liste des L-blocs qui seront les premiers à être référencés dans chaque ensemble du cache. Tandis que l'analyse MAY fournit la liste des L-blocs qui peuvent être les premiers à être référencés dans les ensembles du cache.

L'analyse ENTRY est une analyse intra-tâche. Ainsi les résultats resteront invariants avec la variation de l'ordonnancement ou du contexte d'exécution des tâches. De plus, les ensembles MUST ENTRY et MAY ENTRY , sont calculés une seule fois pour chaque tâche mais seront utilisés pour toutes ses instances dans l'ordonnancement.

Le calcul de l'ensemble ENTRY pour un cache d'instruction à accès direct est trivial car quand un L-bloc est référencé, s'il n'existe pas dans le cache et la ligne ou il doit être chargé est pleine, le contenu de cette ligne sera supprimé. Au contraire, pour un cache associatif il faut calculer la liste des L-blocs qui seront les premiers à être chargés dans le cache en respectant la politique de remplacement choisie (LRU). Comme pour les analyses précédentes il faut sauvegarder les accès aux L-blocs pour déterminer, en cas de remplacement, lequel est plus vieux pour qu'il soit remplacé par la nouvelle référence. Ainsi, nous utilisons pour l'analyse ENTRY les mêmes fonctions U S et U C définies pour l'analyse EXIT, qui permettent la mise à jour de l'état du cache quand un L-bloc est référencé. De même U S

∩ et U C∩ sont

utilisées pour l'analyse MUST et U S∪ et U C

∪ pour l'analyse MAY.

Contrairement à l'analyse EXIT, ENTRY traverse le CFG de la tâche d'une manière ascendante et l'ensemble des successeurs de chaque bloc de base est utilisé. Ainsi, quand le point fixe est atteint, nous obtenons la liste des L-blocs qui seront les premiers à être chargés dans le cache : les blocs utilisés au plus tôt en raison du parcours en sens inverse du CFG.

Une fois les ensembles ENTRY et les états du cache MUST et MAY calculés, nous

144144

/* Initialisation */for B k∈BBT do { IN[Bk ]= OUT [Bk ]=LT ; }

/* Main Loop */IN [Bk ] = J∩ OUT[ s] ; // s∈Successor [Bk ]

Figure 4.22 - Analyse MUSTENTRY

/* Initialisation */for Bk∈BBT do { IN[B k ]= OUT [B k ]=∅ ; }/* Main Loop */

IN [Bk ] = J∪ OUT[ s] ; // s∈Successor [Bk ]

Figure 4.23 - Analyse MAYENTRY


pouvons calculer pour chaque instance Ti ,j d'une tâche Ti, un intervalle du nombre de hits [minHit, MaxHit]. La borne inférieure est l'intersection de son MUST ENTRY et son IN MUST tandis que la borne supérieure est l'intersection de son MAY ENTRY et de son IN MAY .

Donc le résultat du MUST est un résultat minimal mais sûr, de l'approche indépendamment du chemin d'exécution des tâches. Le WCET initial étant donné, la pénalité du miss et le coût du hit connus, nous utilisons le nombre de hit minimal pour affiner l'estimation initiale du WCET. La nouvelle estimation du WCET notée par WCETNEW est calculé comme suit:

WCET NEW =WCET Initial −minHit × Miss penalty minHit × HitCost

Notons que si nous connaissions le chemin d'exécution de la tâche, nous serions capables de définir un nombre exact de hits qui peut être utilisé pour affiner encore plus l'estimation du WCET initial au cas où ce nombre est supérieur au minHit.

6. INJECTION D'UN ÉTAT DU CACHE ET CALCUL DU WCET

Nous avons proposée une approche qui analyse un ordonnancement statique des tâches d'une application temps-réel pour construire les états du cache d'instruction à l'entrée de chaque tâche afin d'optimiser l'estimation du WCET des tâches.

L'analyse ENTRY permet d'affiner l'estimation initiale du WCET en combinant l'état en IN de la tâche avec l'ensemble des L-blocs qui seront les premiers à être chargés dans les lignes du cache. Elle permet d'identifier les faux miss induits par les hypothèses conservatrices utilisées par les autres approches intra-tâche. Ces miss sont considérés comme hits dans la nouvelle estimation du WCET. ENTRY fournit un intervalle pour le nombre de hits pour chaque instance des tâches de l'application. La borne inférieure, fournie par l'analyse MUST, est le nombre de hits qu'ont doit obtenir quel que soit le flot de contrôle de la tâche. Tandis que la borne supérieure fournie par l'analyse MAY est une valeur maximale qui ne sera jamais atteinte mais qui est utilisée pour borner l'estimation de ce nombre de hits.

Nous proposons dans ce paragraphe un autre usage des états du cache d'instruction fournis par l'analyse inter-tâche. Cette méthode consiste à utiliser l'état du cache à l'entrée de chaque tâche et le fournir à la méthode qu'on a utilisée pour calculer les estimations initiales des WCET. Ainsi l'état indéfini sera remplacé par un état bien précis. Nous désignerons ce processus par réinjection dans la suite ce document. Comme l'analyse MAY est très vague, difficile et peu utile pour le calcul effectif des miss, car elle combine tous les états possibles du cache, nous utiliserons la réinjection uniquement pour les résultats de l'analyse MUST.

145145

Chapitre 4 - Analyse d'une application multi-tâches 6.Injection d'un état du cache et calcul du wcet

L'ensemble MUST ENTRY contient la liste des L-blocs qui seront sûrement les premiers à être chargés dans les lignes du cache quel que soit le flot d'exécution et non seulement pour le chemin d'exécution pire cas. Cependant, si nous analysons le chemin d'exécution pire cas seul nous construisons un ensemble ENTRY qui est au moins égal à MUST ENTRY . Cette réalité engendre un certain pessimisme dans le calcul de la nouvelle estimation du WCET par la formule 4.2.

En effet le nombre exact de hits (nbHit) pour le chemin d'exécution pire cas est supérieur ou égal au MinHit fourni par l'analyse ENTRY.

Pour mieux comprendre la différence entre les deux méthodes, la figure 4.24 montre le CFG d'une tâche ayant quatre blocs de base, où chaque bloc de base est formé d'un seul L-bloc. L'étude de ce CFG est fournie pour un cache à accès direct de quatre lignes. Les L-blocs de même couleur sont chargés dans la même ligne du cache et sont donc conflictuels. La figure 4.24 fournit aussi un état du cache à l'entrée de la tâche. Cet état est construit par l'analyse inter-tâche MUST. Le CFG possède deux chemins d'exécution possibles P1={1, 2, 3, 5} et P2={1, 2, 3, 4}.

L'analyse MUST construit l'ensemble MUSTENTRY={1, 2}, comme ces deux L-blocs seront les premiers à être chargés dans le cache pour les deux chemins. Autrement dit, MUSTENTRY

est l'intersection de ENTRYP1 et ENTRYP2. MUSTENTRY combiné avec l'état du cache en entrée {1, a, 4, 2} nous permet d'identifier deux hits. Si on suppose que le coût d'un miss est de 10 cycles et le coût d'un hit est de 1 cycle, la formule 4.2 permet de réduire l'estimation initiale du WCET, notée par w, de 18 cycles. Cette nouvelle estimation est notée par w1.

Or, cette analyse ne considère que les L-blocs communs à tous les chemins d'exécution et n'analyse pas uniquement le chemin pire cas. Supposons que le chemin pire cas est la branche droite du CFG notée précédemment par P2. Alors l'accès au L-bloc 4 engendre un hit qui n'est pas compté lors de l'analyse MUST ENTRY. Si nous remplaçons dans la méthode que nous

146146

Figure 4.24 - Exemple1

Chapitre 4- Analyse d'une application multi-tâches 6.Injection d'un état du cache et calcul du wcet

avons utilisée pour calculer w, l'état indéfini du cache par l'état en entrée connu nous obtiendrons une nouvelle estimation w2 du WCET de cette tâche inférieur à w. De plus w2 est inférieur à w1, car la méthode de calcul du WCET détermine le temps d'exécution du chemin pire cas, elle est donc capable de détecter les hits comptés par l'analyse MUSTENTRY ainsi que le hit induit par la présence du L-bloc 4 dans l'état du cache en entrée d'où l'avantage majeur de la réinjection.

L'estimation fournit par la réinjection sera énormément réduite par rapport l'estimation fournit par l'analyse ENTRY en cas où MUSTENTRY est vide ou très réduit par rapport à l'ENTRY du chemin pire cas comme c'est le cas pour l'exemple de la figure 4.25. Supposons que le chemin pire cas est {a, 1, 2, 4, 5}, l'analyse MUSTENTRY ne peut réduire l'estimation initiale du WCET que de 9 cycles bien que la réinjection réduit cette estimation de 36 cycles.

7. CHOIX DU MEILLEUR ORDONNANCEMENT L'optimisation du WCET des tâches de l'application suite à l'analyse ENTRY ou la

réinjection n'invalide pas l'ordonnançabilité des tâches. En effet, ces tâches sont ordonnançables avec les valeurs initiales de leur WCET qui sont calculées par une approche conservatrice. Ainsi ces WCET initiaux sont des bornes supérieures pour les nouvelles estimations.

Dans ce paragraphe, nous introduisons une idée pour choisir le meilleur ordonnancement

147147

Figure 4.25 - Exemple 2

Chapitre 4 - Analyse d'une application multi-tâches 7.Choix du meilleur Ordonnancement

d'un ensemble des tâches d'une application temps-réel. Le but est de fournir un algorithme itératif qui prend en entrée un ordonnancement initial, puis l'utilise pour effectuer notre analyse inter-tâche pour fournir de nouvelles estimations des WCET des tâches. Ces nouvelles estimations seront utilisées pour générer un nouvel ordonnancement jusqu'à convergence.

Nous ne proposons pas une politique d'ordonnancement, mais nous laissons à l'utilisateur le choix de cette politique qui va être utilisée pour générer l'ordonnancement initial ainsi que les autres ordonnancements intermédiaires dans notre algorithme itératif.

Ainsi les hypothèses fixes de cet algorithme sont les suivantes :

➢ choix de la politique d'ordonnancement (RM, EDF, DM, ...)➢ choix de la méthode du WCET par analyse statique intra-tâche qui supporte la

modélisation de l'état du cache d'instructions➢ choix de la méthode d'amélioration du WCET (ENTRY, réinjection)

Nous avons suggéré au chapitre 2 qu'il est souhaitable de concevoir les applications temps-réels avec des petites tâches plutôt que des tâches très grandes en termes de nombre d'instructions et de WCET. Cette conception favorise la répartition de la charge du processeur sur l'ensemble des sous-cycles de l'ordonnancement qui permettra plus tard de choisir un processeur adéquat pour exécuter cet ordonnancement. En particulier, nous aurons une idée sur la vitesse du processeur requise pour exécuter cet ordonnancement ce qui permet de réduire le coût du matériel car nous n'avons plus à choisir le processeur le plus puissant dès le départ.

Or, la taille des tâches n'est pas le seul paramètre qui peut influencer la répartition de la charge du processeur mais aussi le WCET des tâches et la politique d'ordonnancement jouent un rôle majeur. Nous avons laissé à l'utilisateur le choix de la politique d'ordonnancement car plusieurs politiques d'ordonnancements temps-réel existent et chacune possède ses avantages et ses inconvénients. Notre but est donc d'étudier la variation des WCET des tâches pour choisir le meilleur ordonnancement de ses tâches à partir de la politique choisie.

Nous qualifions de meilleur un ordonnancement qui possède le plus petit WCET global (somme des WCET des instances des tâches).

Nous avons besoin des WCET initiaux, notés par WCET Init , des tâches pour générer l'ordonnancement initial, Oinit et pour vérifier que les ordonnancements intermédiaires sont corrects. Dans la partie initialisation, nous appliquons notre analyse inter-tâche expliquée ci-dessus et améliorons les WCET initiaux des tâches. Les nouvelles estimations des WCET, notées par WCET amélioré vont être utilisées pour générer un nouvel ordonnancement O courant .

Une deuxième étape consiste à appliquer l'analyse inter-tâche sur O courant pour calculer de nouvelles estimations des WCET en fonction du nouvel ordre d'exécution des tâches, ces WCET seront notés par WCET New . Nous avons montré que l'ordre d'exécution des tâches influe sur notre analyse inter-tâche, ainsi en partant des WCET Init et pour des ordres

148148

Chapitre 4- Analyse d'une application multi-tâches 7.Choix du meilleur Ordonnancement

d'exécutions différents, les WCET New peuvent être différents des WCET amélioré .

Cette différence pose un problème si pour une instance donnée T i , j , nous avons WCET New[T i , j]WCET amélioré [T i , j] . En effet, WCET New est fonction de WCET Init , vrai quel que soit l'ordonnancement, et WCET amélioré vrai pour l'ordonnancement Oinit . Si WCET New[T i , j]WCET amélioré [T i , j] alors l'hypothèse que O courant est correct est invalidée. Ainsi, on remplace uniquement pour les tâches qui vérifient cette condition WCET New par WCET Init pour générer un nouvel ordonnancement Onew qui n'invalide pas les améliorations fournies par les WCET amélioré . Après la correction de l'ordonnancement courant, nous pouvons appliquer le test de convergence sur ONew pour vérifier si la convergence est atteinte, donc le meilleur ordonnancement est obtenu, sinon on réitère l'algorithme jusqu'à convergence.

En considérant qu'il y a n instances de tâches dans l'ordonnancement initial généré à partir des WCET Init , l'algorithme itératif peut être écrit comme suit :

Initialisationgénérer de l'ordonnancement initial O Init en fonction des WCET Init des n tâchesconvergence = false;effectuer l'analyse inter-tâche;amélioration des WCET des tâchesfor Ti,j

WCET amélioré [T i , j]=WCET Init [T i , j]nbHit [T i , j]×couthit− penalitémiss;générer un nouvel Ordonnancement O courant ;

do{effectuer l'analyse inter-tâche sur Ocourant ;//calculer les nouvelles estimations des WCET sur Ocourantfor Ti,j

WCET New[T i , j]=WCET Init [T i , j ]nbHit [T i , j]×couthit−penalitémiss ;//corriger les WCET de l'ordonnancement courantfor Ti,j

if( WCET New[T i , j]WCET amélioré [T i , j ] )WCET amélioré [T i , j]=WCET Init [T i , j] ;

else WCET amélioré [T i , j ]=WCET New [T i , j ] ;

générer un nouvelle ordonnancement ONew ;effectuer l'analyse inter-tâche sur ONew ;//calculer les nouvelles estimation for Ti,j

WCET New[T i , j]=WCET Init [T i , j ]nbHit [T i , j]×couthit−penalitémiss ;WCET globalCourant=∑WCET amélioré [T i , j ]WCET globalNew=∑WCET New[T i , j] ;int boucle = 1;if( WCET globalNewWCET globalCourant ){

149149

Chapitre 4 - Analyse d'une application multi-tâches 7.Choix du meilleur Ordonnancement

convergence = true;print (« le meilleur ordonnancement est OCourant »);

}else{

if( WCET globalNew= = WCET globalCourant ) boucle ++;if(boucle <100){

Ocourant=ONew ;WCET amélioré [T i , j ]=WCET New [T i , j ] , ∀T i , j ;

}else{

convergence = true;print (« le meilleur ordonnancement est OCourant »);

}}

}while(!convergence)

8. CONCLUSION

Nous avons proposé une nouvelle approche pour des systèmes temps-réel stricts, multi-tâches et non préemptifs.

Notre méthode consiste à étudier un ordonnancement statique des tâches de ces systèmes pour optimiser l'estimation initiale de leurs WCET en modélisant le comportement du cache d'instruction. Les WCET initiaux sont calculés par n'importe quelle analyse intra-tâche qui permet de modéliser le comportement du cache d'instruction.

Notre analyse consiste à étudier le comportement du cache intra- et inter-tâche qui permet de bénéficier de la trace de l'enchaînement des tâches dans le cache. Nous identifions ainsi les hits considérés comme miss par les approches conservatrices. Nous utilisons un algorithme de DFA et nous proposons une analyse MUST qui fournit des résultats sûrs et une analyse MAY qui fournit des résultats probables.

L'analyse intra-tâche nous permet de construire pour chaque tâche de l'application : l'ensemble, EXIT, des L-blocs qui seront dans le cache à la fin de son exécution, l'ensemble ENTRY qui contient la liste des L-blocs qui seront les premiers à être chargés dans les lignes du cache et pour terminer nous calculons le nombre de remplacements qui aura lieu dans le cache suite à l'exécution de la tâche. Les résultats de cette analyse sont vrais quel que soit l'ordonnancement des tâches. Ils sont calculés en supposant un état vide du cache d'instruction avant l'exécution de la tâche. D'autre part, nous effectuons une analyse inter-tâche qui en fonction de l'ordonnancement des tâches construit les états du cache avant et après l'exécution de chaque tâche.

Ayant terminé ces deux analyses, nous proposons deux méthodes pour améliorer les estimations initiales des WCET: 1) la première, ENTRY, compte le nombre de hits oubliés en combinant les résultats des analyses inter- et intra-tâche et substitue les coûts de miss par des

150150

Chapitre 4- Analyse d'une application multi-tâches 8.Conclusion

coûts de hit pour calculer la nouvelle estimation ; 2) une deuxième méthode par réinjection consiste à remplacer l'état indéfini du cache, dans la méthode conservatrice qui a fourni les estimations initiales, par les états inter-tâche fournis par notre analyse. Les deux méthodes ont été implantées dans l'outil OTAWA [25], [26].

Finalement nous avons proposé un algorithme itératif qui permet de choisir le meilleur ordonnancement des tâches d'une application temps-réel suite à l'application de notre méthode. Nous testerons notre approche dans le chapitre suivant sur les deux versions de PapaBench, mais nous n'avons pas expérimenté l'algorithme itératif. Cet algorithme est pour le moment une idée non implantée et non expérimentée.

Notre méthode étudie uniquement le comportement du cache d'instruction mais elle peut être adaptée pour étudier l'état de n'importe quel composant matériel dont le comportement dépend de l'ordonnancement des tâches.

151151

152152

CHAPITRE 5

EXPÉRIMENTATIONS

Nous avons proposé au chapitre précédent une approche qui analyse les systèmes temps-réel stricts, multi-tâches non préemptifs. Cette analyse consiste à étudier un ordonnancement statique des tâches du système pour prédire le comportement inter-tâche du cache d'instruction. La modélisation des états du cache permet d’identifier les hits considérés comme miss par les approches conservatrices. Ces hits sont utilisés pour affiner l'estimation initiale du WCET des tâches de l'application.

Ce chapitre est consacré à la présentation des résultats de nos expérimentations effectuées sur les deux versions de PapaBench. Ces expérimentations ont permis d'étudier la variation du nombre de hits en fonction de la variation des paramètres du cache d'instruction.

Nous comparons aussi l'impact de l'analyse ENTRY et de la réinjection sur les WCET initiaux des tâches. Ces WCET peuvent être calculés par n’importe quelle approche par analyse statique intra-tâche (chapitre 3) qui suppose un contexte d’exécution indéfini pour chaque tâche et modélise son comportement dans le cache d’instructions.

1. BENCHMARKS

Comme les benchmarks temps-réel ne représentent pas les caractéristiques d'une application complète, ils ne permettent pas d'analyser l'effet de l'enchaînement des tâches sur l'estimation du WCET. Ainsi nous utilisons uniquement PapaBench pour montrer les avantages de notre approche.

Des mesures seront fournies pour les deux versions du benchmark. Nous utilisons un modèle AADL double processeurs car les versions actuelles de PapaBench ne permettent pas de compiler l'application sur un seul processeur. Nous avons donc deux microcontrôleurs ayant chacun une liste de tâches. Chaque microcontrôleur possède sa propre mémoire ce qui fait que l'ordonnancement des tâches de l'un n'a aucun effet sur l'ordonnancement de l'autre. Ainsi l'état de l'un n'affecte pas l'état de l'autre et par suite n'a aucun effet sur le contexte d'exécution de ses tâches.

153153

Chapitre 5 - Expérimentations 2.Outils

2. OUTILS

Nous avons utilisé OTAWA [25], [26], un environnement « open source » dédié à l'analyse statique d'un code exécutable, pour calculer les WCET des tâches de PapaBench1 et PapaBench2. Dans cet environnement, le calcul du WCET consiste à réaliser une chaîne d'analyses qui utilisent et produisent des annotations accrochées au code jusqu'à l'obtention du WCET. Nous avons choisi la technique d'énumération implicite des chemins IPET (Implicit Path Enumeration Technique) [28] et l'approche CAT2 pour estimer les effets du cache d'instruction sur l'évaluation du WCET. CAT2 est notre adaptation de la méthode par catégorisation de Ferdinand [61] à la technique IPET5. La chaîne d'analyse effectuée sur le code génère un ensemble de n équations à n inconnues. La solution de ce système est réalisé par un solveur linéaire (Integer Linear Programming solver) lp_solve 5.5 et fournit la valeur du WCET de la tâche.

La méthode IPET utilise un simulateur de processeur pour effectuer les calculs nécessaires. Nous avons choisi un modèle de processeur générique doté d'un pipeline de quatre étages avec une politique d'exécution ordonnée des instructions. Chaque étage du pipeline traite deux instructions par cycle et possède deux unités de calcul entier et deux unités de calcul des flottants. Le binaire utilisé est généré par le compilateur PowerPC de GCC. Les WCET ainsi calculés sont utilisés pour générer des ordonnancements dans l'outil des générations d'ordonnancements temps-réel CHEDDAR [18]. Chaque tâche est caractérisée par une période, un WCET et une date d'échéance supposée être à la fin de la période. Pour chaque version du benchmark, nous avons généré quatre ordonnancements différents, suivant les politiques, RM, DM, EDF et LLF. En supposant que la date d'échéance est égale à la période, DM est identique à RM. Nous utilisons donc uniquement RM, EDF et LLF dans nos expérimentations.

3. RÉSULTATS

Nous avons testé notre approche avec plusieurs configurations du cache et trois ordonnancements possibles des tâches pour chaque version de PapaBench.

Nous présentons au début la variation du nombre de hits en fonction des paramètres du cache (taille du cache, taille de bloc, degré d'associativité). Ensuite, nous étudions l'impact de la variation de la politique d'ordonnancement sur le calcul du nombre hits total. Le nombre de hit total est la somme des nombre des hits détectés pour chaque instance de tâche dans l'ordonnancement. Enfin, nous comparons l'impact de l'analyse ENTRY et de la réinjection sur l'amélioration de l'estimation initiale des WCET des tâches et sur le WCET global de l'application.

5 Pour plus de détails concernant ces deux techniques, voir le chapitre 3.

154154

Chapitre 5- Expérimentations 3.Résultats

3.1. VARIATION DES PARAMÈTRES DU CACHE

3.1.1. Variation de la taille de blocLes tâches de mcu0 représentent, en PowerPC, 30 Ko et celles de mcu1 3 Ko. Nous avons

choisi une taille moyenne d'un cache d'instruction de 16 Ko pour tester la variation du nombre de hits total en fonction de la taille du bloc mémoire. Nous avons étudié cette variation pour un cache à accès direct (A1) et pour des caches associatifs de degré 2 et 4 (A2 et A4).

Les figures 5.1, 5.2 et 5.3 montrent les résultats de cette étude pour un ordonnancement RM de mcu0 (PapaBench1), de mcu0 (PapaBench2) et de mcu1 respectivement. Comme les tâches de mcu1 sont identiques dans les deux versions, nous ne distinguons pas mcu1 (PapaBench1) et mcu1(PapaBench2) ni pour cette étude, ni pour les études suivantes.

Nous déduisons de ces trois figures que le nombre de hits décroît lorsque la taille du bloc de cache augmente pour une même taille du cache. Et ces résultats sont vrais pour un cache d'instructions à accès direct ainsi que pour un cache associatif. Ainsi avec une taille de bloc de

155155

Figure 5.1 - mcu0 (PapaBench1), nombre de hits total (cache 16 Ko)

0

100

200

300

400

500

600

700

800

A1 A2 A4

B8o

B16o

B32o

Figure 5.2 - mcu0 (PapaBench2), nombre de hits total (cache 16 Ko)

0

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

A1 A2 A4

B8o

B16o

B32o

Chapitre 5 - Expérimentations 3.Résultats

8 octets, le nombre de hits est le plus grand. Ceci est certainement dû au fait que, quand la taille de bloc est petite, le code est mieux réparti dans la mémoire cache ce qui diminue les conflits entre les L-blocs des tâches. Notons aussi que ces résultats montrent que pour une taille réduite du bloc du cache le nombre de hits oubliés est plus grand, d'où l'intérêt d'appliquer notre approche. De plus, nous voyons également que, dans tous les cas, le nombre de hits oubliés puis, détectés est loin d'être négligeable.

3.1.2. Variation de la taille du cacheNous avons ensuite fixé la taille du bloc de cache à 8 octets, comme le nombre de hits

oubliés pour cette taille est très grand, et nous avons testé notre approche sur plusieurs tailles du cache : 8 Ko, 16 Ko, 32 Ko, 64 Ko et 128 Ko sur mcu0. La taille 4Ko est uniquement testée pour mcu1 car pour mcu0, elle fournit plus de conflits donc un nombre de hits très petit donc non intéressant.

156156

Figure 5.3 - mcu1, nombre de hits total (cache 16 Ko)

Figure 5.4 - mcu0(PapaBench1), nombre de hits total (taille bloc 8 octets)

0

200

400

600

800

1000

1200

8Ko 16Ko 32Ko 64Ko 128Ko 8Ko 16Ko 32Ko 64Ko 128Ko 8Ko 16Ko 32Ko 64Ko 128Ko

A1 A2 A4

0

20

40

60

80

100

120

A1 A2 A4

B8o

B16o

B32o


Pour valider nos résultats pour un cache à accès direct et pour les caches associatifs, nous avons mesuré le nombre de hits total en variant le degré d'associativité (1, 2, 4) pour chaque taille du cache. Les figures 5.4, 5.5 et 5.6 montrent les résultats pour un ordonnancement RM de mcu0 (PapaBench1), mcu0 (PapaBench2) et mcu1 respectivement.

Nous avons constaté que pour un même degré d'associativité, le nombre de hits total pour l'ordonnancement des tâches choisi augmente en fonction de la taille du cache pour mcu0 dans les deux versions de PapaBench. Ceci est logique car, pour une taille petite de bloc, comme le code est mieux réparti dans la mémoire cache, si on augmente la taille du cache, il y

157157

Figure 5.5 - mcu0(PapaBench2), nombre de hits total (taille bloc 8octets)

0

5000

10000

15000

20000

25000


A1 A2 A4

Figure 5.6 - mcu1, nombre de hits total (taille de bloc 8octets)

75

80

85

90

95

100

105

4Ko 8Ko 16Ko 32Ko 64Ko 128Ko 4Ko 8Ko 16Ko 32Ko 64Ko 128Ko 4Ko 8Ko 16Ko 32Ko 64Ko 128Ko

A1 A2 A4


aura plus de L-blocs qui seront chargés dans le cache et non supprimés à un point donné de l'ordonnancement.

Cependant, pour les tailles du cache testées, la variation de la taille du cache n'affecte pas énormément le nombre de hits total pour un ordonnancement de mcu1. En effet, pour un cache à accès direct aucun effet n'est constaté donc il vaut mieux choisir la taille du cache la plus petite de 4 Ko pour réduire le coût matériel du système. En outre, pour un cache associatif de degré 2, la meilleur taille de cache est de 8 Ko alors qu'une taille de 16 Ko convient le plus pour un cache associatif par ensembles de quatre lignes.

La taille de cache qui fournit le meilleur nombre de hits total est 128Ko pour mcu0 dans les deux versions de PapaBench, ce qui est assez logique vu qu'il contient complètement l'application. Or, si le coût matériel du système est limité, il faut choisir un cache de taille plus petite donc moins cher pour réduire ce coût. Nous pouvons choisir une taille pour laquelle le nombre de hits obtenu est assez grand pour réduire le WCET total de l'application. Comme le nombre de hits calculé pour 8 Ko n'est pas intéressant comparé aux autres résultats, nous pouvons choisir parmi les tailles 16 Ko, 32 Ko et 64 Ko.

3.1.3. Variation du degré d'associativitéAprès avoir étudié l'impact de la variation de la taille du cache et la taille du bloc sur les

résultats de notre approche, nous avons fixé la taille du bloc à 8 octets et fait varier le degré d'associativité pour trois tailles de cache 8 Ko, 16 Ko et 32 Ko. Le but est d'observer la variation du nombre de hits total d'un ordonnancement RM de mcu0 et mcu1 pour un cache variant de l'accès direct au cache totalement associatif. Ces mesures répondent à la question suivante : est ce qu'il faut augmenter l'associativité du cache pour avoir plus de hits ?

158158

Figure 5.7 - mcu0 (PapaBench1), variation du nombre de hits total en fonction de A

0

100

200

300

400

500

600

700

800

900

1000

A1 A2 A4 A8 A16 A32 A64 A128 A256 A512 A1024 A2048 A4096

16Ko

32Ko


Les figures 5.7, 5.8 et 5.9 montrent que le nombre de hits augmente en fonction du degré d'associativité pour atteindre un maximum pour un A donné qui est différent selon la taille du cache. Ensuite, pour des degrés d'associativité supérieurs à A, le nombre hits diminue puis se stabilise. Donc la variation du nombre de hits possède une allure parabolique sauf pour mcu1 qui présente quelques particularités. Ainsi pour un cache de 16 Ko le meilleur degré d'associativité est 32 pour mcu0 (PapaBench1), et 8 pour mcu0 (PapaBench2) ; pour un cache de 32 Ko, mcu0 (PapaBench1) obtient un nombre de hit maximal pour A=8 et mcu0 (PapaBench2) atteint le maximum pour A=4.

En revanche pour mcu1, le maximum est atteint en A égal à {2, 4, 16, 32} pour un cache de 16Ko, et en A égal à {2, 4, 8, 16, 32, 64} pour un cache de 32Ko. Donc, le mieux est de choisir un cache associatif de degré 2 pour mcu1.

159159

Figure 5.9 - mcu1, variation du nombre de hits total en fonction de A

40

50

60

70

80

90

100

A1 A2 A4 A8 A16 A32 A64 A128 A256 A512 A1024 A2048 A4096

16Ko

32Ko

Figure 5.8 - mcu0 (PapaBench2), variation du nombre de hits total en fonction de A

0

5000

10000

15000

20000

25000

A1 A2 A4 A8 A16 A32 A64 A128 A256 A512 A1024 A2048 A4096

16Ko

32Ko


Nous avons montré que la variation du degré d'associativité influe sur le nombre hits total mais il n'est pas toujours nécessaire d'augmenter indéfiniment le degré d'associativité et qu'un cache totalement associatif n'est pas toujours meilleur qu'un cache associatif par ensembles, ni même un cache à accès direct.

3.2. VARIATION DE L'ORDONNANCEMENT

L'ordre d'exécution des tâches influe sur les résultats de notre analyse. En effet, les états du cache IN avant l'exécution de chaque tâche dépend de la trace laissée par l'exécution des tâches précédentes dans le cache d'instruction. Ainsi, la variation de l'ordre d'ordonnancement peut augmenter ou diminuer le nombre de hits global obtenu pour une même configuration du cache.

Nous avons testé notre approche sur trois ordonnancements RM, EDF et LLF des tâches de mcu0 et mcu1. La taille du bloc de cache est fixée à 8 octets et la taille du cache à 16 Ko et nous avons testé l'impact de la variation de l'ordonnancement pour des degrés d'associativité différents A variant parmi 1, 2, 4 et 8. Les figures 5.10, 5.11 et 5.12 montrent les résultats de ces mesures pour les ordonnancement de mcu0 (PapaBench1), mcu0 (PapaBench2) et mcu1 respectivement.

Nous pouvons déduire des figures 5.10 et 5.11 que la variation de l'ordre d'exécution des tâches influe peu sur le calcul du nombre de hits global. Ainsi pour un cache à accès direct et un cache associatif de degré 2, les trois ordonnancements fournissent le même résultat pour mcu0 (PapaBench1). Cependant RM et LLF donnent des résultats meilleurs que EDF pour le cache associatif de degré 8, tandis que EDF est le meilleur ordonnancement pour un cache associatif de degré 4. Or, pour mcu0 (PapaBench2), RM est le meilleur ordonnancement pour

160160

Figure 5.10 - mcu0 (PapaBench1), impact de la variation de l'ordonnancement

550

600

650

700

750

800

850

A1 A2 A4 A8

RM

EDF

LLF


un degré d'associativité du cache d'instruction analysé inférieur à 8, tandis que LLF est le meilleur ordonnancement pour A égal à 8.

En revanche, la figure 5.12 montre que la variation de l'ordonnancement n'a aucun impact sur l'estimation du nombre de hits global sauf pour un degré d'associativité égale à 8 pour un cache de taille 16 Ko avec une taille de bloc de 8 octets. Ainsi, quand A est inférieur à 8 nous sommes libres de choisir l'ordonnancement d'une manière indifférente des performances, cependant pour A égal à 8, RM et EDF sont meilleurs que LLF.

Donc, ayant choisit la configuration du cache qui convient le plus à l'application, en fonction d'un ordonnancement choisi à l'avance, notre approche permet en plus de vérifier que

161161

Figure 5.11 - mcu0 (PapaBench2), impact de la variation de l'ordonnancement

15000

16000

17000

18000

19000

20000

A1 A2 A4 A8

RM

EDF

LLF

Figure 5.12- mcu1, impact de la variation de l'ordonnancement

75

80

85

90

95

100

105

A1 A2 A4 A8

RM

EDF

LLF


cet ordonnancement est le plus adapté en termes de nombre de hits, sinon nous pourrions choisir un meilleur ordonnancement des tâches de l'application.

3.3. COMPARAISON RÉINJECTION ENTRY

L'ensemble MUST ENTRY contient la liste des L-blocs qui seront sûrement les premiers à être chargés dans les lignes du cache quel que soit le flot d'exécution et non seulement pour le chemin d'exécution pire cas. Cet ensemble permet d'identifier les faux miss induits par les approches conservatrices. Or, la combinaison de cet ensemble avec le IN MUST permet d'identifier un nombre de hits minimal quel que soit le flot d'exécution de la tâche. Inversement, la réinjection permet analyser l'impact d'un état bien défini du cache IN MUST sur le nombre de hits du chemin d'exécution pire cas exactement. Nous avons montré sur un exemple que la réinjection permet d'obtenir un nombre de hits supérieur ou égal au nombre de hits obtenu par l'analyse ENTRY.

Dans ce paragraphe, nous comparons les résultats des deux méthodes pour un ordonnancement RM de mcu0 et mcu1 et pour un cache 16 Ko ayant une taille de bloc de 8 octets. Mais, nous varions le degré d'associativité pour observer la différence des résultats des deux analyses.

Les figures 5.13, 5.14 et 5.15 montrent les résultats de cette comparaison pour mcu0 (PapaBench1), mcu0 (PapaBench2) et mcu1 respectivement. Nous remarquons que, quel que soit le degré d'associativité du cache, les résultats de la réinjection sont meilleurs que les résultats de l'analyse ENTRY. Cependant, pour mcu0 (PapaBench1), cette différence est seulement de 9 hits pour A>=2 et de 26 hits pour un cache à accès direct. Or, il est plus coûteux en temps de calcul de réinjecter les états du cache pour améliorer l'estimation du

162162

Figure 5.13- mcu0 (PapaBench1), réinjection / ENTRY

500

550

600

650

700

750

800

850

A1 A2 A4 A8

reinjection

ENTRY


WCET global, l'analyse ENTRY est suffisante. Mais, pour mcu1 et mcu0 (PapaBench2), il est préférable de réinjecter les états IN pour améliorer la performance de l'application car la différence entre les deux méthodes varie 610 à 2589 hits pour mcu0 et entre 132 à 150 hits pour mcu1.

3.3.1. Amélioration des WCET des tâches et du WCET globalAprès avoir analysé la variation du nombre de hits en fonction des paramètres du cache et

en fonction de la variation de l'ordonnancement des tâches, ce paragraphe montre l'impact de notre analyse sur le WCET des tâches et sur le WCET global de l'application.

163163

Figure 5.14 - mcu0 (PapaBench2), réinjection / ENTRY

15000

16000

17000

18000

19000

20000

21000

A1 A2 A4 A8

ReinjectionENTRY

Figure 5.15 - mcu1, réinjection / ENTRY

0

50

100

150

200

250

300

A1 A2 A4 A8

reinjectionENTRY


Nous calculons le WCET moyen de chaque tâche suite à l'application de notre approche (ENTRY et réinjection) et le gain sur le WCET initial, ces deux valeurs sont représentées en pourcentage sur le WCET initial.

Nous avons choisi un ordonnancement Rate Monotonic des tâches de mcu0 et de mcu1, et un cache d'instruction de taille 16 Ko avec une taille de bloc 8 octets et associatif par ensembles de taille 2, avec une pénalité de miss de 10 cycles et un coût de hit de 1 cycle. Les résultats de nos calculs sont présentés dans les figures 5.16, 5.17 et 5.18 pour mcu1, mcu0 (PapaBench1) et mcu0 (PapaBench2) respectivement.

Pour terminer, le gain moyen entre les tâches de mcu1 est de 17,8% pour ENTRY et de 28,4% pour la réinjection. Ce gain atteint les 52,9% pour la tâche __vector_6 en appliquant l'analyse ENTRY et le 64,2% en appliquant la réinjection. Cette tâche est très petite et ne contient pas de boucle donc tous les L-blocs accédés ont conservativement donné lieu à un miss alors qu'elle possède une fréquence très grande.

Le pourcentage moyen de gain des tâches de mcu0 (PapaBench1) est de 7,5% pour ENTRY et de 8,5% pour la réinjection. Mais ce gain atteint les 41,9% pour la tâche « stabilisation_task » en appliquant l'analyse ENTRY et les 46,7% en appliquant la réinjection.

164164

Figure 5.16 - mcu1, amélioration des WCET des tâches

0% 20% 40% 60% 80% 100%

servo_transmit

__vector_10

__vector_6

check_mega128_values_task

check_failsafe_task

servo_transmit

__vector_10

__vector_6

check_mega128_values_task

check_failsafe_task

Réi

njec

tion

ENTR

Y

WCET Moyen Gain


De même, pour mcu0 (PapaBench2), le gain moyen est de 5,6% pour ENTRY et de 6,7% pour la réinjection. Ce gain atteint les 55% pour « stabilisation_task » en appliquant ENTRY et les 62% en appliquant la réinjection.

165165

Figure 5.17 - mcu0 (PapaBench1), amélioration des WCET des tâches

0% 20% 40% 60% 80% 100%

__vector_12__vector_17__vector_30__vector_5

altitude_control_taskclimb_control_task

link_fbw_sendnavigation_task

receive_gps_data_taskreporting_task

stabilisation_task__vector_12__vector_17__vector_30__vector_5


link_fbw_sendnavigation_task

receive_gps_data_taskreporting_task

stabilisation_taskRé

injec

tion

ENTR

Y

WCET Moyen Gain Moyen


166166

Figure 5.18 - mcu0 (PapaBench2), amélioration des WCET des tâches

0% 20% 40% 60% 80% 100%

__vector_12__vector_17__vector_30__vector_5


course_runlink_fbw_send

navigation_updateparse_gps_msg

send_adcsend_attitude

send_batsend_boot

send_climbsend_debug

send_desiredsend_gps_pos

send_modesend_nav_ref

send_nav_valuessend_radIR

send_settingssend_takeOff

stabilisation_task__vector_12__vector_17__vector_30__vector_5


course_runlink_fbw_send

navigation_updateparse_gps_msg

send_adcsend_attitude

send_batsend_boot

send_climbsend_debug

send_desiredsend_gps_pos

send_modesend_nav_ref

send_nav_valuessend_radIR

send_settingssend_takeOff

stabilisation_task

Réinj

ectio

nEN

TRY

WCET Moyen Gain Moyen


Les figures 5.19, 5.20 et 5.21 montrent le pourcentage de gain obtenu sur le WCET global de l'ordonnancement des tâches de mcu0 (PapaBench1), mcu0 (PapaBench2) et mcu1 respectivement en appliquant l'analyse ENTRY. Nous calculons ce pourcentage pour différentes configurations du cache avec une taille du bloc fixée à 8 octets et nous varions la taille du cache et le degré d'associativité. La pénalité de miss est fixé dans le cache à 10 cycles et le coût d'un hit à un cycle.

167167

Figure 5.20 - mcu0 (PapaBench2), Pourcentage de réduction du WCET global

0%10%20%30%40%50%

60%70%80%90%

100%


A1 A2 A4

WCET Global Gain

Figure 5.19 - mcu0 (PapaBench1), Pourcentage de réduction du WCET global

0%10%20%30%40%50%

60%70%80%90%

100%


A1 A2 A4

WCET Global Gain


Le pourcentage de gain pour mcu0 (PapaBench1) est en moyenne de 5% et peut atteindre les 8% selon la configuration utilisée du cache d'instructions. Pour mcu0 (PapaBench2), le pourcentage moyen de gain et de 10,98% et peut atteindre les 13,73%. Enfin, pour mcu1 le pourcentage moyen et le pourcentage maximal est de 10,15%.

4. CONCLUSION

Nous avons présenté dans ce chapitre les résultats de l'expérimentation de notre approche sur les deux versions de PapaBench. Nous avons étudié la variation du nombre de hits global en fonction de la variation des paramètres du cache d'instruction. Nous avons aussi analysé l'impact de la variation de la politique d'ordonnancement sur le calcul du nombre hits total. Enfin, nous avons comparé l'impact de l'analyse ENTRY et de la réinjection sur l'amélioration de l'estimation initiale des WCET des tâches et sur le WCET global de l'application.

Ces résultats montrent que notre approche permet de choisir la meilleure configuration du cache (taille du cache, taille de bloc, degré d'associativité) pour un ordonnancement de tâches fixé au départ. Ensuite, elle permet de choisir, en fonction de la configuration du cache, le meilleur ordonnancement de ces tâches. Les mesures montrent que le gain obtenu par rapport au WCET global varie entre 5 et 13,73% en fonction de la configuration du cache pour une taille de bloc de 8 octets. Le gain moyen du WCET des tâches varie entre 5,6 et 64,2% pour un cache de 16 Ko et une taille de bloc de 8 octets avec un degré d'associativité 2.

Ainsi, à partir des WCET initiaux des tâches, nous pouvons choisir une vitesse de processeur pour laquelle la liste des tâches est ordonnançable puis, en fonction de cet ordonnancement, choisir la meilleure configuration du cache et le meilleur ordonnancement

168168

Figure 5.21 - mcu1, Pourcentage de réduction du WCET global

0%10%20%30%40%50%60%70%80%90%

100%

8K

o

16K

o

32K

o

64K

o

128K

o

8K

o

16K

o

32K

o

64K

o

128K

o

8K

o

16K

o

32K

o

64K

o

128K

o

A1 A2 A4

WCET global Gain

Chapitre 5- Expérimentations 4.Conclusion

de ces tâches. Après avoir appliqué notre approche pour améliorer les WCET initiaux, nous vérifions si nous les améliorations nous permettent de choisir une vitesse plus basse du processeur. Ainsi, nous sommes capables d'optimiser le coût de l'architecture matérielle nécessaire pour faire tourner l'application par rapport à des critères de pire temps d'exécution.

169169

170170

CONCLUSION

L'objectif de notre étude a été l'amélioration du temps d'exécution pire cas des tâches d'une application temps-réel par analyse statique du comportement inter-tâche du cache d'instruction. Nous dressons dans ce chapitre un bilan de notre travail et nous présentons ensuite les perspectives ouvertes par ce dernier.

RÉSUMÉ

Les systèmes temps-réel se distinguent des autres systèmes informatique par la prise en compte de contraintes temporelles dont le respect est aussi important que l'exactitude du résultat. Notre étude s'intéresse principalement aux systèmes temps-réel stricts qui ne tolèrent aucun dépassement de ces contraintes, car de tels dépassements peuvent conduire à des situations critiques, voire catastrophiques.

Théoriquement, le concepteur d'un système temps-réel strict devrait être capable de prouver que les limites temporelles ne seront jamais dépassées quelle que soit la situation. Cette vérification est appelée test d'acceptabilité, analyse de faisabilité ou encore contrôle d'admission ; elle fait appel à la théorie de l'ordonnancement. Elle dépend de la politique d'ordonnancement utilisée et des caractéristiques des tâches du système. Cette analyse nécessite en particulier la connaissance du temps d'exécution pire cas des tâches. Le WCET d'une tâche peut être calculé en mesurant son temps d'exécution sur un système réel ou un simulateur, connaissant tous les jeux d'entrée possibles. Mais ceci n'est pas toujours possible en pratique car la complexité des programmes à analyser conduit à un nombre extrêmement grand de tests possibles. D'où la nécessité des analyses statiques qui analysent le code source sans avoir à l’exécuter sur le matériel cible. Ces méthodes fournissent alors une borne supérieure du WCET appelé aussi « WCET estimé ».

Si pour un programme donné, on a pu définir le jeu d'entrée pire cas, alors la mesure dynamique de son temps d'exécution permet d'obtenir une valeur précise du WCET notée par « WCET réel ». Mais si le jeu d'entrée pire cas ne peut être défini, ces mesures ne garantissent que le temps d'exécution du programme soit bien son temps d'exécution pire cas. Dans ce cas, les mesures risquent d'être très optimistes, ce qui peut générer un dépassement des contraintes temporelles. En revanche, les approches par analyse statique ont l'avantage d'être sûres. Cette

171171

sûreté des estimations a une contrepartie, les estimations obtenues sont pessimistes. Ce pessimisme induit une surestimation des moyens matériels nécessaires au fonctionnement du système.

Comme la plupart des systèmes temps-réel stricts sont embarqués, ils possèdent en plus des contraintes temporelles, des contraintes de ressources, telles que : la mémoire, la consommation électrique, la taille, le poids, la puissance de calcul, etc. Il faut à tout prix optimiser le calcul du WCET estimé pour respecter toutes ces contraintes.

La plupart des méthodes d'évaluation du WCET par analyse statique calculent le WCET d'une tâche en considérant un état vide ou indéfini du matériel notamment du cache d'instruction assurant ainsi une surestimation du WCET qui garantit la contrainte que le WCET estimé est supérieur ou égal au WCET réel. Bien que ces méthodes produisent des approximations sûres sous réserve de certaines hypothèses sur le processeur, elles ignorent plusieurs facteurs des systèmes temps-réel multi-tâches, essentiellement l'enchaînement des tâches, qui affectent naturellement la précision du WCET estimé. Plusieurs techniques modélisent le comportement du cache intra-tâche et rares sont celles qui traitent l'état du cache inter-tâche.

Nous avons proposé une nouvelle approche, qui s’applique aux systèmes temps-réel stricts, multi-tâches. Cette méthode étudie un ordonnancement statique des tâches d’une application temps-réel pour analyser le comportement inter- et intra-tâche du cache d'instruction LRU. Le but est de remplacer les hypothèses conservatrices qui supposent un état vide ou indéfini du cache par un état bien défini avant l’exécution de chaque tâche de l’ordonnancement. Ceci va nous permettre d’optimiser l’estimation du WCET de ces tâches en utilisant la trace de l’exécution d’autres tâches dans le cache. Nous identifions ainsi les hits considérés comme miss par les approches conservatrices. Nous utilisons un algorithme de DFA pour implémenter notre approche et nous proposons une analyse MUST qui fournit des résultats sûrs et une analyse MAY qui fournit des résultats probables. Notre méthode comporte une analyse intra-tâche et une analyse inter-tâches. L'analyse est appliquée au début à un cache à accès direct, mais nous présentons aussi la généralisation de notre approche au cas d'un cache associatif de degré A, et un cache totalement associatif.

L'analyse intra-tâche consiste à identifier pour chaque tâche l'ensemble des L-blocs qui seront dans le cache après l'exécution de la tâche, noté par EXIT, et l'ensemble des L-blocs qui seront les premiers à être chargés dans le cache pendant l'exécution de la tâche, noté ENTRY. Nous construisons l'ensemble ENTRY car ses éléments sont les seuls à être affectés par la variation de l'état du cache à l'entrée de la tâche. Ces ensembles sont calculés en supposant un état vide du cache d'instruction avant l'exécution de la tâche.

L'analyse inter-tâche construit, en fonction de l'ordonnancement des tâches, les états du cache avant, IN, et après, OUT, l'exécution de chaque tâche à partir des ensembles EXIT.

Ayant terminé ces deux analyses nous proposons deux méthodes pour améliorer les estimations initiales des WCET : 1) la première ENTRY, identifie les hits considérés comme

172172

miss par les approches conservatrices, en effectuant pour chaque tâche l'intersection de son couple (IN, ENTRY), si l'ensemble résultant est non vide, on substitue, pour ses éléments, les coûts de miss par des coûts de hit pour calculer la nouvelle estimation ; 2) une deuxième méthode par Réinjection, consiste à remplacer l'état indéfini du cache, dans la méthode conservatrice qui a fourni les estimations initiales, par les états inter-tâche fournis par notre analyse.

Finalement, nous avons proposé un algorithme itératif qui permet de choisir le meilleur ordonnancement des tâches d'une application temps-réel suite à l'application de notre méthode. L'algorithme itératif prend en entrée un ordonnancement initial, puis l'utilise pour effectuer notre analyse inter-tâche pour fournir de nouvelles estimations des WCET des tâches. Ces nouvelles estimations seront utilisées pour générer un nouvel ordonnancement jusqu'à convergence. Nous ne proposons pas une politique d'ordonnancement, mais nous laissons à l'utilisateur le choix de cette politique qui va être utilisée pour générer l'ordonnancement initial ainsi que les autres ordonnancements intermédiaires dans notre algorithme itératif.

Comme tout logiciel, le calcul du WCET nécessite des expérimentations, des évaluations et des comparaisons d’où la nécessité des benchmarks qui représentent les fonctionnalités des applications temps-réel. Or, les benchmarks temps-réel sont très rares et sont constitués généralement d'un ensemble d'algorithmes de base utilisés dans les applications temps-réel mais hors contexte et sans lien véritable. Il est ainsi inadéquat de les utiliser pour expérimenter l’impact de l’enchaînement des tâches sur l’estimation du WCET. Comme solution à ce problème, nous avons conçu un benchmark temps-réel, PapaBench, décrivant une application temps-réel complète pour le pilotage d'un UAV (Unmanned Aerial Vehicles). Il a été conçu afin de constituer une base utile pour les expérimentations de calcul de WCET par méthode statique ou dynamique mais il peut être aussi utile pour les analyses d'ordonnancement.

Dans le dernier chapitre de ce document, nous avons présenté les résultats de l'expérimentation de notre analyse, effectuée sur les deux versions de PapaBench. Ces expérimentations ont permis d'étudier la variation du nombre de hits en fonction de la variation des paramètres du cache d'instructions et de l'ordonnancement. Nous avons aussi comparé l'impact de l'analyse ENTRY et de la réinjection sur les WCET initiaux des tâches.

Ces résultats montrent que notre approche permet de choisir la meilleure configuration du cache (taille du cache, taille de bloc, degré d'associativité) pour un ordonnancement de tâches fixé au départ. Et ensuite vérifier que c'est l'ordonnancement qui fournit le WCET global le plus petit pour la configuration du cache choisie, sinon il sera remplacé par un ordonnancement généré suivant une politique d'ordonnancement différente.

Les mesures montrent que le gain obtenu par rapport au WCET global varie entre 5 et 13,8% en fonction de la configuration du cache pour une taille de bloc de 8 octets. Et le gain par rapport aux WCET initiaux des tâches varie entre 5,6 et 64,2% pour un cache de 16 Ko et une taille de bloc de 8 octets et un degré d'associativité 2.

173173

PERSPECTIVES

Nous avons présenté dans ce document deux analyses MUST et MAY pour notre approche, mais nous avons uniquement expérimenté l'aspect MUST, comme ses résultats sont sûrs quel que soit le chemin d'exécution des tâches. Notre méthode MUST considère tous les chemins d'exécution possibles du graphe de flot de contrôle de la tâche. Or, il existe des chemins impossibles qui sont considérés et qui risquent de limiter le nombre d'éléments de MUST EXIT , MUST ENTRY et IN MUST et par suite fournir un nombre de hits minimal très petit. Ainsi en écartant ces chemins impossibles, le nombre de hits minimal sera au pire égal au nombre de hits fourni par la version actuelle de l'approche ce qui permet d'améliorer encore l'estimation initiale des WCET dans le cas où le nombre de hits minimal est plus grand.

L'analyse MAY ne fournit qu'un résultat probable donc une borne supérieure du nombre de hits qu'on peut obtenir en appliquant notre approche. Cette analyse était nécessaire pour l'étude du comportement du cache à accès direct, dans la première version de notre analyse. En effet, elle permet de déterminer l'ensemble des L-blocs qui rentrent en conflit avec les L-blocs de chaque tâche pour construire les états du cache inter-tâche. Or, avec la généralisation de l'approche au cache associatif la suppression des L-blocs du cache est gérée par le vieillissement des L-blocs suivant la politique LRU. Donc, l'analyse MAY ne sert que pour avoir une idée de la borne supérieure du nombre de hits. D'autre part, l'exploitation des ensembles MAY crée beaucoup de divergences, ainsi il n'est pas intéressant pour la suite. Cependant, on peut essayer d'optimiser l'estimation de cette borne supérieure.

Notre méthode étudie uniquement le comportement du cache d'instruction mais elle peut être adaptée pour étudier l'état de n'importe quel composant matériel dont le comportement a une inertie suffisante pour dépendre de l'ordonnancement des tâches. L'adaptation au prédicteur de branchement est un aspect qui mérite d'être étudié. En effet, le prédicteur de branchement prédit si un branchement est pris ou non pris, il se comporte comme un cache d'instruction mais au lieu de stocker les adresses des instructions, il sauvegarde des informations sur les instructions de contrôle (type de l'instruction, destination de saut et compteur 2 bits) et il peut être à accès direct ou associatif par ensembles. Comme pour le cache d'instruction, il faut déterminer les branchements qui accèdent à une même entrée de la table de prédiction, pour identifier les conflits.

Une fois les conflits détectés, il faut analyser tous les branchements concernés de manière conjointe pour appréhender l'évolution de leur compteur commun : en cas de miss, le compteur commun est incrémenté et une entrée est créée pour l'instruction de contrôle qui a généré ce miss dans la table de prédiction ; en cas de hit sur une entrée, on utilise l'information stockée pour faire la prédiction. Donc, notre approche est utile pour profiter de la trace laissée par l'enchaînement des tâches sur la prédiction de branchement de la tâche courante.

Nous avons proposé un algorithme itératif pour le choix du meilleur ordonnancement des tâches d'une application temps-réel connaissant la politique d'ordonnancement et

174174

l'ordonnancement initial des tâches. Cet algorithme n'est pas encore testé, nous envisageons de l'implémenter et le tester sur PapaBench pour prouver sa convergence et que le résultat fourni est l'ordonnancement optimal qui fournit le plus petit WCET global.

PapaBench est conçu pour constituer une base utile pour les expérimentations de calcul de WCET par méthodes statiques et pour les analyses d'ordonnancement. Nous envisageons de fournir des jeux d'entrée utiles pour effectuer des mesures dynamiques du temps d'exécution de ses tâches sur des systèmes réels ou des simulateurs. Ces jeux d'entrée nécessitent la connaissance des valeurs des registres à chaque instant, donc il faut analyser les traces de vols du système paparazzi pour ne garder que les valeurs des registres utilisés par les tâches de PapaBench.

175175

176176

RÉFÉRENCES

[1]. K. Marzullo, M. Wood. Making a real-time reactive systems reliable. ACM SIGOPS Operating Systems review, Vol. 25, Issue 1, pp. 45-48, January, 1991.

[2]. R. Arnold, F. Mueller, D. Whalley, M. Harmon. Bounding worst-case instruction cache performance. 15th IEEE Real-Time Systems Symposium (RTSS94), pp. 172-181, December, 1994.

[3]. K. Jeffay, D. F. Stanat, C. U. Martel. On Non-Preemptive Scheduling of Periodic and Sporadic Tasks. IEEE Real-Time Systems Symposium, San-Antonio, pp. 129-139, December, 1991.

[4]. A. Burns. Scheduling hard real-time systems-a review. Software engineering journal, Vol. 6, Issue 3, pp. 116-128, May, 1991.

[5]. U.C. Devi. An improved schedulability test for uniprocessor periodic task systems. 15th Euromicro conference on real-time systems, pp. 23-30, July, 2003.

[6]. E.G. Coffman, J. Sethuraman, V.G. Timkovsky. Ideal preemptive schedules on two processors. Acta Informat, Vol. 39, pp. 597-612, 2003.

[7]. L. Sha, R. Rajkumar, J.P. Lehoczky. Priority inheritance protocols: An approach to real-time synchronization. Advances in Real-Time Systems, pp. 53-63.

[8]. L. Sha, JB. Goodenough. Real-time scheduling theory and ada. Computer Vol. 23, Issue 4, pp. 53-62, April, 1990.

[9]. L. Sha, R. Rajkumar, J.P. Lehoczky, K. Ramamritham. Mode change protocols for priority-driven preemptive scheduling. UM-CS-1989-060, 1989.

[10]. G.C. Buttazzo. Rate Monotonic vs. EDF: Judgment Day. Journal of Real-time Systems, Vol. 29, pp. 5-26, January, 2005.

[11]. A.-M. Deplanche, O.-H. Roux. Ordonnancement temps réel et ordonnançabilité. Institut de Recherche en Communications et Cybernétique de Nantes, Rapport technique, Juin, 2002.

[12]. C. Kaiser. Ordonnancement dynamique des processus. Rapport technique, Juin, 2002.

[13]. G. Lipari. Earliest Deadline First. Scuola Superiore Sant'Anna, Pisa, Italy, 2005.

[14]. P.H. Feiler, B.Lewis, S. Vestal. The SAE Avionics Architecture Description Language

177177

(AADL) standard: A Basis for Model-Based Architecture Driven Embedded Systems Engineering. Workshop on Model-driven embedded systems, IEEE, Washington D.C., RTAS, May, 2003.

[15]. S. Vestal, P. Binns. Scheduling and conmmunication in MetaH. Real-Time Systems Symposium, pp. 194-200, December, 1993.

[16]. P. Feiler, D. P. Glush, J. J. Hudak, B. A. Lewis. Embedded System Architecture Analysis Using SAE AADL. , June, 2004.

[17]. SAE International. Architecture Analysis & Design Language (AADL). August, 2004.

[18]. F. Singhoff, J. Legrand, L. Nana. AADL resource requirements analysis with Cheddar. LYSIC/EA 3883, .

[19]. M.R. Guthaus, J.S. Ringenberg Austin, T. Mudge, R.B. Brown. MiBench: A Free, Commercially Representative Embedded Benchmark Suite. 4th Workshop on Workload Characterization, Austin, TX, December, 2001.

[20]. SNU Real-Time Benchmark Suite. Http://archi.snu.ac.kr/realtime/benchmark.

[21]. Mälardalen benchmarks. http://www.mtc.mdh.se/projects/ wcet/ benchmarks.html.

[22]. P. Brisset. Drones civils perspectives et réalités. Ecole nationale de l'aviation civile, Rapport technique, August, 2004.

[23]. ATMEL Corporation. ATMega128 complete datasheet. http://www.atmel.com/dyn/resources/prod_documents/doc2467.pdf.

[24]. F. Nemer, H. Cassé, P. Sainrat, J.P. Bahsoun, M. de Michiel. PapaBench – A free real-time benchmark. 6th Workshop on Worst-Case Execution Time Analysis, July, 2006.

[25]. H. Cassé, C. Rochange, P. Sainrat. An open Framework for WCET Analysis. IEEE Real-Time Systems Symposium-WIP session, pp. 13-16, Lisbon, December, 2004.

[26]. H. Cassé, C. Rochange, P. Sainrat. OTAWA, a framework for experimenting WCET computations. 3rd European Congress on Embedded Real-Time, Toulouse, December, 2005.

[27]. EEMBC Real-Time benchmarks . http://www.eembc.com.

[28]. Y.-T. S. Li, S. Malik. Efficient Microarchitecture Modeling and Path Analysis for Real-Time Software. 16th IEEE Real-Time Systems Symposium, pp. 298-307, December, 1995.

[29]. F. Mueller, D. Whalley, M. Harmon. Predicting instruction cache behavior. In ACM SIGPLAN Workshop on Languages, Compilers, and Tools for Embedded Systems, June,

178178

1994.

[30]. P. Puschner and C. Koza. Calculating the maximum execution time of real-time programs. Real-Time Systems, Vol. 1, Issue 2, pp. 159-176, September, 1989.

[31]. A. C. Shaw. Reasoning about time in higher-level langage software. IEEE Transactions on Software Engineering, Vol. 15, Issue 7, pp. 875-889, July, 1989.

[32]. N. Tracey, J. Clark, K. Mander. The way forward for unifying test case generation: Theoptimisation-based approach. In IFIP Workshop on Dependable Computing and Its Applications, pp. 73-81, January, 1998.

[33]. J. Wegener and F. Mueller. A comparison of static analysis and evolutionary testing for the verification of timing constraints. Real-Time Systems, Vol. 21, Issue 3, pp. 239-264, November, 2001.

[34]. T. Lundqvist, P. Stenström. An integrated path and timing analysis method based on cycle-level symbolic execution. Real-Time Systems, Vol. 17, Issue 2-3, pp. 183-207, November, 1999.

[35]. G. Bernat, A. Colin, S.M. Petters. WCET Analysis of Probabilistic Hard Real-Time Systems. 23rd IEEE Real-Time systems symposium, RTSS, pp. 279-288, 2002.

[36]. R. Kirner, P. Puschner, I. Wenzel. Measurement-Based Worst-Case execution time analysis using automatic test-data generation. 4th Workshop on Worst-Case Execution Time Analysis, 2004.

[37]. I.Wenzel, B.Rieder, R. Kirner, P. Puschner. Automatic Timing Model Generation by CFG Partitioning and Model checking. Design, Automation and Test in Europe, Vol. 1, pp. 606-611, 2005.

[38]. D. Macos, F. Mueller. Integrating gnat/gcc into a timing analysis environment. 10th Euromicro Conference on Real-Time Systems, pp. 15-18, June, 1998.

[39]. F. Bodin, E. Rohou, A. Seznec. Salto: System for assembly-language transformation and optimization. 6th Workshop on Compilers for Parallel Computers, December, 1996.

[40]. S. M. Petters, G. Färber. Making worst case execution time analysis for hard real-time tasks on state of the art processors feasible. 6th International Conference on Real-Time Computing Systems and Applications, 1999.

[41]. F. Stappert, P. Altenbernd. Complete worst-case execution time analysis of straight-line hard real-time programs. Journal of Systems Architecture, Kluwer Academic Publishers, Vol. 13, pp. 67-91, 1997.

[42]. P. Puschner, A. V. Schedl. Computing maximum task execution times – a graph based approach. IEEE Real-Time Systems Symposium, Vol. 13, pp. 67-91, Kluwer Academic

179179

Publishers, 1997.

[43]. G. Ottosson, M. Sjödin. Worst-case execution time analysis for modern hardware architectures. ACM SIGPLAN Workshop on Languages, Compilers,and Tools Support for Real-Time Systems (LCTRTS'97), June, 1997.

[44]. G. Bernat, A. Burns, A. Wellings. Portable worst-case execution time analysis using Java byte code. 12th Euromicro Workshop of Real-Time Systems, pp. 81-88, 2000.

[45]. I. Bate, G. Bernat, G. Murphy, P. Puschner. Low-level analysis of a portable WCET analysis framework. 7th International Conference on Real-Time Computing Systems and Applications, pp. 39-48, December, 2000.

[46]. P. Puschner. A tool for high-level language analysis of worst-case execution times. 10th Euromicro Conference on Real-Time Systems, Berlin, Germany, 1998.

[47]. A. Ermedahl, J. Gustafsson. Automatic derivation of path and loop annotations in object-oriented real-time programs. Journal of Parallel and Distributed Computing Practices, Vol. 1, Issue 2, pp. 61-74, 1998.

[48]. L. Ko, D. B. Whalley, M. G. Harmon. Supporting user-friendly analysis of timing constraints. ACM SIGPLAN Notices, Vol. 30, Issue 11, pp. 99-107, November, 1995.

[49]. C. Healy, M. Sjödin, V. Rustagi, D. Whalley, R. van Engelen. Supporting timing analysis by automatic bounding of loop iterations. Real-Time Systems, Vol. 18, Issue 2-3, pp. 129-156, May, 2000.

[50]. C.A. Healy, R.D. Arnold, F. Mueller, D.B. Whalley, M.G. Harmon. Bounding Pipeline and Instruction Cache Performance. IEEE Transactions on Computers, pp. 53-70, January, 1999.

[51]. J. Engblom, B. Jonsson. Processor pipelines and their properties for static wcet analysis. EMSOFT '02, Second International Conference on Embedded Software, London, UK, pp. 334-348, Springer-Verlag.

[52]. B.-D. Rhee, S.-S. Lim, S. L. Min, C. Y. Park, H. Shin, C. S. Kim. Issues of advanced architectural features in the design of a timing tool. Workshop on Real-Time Operanting Systems and Software, pp. 59-62, May, 1994.

[53]. J. Engblom, A. Ermedah. Pipeline Timing Analysis Using a Trace-Driven Simulator. 6th Conference on Real-Time Computing Systems ans Applications (RTCSA'99), December, 1999.

[54]. X. Li, A. Roychoudhury, T. Mitra. Modeling Out-of-Order processors for WCET analysis. Real-Time Systems, Kliwer, Vol. 34(3), 2006.

[55]. C. Rochange, P. Sainrat. A Context-Parameterized Model for Static Analysis of

180180

Execution Times. Transactions on High-Performance Embedded Architecture and Compilation, Vol. 2, Issue 3, pp. 109-128, Springer.

[56]. J. Barre, C. Landet, C. Rochange, P. Sainrat. Modeling Instruction-Level Parallelism for WCET Evaluation. 12th IEEE Internalional conference on Embedded and Real-Time Systems and Applications, August, 2006.

[57]. J.L. Hennessy, D.A. Patterson. Architecture des ordinateurs, approche quantitative. Chapitre 5 - Réalisation d'une hiérarchie mémoire, International Thomson Publishing.

[58]. J. Reinke, D. Grund, C. Reg, R. Wilhelm. Timing Predictability of Cache Replacement Policies. Real-Time Systems, Vol. 37, Issue 2, pp. 99-122, November, 2007.

[59]. Y.-T. S. Li, S. Malik. Performance analysis of embedded software using implicit path enumeration. ACM SIGPLAN Notices, Vol. 30, Issue 11, pp. 88-98, November, 1995.

[60]. Y.-T. S. Li, S. Malik, A. Wolfe. Cache modeling for real-time software: Beyond direct mapped instruction cache. 17th IEEE Real-Time Systems Symposium (RTSS96), pp. 254-263. IEEE Computer Society Press, December, 1996.

[61]. C. Ferdinand, F. Martin, R. Wilhelm. Applying compiler technique to cache behavior prediction. ACM SIGPLAN Workshop on Languages, Compilers, and Tools for Real-Time Systems, pp. 37-46, June, 1997.

[62]. A. Rakib, O. Parshin, S. Thesing, R. Whilhem. Component-Wise Instruction-Cache Behavior Prediction. Second International Conference Automated Technology for Verification and Analysis (ATAVA), October 31-November 3, 2004.

[63]. S.-K. Kim, S. L. Min, R. Ha. Efficient worst case timing analysis of data caching. Real-Time technology and Applications Symposium, pp. 230-240, June, 1996.

[64]. A. Colin, I. Puaut. A modular and retargetable framework for tree-based wcet analysis. 13th Euromicro Conference on Real-Time Systems, pp. 37-44, Delft, Netherlands, June, 2001.

[65]. A. Colin, I. Puaut. Worst-case execution time analysis of the RTEMS real-time operating system. 13th Euromicro Conference on Real-Time Systems, Netherlands, June, 2001.

[66]. A. Colin, G. Bernat. Scope-tree: a program representationfor symbolic worst-case execution time analysis. 14th Euromicro Conference on Real-Time Systems, pp. 19-21, Vienna, Austria, 2002.

[67]. J. Staschulat, R. Ernst. Static Running Time Analysis with Sympta/P. http://www.ida.ing.tu-bs.de/research/projects/symta/symtaP-overview.pdf, 2004.

[68]. F. Wolf. Behavioral intervals in embedded software. Kluwer Academic Publishers,

181181

Norwell, MA, 2002.

[69]. F. Wolf, J. Staschulat, R. Ernst. Hybrid cache analysis in running time verification of embedded software. Design Automation for embedded systems, Vol. 7, Issue 3, pp. 271-295, October, 2002.

[70]. F. Wolf, J. Staschulat, R. Ernst. Associative caches in formal software timing analysis. IEEE/ACM Design Automation Conference, June, 2002.

[71]. F. Wolf, R. Ernst, W. Ye. Path clustering in software timing analysis. IEEE Transactions on VLSI Systems, Vol. 9, Issue 6, December, 2001.

[72]. A. Burns and S. Edgar. Statistical analysis of WCET for scheduling. IEEE Real–Time Systems Symposium (RTSS’01), London, United Kingdom, December, 2001.

[73]. J. L. Diaz, D. F. Garcia, K. Kim, C. Lee, L. Lo Bello, J. M. Lopez, S. L. Min, O. Mirabella. Stochastic analysis of periodic real-time systems. 23rd Real-Time Systems Symposium (RTSS), Austin, Texas, USA, 2002.

[74]. Y. Tan, V. Mooney. Integrated Intra- and Inter-Task Cache Analysis for Preemptive Multi-Tasking Real-Time Systems. 8th International Workshop, SCOPES, Lecture Notes on Computer Science, LNCS3199, pp. 182-199, 2004.

[75]. Y. Tan, V. Mooney. Timing analysis for preemptive multi-tasking real-time systems with caches. Design, automation and test in Europe Conference and Exhibition, Vol. 2, pp. 1034-1039, 2004.

[76]. J. Staschulat, R. Ernst. Cache Effects in Multi Process Real-Time Systems with Preemptive Scheduling. Technical report, IDA, TU Braunschweig, Germany, November, 2003.

[77]. F. Nemer, H. Cassé, P. Sainrat, A. Awada. Improving the Worst Case Execution Time accuracy by Inter-Task cache analysis. IEEE Second Intenational Symposium on Industrial Embedded Systems, SIES'07, Lisbon, July, 2007.

[78]. I. Puaut, D. Decotigny. Low-complexity algorithms of static cache loking in multitasking hard real-time systems. 23rd IEEE Real-Time Systems Symposium (RTSS02), 2002.

[79]. A.V. Aho, R. Sethi, J.D. Ullman. Compilers: Principles, Techniques and Tools. Adison Wesley, 1986.

182182

IMPROVING THE WCET ACCURACY BY INTER-TASK INSTRUCTION CACHE ANALYSIS

The main characteristic of hard real-time systems is that they must guarantee a correct timing behaviour. A hard real time system doesn't tolerate the completion of an operation after its deadline while a soft real-time allow such delay and may respond with decreased service quality.Each hard real-time task has a deadline to meet, otherwise the real-time system fails and the failure can have catastrophic consequences. Schedulability analysis methods are commonly used in hard real-time systems to check whether or not all tasks deadlines will be met. Most of them rely on the knowledge of an upper bound on the computation time of every task, named WCET, for Worst-Case Execution Time. We study the optimisation of the WCET in this document.The Worst-Case Execution Time of a program can be computed by simulation or by performing a static analysis of the executable. Dynamic analyses give the actual WCET of a program if we can simulate all possible combinations of input data values and initial system states. Which is clearly impractical due to the exponentially large number of simulations required. As a result, we often obtain an estimate of the actual WCET by performing a static analysis of the program despite of the pessimism generated by the aproximations. Most static WCET analysis are performed at the task level and doesn't consider the tasks actual environnement. Hence they don't take advantage from the features of the multi-tasking real-time systems such as the tasks' chaining that affects straightforwadly the accuracy of the WCET estimation.We propose an approach that studies the instruction cache behavior of a static tasks scheduling for a single processor multi-tasking critical real-time application, assuming that no preemption is allowed between and inside the tasks. The main goal consists of replacing the conservative approximations that consider an empty or undefined cache state before the task execution, by an abstract cache state. The WCET estimation is thus improved.We also present a free real-time benchmark, PapaBench, describing a complete embedded real-time system driving an UAV (Unmanned Aerial Vehicle). This benchmark is designed to be valuable for experimental works in WCET computation and may be also useful for scheduling analysis.

Documents

THESEthesesups.ups-tlse.fr/188/1/Nemer_Fadia.pdf · Fadia NEMER le 27 Février 2008 Titre OPTIMISATION DE L'ESTIMATION DU WCET PAR ANALYSE INTER-TACHE DU CACHE D'INSTRUCTIONS Directeurs