• Aucun résultat trouvé

2.5 Résultats

2.5.7 Implications pour la gestion du test en ligne

Comme nous l’avons mentionné dans l’introduction de ce mémoire, notre objectif est de développer des méthodes de test en ligne adaptées à la fois aux erreurs intermittentes et aux architectures multiprocesseurs. Dans ce sens, les résultats de ce chapitre permettent d’apporter plusieurs informations utiles pour la suite.

Premièrement, nous avons prouvé qu’il est possible d’observer des erreurs intermittentes avant l’apparition d’erreurs permanentes. Et cela suffisamment tôt pour envisager la restauration des processeurs. Cela confirme que l’utilisation d’un test en ligne doit être mise en place.

Deuxièmement, nous savons que les erreurs intermittentes apparaissent en burst et que seul l’arrêt du processeur permet de stopper ces erreurs. Tant que le processeur est en activité les erreurs sont maintenues. Cela peut être utilisé en plus du test en ligne comme méthode de restau- ration du système. Une fois l’erreur détectée, le processeur peut être arrêté le temps de stopper l’apparition de l’erreur.

Troisièmement, nous avons vu que les burst d’erreurs intermittentes peuvent être représentés par deux paramètres, leur durée moyenne de maintien et la durée moyenne entre deux erreurs. Basé sur ces paramètres, nous pourrons modéliser ces erreurs par un modèle de Markov afin d’évaluer la probabilité de détection de plusieurs méthodes de test en ligne.

Quatrièmement, nous avons observé plus d’erreurs sur les processeurs soumis à la plus forte activité. Dans une architecture multiprocesseurs, ce résultat permettra de faire l’hypothèse que les processeurs soumis à la plus forte activité ont la plus grande probabilité d’être en erreur.

2.6

Conclusion

Jusqu’à présent, aucune étude n’a observé des erreurs intermittentes sur un système embarqué dans une technologie actuelle. Ce chapitre a permis de définir une plateforme expérimentale capable d’observer des erreurs intermittentes. Pour cela, des processeurs en technologie 65 nm sont soumis, d’une part à une température supérieure à 160°C et d’autre part à l’exécution d’un ensemble d’applications. Ces deux paramètres représentent respectivement un stress externe et un stress interne. Le stress en température permet d’accélérer le vieillissement des processeurs et ainsi de générer des erreurs intermittentes. Le stress interne permet de sensibiliser les différentes parties du processeur et permet de générer plusieurs profils d’activité différents.

Nous avons pu confirmer que les erreurs intermittentes peuvent être observées avant l’appari- tion d’erreurs permanentes. Nos résultats confirment la présence de défauts intermittents très tôt avant la période d’usure du circuit. De plus, nous montrons que les circuits intégrés soumis à la plus forte activité présentent le plus grand nombre d’erreurs intermittentes. Cependant, toutes les applications utilisées n’ont pas présenté le même nombre d’erreur, ainsi l’observation des erreurs intermittentes dépend aussi des applications.

Concernant le mode d’apparition des erreurs intermittentes, toutes nos observations ont mon- tré une apparition de type burst. Les erreurs apparaissent en rafale et seul l’arrêt des processeurs semble les stopper.

Ces informations seront utiles pour mettre en place un système de détection en ligne des erreurs intermittentes.

CHAPITRE

3

Méthodes de détection en ligne des

erreurs

Sommaire

3.1 Critères de sélection . . . 54 3.2 Notions de tolérance aux fautes . . . 54 3.2.1 Les différentes étapes de la tolérance aux fautes . . . 54 3.2.2 Masquage . . . 55 3.2.3 Détection . . . 55 3.2.4 Isolation . . . 58 3.2.5 Diagnostic . . . 59 3.2.6 Reconfiguration/réparation . . . 60 3.2.7 Rétablissement . . . 60 3.3 Les approches de détection en ligne des erreurs . . . 61 3.3.1 Détection en ligne des erreurs par redondance spatiale . . . 62 3.3.2 Détection en ligne des erreurs par vérification de propriétés d’exécution 64 3.3.3 Détection en ligne des erreurs par redondance temporelle matérielle 67 3.3.4 Détection en ligne des erreurs par redondance temporelle logicielle . 69 3.3.5 Détection en ligne des erreurs par utilisation de structures de test . . 72 3.4 Conclusion . . . 75

L

ES DEUX CHAPITRES précédents ont permis de situer le contexte de ce mémoire. Nous

avons vu, dans le premier chapitre que plus la technologie évolue et plus il est difficile de fabriquer des circuits intégrés sans aucun défaut. Ces défauts ne sont pas forcément visibles dès le début de la vie du composant, et peuvent se matérialiser par des fautes de délais avec le vieillissement du circuit, des fluctuations des tensions d’alimentation ou de la température. Ainsi, un circuit intégré peut être soumis à différents types de fautes durant sa vie. Nous avons vu que ces fautes peuvent être transitoires, intermittentes ou permanentes.

Nous avons confirmé, dans le deuxième chapitre, que des erreurs intermittentes peuvent se manifester avant que le système ne soit défaillant. Avant cela, aucune étude n’avait analysé ex- périmentalement l’apparition des erreurs intermittentes sur un système embarqué complexe dans une technologie actuelle. Nous avons, en particulier, montré que les erreurs intermittentes peu- vent être observées à un niveau système pendant le fonctionnement du circuit intégré. Ainsi, il est possible de définir des méthodes de test en ligne capables de détecter les erreurs intermittentes.

Dans ce sens, la première partie de ce chapitre présentera la notion de tolérance aux fautes et toutes les étapes nécessaires pour la mettre en place. La deuxième partie présentera un état de l’art des techniques de détection en ligne des erreurs. Cela permettra, dans la troisième partie, de comparer les différentes techniques dans le but de déterminer une méthode adaptée à la fois aux erreurs intermittentes et aux architectures multiprocesseurs.

3.1

Critères de sélection

Le but de notre étude est de définir une méthode capable de détecter en ligne des erreurs intermittentes dans une architecture multiprocesseur. Cependant, nous définissons ici un certain nombre de critères auxquels la méthode sélectionnée devra répondre. Tout d’abord, la solution choisie ne devra pas nécessiter la modification des processeurs. En effet, nous considérerons dans notre étude que nous avons peu de connaissances des processeurs et qu’ils peuvent être de plusieurs types différents au sein de l’architecture. De même, l’impact sur les performances et le coût en surface silicium seront des critères déterminants.

Nous avons montré dans les deux chapitres précédents, que le vieillissement varie dans le temps et que le besoin en fiabilité n’est pas le même pour toutes les applications. Ainsi, la méth- ode que nous voulons déterminer doit pouvoir être adaptée en fonction du vieillissement et en fonction des applications.

Fonctionnalités à apporter :

– Capacité à détecter des erreurs intermittentes – Adaptation au vieillissement

– Adéquation application ⇔ niveau de fiabilité – Gestion en ligne de fiabilité

– Évaluation de l’apport en fiabilité

Peu d’impact sur : – Coût silicium

– Design (Pas de modification des IP) – Consommation

– Performance

TABLE3.1 :Critères de sélection du procédé de détection en ligne des erreurs.