Méthode de reconfiguration dynamique pour un réseau-sur-puce tolérant aux fautes

Texte intégral

(1)UNIVERSITÉ DE MONTRÉAL. MÉTHODE DE RECONFIGURATION DYNAMIQUE POUR UN RÉSEAU-SUR-PUCE TOLÉRANT AUX FAUTES. JESSICA ALLARD BERNIER DÉPARTEMENT DE GÉNIE INFORMATIQUE ET DE GÉNIE LOGICIEL ÉCOLE POLYTECHNIQUE DE MONTRÉAL. MÉMOIRE PRÉSENTÉ EN VUE DE L’OBTENTION DU DIPLÔME DE MAÎTRISE ÈS SCIENCES APPLIQUÉES (GÉNIE INFORMATIQUE) DÉCEMBRE 2011. © Jessica Allard Bernier, 2011..

(2) UNIVERSITÉ DE MONTRÉAL. ÉCOLE POLYTECHNIQUE DE MONTRÉAL. Ce mémoire intitulé:. MÉTHODE DE RECONFIGURATION DYNAMIQUE POUR UN RÉSEAU-SUR-PUCE TOLÉRANT AUX FAUTES. présenté par : ALLARD BERNIER Jessica en vue de l’obtention du diplôme de : Maîtrise ès Sciences Appliquées a été dûment accepté par le jury d’examen constitué de :. M. LANGLOIS Pierre J.M., Ph. D., président M. BOIS Guy, Ph. D., membre et directeur de recherche M. LANGEVIN Michel, Ph. D., membre.

(3) iii. REMERCIEMENTS. Je tiens tout d’abord à remercier mon directeur de recherche, M. Guy Bois, pour son support et son encadrement tout au long de ma maîtrise, mais aussi pour la confiance qu’il m’a accordée en me permettant de réaliser ce projet.. Je tiens également à remercier STMicroelectronics pour leur intérêt face à ce projet et pour l’aide qu’ils m’ont offerte au niveau de la définition de mon projet de recherche.. Mes remerciements vont également à toute l’équipe du GRM (Groupe de recherche en microélectronique), notamment à Réjean Lepage, administrateur réseau, et Jean Bouchard, technicien, pour leur soutien technique et leur disponibilité.. Un merci particulier à Hubert Guérard, collègue du laboratoire CIRCUS, pour l’aide et les conseils qu’il a su m’apporter au cours de ces dernières années. Également, merci à Jérôme Collin, chargé d’enseignement au département de Génie informatique et Génie logiciel, pour les petits trucs qu’il a su partager avec moi et toutes les fois où il a pu me dépanner.. Je remercie la CMC pour avoir fourni les outils nécessaires au bon déroulement de ce projet.. D’un côté un peu plus personnel, je remercie mes parents de toujours avoir cru en moi. Je veux finalement remercier mon copain, Eric, qui a su m’épauler et me motiver pour mener à terme ce projet, mais aussi pour toutes les pages qu’il a lues et relues et ses commentaires constructifs.. Merci à tous !.

(4) iv. RÉSUMÉ. Avec l’avancement des technologies, les systèmes intégrés ne cessent de gagner en complexité dans le but de remplir toujours plus de fonctionnalités. Pour augmenter les performances et permettre de connecter plus de ressources ensemble pour répondre aux nouveaux besoins sans dégrader les communications, l’utilisation des réseaux sur puce a fait son apparition. Beaucoup d’architectures de réseaux sur puce ont été proposées lors des dernières années. Elles diffèrent selon leur topologie, leur technique de commutation, leurs interconnexions, l’implémentation de leurs nœuds, etc. Parmi les nouvelles architectures de réseaux sur puce, nous comptons notamment le Rotator-on-Chip (RoC) qui a été développé en partenariat par l’École Polytechnique de Montréal et STMicroelectronics.. La constante miniaturisation des transistors a mené les réseaux sur puce, et même tous les systèmes, à devenir de plus en plus vulnérables aux fautes. Il est devenu essentiel pour rencontrer un certain niveau de fiabilité d’intégrer des méthodes de tolérance aux fautes dans les systèmes. Les fautes peuvent affecter les circuits de différentes façons. Elles peuvent avoir des effets permanents comme des défauts de fabrication par exemple. Elles peuvent également engendrer de mauvais fonctionnements ayant un comportement transitoire comme dans le cas d’interférences magnétiques.. L’objectif est que les systèmes remplissent leurs fonctionnalités même en présence de fautes. Dans le cas des réseaux sur puce, la fonctionnalité principale est de transmettre des messages entre les ressources. Alors, le but est de s’assurer qu’aucun bit ne soit altéré lors du transfert. Pour ce faire, plusieurs recherches ont déjà été menées à ce sujet, exploitant des concepts de détection, de redondance, de retransmission, de correction, etc..

(5) v Ce mémoire met tout d’abord en lumière le concept de réseau sur puce. Il définit les différentes bases de leur implémentation, notamment leurs composants, leurs techniques de commutation et de routage et leurs topologies. Puisque la tolérance aux fautes est un aspect central de ce travail, une explication de la provenance et de la classification des fautes pouvant survenir à l’intérieur des réseaux sur puce est également détaillée. Pour parvenir à contrer l’effet de ces fautes, plusieurs techniques de tolérance aux fautes ont été développées, que ce soit par l’industrie ou suite à des recherches universitaires. Ce travail présente quelques-unes d’entre elles.. L’essentiel de ce mémoire repose sur l’élaboration d’une technique de tolérance aux fautes adaptée aux caractéristiques du RoC. La technique proposée est de type prévention plutôt que de type correction. Lorsqu’une faute est détectée sur le chemin de données, la méthode s’assure que la faute n’affectera pas d’autres paquets en reconfigurant les canaux du RoC. Pour parvenir à définir la technique de prévention la plus efficace, plusieurs implémentations sont comparées. La couche où la technique de prévention est gérée, que ce soit au niveau logiciel ou matériel, le mécanisme de détection utilisé et la méthode de reconfiguration des canaux font notamment partie de celles-ci.. Pour déterminer quelle technique de prévention s’avère être la plus efficace pour le RoC, ces dernières sont évaluées en termes du nombre d’erreurs évitées, du délai moyen des paquets, du temps de vérification nécessaire et du nombre de ressources utilisées. Les simulations effectuées démontrent qu’une technique intégrée au niveau matériel nécessite beaucoup plus de ressources qu’une technique gérée au niveau logiciel, mais qu’elle permet d’éviter beaucoup plus d’erreurs. Entre autres, les fautes causées par des effets transitoires et une partie des fautes présentes sur l’en-tête des paquets ne sont pas prises en charge dans le cas de la gestion logicielle. De plus, la technique au niveau matériel se démarque par son temps de vérification nul étant donné que la vérification et l’exécution de l’application sont effectuées de façon simultanée. Pour obtenir le rapport de performance le plus élevé, ce sont le bit de parité, comme mécanisme de détection, et la reconfiguration instantanée des canaux qui sont utilisés..

(6) vi La technique de prévention présentée, bien qu’elle soit développée sur le RoC, pourrait être implémentée sur d’autres réseaux sur puce multidimensionnels. Cette méthode permet de gérer autant les fautes permanentes que transitoires. Cela signifie que les circuits présentant des défauts de fabrication pourraient quand même être utilisés. D’autres circuits pourraient en tirer des bénéfices en étant plus robustes pour répondre à des applications critiques..

(7) vii. ABSTRACT. With the advancement in technology, embedded systems are continuously asked to support more functionalities and that brings them in becoming more and more complex. The networks on chip (NoCs) appeared in embedded systems to help managing this new complexity. A lot of NoC architectures have been proposed in the last few years, each differentiating from one another by their topology, switching technique, routing technique and so on. The Rotator on Chip (RoC), a NoC architecture developed by Polytechnique and STMicroelectronics, is one of them.. The technology scaling caused NoCs to become more vulnerable to faults. These faults can affect the system permanently, like in the case of manufacturing defects, or transiently, with magnetic interferences for instance. In order to attain a certain reliability level, fault tolerance methods must be implemented in systems. The objective is that the systems are able to achieve their functionalities even in the presence of faults. In the case of NoCs, the purpose is to make sure that no bit of the transferred packets will be corrupted. That can be done using different concepts like detection, redundancy, retransmission, correction and so on.. This thesis highlights the use of fault tolerance mechanisms in NoCs by describing the main concepts involved in NoC implementation, the faults which can occur in NoCs and the fault tolerance methods used in some specific cases.. The elaboration of a fault tolerance method adapted to the RoC characteristics is the main focus of this thesis. The proposed technique is a preventive method, rather than a corrective method. When a fault is detected on the data path, the channel reconfiguration prevents this fault from affecting other packets. Among the different implementations being compared are the layer where the preventive method is managed, the detecting mechanisms and the reconfiguration methods. Those implementations are evaluated in terms of residual packet error rate, average latency, verification time and cost in resources..

(8) viii Simulations show that a method managing at the hardware level, although more expensive than one managing at the software level, is more effective. This hardware method prevents many more errors and requires no verification time. The best performing rate is obtained with parity bit as the detecting mechanism and with instant channel reconfiguration.. This preventing technique could be integrated in others multidimensional NoCs. Furthermore, it could be used to allow circuits with manufacturing defects to be used in some cases and to allow NoCs to execute critical applications..

(9) ix. TABLE DES MATIÈRES REMERCIEMENTS ..................................................................................................................... III RÉSUMÉ ....................................................................................................................................... IV ABSTRACT .................................................................................................................................VII TABLE DES MATIÈRES ............................................................................................................ IX LISTE DES TABLEAUX ............................................................................................................XII LISTE DES FIGURES ............................................................................................................... XIII LISTE DES SIGLES ET ABRÉVIATIONS ............................................................................. XVI LISTE DES ANNEXES .......................................................................................................... XVIII INTRODUCTION ........................................................................................................................... 1 CHAPITRE 1 1.1. REVUE DE LITTÉRATURE ............................................................................. 6. Les réseaux sur puce ........................................................................................................ 6. 1.1.1. Les couches des réseaux sur puce ................................................................................ 7. 1.1.2. L’implémentation générale des réseaux sur puce ........................................................ 8. 1.1.3. Les topologies des réseaux sur puce .......................................................................... 11. 1.2. Les fautes dans les réseaux sur puce .............................................................................. 16. 1.2.1. Causes et classification des fautes .............................................................................. 16. 1.2.2. Caractérisation des fautes ........................................................................................... 17. 1.3. Méthodes de gestion des fautes pour les réseaux sur puce ............................................ 21. 1.3.1. Méthodes de redondance de base pour la tolérance aux fautes .................................. 22. 1.3.2. « Nouvelles » méthodes pour la tolérance aux fautes ................................................ 24. CHAPITRE 2. ROTATOR ON CHIP ....................................................................................... 31. 2.1. Vue d’ensemble .............................................................................................................. 31. 2.2. Architecture du RoC....................................................................................................... 33.

(10) x 2.2.1. Interface Nœud ........................................................................................................... 33. 2.2.2. Banque ........................................................................................................................ 33. 2.2.3. Nœud .......................................................................................................................... 33. 2.3. Optimisations ................................................................................................................. 36. 2.3.1. Flot de communication ............................................................................................... 36. 2.3.2. Optimisation du chemin de données .......................................................................... 37. CHAPITRE 3. MÉTHODES DE TOLÉRANCE AUX FAUTES PROPOSÉES ..................... 38. 3.1. Vue d’ensemble .............................................................................................................. 38. 3.2. Mécanismes de détection des fautes............................................................................... 38. 3.3. Technique de prévention des fautes au niveau logiciel .................................................. 39. 3.3.1. Protocole de communication ...................................................................................... 39. 3.3.2. Modifications apportées à l’architecture du RoC ....................................................... 42. 3.3.3. Technique de vérification ........................................................................................... 44. 3.3.4. Limitation de la méthode............................................................................................ 47. 3.4. Technique de prévention des fautes au niveau matériel ................................................. 49. 3.4.1. Types de fautes ........................................................................................................... 49. 3.4.2. Modifications apportées à l’architecture du RoC ....................................................... 49. 3.4.3. Techniques de vérification ......................................................................................... 54. CHAPITRE 4 4.1 4.1.1. ENVIRONNEMENT DE TEST ....................................................................... 56. Injection de fautes .......................................................................................................... 56 Format des fautes ....................................................................................................... 56. 4.2. Architecture des bancs de tests....................................................................................... 58. 4.3. Description des scénarios de simulation ........................................................................ 61. 4.3.1. Scénarios d’injection des fautes ................................................................................. 61.

(11) xi 4.3.2 4.4. Scénario de communication ....................................................................................... 62 Hypothèses ..................................................................................................................... 63. CHAPITRE 5 5.1. RÉSULTATS ET ANALYSE ........................................................................... 65. Méthode de vérification logicielle.................................................................................. 65. 5.1.1. Sélection des canaux de communication .................................................................... 66. 5.1.2. Technique de détection des fautes .............................................................................. 67. 5.1.3. Délai moyen des paquets ............................................................................................ 70. 5.1.4. Temps nécessaire à la vérification ............................................................................. 71. 5.1.5. Prise en charge des fautes transitoires ........................................................................ 72. 5.2. Méthode de vérification matérielle ................................................................................ 73. 5.2.1. Fautes permanentes .................................................................................................... 73. 5.2.2. Fautes transitoires ....................................................................................................... 79. 5.3. Ressources utilisées ........................................................................................................ 87. 5.4. Discussion ...................................................................................................................... 89. CONCLUSION ET TRAVAUX FUTURS .................................................................................. 90 BIBLIOGRAPHIE ........................................................................................................................ 93.

(12) xii. LISTE DES TABLEAUX Tableau 1-1: Probabilités de différents types de fautes sur un réseau sur puce ............................. 20 Tableau 1-2: Comparaison des méthodes de correction et de vérification des fautes .................... 29 Tableau 3-1: Description de l'interface du module bitmap_error_update ..................................... 43 Tableau 3-2: Algorithme général de la technique de prévention au niveau logiciel ...................... 45 Tableau 3-3: Niveau critique des champs de l'en-tête .................................................................... 48 Tableau 3-4: Description de l'interface du module test_generator ................................................ 51 Tableau 3-5: Description de l'interface du module test_receiver ................................................... 52 Tableau 3-6: Algorithme général de la technique de prévention au niveau matériel ..................... 54 Tableau 4-1: Paramètres d'une faute .............................................................................................. 57 Tableau 5-1: Simulations effectuées pour la méthode de prévention des fautes au niveau logiciel ................................................................................................................................................ 66 Tableau 5-2: Définition des fautes injectées pour tester le délai.................................................... 70 Tableau 5-3: Simulations effectuées au niveau matériel (fautes permanentes) ............................. 73 Tableau 5-4: Simulations effectuées pour la méthode de prévention au niveau matériel (fautes transitoires) ............................................................................................................................. 79 Tableau 5-5: Paramètres des scénarios de test pour la sélection des canaux ................................. 81 Tableau 5-6: Paramètres des scénarios de test pour les fautes multiples ....................................... 85 Tableau 5-7: Ressources disponibles sur le XC4VFX60-11FFG1152 .......................................... 87 Tableau 5-8: Ressources utilisées par les composants de test intégrés aux nœuds ........................ 87 Tableau 5-9: Ressources utilisées pour un seul nœud dans une configuration 8 nœuds et 3 canaux ................................................................................................................................................ 87 Tableau 5-10: Ressources utilisées pour les différentes techniques de prévention........................ 88.

(13) xiii. LISTE DES FIGURES Figure 1-1: Couches des réseaux sur puce ....................................................................................... 7 Figure 1-2: Éléments d'un réseau sur puce ..................................................................................... 10 Figure 1-3: Topologie maille.......................................................................................................... 11 Figure 1-4: Topologie tore ............................................................................................................. 11 Figure 1-5: Topologie d’arbre élargi .............................................................................................. 12 Figure 1-6: Topologie anneau ........................................................................................................ 13 Figure 1-7: Topologie étoile augmentée (NOVA) ......................................................................... 15 Figure 1-8: Circuit du calcul du bit de parité ................................................................................. 22 Figure 1-9: Circuit du calcul du CRC-16 ....................................................................................... 23 Figure 2-1: Architecture du RoC avec 4 nœuds et 2 canaux .......................................................... 32 Figure 2-2: Implémentation d'un nœud du RoC ............................................................................. 34 Figure 2-3: Flot bidirectionnel pour un RoC à 4 nœuds ................................................................ 36 Figure 3-1: Format d'un paquet "application " ............................................................................... 40 Figure 3-2: Format d'un paquet "test parité" .................................................................................. 40 Figure 3-3: Format d'un paquet "test CRC" ................................................................................... 41 Figure 3-4: Format d'un paquet "reconfiguration" ......................................................................... 41 Figure 3-5 : Module node avec prise en charge de la reconfiguration des canaux ........................ 42 Figure 3-6: Flot de tests .................................................................................................................. 45 Figure 3-7: Format de l'en-tête ....................................................................................................... 47 Figure 3-8: Module node avec intégration de la technique de prévention au niveau matériel ...... 50 Figure 4-1: Format d'un paquet de faute ........................................................................................ 56 Figure 4-2: Emplacement du processus d'injection de faute dans un nœud (exemple d'un nœud supportant la technique de vérification logicielle) ................................................................. 57.

(14) xiv Figure 4-3: Architecture générale du banc de tests ........................................................................ 58 Figure 4-4: Architecture spécifique du banc de tests ..................................................................... 59 Figure 4-5: Scénario de communications aléatoires ...................................................................... 62 Figure 4-6: Graphiques démontrant la proportionnalité des résultats ............................................ 63 Figure 4-7: Graphiques présentant le taux de répercussion des fautes horaire et antihoraire ........ 64 Figure 5-1: Graphique de comparaison pour la sélection des canaux ............................................ 66 Figure 5-2: Graphiques comparant les techniques de parité et CRC pour des fautes simples ....... 67 Figure 5-3: Graphiques comparant les techniques de parité et CRC pour des fautes multiples .... 67 Figure 5-4: Graphiques comparant les performances des techniques de double vérification ........ 68 Figure 5-5: Graphique du nombre de paquets erronés avec des fautes sur la partie des données seulement ................................................................................................................................ 69 Figure 5-6: Graphique du délai moyen en fonction du nombre de fautes injectées ....................... 70 Figure 5-7: Graphique présentant l'augmentation du temps pour la vérification double ............... 71 Figure 5-8: Graphique comparant les algorithmes de gestion des fautes ....................................... 75 Figure 5-9: Graphique montrant l'évolution des paquets en faute ................................................. 75 Figure 5-10: Graphiques comparant les techniques de détection avec une configuration 16 nœuds et 3 canaux .............................................................................................................................. 77 Figure 5-11: Graphiques comparant les techniques de détection pour une configuration 32 nœuds et 4 canaux .............................................................................................................................. 78 Figure 5-12: Graphique comparant les algorithmes de gestion de fautes avec des fautes transitoires .............................................................................................................................. 80 Figure 5-13: Graphique comparant la sélection des canaux avec la technique de détection CRC 82 Figure 5-14: Graphique comparant la sélection des canaux avec la technique de parité ............... 82 Figure 5-15: Graphique comparant les techniques de détection avec une sélection tourniquet .... 84.

(15) xv Figure 5-16: Graphique comparant les techniques de détection avec une sélection des canaux par priorité .................................................................................................................................... 84 Figure 5-17: Graphique comparant les techniques de détection des fautes pour des fautes multiples ................................................................................................................................. 86 Figure 5-18: Graphique comparant les technique de détection avec une architecture 32 nœuds et 4 canaux..................................................................................................................................... 86.

(16) xvi. LISTE DES SIGLES ET ABRÉVIATIONS La liste des sigles et abréviations présente, dans l’ordre alphabétique, les sigles et abréviations utilisés dans le mémoire ou la thèse ainsi que leur signification. En voici quelques exemples : ARQ. Automatic Repeat Request. BER. Bit Error Rate. BIST. Built-in Self-test. CRC. Cyclic Redundancy Check. DUT. Design Under Test. FDAR. Fault Diagnosis And Repair. FEC. Forward Error Correction. FIFO. First In First Out. FIT. Failures In Time. Flit. Flow control digits. FPGA. Field Programmable Gate Array. GP. Generalized Petersen. HARQ. Hybride ARQ/FEC. ID. Identification. LSB. Least Significant Bit. LUT. Lookup Table. MCC. Mesh Connected Crossbars. MSB. Most Significant Bit. MSN. Manhattan Street Network. MTBF. Mean Time Between Failures. OVM. Open Verification Methodology.

(17) xvii R2NoC. Ring Road NoC. RPER. Residual Packet Error Rate. RoC. Rotator on Chip. RRA. Round Robin Arbiter. RTL. Register Transfer Level. SEE. Single Event Effects. SET. Single Event Transient. SEU. Single Event Upset. SHE. Single Hard Error. SPIN. Scalable Programmable Interconnection Network. VCR. Vertical Redundancy Checks. XGFT. eXtended Generalized Fat Tree.

(18) xviii. LISTE DES ANNEXES. ANNEXE 1 - Calcul du CRC…………………………………………………………………….97.

(19) 1. INTRODUCTION. Les systèmes intégrés sont de plus en plus utilisés dans le but d’optimiser des applications dédiées. Nous n’avons qu’à penser aux téléphones cellulaires ou aux lecteurs MP3 qui font partie intégrante de notre vie quotidienne. Ils peuvent également avoir des applications plus critiques comme dans le domaine de la santé, de l’automobile, de l’aérospatial, etc. Avec l’avancement des technologies, ces systèmes ne cessent de gagner en complexité dans le but de remplir toujours plus de fonctionnalités. Pour augmenter les performances et répondre à toutes les fonctionnalités, il faut se tourner vers des systèmes présentant de plus en plus d’éléments de traitement.. Dans le but d’optimiser ces systèmes, deux principaux axes peuvent être analysés : les traitements de calcul et les communications entre les différents éléments. En solution au deuxième axe, différents designs ont été étudiés. Les communications point-à-point ont longtemps été utilisées, mais plus le nombre d’éléments à interconnecter augmente, plus cette solution devient impensable étant donné le nombre de liens nécessaires. Les bus ont longtemps été (et sont encore) une alternative en connectant toutes les ressources sur un bus qui gère les accès à l’aide d’un arbitre. Cette architecture a, par contre, beaucoup de limitations au niveau de la latence des paquets et de la bande passante. Une solution proposée pour éviter ces problèmes est l’utilisation des réseaux sur puce.. Les réseaux sur puce utilisent les mêmes principes que les réseaux informatiques permettant de faire communiquer plusieurs usagers ensemble. En plus d’offrir une bande passante beaucoup plus grande, ils permettent une bonne adaptation au nombre d’éléments à connecter et des communications plus rapides. Diverses architectures de réseaux sur puce ont été développées ces dernières années notamment en se basant sur les topologies de la maille et de l’anneau qui restent des paradigmes dans le monde des réseaux. Le Rotator-on-Chip (RoC) (Hadjiat et al., 2007), architecture. développée. en. partenariat. par. l’École. Polytechnique. de. Montréal. STMicroelectronics, fait partie de ces réseaux sur puce utilisant une topologie en anneau.. et.

(20) 2 Problématique Tous les réseaux sur puces ont des caractéristiques propres à eux qui les rendent plus attrayants dans certains domaines, notamment le nombre de ressources supportées, la rapidité des communications, l’énergie nécessaire, le nombre de ressources utilisées, etc. Au niveau des communications, bien que le débit soit une des métriques les plus importantes, il ne faut pas non plus oublier la fiabilité du transit des données. C’est pourquoi de plus en plus de réseaux sur puce sont développés dans une optique de tolérance aux fautes.. « […] fault tolerant systems which must continue to meet their functional and performance requirements in the presence of failures [….] » (Douglass Locke, 1994). Avec la taille des systèmes sur puce devenant de plus en plus petite, ces systèmes sont maintenant beaucoup plus vulnérables aux fautes. Il est devenu essentiel pour rencontrer un certain niveau de fiabilité d’intégrer des méthodes de protection pour contrer l’effet des fautes dans ces systèmes. En plus qu’il est presque impossible de fabriquer des circuits de la taille d’un nanomètre sans aucun défaut, différentes sources induisant du bruit dans les réseaux sur puce mettent en péril leur fiabilité. Ces sources peuvent être internes au circuit lui-même telles les variations de tension et la diaphonie (crosstalk), mais elles peuvent également provenir de l’extérieur comme les interférences magnétiques et les effets des particules alpha en témoignent.. La quête de la tolérance aux fautes n’est pas nouvelle en soi dans le domaine des réseaux sur puce et plusieurs recherches ont été menées sur ce sujet. Le but ultime est qu’aucune donnée ne soit corrompue, autrement dit, qu’aucun bit lors de la transmission ne soit modifié ou, tout simplement, n’arrive pas à destination. Pour ce faire, dans la majorité des cas, l’erreur est tout d’abord détectée et, par la suite, traitée. Dans la littérature, les méthodes de détection d’erreur les plus utilisées sont le contrôle par redondance cyclique (cyclic redundancy check, CRC) (Peterson, 1960), le code de Hamming (Hamming, 1950) et le bit de parité. Une fois l’erreur détectée, il faut définir de quelle manière elle sera traitée. Dans certains cas, d’un point de vue énergétique, quand les communications se font point-à-point sur une courte distance, il est préférable d’opter pour.

(21) 3 une technique de retransmission. Par contre, pour des connexions plus longues, il est préférable d’opter pour une technique de correction d’erreur (Bertozzi, Benini, & De Micheli, 2005). Il est également possible d’amalgamer plusieurs stratégies existantes dans le but de trouver celle qui est la plus performante pour la topologie et l’utilisation de notre réseau sur puce; c’est essentiellement l’objectif principal de ce projet. Cette composition peut être effectuée à différents niveaux, notamment en évaluant le niveau de bruit présent sur chaque connexion (Li, Vijaykrishnan, Kandemir, & Irwin, 2003) ou en associant un mode de contrôle des erreurs différent à chacun des sous-modules de notre réseau.. Objectifs L’objectif principal de ce mémoire est de concevoir une technique de tolérance aux fautes adaptée aux caractéristiques du RoC. Plusieurs techniques de tolérance aux fautes ont déjà été développées pour les réseaux sur puce, soit pour énoncer des concepts de base, comme la détection et la correction, ou pour répondre à des besoins bien précis pour certaines architectures. Il s’agira donc d’être capable de tirer profit de toutes ces techniques en créant un amalgame pour augmenter la tolérance aux fautes du RoC qui sera évaluée en termes de nombre de fautes évitées, de latence moyenne des paquets et de ressources utilisées. Par la suite, il sera possible de comparer la méthode présentée à d’autres méthodes existantes.. Un second objectif est de comparer des techniques de tolérance aux fautes gérées au niveau logiciel avec d’autres intégrées directement au matériel. Cela sera effectué à partir des techniques de tolérance aux fautes élaborées pour le RoC.. Méthodologie La première étape de ce travail est de définir l’architecture de réseau sur puce utilisée et de définir ses caractéristiques. Il sera important ici d’utiliser une architecture de réseau sur puce novatrice dont il est possible d’avoir accès à l’implémentation. Le RoC étant développé en collaboration avec STMicroelectronics et Polytechnique, cela permet d’avoir accès au code source de ce réseau sur puce et, de plus, il s’agit d’un nouveau design de réseau, ce qui répond.

(22) 4 aux deux requis préalablement établis. Lors de la définition du fonctionnement et des caractéristiques du RoC, il sera possible de mettre en lumière certaines particularités qui pourront être exploitées lors du développement de la technique de tolérance aux fautes pour la rendre plus performante et efficace. Nous pouvons penser notamment à son aspect multidimensionnel. Bien entendu, parallèlement à cette étape, une étude sur l’état de l’art sera effectuée dans le but d’aiguiller le travail sur le RoC.. La deuxième étape est de définir une méthode de tolérance aux fautes utilisant les particularités du RoC qui peuvent se retrouver dans d’autres réseaux. Pour permettre de définir la technique la plus performante et efficace, plusieurs variantes devront être explorées. Les deux axes principaux seront la technique au niveau logiciel et celle intégrée au niveau matériel. Des modèles RTL (Register Transfer Level) des différentes techniques seront implémentés à l’intérieur du réseau choisi (RoC) pour permettre de les comparer.. L’étape finale sera de déterminer quelle technique de tolérance aux fautes s’avère être la meilleure. La performance des techniques sera évaluée en fonction du temps de vérification nécessaire, du nombre de fautes évitées, de la latence moyenne des paquets et du nombre de ressources utilisées. Tous ces résultats seront obtenus à l’aide des modèles RTL développés lors de l’étape précédente.. Contribution Le RoC est une architecture de réseau sur puce nouvellement développée qui ne possédait pas de mécanisme pour s’assurer d’une certaine fiabilité au niveau du transfert des données. L’une des contributions les plus importantes de ce travail est de doter le RoC d’un mécanisme de tolérance aux fautes répondant à certains critères de fiabilité au niveau des données.. À un niveau plus étendu, la technique de tolérance étant développée en exploitant certaines particularités du RoC, notamment son aspect multidimensionnel, elle pourrait être intégrée à d’autres réseaux possédant les mêmes caractéristiques pour en retirer les mêmes avantages. Cette.

(23) 5 méthode permet de gérer autant les fautes permanentes que transitoires en ne nécessitant aucun matériel de rechange. Cela signifie que les circuits présentant des défauts de fabrication pourraient quand même être utilisés et, également, que les circuits pourraient être plus robustes pour répondre à des applications critiques.. Distribution des chapitres Ce mémoire est divisé en quatre principales sections. Le chapitre 1 débute par une revue de littérature regroupant deux principaux concepts : les réseaux sur puce et la tolérance aux fautes. En ce qui concerne les réseaux sur puce, le fonctionnement général, les topologies de base ainsi que quelques nouvelles architectures sont présentées. Pour ce qui est de la partie portant sur la tolérance aux fautes, qui est plus explicite, il est discuté de la provenance des fautes, des techniques de modélisation et des méthodes de tolérance. Le chapitre 2 présente l’architecture du RoC, son fonctionnement et ses caractéristiques, plus en détail.. Le chapitre 3 décrit l’implémentation des différentes techniques de prévention des fautes qui ont été développées, que ce soit en utilisant une gestion au niveau logiciel ou au niveau matériel. Finalement, le chapitre 4 présente les résultats obtenus dans le but de comparer les différentes variantes des méthodes..

(24) 6. CHAPITRE 1 REVUE DE LITTÉRATURE. Avec les systèmes sur puce grandissant et utilisant toujours plus de ressources, c’est dans le but de continuer de rencontrer les exigences en termes de performance et de consommation d’énergie que les réseaux sur puce ont été développés. La fiabilité des réseaux sur puce est continuellement reconsidérée avec les technologies de plus en plus petites qui apportent leur lot de gains mais, également, de désavantages. Malheureusement, bien que la réduction de taille permette de gagner notamment en aire, les liens deviennent très susceptibles au bruit, que ce soit par la diminution de la tension et de l’espacement entre les liens ou par l’augmentation de la fréquence d’horloge. Les sources de bruit peuvent être autant de nature interne, si nous pensons à la diaphonie, qu’externe dans le cas des interférences magnétiques, par exemple. Différentes sources de bruit qui peuvent entraîner différents types de fautes seront décrites un peu plus loin dans cette section. Pour faire face à cette réalité, des méthodes ont été développées dans le but d’éviter la propagation de ces erreurs. Les principes de base de ces méthodes sont la détection et la correction des erreurs. Il sera également fait état un peu plus loin dans cette section de plusieurs méthodes qui ont fait leurs preuves et de nouvelles méthodes qui ont été développées dans le but de toujours augmenter l’efficacité de tolérance aux fautes.. 1.1 Les réseaux sur puce Le rôle principal des réseaux sur puce est d’interconnecter plusieurs ressources sans dégrader le débit de données. Chaque réseau a des caractéristiques qui lui sont propres et qui le rend plus attrayant dans certains domaines, notamment le nombre de ressources supportées, la rapidité des communications, etc. Ces caractéristiques dépendent directement des choix architecturaux et du design du réseau. Plusieurs types d’interconnexions sont présentement utilisés pour les systèmes à plusieurs ressources, dont les bus et les réseaux sur puce. Malheureusement, les bus sont dotés d’une faible possibilité d’évolution. Plus le nombre d’éléments augmente, plus les performances diminuent de façon drastique. Les réseaux sur puce, par leur aspect évolutif, sont capables de.

(25) 7 répondre aux carences des bus. Par contre, ils sont limités par leur aire et leur consommation (Arteris, 2005).. 1.1.1 Les couches des réseaux sur puce Les réseaux sur puce sont constitués de différentes couches : la couche physique, la couche liaison, la couche réseau, la couche transport et, finalement, la couche logicielle (Benini & Micheli, 2006).. Figure 1-1: Couches des réseaux sur puce. 1.1.1.1 La couche physique La couche physique consiste en l’implémentation physique. Pour un réseau sur puce, cette implémentation se traduit par les canaux de communication par où la transmission des messages est effectuée.. 1.1.1.2 La couche liaison La couche liaison, quant à elle, va abstraire les données transmises par les canaux de communication en une liaison. Cette liaison est considérée presque sans erreur par la couche réseau. Cette couche permet d’assurer un certain niveau de fiabilité des données qui ne peut pas.

(26) 8 être atteint avec la couche physique. Pour ce faire, cette couche transmet les données sous forme de paquet ou de flit (flow control digits), ce qui facilite la détection et la correction des erreurs.. 1.1.1.3 La couche réseau La couche réseau permet de gérer le routage des paquets créés par la couche liaison qui représente le chemin emprunté pour aller de la source à la destination. Également, elle permet de définir le type d’interconnexion et les différents sous-réseaux.. 1.1.1.4 La couche transport La couche transport est l’entité responsable de la bonne transmission des messages. Elle obtient les messages à transmettre de la couche logicielle, les fragmente en paquets plus petits si nécessaire et les transmet à la couche réseau. Lors de la réception des paquets, elle effectue les opérations contraires dans le but de reconstruire le message envoyé rendu à destination.. 1.1.1.5 La couche logicielle La couche logicielle ici comprend le logiciel matériel, qui correspond à une abstraction de la plateforme, et le logiciel de l’application. Le logiciel matériel peut être associé à la connexion des ressources au réseau habituellement effectuée via des interfaces nœud. Le logiciel application, quant à lui, est le logiciel s’exécutant directement sur les ressources connectées au réseau.. 1.1.2 L’implémentation générale des réseaux sur puce Chaque réseau sur puce a des caractéristiques propres en termes de latence, de débit, d’aire, d’énergie consommée, de fiabilité, etc. Ces caractéristiques sont directement reliées aux choix architecturaux notamment à la commutation, au routage et à la topologie..

(27) 9 1.1.2.1 Les techniques de commutation La commutation dans les réseaux sur puce prend principalement deux formes : la commutation de circuits et la commutation par paquets. La commutation de circuits établit un lien unique entre le transmetteur et le receveur. Lorsque ce lien est réservé, il envoie le message entier par ce même chemin. Si, lors de l’établissement du lien, il y a conflit avec un chemin déjà réservé, l’envoi du message est retardé jusqu’à la libération du chemin en conflit. C’est la technique de commutation qui est utilisée dans le cas du SoCBUS (Wiklund & Dake, 2003), car elle demande un minimum de mémoire et permet d’éviter les interblocages. La commutation par paquets, quant à elle, ne fait aucune réservation de liens et tous les paquets fragmentés du message sont indépendants selon leur chemin. Étant donné qu’il n’y a pas de réservation de chemin, si plusieurs paquets veulent obtenir le même lien, un seul pourra l’avoir et les autres devront attendre.. 1.1.2.2 Les techniques de routage Le routage des paquets est la façon dont le chemin de la source à la destination est défini. Dans le cas de la commutation par paquets, il y a trois principales techniques : stockage et retransmission (store and forward), virtual cut through et trou de ver (wormhole). Le stockage et retransmission est la technique la plus simple qui consiste à ce que le paquet soit envoyé seulement quand il est assuré que le récepteur a suffisamment d’espace mémoire pour le recevoir. Le virtual cut through est similaire à la technique précédente dû au fait que la destination doit être capable de recevoir tout le paquet, mais il se distingue par le fait que ce sont des flits qui sont envoyés en cascade et non pas des paquets entiers. Cela permet donc des transferts de données plus rapides. Finalement, le trou de ver se distingue du virtual cut through par le fait qu’il nécessite de l’espace mémoire pour seulement un flit et non pas un paquet entier. Donc, si l’espace mémoire disponible n’est pas égal à la largeur d’un paquet entier, les flits d’un paquet peuvent être dispersés dans plusieurs routeurs. C’est cette technique qui obtient les meilleures performances en termes de mémoire nécessaire et de latence, mais elle est plus susceptible aux interblocages..

(28) 10 1.1.2.3 Les composants de base Les quatre composants de base à toute architecture de réseaux sur puce sont : l’interface réseau, les nœuds, les interconnexions et les canaux de communication. L’interface réseau sert en quelque sorte d’adaptateur et permet aux ressources externes de se connecter et d’utiliser le réseau sur puce. Les nœuds sont des éléments de calcul, mais aussi de mémoire, qui correspondent aux points d’entrée et de sortie des messages dans le réseau. Les interconnexions servent à acheminer les messages de la source à la destination et peuvent être intégrées au nœud ou non. Les canaux de communication relient les interconnexions ou les nœuds, selon le cas, entre eux.. Figure 1-2: Éléments d'un réseau sur puce. Dans le cas où les interconnexions sont intégrées aux nœuds et où ces derniers ont des liaisons point-à-point entre eux, ces réseaux sont considérés comme des réseaux directs. Dans le cas où les interconnexions sont détachées, mais ont des connexions entre elles, ce sont des réseaux indirects. Des solutions hybrides peuvent aussi exister..

(29) 11. 1.1.3 Les topologies des réseaux sur puce Les topologies des réseaux sur puce sont très similaires à celles des réseaux informatiques classiques. La topologie définit comment les ressources sont reliées entre elles. Chaque disposition obtient des caractéristiques particulières, que ce soit en cas de panne ou pour sa technique de routage. Parmi les topologies de réseaux sur puce, nous comptons notamment la maille, l’arbre et l’anneau, mais il en existe bien plus ayant chacune quelques variantes.. 1.1.3.1 La topologie en maille La topologie en maille est l’une des plus simples et des plus étudiées. Elle consiste à ce que tous les nœuds soient connectés avec leurs voisins, ce qui permet une certaine fiabilité car, en cas de panne d’un lien ou d’un nœud, d’autres chemins sont possibles. La forme la plus simple est une topologie de maille en deux dimensions où chaque nœud est associé à un commutateur, comme présentée à la Figure 1-3 . Par contre, d’autres architectures sont possibles. Notamment, une alternative à la maille de base est le Mesh Connected Crossbars (MCC) (Tavakkol, Moraveji, & Sarbazi-Azad, 2008) qui connecte les nœuds via des barres croisées (crossbars) sur les diagonales du réseau et point-à-point aux bordures. Cette topologie a pour avantage de diminuer la densité de canaux. Cette architecture utilise une technique de routage adaptative qui permet d’acheminer les paquets à travers le réseau en empruntant le chemin minimal.. Figure 1-3: Topologie maille. Figure 1-4: Topologie tore.

(30) 12 Dérivé de la topologie en maille, il existe également le tore (torus) qui est très similaire à la maille, mais qui complète en quelque sorte les liens du réseau en reliant le dernier nœud au premier sur chaque axe, comme il est présenté à la Figure 1-4. Cette topologie est notamment utilisée dans l’architecture du Manhattan Street Network (MSN) (Oommen & Harle, 2005). Le MSN a la particularité que le sens des liens alterne d’une colonne ou d’une ligne à l’autre (verticalement et horizontalement). Comme dans le modèle de base, chaque nœud est associé à une interconnexion qui est en fait une barre croisée. Dans cette architecture, le trafic sur le réseau a priorité sur le trafic spécifique aux nœuds. Également, une autre topologie similaire à celle de la maille et du tore est l’hypercube où les nœuds représentent les sommets du cube et les liens, les arêtes.. 1.1.3.2 La topologie en arbre La topologie en arbre fait appel à la hiérarchie et à la relation parents-enfants. Le nœud au sommet peut être connecté à plusieurs nœuds à un niveau inférieur, qui peuvent eux-mêmes être connectés à d’autres nœuds de niveaux inférieurs, et ainsi de suite. Un des risques de cette topologie est que si l’un des nœuds parents tombe en panne, ce sont tous ses enfants qui sont mis hors service. Une topologie dérivée est celle de l’arbre élargi (fat tree) qui est en réalité une topologie en arbre où les nœuds peuvent seulement être au dernier niveau (feuilles). Par contre, dans cette topologie, les interconnexions aux niveaux supérieurs peuvent avoir plusieurs connexions entre elles, comme présentées à la Figure 1-5. Parmi les architectures d’arbre élargi, nous comptons notamment le SPIN (Scalable Programmable Interconnection Network) (Adriahantenaina, Charlery, Greiner, Mortiez, & Zeferino, 2003) et le XGFT (eXtended Generalized Fat Tree) (Kariniemi & Nurmi, 2005) qui utilisent des liens bidirectionnels.. Figure 1-5: Topologie d’arbre élargi.

(31) 13 1.1.3.3 La topologie en anneau La topologie en anneau relie les nœuds d’un réseau entre eux afin de former une boucle comme à la Figure 1-6. Chaque nœud entre la source et la destination sert alors d’interconnexion. Parmi les architectures de réseau sur puce utilisant la topologie anneau, notons notamment le Proteo, le ftNoC et le RoC. L’implémentation du RoC sera décrite plus en détail dans le chapitre suivant. Le Proteo (Siguenza-Tortosa & Nurmi, 2002) peut être utilisé pour des systèmes hétérogènes divisés en clusters. Le réseau est composé d’un anneau bidirectionnel avec des sous-réseaux de topologie bus ou en étoile. Les ressources sont connectées au réseau via des nœuds qui sont reliés entre eux par des liens. Le réseau est paramétrable à plusieurs niveaux, notamment la profondeur des tampons, le nombre de canaux, leur dimension, la largeur des données, la segmentation des paquets, etc. Dans le but d’économiser de la puissance, il est possible d’éteindre des sous-réseaux en bloquant le nœud qui y est attaché. Comme mécanisme de tolérance aux fautes, les nœuds fautifs sont déconnectés de façon permanente.. Figure 1-6: Topologie anneau. Pour ce qui est du ftNoC (Liguo, Huimin, & Jungang, 2008), il est composé de deux groupes d’anneaux dont l’un est utilisé dans le but de remplacer le premier s’il s’avère défaillant. Chaque groupe d’anneaux est composé d’un anneau de contrôle et d’un de données. Il y a trois types de nœuds qui sont utilisés dans ce réseau : les nœuds de contrôle, les nœuds de données et les nœuds d’interface qui servent à assurer l’interface entre le réseau principal et les sous-réseaux. L’architecture proposée permet d’éviter la congestion, les interblocages, la famine et assure une utilisation efficace de la bande passante. Chaque nœud a un mécanisme de détection des erreurs.

(32) 14 sur les liens de données et les liens de contrôle dans le réseau. S’il y a une erreur sur les données, l’information est propagée à tous les nœuds du réseau par les liens de contrôle. Les données ne sont plus envoyées sur ce lien et l’autre anneau de données est utilisé. S’il y a une erreur sur le contrôle, il y a un changement direct qui est effectué sur le second anneau de contrôle.. Une autre architecture qui peut s’apparenter en quelque sorte à celle de l’anneau est le GP(2m,1) (Generalized Petersen) (Liu, Jungang, & Du, 2008). Cette architecture présente deux anneaux qui sont interconnectés entre eux. Cette topologie a l’avantage d’être régulière. Tout comme pour la topologie en anneau, les nœuds n’ont pas besoin de l’information complète du réseau, mais seulement celle du nœud courant et de celui de destination. Lorsqu’un nœud reçoit un paquet, il vérifie s’il doit l’envoyer au nœud suivant ou au nœud adjacent. Les paquets sont acheminés par le chemin le plus court. Une autre architecture présentant plusieurs anneaux reliés entre eux est le Ring Road NoC (R2NoC) (Samuelsson & Kumar, 2004). Ici, les anneaux sont bidirectionnels et deux types de nœuds sont utilisés, ceux connectant les ressources au réseau et ceux reliant les anneaux entre eux.. 1.1.3.4 La topologie en étoile La topologie en étoile consiste à relier tous les nœuds par une connexion centrale. L’avantage de cette configuration est que si un nœud tombe en panne, le reste du réseau peut continuer à fonctionner normalement. Par contre, si la connexion centrale tombe en panne, c’est le réseau complet qui est affecté. Une variante de cette topologie est NOVA (Martinez Vallina, Jachimiec, & Saniie, 2007), une architecture en étoile « augmentée », qui est présentée à la Figure 1-7. En fait, ce sont des tuiles de huit nœuds reliés par un commutateur Banyan (Banyan switch) qui sont disposées selon une topologie en étoile utilisant le même type d’interconnexion. Les communications locales d’une tuile peuvent s’effectuer directement entre deux nœuds voisins ou en utilisant l’interconnexion centrale. Par contre, les transferts de données entre les tuiles peuvent seulement être faits en utilisant la connexion centrale..

(33) 15 N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. N. Figure 1-7: Topologie étoile augmentée (NOVA). 1.1.3.5 Autres topologies Certaines architectures ont été développées en utilisant des caractéristiques de différentes topologies. Le Spidergon (Concer, Iamundo, & Bononi, 2009) en est un exemple. Les nœuds sont disposés sur un anneau bidirectionnel et sont reliés entre eux par une barre croisée comme dans une structure en étoile. Si la destination est proche, les communications se feront par l’anneau et, dans le cas contraire, par l’interconnexion centrale. Comme plusieurs types de réseau sur puce, le Spidergon utilise comme technique de commutation le trou de ver pour l’économie qu’elle permet en termes de mémoire..

(34) 16. 1.2 Les fautes dans les réseaux sur puce Les avancées technologiques poussent toujours à obtenir les meilleures performances avec des composants toujours plus petits. Les interconnexions des systèmes sur puce ne cessent de diminuer de taille également et sont maintenant rendues à l’échelle du nanomètre. Cette diminution de taille amène les interconnexions à devenir de plus en plus sensibles et vulnérables aux fautes (Shivakumar, Kistler, Keckler, Burger, & Alvisi, 2002). Ces fautes peuvent avoir un effet permanent aussi bien que transitoire. Elles peuvent exister à la création même du système, un défaut de fabrication par exemple, ou elles peuvent être causées par des perturbations extérieures lors de son utilisation.. 1.2.1 Causes et classification des fautes Principalement, il existe deux grandes catégories de fautes : celles qui présentent un effet permanent et celles qui ne durent que de façon transitoire. Ces fautes peuvent avoir lieu autant au niveau des éléments de mémoire que des circuits logiques. Un routeur peut faire une erreur de routage sans pour autant corrompre la donnée, ce qui résulte à une erreur lors de la transmission du paquet dans un cas comme dans l’autre.. Parmi les fautes permanentes, nous pouvons noter deux types, soit statique et dynamique. Les fautes statiques se produisent généralement lors de la fabrication du réseau, qui nécessite des techniques de plus en plus minutieuses, et leur effet est irréversible excepté par des modifications physiques du réseau. Les fautes dynamiques, étant de nature permanente également, ont lieu de façon aléatoire durant l’exécution, contrairement aux fautes statiques. Elles peuvent être allouées aux effets de vieillissement, à l’électromigration, etc.. Les fautes transitoires sont, quant à elles, de nature non permanente. Tout comme les fautes dynamiques, elles apparaissent de façon aléatoire sur le réseau, mais se résorbent d’elles-mêmes. Elles sont souvent associées au bruit présent sur le réseau. Le fait que la tension dans le réseau soit diminuée, cela peut rendre les connexions plus susceptibles à la diaphonie (crosstalk), au.

(35) 17 bruit de couplage et aux erreurs logiques (soft errors) (Baumann, 2000). Elles peuvent également être dues à des radiations, des sauts et des interférences électromagnétiques. Les erreurs logiques peuvent être divisées en deux catégories : erreurs sur les liens et erreurs intrarouteurs.. Les single event effects (SEE) sont des événements perturbant le comportement d’un circuit dû à une grande charge de particules qui peuvent résulter par la corruption de données. Leur effet peut être aussi bien permanent que transitoire.. Parmi ces SEE, nous en comptons deux principaux : les single event upsets (SEU) et les single event transients (SET) (Bastos, 2010). Dans le cas des SEU, ce sont des particules cosmiques qui entrent en contact avec le circuit et qui créent un changement d’état dans un élément logique tel une mémoire ou un registre.. Les SET sont également dus à des particules cosmiques et peuvent être propagés à travers du circuit. Ils sont généralement représentés sous forme de pulsions (glitches). Cela peut résulter en une mauvaise donnée transmise si l’événement atteint un loquet (latch) ou une bascule (flip flop). Habituellement, les effets des SEU et des SET sont transitoires.. Il peut également exister des SEE qui ont des effets permanents tels les single event hard errors (SHE) qui consistent en un bombardement d’énergie sur certains bits, ce qui peut souvent mener à une valeur forcée (stuck-at).. 1.2.2 Caractérisation des fautes Les fautes pouvant être créées par différentes sources, de la même façon, il est possible de les injecter de différentes façons dans les circuits. Parmi les méthodes d’injection physiques, nous comptons notamment la variation de la tension d’alimentation, de l’horloge (Ozev, Sorin, & Yilmaz, 2007) et de la température ainsi que le flash de lumière, la source de particules ou le laser (Monnet, 2007). Il est possible d’injecter les fautes à différents niveaux, soit physique,.

(36) 18 logique et fonctionnel. Nous nous concentrerons sur la modélisation au niveau logique, comme la majorité des études analysées. Quelques avantages de la modélisation au niveau logique sont que la représentation est assez minutieuse (portes logiques) pour permettre de simuler des effets physiques sans avoir à procéder à des bombardements de particules, par exemple, et que le modèle est indépendant des technologies utilisées.. 1.1.2.2 Métriques utilisées Une des métriques utilisées dans la modélisation des fautes est le taux d’erreur sur les bits (bit error rate, BER). Le BER correspond au ratio de bits en erreur et est défini comme étant le nombre de bits en erreur divisé par le nombre total de bits transmis. L’équation correspondante est présentée ci-dessous. Le nombre de bits en erreur est le nombre de bits reçus qui ont été altérés lors de leur transfert sur le canal de communication (Khalili & Salamatian, 2005).. = .

(37) . . (1)

(38) . D’autres métriques permettant d’évaluer les fautes influant sur un système sont le MTBF et le FIT. L’intervalle moyen entre les défaillances (mean time between failures, MTBF) correspond au temps moyen entre deux fautes (équation 2). Le nombre de défaillances dans le temps (failures in time, FIT) représente quant à lui le nombre de fautes qui peuvent avoir lieu pendant 10-9 heures d’utilisation. La relation entre MTBF et FIT est présentée à l’équation 3.

(39) é = (2)

(40) =. 1 000 000 000 (3) ". Une métrique permettant d’évaluer la fiabilité de différentes méthodes de tolérance aux fautes consiste à les comparer en utilisant le taux d’erreur sur les paquets résiduels (residual packet.

(41) 19 error rate, RPER) (Bertozzi et al., 2005) qui correspond à la probabilité qu’un paquet erroné soit encore présent après le contrôle d’erreur. Ce taux peut également être défini à d’autres niveaux, notamment en fonction des messages ou des bits. Également, plusieurs recherches utilisent la latence moyenne des paquets, l’aire nécessaire ainsi que l’énergie consommée pour définir la performance des techniques.. 1.2.2.1 Modélisation des fautes Comme il a été mentionné précédemment, les fautes peuvent être dues à différentes causes autant internes, tels les bruits de puissance et la diaphonie, qu’externes comme l’effet de particules alpha ou l’électromigration. De ce fait, la probabilité des fautes est différente pour chaque circuit et dépend de plusieurs facteurs, notamment les facteurs environnementaux, les paramètres de design du circuit et l’usage du circuit à proprement dit (Hass, 1999). En ce qui concerne les effets que le design peut avoir sur la probabilité des erreurs, nous savons que le ratio d’erreurs augmente avec la complexité du circuit, la densité, la diminution du voltage, la diminution des latences et la diminution de la capacitance des cellules (Tezzaron, 2004).. Concernant les éléments de mémoire, une étude (Tezzaron, 2004) démontre que, pour différentes technologies, le ratio d’erreur de type erreur logique peut aller de 4-7 à 5-14 erreur/bit/heure. Ce qui donne en moyenne, 1000 à 5000 FIT/Mbit. De plus, environ 2% de ces erreurs peuvent avoir un effet permanent sur le réseau. Ces données sont obtenues au niveau du sol et les ratios d’erreurs ont tendance à augmenter avec l’altitude. Il est fait mention (MoSys, 2002) que le ratio peut augmenter de cinq (5) fois à 2600 pieds et de dix (10) fois à une altitude de 5280 pieds.. Le Tableau 1-1 présente les probabilités pour différents types de fautes qui peuvent affecter les réseaux sur puce, tirées du livre « Networks on Chip » de Benini et De Micheli (Benini & Micheli, 2006)..

(42) 20 Tableau 1-1: Probabilités de différents types de fautes sur un réseau sur puce. Type de faute Bruit gaussien sur un canal Effet particule alpha sur un élément de mémoire Effet particule alpha sur un élément logique Électromigration Changement de seuil Corrosion d’un connecteur Joint de soudure Défaillance de tension Défaillance logicielle. Modèle de la faute. Valeur. Unité. -20. BER. Erreur logique. 10-9. SER. Transitoire. 10-10. BER. Valeur forcée. 1 1 10 10 104 104. MTBF (FITs) MTBF (FITs) MTBF (FITs) MTBF (FITs) MTBF (FITs) MTBF (FITs). Transitoire. Valeur forcée Valeur forcée Valeur forcée Arrêt Arrêt. 10. Au niveau de la modélisation des fautes, (Young Hoon, Taek-Jun, & Draper, 2010) utilisent l’injection de faute statistique (statistical fault injection, SFI) (Mukherjee, Emer, & Reinhardt, 2005) qui injecte des changements de bits aléatoires autant en termes de temps que de localisation. Cette technique est appliquée à chaque bit de chaque lien dans le routeur avec des probabilités indépendantes. Ils évaluent leur méthode à différents niveaux de taux d’erreur. Ils évaluent leur technique pour différents taux d’erreur allant de 10-6 à 10-3 (erreur/fil (wire)/cycle), ce qui est très haut et qui représente un cas extrême pour des fautes transitoires. Cela permet de mettre le réseau sous stress. D’autres testent leurs méthodes sur un éventail plus large utilisant un BER allant de 10-15 à 10-2 (Li et al., 2003).. Dans certains cas (Qiaoyan & Ampadu, 2011), les fautes sont modélisées selon des scénarios de fautes transitoires seulement et de fautes permanentes seulement. D’autres (Ababei & Katti, 2009) évaluent avec des cas de défaillances simples et de défaillances multiples simultanées. Il peut aussi arriver que des erreurs logiques variées soient injectées de façon aléatoire dans les routeurs et les liens inter-routeurs (Park, Nicopoulos, Kim, Vijaykrishnan, & Das, 2006)..