Validation de la méthode pour le prototype Leon3

Après l'étude sur le 68HC11, on se propose dans ce paragraphe d'évaluer la criticité des registres pour un processeur plus complexe, à savoir celui choisi pour le prototype. Cette étude ayant été réalisée sur la première version du prototype, le processeur considéré est le Leon2,

doté d'un pipeline à cinq étages. Les résultats peuvent être extrapolés au cas encore plus

complexe du Leon3.

Comme pour le cas du 68HC11, nous avons effectué des injections de bit-flips dans le banc de registres du processeur Leon2, pendant l'exécution de diverses applications. Outre les bit-flips simples injectés pour représenter les effets des SEUs dans des éléments de mémoire, des bits-flips multiples ont également été pris en considération. Les injections sur cet exemple plus

complexe ont été réalisées grâce à l'environnement d'émulation présenté dans [Vanh. 06].

Pour nos premières expérimentations, dont les résultats sont présentés dans le tableau III-III,

nous avons essentiellement ciblé les registres locaux. Les registres sont classés par ordre de

criticité décroissante, telle qu'évaluée par les deux approches. Notons que la comparaison des

chiffres n'est pas significative, seul le classement nous intéresse.

Dans le cas du filtre FIR, nous pouvons voir que, pour ces registres locaux, les deux approches conduisent à des classements assez similaires. Globalement, les premières évaluations permettent au concepteur de prendre rapidement des décisions cohérentes au moment de décider des éléments les plus critiques à protéger. Dans le cas de Mtmx, la cohérence est plus faible, probablement en raison d'un plus grand impact des optimisations micro-architecturales pendant l'exécution du programme. Nous allons revenir sur ce point.

Tableau III-III: Taux d’erreurs obtenus après injections de fautes VS. Criticités calculées pour les applications Fir et Mtmx

Taux d’erreurs Criticité Taux d’erreurs Criticité

%l3 0.98 %l3 0.75 %l6 1.00 %l5 0.69 %l7 0.90 %l5 0.59 %l7 1.00 %l6 0.60 %l5 0.79 %l7 0.39 %l5 0.78 %l1 0.60 %l1 0.78 %l4 0.37 %l4 0.48 %l7 0.53 %l4 0.76 %l6 0.34 %l1 0.38 %l4 0.48 %l6 0.70 %l1 0.28 %l2 0.30 %l0 0.26 %l2 0.70 %l2 0.26 %l3 0.22 %l3 0.22 FIR %l0 0.43 %l0 0.21 MTMX %l0 0.18 %l2 0.21

Pour aller plus loin, nous avons classifié les fautes injectées dans le banc de registres, en fonction du comportement du système après l'injection, comme "Silencieuse" (pas d'effet sur les résultats de l'application), "Erreur" (mauvais résultat, mais le système continue de fonctionner et peut effectuer d'autres calculs), "Défaillance" (Mauvaise terminaison du programme, comportement inattendu, comportement futur incertain) ou "Crash" (erreur et comportement du système entièrement irrécupérable, jusqu'à la réinitialisation). Pour cette analyse, nous avons choisi une application un peu plus complexe, à savoir un chiffrement AES dont les résultats de classification sont présentés dans le tableau III-IV. Les fautes ont été injectées dans un premier temps dans l'ensemble du banc de registres, puis sélectivement dans les registres effectivement utilisés par l'application.

Un fort pourcentage d’injections de bit-flips conduit à des fautes silencieuses, même lorsque les registres ciblés sont effectivement utilisés par l'application. Les résultats de classification obtenus après injections en inversant tous les bits dans un registre sont assez similaires, bien que le nombre d'erreurs silencieuses soit un peu plus faible. Cette faible sensibilité aux erreurs dans le banc de registres a été également confirmée par d’autres campagnes d’injections effectuées sur d’autres benchmarks. Le tableau III-V résume les résultats pour Mtmx et FIR lors de l'injection de fautes sur les registres réellement utilisés par l'application. Certaines fautes silencieuses sont dues à l’écrasement des valeurs erronées, d'autres conduisent seulement à un léger retard dans le calcul. Les fautes classées comme "Défaillance" dans le filtre FIR sont principalement dues à l'avenir incertain du système.

Tableau III-IV: Classification des résultats d’injection de fautes sur le banc de registres

pour l’application AES Cibles d’injection Tout le banc de registres Registres utilisés dans le banc de registres Nombre de fautes injectées (single bit-flips) 5000 1000 Marge d’erreur de la classification 1.8% 4.1% Silencieuse 98.4% 86.4% Erreur 0.2% 1.9% Défaillance 0.9% 5.7% Crash 0.5% 5.2%

Tableau III-V: Classification des résultats d’injection de fautes sur le banc de registres

pour les applications MTMX et FIR Cibles d’injection Registres utilisés dans le banc de registres Silencieuse 86,8% Erreur 8,8% Défaillance 2,8% MTMX Crash 1,6% Silencieuse _87.0% Erreur _0% Défaillance _13.0% FIR Crash _0%

Les effets limités de l’injection de fautes sur les registres utilisés, et ce pour les différents

benchmarks, soulèvent des interrogations.En effet, la criticité des registres du banc de registres,

telle qu'évaluée par les approches plus théoriques, n'est pas cohérente avec ces résultats. Nous avons donc réalisé une analyse très détaillée de l'exécution de certains programmes afin de comprendre les écarts observés entre les différentes analyses de criticité prédictives et les résultats expérimentaux par injection de fautes.

La figure 3-9 montre la structure du pipeline entier dans le microprocesseur Leon2. Le banc de registres est écrit dans le dernier des cinq étages du pipeline. Des trajets de by-pass classiques existent dans le pipeline pour la gestion des aléas d'exécution (et en particulier les dépendances de données), afin de réutiliser les valeurs dès qu’elles sont disponibles, et cela même avant leur

écriture dans le banc de registres. Cette caractéristique micro-architecturale conduit à des

divergences entre les évaluations faites au moment de la compilation et la criticité réelle

observée lors de l'injection de fautes dans le banc de registres. En effet, dans le cas où nous

avons une valeur réutilisée par la voie d'un by-pass avant d'être écrite dans le banc de registres, la corruption de cette valeur dans le banc de registres n'aura pas forcément d'impact. Quand un registre ne contient que des valeurs temporaires immédiatement réutilisées par l'instruction suivante, ce registre peut théoriquement avoir une durée de vie importante (parce que les valeurs y sont stockées très fréquemment), mais n'a dans la pratique aucune criticité, car les valeurs qu'il contient ont déjà été réutilisées par anticipation et n'auront plus de rôle dans les calculs suivants.

Figure 3-9 : Architecture du pipeline du microprocesseur Leon2

La conclusion de cette analyse est que l’étude de criticité des registres du banc de registres, telle qu’elle est faite dans toutes les approches existantes, ne peut être exacte que pour les architectures simples. Dans le cas contraire, la durée de vie réelle d’un registre architectural (comme ceux du banc de registres) est en fait répartie entre plusieurs registres physiques, la plupart d'entre eux étant des registres internes de la micro-architecture qui ne sont pas directement visibles par le programmeur. L'existence, dans le cas de l'architecture Sparc, d'un fenêtrage de registres, complique encore le lien entre la criticité des registres logiques et celle des registres physiques. Une étude plus spécifique pour ce type d'architecture est en cours mais

ne sera pas détaillée dans ce document. La difficulté actuelle d'assurer une bonne sélection des variables les plus critiques est l'une des raisons ayant conduit à ne pas implanter la détection des erreurs de données dans le prototype basé sur le Leon3. Toutefois, il est raisonnable de penser que le classement de criticité obtenu par notre évaluation prédictive reste utilisable au niveau des variables (ou des pseudo-registres). En effet, même si la criticité calculée se répartit entre plusieurs registres physiques, l'évaluation ne tenant pas directement compte de la micro-architecture du processeur, la somme des criticités des différents registres contenant, à un instant donné, une certaine variable peut a priori être correctement évaluée par notre approche. Ceci reste à confirmer par des études détaillées, mais ce postulat sera utilisé au chapitre 4.

III.5. Présentation de la méthode d’injection de fautes utilisée pour la