Implantation des blocs du watchdog

III.3.1. L’interface microprocesseur 

Le but de l'unité d'interface avec le microprocesseur est de mettre les informations disponibles dans un état défini pour les autres unités quelque soit l’état du processeur principal. Cette description est paramétrée avec les informations décrivant le processeur principal.

Selon le principe exposé au chapitre II, cette interface devait recevoir en entrée le contenu du bus d’adresses du microprocesseur, les bus de données et d'instructions et certains signaux de contrôle. Pour notre prototype, ces informations sont extraites juste après leur lecture dans le pipeline, c'est-à-dire en entrée de l'étage de décodage, plutôt que dans l'étage de lecture d'instruction. Certains signaux de contrôle devant être extraits à ce niveau là, il était plus simple de ne modifier que cette partie du modèle du Leon3 pour l'extraction de l'ensemble des informations utiles. Nous reviendrons sur les conséquences lorsque nous discuterons les résultats des injections de fautes.

Cette interface est structurée en deux parties. La première permet de déterminer l’état du système afin de synchroniser le processeur et le coprocesseur. La deuxième permet de mimer partiellement la structure interne du processeur pour pouvoir donner à l’unité d’exécution du watchdog des données structurées indépendamment du processeur.

Le bloc de synchronisation permet de vérifier la plage de mémoire qui est utilisée. En effet le processeur Leon3 exécute les programmes que nous lui avons fournis et situés dans une zone spécifique de la mémoire. Par défaut cette plage commence à x’’40000000’’, mais c’est une donnée configurable si nécessaire.

Le bloc de synchronisation utilise différentes informations provenant du processeur. Pour connaître l’état du Leon nous avons un signal très important appelé « holdMicro ». Ce signal permet de déterminer si le pipeline du Leon est actif, si c’est le cas alors cela signifie que les informations prises sur le bus d’instructions doivent être prise en compte. Un deuxième signal est très important, c’est celui que nous avons appelé « annul_bit ». Ce signal apparaît dans l’étage des exceptions du Leon. S’il est levé alors l’instruction étant dans le même étage n’est pas exécutée. C’est pourquoi il faut attendre cet étage pour savoir s’il faut prendre en compte cette instruction.

Le deuxième bloc de l’unité est en fait une sorte de faux pipeline, illustrée par la figure 3-3. Ce deuxième bloc crée également les deux signaux d’horloges, en opposition de phase, utilisés pour synchroniser l’ensemble.

III.3.2. L’unité de compaction 

L'unité de compaction est constituée d’un MISR permettant de faire une division polynomiale récursive sur 32 bits en utilisant ce qui vient du bus d’instruction du processeur principal, les bits de poids faible servant de signature. Cette unité contient également une pile permettant de sauvegarder des signatures intermédiaires avant de faire certains sauts (Voir figure 3-4).

Figure 3-4: Schéma simplifié de l'unité de compaction III.3.3. L’unité d’exécution 

L'unité d'exécution est de loin la plus complexe du watchdog et aussi la plus importante en nombre de composants (autour de 60% du watchdog). C’est cette unité qui dirige l’exécution des instructions, effectue les vérifications et commande l’interface mémoire et l’unité de compaction. De plus, cette unité reçoit de nombreuses informations provenant à la fois de l’interface microprocesseur, de l’interface mémoire et de l’unité de compaction.

Les différents rôles de cette unité doivent être synchronisés avec les autres blocs du watchdog. Pour certaines instructions, nous avons même eu besoin que plusieurs blocs synchrones soient utilisés successivement dans le même cycle pour éviter de ralentir le processeur. Il faut alors utiliser une synchronisation à la fois sur front montant et sur front descendant.

La figure 3-5 permet d’illustrer le flux de données dans l'architecture au cours du temps. L'unité d'exécution a été éclatée pour avoir une vision plus précise des dépendances. Le décodage et les vérifications sont purement combinatoires. Le schéma représente dans quelle partie du cycle leur calculs sont significatifs.

Figure 3-5: Flux de données dans le watchdog

Figure 3-6: Schéma de l'unité d'exécution

• _{Address_in : Ce bloc utilise les adresses provenant de l’interface microprocesseur pour} détecter si les adresses se suivent ou non, émettant ainsi un signal « not_adjacent_addr » réceptionné par le bloc instruction_pointer.

Ce bloc délivre aussi en sortie l’adresse précédemment reçue.

• _{Decoder : Ce bloc permet de séparer les différents champs contenus dans l’instruction}

du watchdog. Les détails des champs sont présentés dans l’annexe A.

Ce bloc envoie aussi les signaux de contrôle à différents blocs de l’unité, notamment les blocs de comparaisons, ainsi qu’à l’unité de compaction.

• Extract : Certains champs du jeu d’instruction comportent des informations hachées

pour diminuer l’espace utilisé dans l’instruction. Les détails de ces champs sont présentés dans l’annexe A. Dans plusieurs formats d’instructions, les adresses de sauts, permettant au watchdog de suivre le Leon, ou encore les adresses de destination, permettant de contrôler l’arrivée du Leon à bon port, sont hachées avec les signatures. Ce bloc permet donc de décoder les champs hachés en utilisant les signatures calculées en ligne, pour récupérer les adresses.

• _{Inst_pointer : Ce bloc permet simplement d’incrémenter l’adresse de l’instruction lue. Il}

permet également de déterminer si un saut est possible. En effet, si le saut n’est pas autorisé et que les adresses n’étaient pas adjacentes alors ce bloc envoi un signal d’erreur au bloc alarm_synthesis.

• _{block_counter : Connaissant la taille d’un bloc, à partir des informations fournies par le}

décodeur, ce bloc permet de faire le décompte des instructions de ce bloc à chaque front montant de l’horloge clk_b. Ce mécanisme permet de déclencher l’instruction de fin de bloc du watchdog quand le Leon arrive sur une instruction de saut.

Ce bloc permet également de faire une comparaison entre les adresses du Leon et les adresses relatives de référence marquant le moment où certaines instructions doivent être effectuées (lecture et écriture des variables critiques).

• cv_comp, sign_comp, addr_comp : Ces trois blocs sont très semblables entre eux. Ils

permettent de comparer deux valeurs à leurs entrées et d’envoyer un signal d’erreur correspondant au bloc alarm_synthesis au cas où ces valeurs ne sont pas égales.

• alarm_synthesis : Ce bloc reçoit tous les signaux d’erreur des différents blocs et en fait la

synthèse. Quand tous les signaux sont dit valides, le signal d’alarme est enregistré et envoyé à l’interface microprocesseur, au front montant de l’horloge clk_a.

Ces blocs peuvent être regroupés en fonction du moment du cycle d’horloge où ils interviennent. Les traitements à effectuer étant assez simples nous pouvons les séparer en deux parties, la première partie étant essentiellement du décodage et la deuxième étant principalement les comparaisons :

• _{Au front montant de l’horloge principale (clk_a) une instruction est lue et l’interface} microprocesseur envoie l’adresse lue sur le bus du processeur principal.

Le décodage se fait, les signaux de contrôle sont positionnés.

• Au front descendant suivant (clk_b) la RAM, le compteur et le compacteur sont

déclenchés.

Le pointeur d’instruction calcule l’adresse de l’instruction suivante, les comparaisons sont faites. Au front montant suivant (clk_a en bas) le dernier bloc fait une synthèse globale des signaux d’erreur reçu et renvoie le signal d’alarme à l’interface microprocesseur.

III.3.4. L’interface mémoire 

Le rôle de l'unité d'interface mémoire est de gérer les accès et les possibilités de modifications de la mémoire du watchdog, en ajoutant par exemple un niveau de cache, mais aussi de gérer les spécificités éventuelles du stockage en mémoire.

Par ailleurs, une amélioration de cette interface peut être apportée concernant la gestion de réalignement des instructions lues sur le bus d’instructions. En effet, il est vrai que pour notre prototype, nous avons opté pour le schéma « une instruction par ligne », (Voir paragraphe A.4) mais une optimisation de cette organisation peut être envisagée pour des travaux ultérieurs étant donné que les instructions sont de tailles variables. Or, une organisation différente de la mémoire peut engendrer une différence d’alignement entre ce qui est lu dans la mémoire physique et ce qui est attendu sur le bus d’instruction, et cette différence doit pouvoir être gérée par l’interface mémoire.