Mise en page 1 - IRIT
Mise en page 1 - IRIT
Mise en page 1 - IRIT
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Architecture,<br />
Systèmes et Réseaux<br />
Traces stands for Research<br />
group on Architecture<br />
and Compilation<br />
for Embedded Systems<br />
(Recherche <strong>en</strong> Architecture et Compilation pour les Systèmes Embarqués)<br />
TRACES<br />
6Thème<br />
■ Problématique et résultats<br />
L’équipe TRACES rassemble des chercheurs issus de deux anci<strong>en</strong>nes équipes (APARA<br />
et RSDP) qui s’intéress<strong>en</strong>t aux aspects matériels des systèmes embarqués temps-réel.<br />
L’objectif premier est de garantir que le temps d’exécution d’une application est compatible<br />
avec les contraintes temporelles du système.<br />
Deux approches sont explorées :<br />
• l’approche desc<strong>en</strong>dante consiste à générer de manière automatique un matériel<br />
dédié à l’application qui garantit le respect de contraintes temporelles spécifiées.<br />
Cette approche a été explorée dans le cadre du projet RSDP dont l’objectif est<br />
de définir une méthodologie de spécification et de développem<strong>en</strong>t permettant <strong>en</strong>suite<br />
la conception automatique d’une architecture répartie dédiée.<br />
• l’approche asc<strong>en</strong>dante, qui repose sur l’utilisation de processeurs généralistes,<br />
cherche à <strong>en</strong> caractériser les propriétés temporelles. L’objectif est de proposer<br />
des modes d’utilisation permettant une estimation à la fois précise et fiable<br />
des temps d’exécution ainsi que des ext<strong>en</strong>sions architecturales améliorant la prévisibilité<br />
temporelle des composants.<br />
Le temps d’exécution d’un programme dép<strong>en</strong>d des données <strong>en</strong> <strong>en</strong>trée. Or le domaine<br />
de variation de ces données est souv<strong>en</strong>t trop large pour <strong>en</strong>visager de tester tous<br />
les cas. C’est pourquoi les recherches de ces dernières années se sont ori<strong>en</strong>tées vers<br />
des méthodes permettant d’évaluer le temps d’exécution pire cas (WCET : Worst-Case<br />
Execution Time) à partir de mesures de segm<strong>en</strong>ts de code (typiquem<strong>en</strong>t des blocs<br />
de base). Cette évaluation comporte trois volets : une analyse statique du code permet<br />
d’id<strong>en</strong>tifier les chemins d’exécution possibles ; une étude du matériel cible détermine<br />
le temps d’exécution des blocs de base ; <strong>en</strong>fin, les résultats de ces deux analyses<br />
sont combinés pour calculer une borne supérieure du temps d’exécution. Nos travaux<br />
s’inscriv<strong>en</strong>t dans le second volet : analyse du comportem<strong>en</strong>t temporel du matériel.<br />
Les processeurs généralistes haute performance seront sans aucun doute les processeurs<br />
embarqués de demain si la t<strong>en</strong>dance actuelle se poursuit (le système de commande<br />
de vol de l’A380 intègre déjà un PowerPC 750). Or ces processeurs comport<strong>en</strong>t des mécanismes<br />
dynamiques (ordonnancem<strong>en</strong>t des instructions, prédiction de branchem<strong>en</strong>t,<br />
mémoires caches, ...) qui r<strong>en</strong>d<strong>en</strong>t leur analyse statique très difficile et coûteuse.<br />
Les obstacles à leur prévisibilité temporelle sont liés à l’ordonnancem<strong>en</strong>t dynamique<br />
des instructions et à l’exploitation, par certains élém<strong>en</strong>ts (ex : prédicteur de branchem<strong>en</strong>t),<br />
de l’historique d’exécution. Il résulte de ces deux élém<strong>en</strong>ts que le temps d’exécution<br />
d’un bloc de base dép<strong>en</strong>d de ce qui est exécuté avant lui.<br />
PERSONNEL<br />
Professeurs<br />
Daniel Dours (10/05)<br />
Pascal Sainrat<br />
Maîtres de confér<strong>en</strong>ce<br />
Hugues Cassé (09/04)<br />
Marianne De Michiel<br />
Christine Rochange<br />
Doctorants<br />
Jonathan Barre (09/04)<br />
Reda Bekkouche (12/03)<br />
Claire Burguière (09/04)<br />
Belkacem Cherfaoui<br />
(12/03)<br />
Thierry Haquin (09/03)<br />
Tahiry Ratsiambahotra<br />
(09/04)<br />
Philippe Reynès (07/04)<br />
Contractuels<br />
Marc Finet (12 mois)<br />
Antoine Barthe (4 mois)<br />
// 111
Architecture,<br />
Systèmes et Réseaux<br />
Traces stands for Research group on Architecture and Compilation for Embedded Systems (Recherche <strong>en</strong> Architecture<br />
et Compilation pour les Systèmes Embarqués) – TRACES<br />
RÉFÉRENCES<br />
[4834]<br />
Hugues Cassé, Christine<br />
Rochange, Pascal Sainrat.<br />
An Op<strong>en</strong> Framework for WCET<br />
Analysis. IEEE Real-Time Systems<br />
Symposium - WIP session,<br />
décembre 2004.<br />
[4919]<br />
Claire Burguiere,<br />
Christine Rochange.<br />
A contribution to branch<br />
prediction modeling<br />
in WCET analysis.<br />
DATE’2005 (Design, Automation<br />
and Test in Europe), mars 2005.<br />
[5143]<br />
Christine Rochange,<br />
Pascal Sainrat.<br />
A Time-Predictable Execution<br />
Mode for Superscalar Pipelines<br />
with Instruction Prescheduling.<br />
ACM Int. Conf. on Computing<br />
Frontiers. Mai 2005.<br />
[5785]<br />
Daniel Dours,<br />
Marianne De Michiel,<br />
Patrick Magnaud,<br />
Reda Bekkouche,<br />
Belkacem Cherfaoui.<br />
Estimations pour<br />
le partitionnem<strong>en</strong>t de systèmes<br />
temps rée strict sur FPGA.<br />
Technique et sci<strong>en</strong>ce<br />
informatiques,<br />
vol. 23, n° 4, août 2004.<br />
RÉSULTATS IMPORTANTS<br />
Archtecture,<br />
Systèmes et Réseaux<br />
En ce qui concerne l’approche desc<strong>en</strong>dante, le projet RSDP a abouti au développem<strong>en</strong>t<br />
de l’outil RSDT (Real-time Systems Design Tool) qui permet de partitionner une application<br />
et de générer automatiquem<strong>en</strong>t un système réparti (à partir de composants<br />
logiciels ou matériels dédiés) qui réalise l’application <strong>en</strong> respectant les contraintes<br />
temporelles spécifiées [5785].<br />
Pour l’approche asc<strong>en</strong>dante, nos contributions pour une amélioration de la prévisibilité<br />
temporelle se sont portées sur deux élém<strong>en</strong>ts du processeur : le prédicteur de branchem<strong>en</strong>ts<br />
et le pipeline.<br />
Les travaux antérieurs au sujet de la prédiction de branchem<strong>en</strong>ts cherchai<strong>en</strong>t à analyser<br />
ce mécanisme de la même manière qu’une mémoire cache (autre composant exploitant<br />
l’historique d’exécution), c’est-à-dire <strong>en</strong> pr<strong>en</strong>ant <strong>en</strong> compte tous les chemins possibles<br />
dans le graphe de flot de contrôle ou dans l’arbre syntaxique. Nous avons proposé une<br />
approche beaucoup plus simple basée sur une analyse des structures algorithmiques<br />
dans le code source. Cette analyse permet de borner de manière statique le nombre d’erreurs<br />
de prédiction, ce qui permet d’intégrer les pénalités correspondantes dans le temps<br />
d’exécution [4919]. Nous avons égalem<strong>en</strong>t montré qu’une prédiction statique de certains<br />
branchem<strong>en</strong>ts permet parfois de réduire le WCET [5834].<br />
En ce qui concerne le pipeline, il a été montré dans la littérature que, dans un pipeline<br />
un tant soit peu évolué, le temps d’exécution d’un bloc de base peut dép<strong>en</strong>dre<br />
d’un bloc situé bi<strong>en</strong> <strong>en</strong> amont sur le chemin d’exécution. Nous avons quantifié ces<br />
effets (appelés effets temporels longs) pour un processeur superscalaire à exécution<br />
non ordonnée et nous <strong>en</strong> avons analysé les sources. Nous avons, par la suite, proposé<br />
l’intégration, dans le processeur, d’un dispositif de régulation du flot d’instructions<br />
qui impose une distance (calculée dynamiquem<strong>en</strong>t) <strong>en</strong>tre deux blocs de base suffisante<br />
pour empêcher la surv<strong>en</strong>ue de tout effet temporel long [5143].<br />
Ces recherches nécessit<strong>en</strong>t de nombreuses expérim<strong>en</strong>tations visant à évaluer les performances<br />
moy<strong>en</strong>nes et pire-cas des mécanismes proposés. Pour cela, nous sommes<br />
am<strong>en</strong>és à mettre <strong>en</strong> oeuvre divers algorithmes proposés dans la littérature et, parfois,<br />
à les composer <strong>en</strong> fonction des élém<strong>en</strong>ts soumis à évaluation. Nous développons<br />
actuellem<strong>en</strong>t la plate-forme OTAWA destinée à faciliter le processus d’expérim<strong>en</strong>tation,<br />
et de permettre l’exploration de nouvelles méthodes de calcul de WCET adaptées<br />
à des processeurs toujours plus complexes. Cette plate-forme fournit des outils permettant<br />
de manipuler un code objet et une bibliothèque de fonctions d’analyse qui peuv<strong>en</strong>t<br />
<strong>en</strong>richir le code avec des informations temporelles qui peuv<strong>en</strong>t <strong>en</strong>suite être exploitées<br />
pour borner le temps d’exécution [4834].<br />
■ Prospective<br />
Les difficultés de borner le temps d’exécution sur un processeur haute-performance<br />
sont liées aux interfér<strong>en</strong>ces <strong>en</strong>tre blocs de base qui se manifest<strong>en</strong>t au niveau de l’ordonnancem<strong>en</strong>t<br />
des instructions et au sein de mécanismes qui exploit<strong>en</strong>t l’historique<br />
d’exécution (comme les caches).<br />
Or, pour contourner les limites de la technologie qui ne permet pas d’augm<strong>en</strong>ter indéfinim<strong>en</strong>t<br />
la fréqu<strong>en</strong>ce des processeurs, les constructeurs comm<strong>en</strong>c<strong>en</strong>t à mettre <strong>en</strong> oeuvre<br />
des mécanismes qui vis<strong>en</strong>t à accroître <strong>en</strong>core le parallélisme des traitem<strong>en</strong>ts et donc<br />
les risques d’interfér<strong>en</strong>ces. L’approche multiflot simultané (simultaneous multithreading,<br />
ou SMT) permet l’exécution <strong>en</strong> parallèle de plusieurs flots d’instructions (threads) sur<br />
un même processeur : chaque flot dispose d’un <strong>en</strong>semble de ressources privées<br />
(registres, …) et l’<strong>en</strong>semble des flots actifs partag<strong>en</strong>t des ressources de calcul communes<br />
(unités fonctionnelles, mémoires cache, …). La prés<strong>en</strong>ce de plusieurs flots permet d’occuper<br />
au mieux les unités fonctionnelles et de se rapprocher des performances crête.<br />
L’approche multicœur (multicore) consiste à intégrer sur une même puce plusieurs cœurs<br />
d’exécution, un réseau de communication et de la mémoire. Le système est alors similaire<br />
à un multiprocesseur à mémoire partagée classique, capable d’exécuter plusieurs pro-<br />
112 //
cessus <strong>en</strong> parallèle. Cette approche permet d’obt<strong>en</strong>ir des performances plus importantes<br />
qu’avec un seul cœur, ou, à performances égales (avec des cœurs plus simples), de réduire<br />
la consommation, ce qui peut être un paramètre important dans un système embarqué.<br />
Des processeurs mettant <strong>en</strong> oeuvre une ou l’autre de ces approches (et même les deux)<br />
sont déjà disponibles et seront probablem<strong>en</strong>t utilisés dans un contexte temps-réel dans un<br />
futur proche.<br />
Dans un processeur multiflot, l’<strong>en</strong>trelacem<strong>en</strong>t temporel des flots influ<strong>en</strong>ce l’ordonnancem<strong>en</strong>t<br />
de leurs instructions respectives (par « ordonnancem<strong>en</strong>t », on n’<strong>en</strong>t<strong>en</strong>d pas<br />
seulem<strong>en</strong>t « ordre d’exécution » mais aussi « dates d’exécution »). Dans un processeur<br />
multicœur à mémoire partagée, le partage de ressources telles que le bus mémoire est<br />
égalem<strong>en</strong>t susceptible d’avoir une influ<strong>en</strong>ce sur le temps d’exécution de chaque flot<br />
(à cause de son impact sur les lat<strong>en</strong>ces d’accès à la hiérarchie mémoire). Ainsi, il n’est<br />
plus <strong>en</strong>visageable d’évaluer le temps d’exécution d’un flot considéré isolém<strong>en</strong>t et<br />
il devi<strong>en</strong>t nécessaire d’analyser plusieurs flots de manière conjointe, <strong>en</strong> pr<strong>en</strong>ant<br />
<strong>en</strong> compte tous les <strong>en</strong>trelacem<strong>en</strong>ts possibles. Par ailleurs, par le biais du partage<br />
de certaines unités de mémorisation (caches de niveau 1, prédicteur de branchem<strong>en</strong>t…<br />
pour les processeurs multiflot, caches de niveau 2 et 3 pour les processeurs multicœur),<br />
plusieurs flots exécutés <strong>en</strong> parallèle sont susceptibles d’interférer les uns avec<br />
les autres. En effet, ces unités ne sont généralem<strong>en</strong>t pas partitionnées, et chaque flot<br />
peut remplacer des élém<strong>en</strong>ts mémorisés par un autre flot par des élém<strong>en</strong>ts qui<br />
le concern<strong>en</strong>t.<br />
Par ailleurs, dans le cas où les différ<strong>en</strong>ts flots font partie d’une même application et<br />
se partag<strong>en</strong>t une partie de l’espace mémoire, le mécanisme matériel de gestion de<br />
la cohér<strong>en</strong>ce des données dans les caches est lui aussi susceptible d’éliminer certains<br />
élém<strong>en</strong>ts des caches. Là <strong>en</strong>core, cela remet complètem<strong>en</strong>t <strong>en</strong> cause les techniques<br />
actuelles d’analyse de ces unités et nécessite une approche globale pr<strong>en</strong>ant <strong>en</strong> compte<br />
l’<strong>en</strong>semble des flots concurr<strong>en</strong>ts.<br />
[5834]<br />
Claire Burguière,<br />
Christine Rochange,<br />
Pascal Sainrat.<br />
A Case for Static Branch<br />
Prediction in Real-Time Systems.<br />
IEEE International Confer<strong>en</strong>ce<br />
on Embedded and Real-Time<br />
Computing Systems<br />
and Applications (RTCSA),<br />
août 2005.<br />
Nos travaux à v<strong>en</strong>ir se situ<strong>en</strong>t dans ce cadre. Tout d’abord, nous <strong>en</strong>visageons de déterminer<br />
les spécificités de ces architectures et d’id<strong>en</strong>tifier précisém<strong>en</strong>t les obstacles<br />
à leur prévisibilité temporelle. Notre objectif est, à terme, de définir l’architecture idéale<br />
d’un processeur haute performance pour les systèmes embarqués afin de répondre à un<br />
besoin clairem<strong>en</strong>t affiché par l’industrie. Cette architecture devra prés<strong>en</strong>ter les bonnes<br />
propriétés temporelles et être accompagnée d’une représ<strong>en</strong>tation formelle de son fonctionnem<strong>en</strong>t<br />
facilem<strong>en</strong>t manipulable par des outils de haut niveau.<br />
■ Thèses et habilitations<br />
• Reda Bekkouche. Contribution à la conception sûre de sytèmes complexes, critiques<br />
et distribués. Thèse UPS, 12/2003<br />
• Belkacem Cherfaoui. Partitionnem<strong>en</strong>t de systèmes temps-réel-strict pour une<br />
implantation sur FPGAs. Thèse UPS, 12/2003<br />
• Thierry Haquin. Séqu<strong>en</strong>ces de branchem<strong>en</strong>t : prédiction de branchem<strong>en</strong>ts et optimisation<br />
du chargem<strong>en</strong>t des instructions. Thèse UPS, 09/2003<br />
• Philippe Reynès. Étude de mécanismes de réutilisation d’instructions.Thèse UPS,<br />
07/2004<br />
■ Collaborations, contrats et transfert<br />
• RNTL précompétitif ATLAS (Analyse par Test des Logiciels embarqués <strong>en</strong> Appliquant<br />
la Simulation généralisée). Part<strong>en</strong>aires : EADS, TNI, CEA, LRI. 2002-2004<br />
• RNTL exploratoire COP (C<strong>en</strong>tre d’optimisation de programmes). Part<strong>en</strong>aires :<br />
Hewlett-Packard, ST Microelectronics, LRI. 2003-2005<br />
• Participation au cluster « Multithreading » du NoE Hipeac (réseau d’excell<strong>en</strong>ce europé<strong>en</strong>).<br />
Part<strong>en</strong>aires : UPC Barcelona, University of Augsburg. 2005<br />
// 113
Architecture,<br />
Systèmes et Réseaux<br />
Traces stands for Research group on Architecture and Compilation for Embedded Systems (Recherche <strong>en</strong> Architecture<br />
et Compilation pour les Systèmes Embarqués) – TRACES<br />
• Avant-Projet FERIA. ALCAAM. Part<strong>en</strong>aires : ONERA, ENSICA. 2004<br />
• Avant-Projet FERIA. METEoRe. Part<strong>en</strong>aire : LAAS. 2005<br />
• Action spécifique « Nouvelles technologies et nouveaux paradigmes d’architectures<br />
» du RTP Architecture et Compilation<br />
• Action spécifique « Adéquation architecture OS » du RTP System on Chip<br />
• Distribution du générateur de simulateurs fonctionnels GLISS : cet outil génère à<br />
partir d’une description de haut niveau du jeu d’instructions d’un processeur,<br />
le simulateur de ce jeu d’instructions.<br />
• Participation à la création de la bibliothèque Microlib : cette bibliothèque permet<br />
de construire aisém<strong>en</strong>t un simulateur précis au cycle près de processeur et doit<br />
permettre de reproduire tout aussi aisém<strong>en</strong>t des expéri<strong>en</strong>ces.<br />
■ Animation, gestion et vulgarisation<br />
de la recherche<br />
• Animation du RTP Architecture et Compilation<br />
• Animation du groupe Architecture du GDR ARP<br />
• Membre du réseau d’excell<strong>en</strong>ce europé<strong>en</strong> HiPEAC<br />
• Expertise pour la commission europé<strong>en</strong>ne, la région Rhône-Alpes, le RNTL, l’université<br />
Paris-Sud<br />
• Comités de programme (PACT, IPDPS, Sympa)<br />
• Comités de rédaction de “noir sur blanc”, rédaction d’un article « L’objet informatisé »<br />
NsB numéro 3<br />
114 //