Les méthodes de calcul du WCET par analyse statique employées sur des processeurs mono-cœurs sont développées depuis une vingtaine d’années. Elles sont aujourd’hui consi- dérées comme matures. Elles reposent sur des hypothèses qui s’appliquent au processeur ainsi qu’au logiciel embarqué. On suppose par exemple que le logiciel s’exécute en une suite finie d’instructions. Côté matériel, on demande que le traitement d’une séquence d’instructions dans le pipeline d’un cœur soit effectué en un temps borné. Il en va de même pour les opérations effectuées par ce cœur à destination des ressources communes. Le passage au processeurs multi-cœurs, avec la prise en compte des interférences, rend cette dernière hypothèse plus difficile à satisfaire.
L’approche la plus directe consiste à vouloir appliquer les mêmes méthodes de calcul de WCET sans altérer leurs hypothèses de validité. La prise en compte des interférences est effectuée en introduisant une pénalité sur la durée de chaque accès. Cette pénalité
4.2. Résumé des approches existantes s’obtient dans la pire configuration dans laquelle cet accès peut être effectué, en considé- rant toutes les possibilités d’accès concurrents. Comme développé dans la section 3.2.1, nous considérons que, avec nos contraintes, cette approche a peu de chances d’aboutir. Cela demanderait en effet de résoudre les verrous suivants :
1. Les processeurs COTS (cf. contrainte (i)) disposent de composants dont le ni- veau de documentation communiquée par le fabricant est faible, voire nul. Les pistes –empiriques ou analytiques– pour évaluer la pénalité d’interférences re- posent donc sur des hypothèses qu’il est difficile de vérifier pour un équipementier faute d’informations, et sur lesquelles les fabricants de processeur ne s’engagent pas. Construire soi-même un modèle du processeur suffisamment détaillé pour étudier les interférences est donc une tâche incertaine.
2. L’architecture des processeurs COTS est complexe. Ces derniers sont optimisés pour avoir de bonnes performances moyennes au détriment de leur comportement en pire cas. Les quelques approches qui ont voulu analyser des modèles de pro- cesseurs ont mis en évidence une explosion combinatoire du nombre de situations à prendre en compte [48]. A supposer que l’on ait résolu le premier verrou et que l’on dispose d’un modèle du processeur dans lequel on puisse analyser les interférences, une telle analyse serait compliquée.
3. Certaines études ont montré des comportements de processeurs COTS qui mettent en évidence des cas d’interférences dont la pénalité est grande devant les temps d’accès aux ressources, par exemple d’un facteur 20 pour un processeur octo- cœurs [66]. A supposer que l’on ait résolu le deuxième verrou et que la pénalité d’interférence soit bornée, elle serait probablement grande devant les temps d’ac- cès aux ressources et donc peu exploitable dans un calcul de WCET.
Du fait de la présence d’interférences que l’on n’arrive pas à analyser correctement, il ne semble pas réaliste de calculer un WCET sur un processeur multi-cœurs sans remettre en cause certaines pratiques existantes. On peut par exemple introduire des hypothèses supplémentaires pour contourner la complexité de l’analyse du comportement du proces- seur dans un espace de configuration peu contraint. Ces hypothèses peuvent restreindre le comportement du processeur, celui du logiciel, ou altérer la méthode de calcul de WCET. C’est l’objet de diverses approches, dont certaines sont arrivées à un stade de maturité avancé. Ces approches se classent dans les catégories suivantes :
Pénalité globale. La méthode de calcul de WCET est altérée pour effectuer dans un
premier temps un calcul provisoire qui ne prend pas en compte les interférences. Dans un second temps, elle applique à chaque tâche une pénalité d’interférence globale calculée en prenant en compte le détail des opérations effectuées par tous les cœurs. Cela demande une connaissance fine de toutes les tâches exécutées sur le processeur et de l’activité que chacune génère. Cette approche relâche la contrainte (ii), car elle demande de connaître toutes les tâches déployées sur les différents cœurs, ce qui n’est pas compatible avec la propriété de Partitionnement Robuste.
Chapitre 4. Problématique
Processeur déterministe. En altérant l’architecture du processeur, il est possible de garantir par construction l’absence d’interférences. Les approches de cette caté- gorie proposent des processeurs pour lesquels les accès aux ressources communes sont gérés par une politique d’arbitrage time-triggered, en général TDMA. Les ac- tivités concurrentes sont ainsi effectuées dans des fenêtres temporelles disjointes. Cette famille d’approche demande de relâcher la contrainte (i), car elle n’est pas supportée par les fabricants de processeurs COTS.
Logiciel déterministe. Les tâches embarquées sont organisées de telle sorte à assu- rer que les opérations qu’elles génèrent n’interfèrent pas. En général, l’exécution d’une telle tâche est organisée en phases de communication avec les ressources communes et en phases d’exécution interne qui ne génère pas d’activité dans les ressources communes. Les phases de communication ont lieu dans des fenêtres temporelles disjointes. Cette approche demande une connaissance fine des tâches embarquées afin de connaître précisément leur besoin en ressource. Elle demande également de concevoir le logiciel de manière adéquate pour qu’il s’organise selon ces phases de communication et d’exécution. Dans les approches existantes, la rétrocompatibilité vis-à-vis du logiciel existant n’est pas assurée. Cela demande de relâcher la contrainte (iii).
Ces approches éliminent les interférences, ou bornent leur impact sur le temps d’exé- cution du logiciel, mais elles s’appliquent dans le cas où on relâche une des contraintes de départ. Toutefois certaines sont arrivées à un stade de maturité avancé, et les concepts qu’elles portent sont de bons candidats pour résoudre notre problème, à condition qu’on puisse les adapter pour qu’ils supportent nos contraintes. Nous retenons en particulier les points suivants :
Stratégie d’utilisation. Il est possible de calculer des WCET sur des processeurs multi- cœurs, y compris COTS, quand ils sont utilisés selon certaines restrictions, que nous désignons sous le terme de stratégie d’utilisation. Par exemple, on peut interdire qu’un nombre trop important de cœurs accède à certaines ressources en même temps afin de ne pas les saturer. Dans les approches rencontrées, la stratégie d’utilisation est time-triggered, en général basée sur des politiques d’arbitrage TDMA. On élimine donc les interférences en isolant temporellement les activités concurrentes émises par les cœurs.
Stratégie de contrôle. La plateforme d’exécution, composée du processeur et du lo- giciel système, a l’obligation d’assurer la stratégie d’utilisation indépendamment du logiciel applicatif. Dans le cas contraire, la propriété de Partitionnement Ro- buste serait invalidée. Par exemple, on ne peut demander à une application de séquencer elle-même des phases d’exécution et des phases de communication. Il est donc nécessaire de définir une stratégie de contrôle, qui sera implémentée dans la plateforme.
La résolution de notre problème demande donc de choisir une famille d’approche qui dispose de ces deux stratégies. L’utilisation de processeurs multi-cœurs COTS (cf contrainte (i)) présente plusieurs difficultés, que nous détaillons ci-après et qui orientent notre problématique de thèse.