Amélioration du processus de testabilité des circuits intégrés asynchrones dérivés de la topologie de conception d’Octasic

Avec l’apparition d’une variété d’appareils mobiles toujours plus complexes depuis les années 2000 et pour des soucis d’autonomie, la demande de circuits intégrés basse consommation et de meilleures batteries se fait de plus en plus grande. Or, comme il ne devrait plus y avoir d’augmentation notable de la densité énergétique de ces dernières dans les années à venir (Hodson, 2015), il revient donc aux concepteurs de circuits la lourde charge de réduire la dépense énergétique des puces pour pouvoir augmenter l’autonomie des appareils mobiles. La majorité des circuits actuels sont synchrones; or, on sait que la majeure partie de la consommation d’énergie vient de l’horloge (Shinde & Salankar, 2011). Certaines techniques ont déjà été utilisées pour diminuer ou supprimer le signal d’horloge dans certaines parties du circuit, mais les fonctions de contrôle qui permettent ces prouesses consomment elles-mêmes de l’énergie.

Une solution plus radicale pour réduire la dépense énergétique serait de tout simplement supprimer l’horloge globale du circuit. C’est l’idée générale de la méthode de design asynchrone : au lieu que le circuit soit contrôlé de manière globale par une horloge, il est synchronisé localement par des échanges ponctuels entre diverses parties de la puce. Cette méthode de design est déjà utilisée en partie dans les techniques GALS (Globally Asynchronous Locally Synchronous) (Marc Renaudin, 2013) où une multitude de parties synchrones de la puce communique de manière asynchrone.

Toutefois, les conceptions purement asynchrones restent cantonnées à de rares applications qui nécessitent une consommation d’énergie ou une génération de bruit très faible, comme le domaine de la cryptographie par exemple (Marc Renaudin, 2013). Les raisons de cette timide adoption par l’industrie sont multiples. Tout d’abord, les langages de description matérielle comme le VHDL ou le Verilog sont peu adaptés à la conception asynchrone (Spars & Furber, 2002). Encore plus embêtants, les principaux outils de conception de circuit sont globalement tous focalisés sur la méthodologie de design synchrone (Kondratyev & Lwin, 2002). Enfin le manque de procédure de testabilité qui permet de déterminer si la puce est fonctionnelle ou non est un des freins majeurs à l’adoption massive de la méthode de conception asynchrone (Zeidler & Krstić, 2015).

La recherche sur les designs asynchrones est en constante évolution. Il existe donc une grande variété de circuits asynchrones. Certaines méthodes invoquent des éléments spécifiques comme les portes logiques C qui aident dans la synchronisation des signaux. Plusieurs techniques utilisent des méthodes de synchronisation basées sur la communication des éléments qui utilisent des protocoles vérifiant le bon envoi et la bonne réception des données. Enfin certains designs tentent de retarder une impulsion en utilisant des lignes à délais afin de déclencher successivement des opérations dans un pipeline. Les concepteurs peuvent aussi décider de combiner plusieurs techniques dans la même puce. Pour ces raisons et dans la dernière décennie, une multitude de méthodes de test pour les circuits asynchrones ont été développées. Malgré tout, la tâche se révèle toujours compliquée à cause des problèmes de contrôlabilité et d’observabilité qui découlent de tous ces différents designs (Zeidler & Krstić, 2015).

Dans l’article “Exploiting Built-In Delay Lines for Applying Launch-on-capture At-Speed Testing on Self-Timed Circuits” (Hasib et al., 2018), les auteurs dévoilent une méthode qui permet de tester à vitesse de fonctionnement réelle les circuits asynchrones développés par Octasic, une compagnie à la base de plusieurs générations de DSP asynchrones. Cependant, les structures de test utilisées par la méthode employée dans l’article ont été implémentées manuellement par les ingénieurs d’Octasic, car il n’existe à cette heure aucun outil capable de le faire de manière automatisée. Ce mémoire a donc pour objectif d’améliorer et d’automatiser le processus d’insertion de ces structures de test dans les designs asynchrones de style Octasic, à savoir à données groupées sans protocole (Hasib et al., 2018) d’accusé de réception (single-rail bundled-data handshake-free).

Circuits asynchrones 

Cette première partie a pour objectif de présenter les circuits asynchrones afin de fournir au lecteur quelques notions utiles à la compréhension de ce mémoire. La première partie « Classes » permettra de présenter les différents types de circuits asynchrones. Deux types de communication relatifs aux micropipelines seront présentés dans la section « Protocoles ». Enfin, dans « Codages », on introduira les différentes manières de coder les données.

Classes
Selon (Berthier, 2016) et (Rios, 2008), on compte 5 classes de circuit asynchrone : la logique insensible au délai (DI : Delay Insensible), la logique quasi-insensible au délai (QDI : QuasiDelay-Insensitive), les circuits indépendants de la vitesse (SI : Speed Independant), les circuits de Huffman et les circuits micropipeline.

La logique insensible au délai n’impose aucune contrainte de temps sur le circuit. Ainsi, on peut utiliser n’importe quelle porte logique ou longueur de fil sans se soucier du délai qu’ils impliquent. Cette catégorie de circuit est très limitée et leur taille représente un désavantage important.

La logique quasi-insensible au délai reprend les mêmes hypothèses que celle insensible aux délais. La seule différence est que l’on suppose que certaines fourches (fanout) peuvent être isochrones. Dans une fourche isochrone, le délai dans une branche est le même dans toutes les autres branches   (Brégier, 2007). Ce modèle est utilisé par un grand nombre de processeurs asynchrones (Mickaël Fiorentino, 2017a) et type de logique comme les circuits de type NCL (Null Conventionnal Logic).

Les circuits indépendants de la vitesse sont similaires aux circuits QDI. La seule différence est que l’on considère toutes les fourches comme isochrones . Les circuits QDI sont davantage utilisés, car ils contiennent plus d’information et moins d’hypothèses temporelles que les circuits indépendants à la vitesse.

Les circuits de Huffman sont définis sous la forme d’une machine à états finis. Son évolution n’est pas cadencée par une horloge globale. On fixe plutôt un temps sur les délais du calcul de l’état futur ainsi que les entrées et sorties   (Brégier, 2007).

Tous comme leur homologue synchrone, les circuits micropipelines sont composés de blocs de logique combinatoire interconnectés par des registres  . L’horloge globale est remplacée par des modules qui permettent de synchroniser localement les registres. Cette synchronisation est arbitrée à l’aide de signaux de requête et d’acquittement selon divers protocoles.

Notions de base sur le test

Cette section porte sur les notions de base au niveau du test des circuits intégrés. On y aborde les thèmes suivants :
• le test fonctionnel;
• le test structurel;
• les indicateurs de mesure de qualité de test;
• les modèles de pannes;
• les chaînes de balayage;
• la technique de test « launch-on-shift »; et
• la technique de test « launch-on-capture ».

Test fonctionnel
Le test fonctionnel consiste à vérifier la bonne fonctionnalité du circuit à la sortie du procédé de fabrication. On teste le circuit en mode de fonctionnement normal. Ce type de test est non structuré, c’est-à-dire qu’il n’est basé sur aucune théorie ou technique particulière. En pratique, le test fonctionnel a été est très utilisé par les concepteurs et ingénieurs de test pour vérifier le circuit au plus proche de son fonctionnement nominal. Le test fonctionnel nécessite un testeur automatique très couteux, car le test est réalisé à vitesse nominale et demande donc au testeur d’être rapide et précis dans ses mesures. Les tests étant développés manuellement, le temps de développement induit indubitablement un retard de mise sur le marché de la puce et produit donc un coût supplémentaire pour l’entreprise (Maxwell, Hartanto, & Bentz, 2000).

LIRE AUSSI :  Carte du parc Sahamalaza avec ses Iles péripheriques.

Test structurel
Tandis que le test fonctionnel vérifie la fonctionnalité du circuit, le test structurel se concentre à chercher si des pannes existent, i.e., des pannes induites par le procédé de fabrication. Ce type de test est très utilisé, car il est beaucoup plus rapide que le test fonctionnel. En effet, contrairement au test fonctionnel dont les séquences de test sont définies par l’homme, le test structurel utilise généralement un générateur automatique de vecteur de test (ATPG : Automatic Test Pattern Generator) associé à un modèle de panne (décrit plus loin) pour analyser le circuit et dresser la liste des pannes. Par conséquent, le test structurel diminue les coûts du processus et augmente la fiabilité du processus de testabilité. Des structures dédiées au test sont généralement insérées dans le circuit comme du test par balayage que nous allons voir plus loin. Notons que les générateurs automatiques de vecteur de test fournissent également des indicateurs de mesure de qualité de test, décrits dans ce qui suit.

Indicateur de mesure de qualité du test
Plusieurs indicateurs sont associés au test structurel. Ces indices permettent de mesurer la qualité du test pour maximiser le nombre de circuits adéquatement identifiés comme fonctionnels ou fautifs, à la fin de la production. On retrouve ces informations dans les rapports fournis par les outils de génération de vecteur de test, comme Tessent par exemple.

Modèles de panne
Selon (Wang et al., 2006), un modèle de panne est une représentation des défectuosités physiques qui conduisent le circuit à ne plus fonctionner de la manière attendue. On présente ici, le modèle de collage qui est le plus utilisé et le modèle de délai, car ce sont ceux que nous exploitons dans ce mémoire.

Modèle de collage
Les pannes de type collé-à (stuck-at) affectent l’état de la logique dans un circuit. Elles peuvent apparaître sur n’importe quel nœud interne et externe du circuit. Lorsqu’une panne de ce type se produit, le signal affecté se retrouve bloqué à un niveau logique précis. On dit que le signal est collé-à 0 ou collé-à 1 (Wang et al., 2006).

Modèle de délai
Une panne de délai est le résultat d’une augmentation du délai de propagation dans un chemin du circuit de telle sorte que le délai total dépasse la limite préalablement spécifiée. Or, la réduction de la finesse de gravure entraîne inévitablement un raccourcissement des délais internes des circuits intégrés. Par conséquent, les nouvelles puces sont de plus en plus  sensibles aux variations de délai induit par le procédé de fabrication (Verma, Kaushik, & Singh, 2010). Les pannes de délai sont donc de plus en plus présentes. Les modèles de délai se décomposent principalement en deux sous-parties, les pannes de transition et les pannes de chemin (Wang et al., 2006).

Table des matières

INTRODUCTION
CHAPITRE 1 NOTIONS DE BASE ET REVUE DE LITTÉRATURE
1.1 Introduction
1.2 Circuits asynchrones
1.2.1 Classes
1.2.2 Protocoles
1.2.3 Codages
1.3 Notions de base sur le test
1.3.1 Test fonctionnel
1.3.2 Test structurel
1.3.3 Indicateur de mesure de qualité du test
1.3.3.1 Taux de couverture de pannes
1.3.3.2 Taux d’efficacité de la détection des pannes
1.3.4 Modèles de panne
1.3.4.1 Modèle de collage
1.3.4.2 Modèle de délai
1.3.5 Chaîne de balayage
1.3.6 Launch-on-shift
1.3.7 Launch-on-capture
1.4 État de l’art
1.4.1 Testabilité des circuits asynchrones
1.4.1.1 Les défis
1.4.1.2 Les méthodes de test
1.4.1.3 État des processus de testabilité automatisé pour circuit asynchrone
1.4.2 Circuits asynchrones de type Octasic
1.4.2.1 Fonctionnement de la logique
1.4.2.2 Méthode de test
1.4.2.3 QMI : outil de découverte des points de convergence
1.5 Conclusion
CHAPITRE 2 BANC D’ESSAI
2.1 Introduction
2.2 Générateur d’horloge pour circuit asynchrone
2.3 Circuit de test
2.3.1 Machines à états finis issues de ITC99
2.3.2 Pipeline typique des circuits d’Octasic
2.3.3 Microprocesseur asynchrone mini-MIPS
2.3.3.1 Architecture
2.3.3.2 Détails d’implémentation
2.4 Conclusion
CHAPITRE 3 STRATÉGIE DE TEST
3.1 Introduction
3.2 Structure de test spécifique
3.2.1 Multiplexeur de test
3.2.2 Module de test de machine à états finis
3.2.3 Module de contournement de Key Unit
3.3 Intégration des structures de test spécifique dans le banc d’essai
3.3.1 Pipeline typique de l’architecture d’Octasic
3.3.2 Machine à états finis du jeu de circuit ITC99
3.3.3 Mini-MIPS asynchrone
3.3.4 Stratégie de test des chemins de données
3.3.5 Importance du test à vitesse nominale (at-speed)
3.4 Conclusion
CHAPITRE 4 AUTOMATISATION DE L’INSERTION DES STRUCTURES DE TEST SPÉCIFIQUES
4.1 Introduction
4.2 Flot complet de conception pour la testabilité
4.3 Insertion des structures de test conventionnelles et génériques
4.4 Détermination des signaux de contrôle de test
4.4.1 Rappel sur la théorie des graphes
4.4.2 Présentation et détail d’implémentation
4.4.3 Fonctionnement général du programme (haut niveau)
4.4.4 Fonctionnement détaillé du programme
4.4.4.1 Conversion de la netlist d’entrée en graphe orienté
4.4.4.2 Détection du réseau de multiplexeur de test
4.4.4.3 Analyse des domaines d’horloges
4.4.4.4 Analyse de la dépendance des horloges
4.4.4.5 Recherche des chemins de données convergents
4.4.4.6 Coloration de graphe pour déterminer le nombre et la connexion des signaux scan_modes
4.4.4.7 Préparation de la connexion des modules de contournement Bypass_KU
4.5 Insertion des structures de test spécialisées
4.6 Conclusion
CHAPITRE 5 GÉNÉRATION AUTOMATIQUE DE VECTEURS DE TEST
5.1 Introduction
5.2 Présentation du flot de générations des vecteurs de test des circuits
5.3 Plan d’expérimentation
5.3.1 Machines à états finis issues de ITC99
5.3.2 Pipeline typique des circuits d’Octasic
5.3.2.1 Test collé-a
5.3.2.2 Launch-on-capture à vitesse nominale (at-speed)
5.3.3 Mini-MIPS
5.3.3.1 Test collé-à
5.3.3.2 Launch-on-capture entièrement à vitesse nominale (at-speed) 110
5.3.3.3 Launch-on-capture partiellement à vitesse nominale
5.4 Définition des procédures de test
5.4.1 Définition des horloges
5.4.2 Définition de la procédure de chargement/déchargement
5.4.3 Définition des procédures de launch-on-capture pour chemins de données convergents
5.4.4 Définition des procédures de launch-on-capture pour machine à états finis
5.4.5 Définition des procédures de launch-on-capture synchrone
5.5 Conclusion
CHAPITRE 6 RÉSULTATS ET ANALYSES
6.1 Introduction
6.2 Programme de connexion des signaux de contrôle de test
6.2.1 Analyse de la dépendance des horloges
6.2.1.1 Pipeline asynchrone typique d’Octasic
6.2.1.2 Mini-MIPS
6.2.2 Recherche de machine à états finis
6.2.3 Détermination du nombre et de la connexion des signaux scan_mode .. 131
6.2.3.1 Pipeline asynchrone typique d’Octasic
6.2.3.2 Mini-MIPS
6.3 Surface des structures de test
6.4 Qualité du test
6.4.1 Taux d’efficacité de la détection de panne
6.4.2 Taux de couverture de pannes
6.4.2.1 ITC99
6.4.2.2 Pipeline typique d’Octasic
6.4.2.3 Mini-MIPS
6.5 Évolution des méthodes de test et de leurs automatisations par rapport aux précédents travaux
6.6 Conclusion
CONCLUSION

Cours gratuitTélécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *