Détection des erreurs RTL à l’aide des vecteurs structurels LOC et limitations

Modèles de panne

Un modèle de panne est la représentation structurelle d’une défectuosité physique. Il s’agit d’une abstraction et d’une simplification de la réalité. Plusieurs types de défectuosités peuvent être représentés avec un nombre restreint de modèles qui sont habituellement indépendants de la technologie et requièrent peu d’informations. La génération des vecteurs de test structuraux se base sur des modèles de panne bien spécifiques. L’objectif est de choisir un modèle de panne qui représente le plus grands nombre de pannes physiques dans le circuit afin d’atteindre une bonne couverture. Les modèles de pannes visés par les tests manufacturiers sont :

– modèle collé (« stuck-at »): selon ce modèle les noeuds affectés sont en permanence collés à 0 (la masse) ou à 1 (Vcc);

-modèle collé-ouvert (« stuck-open ») : ce modèle représente une connexion brisée du circuit résultant en une déconnexion de certains noeuds, créant des noeuds flottants qui ne sont reliés ni à la masse ni au Vcc;

-modèle court-circuit (« bridging faults ») : ce modèle représente les pannes qui résultent d’une connexion indésirable entre deux noeuds différents;

– pannes de délai : ces pannes ont pour effet de ralentir les transitions qui sont propagées dans le circuit. Elles n’altèrent pas la valeur logique finale, seulement le temps pris pour que cette valeur soit atteinte.

Dans le cadre de cette thèse, nous nous intéressons plus particulièrement aux pannes de délai. Tester un circuit logique pour les pannes de délai correspond à s’assurer que celui-ci respecte les spécifications temporelles et qu’il puisse opérer à la période d’horloge désirée. Il existe deux modèles principaux de pannes de délai : 1) les pannes distribuées sur les chemins combinatoires (« path-delay fault ») et 2) les pannes ponctuelles dites transitionnelles (« transient-delay fault »). Le premier type distribue le délai supplémentaire sur la totalité du chemin ciblé et sert surtout pour la modélisation des chemins critiques affectés par les variations du procédé de fabrication. Le second type, qui est le plus utilisé pour la détection des pannes, suppose qu’une panne de délai affecte un point particulier du réseau combinatoire (ex. la sortie d’une porte) et que le délai supplémentaire est suffisamment important pour causer une violation des spécifications temporelles. Si toutes les pannes sont locales, alors le modèle de pannes transitionnelles est le modèle adéquat à utiliser durant le test. Par contre, si les pannes sont plus globales, il est alors nécessaire d’adopter le modèle de pannes de délai distribuées sur les chemins. Notons cependant que le modèle de pannes transitionnelles est le plus utilisé, car le modèle de pannes de délai distribuées se heurte à l’explosion combinatoire de chemins à tester. Dans cette thèse, nous nous intéressons plus particulièrement au second type de panne, qui est le plus adapté à nos besoins.

Conception en vue du test Tester un composant après sa fabrication est un processus complexe, notamment car le concepteur n’a accès qu’aux entrées et sorties principales du circuit. Si on considère un circuit complexe avec une centaine de millions de transistors et un nombre quasi-infini d’états, il peut s’avérer difficile d’emmener ce composant dans un état particulier pour observer ses sorties. Il s’avère donc avantageux de considérer le test à partir des phases primaires de la conception afin de faciliter et simplifier la tâche : on parle alors de conception en vue du test ou DFT (Rabaey, 1996). Deux propriétés, la contrôlabilité et l’observabilité, sont de grande importance lorsqu’on considère la testabilité d’une conception.

Elles affectent la qualité des tests manufacturiers. 45 La contrôlabilité mesure la facilité avec laquelle on peut contrôler un noeud donné à partir de l’entrée, tandis que l’observabilité est la facilité avec laquelle on peut observer la valeur d’un noeud aux broches de sortie d’un circuit intégré. Donc, plus le circuit est observable et contrôlable, plus il est facile à tester et plus la couverture du test est élevée. Vu la complexité de la génération des vecteurs de test et de production d’une couverture de test, l’idée est de considérer le test bien avant le stade final, en influençant le design tout au long du processus de conception afin d’augmenter la contrôlabilité et l’observabilité de ces circuits et d’améliorer au final la qualité de test. Les circuits purement combinatoires sont généralement facilement observables et contrôlables, alors que les circuits séquentiels peuvent présenter des lacunes a ce niveau. Les techniques DFT, qui ont été développées pour les circuits séquentiels, se classent en 3 catégories (Rabaey, 1996) :

les méthodes ad-hoc : elles sont basées sur le principe «diviser pour conquérir ». Il s’agit de partitionner les grands circuits séquentiels et d’ajouter des points de test ainsi que des multiplexeurs ou d’autres matériels supplémentaires à l’intérieur du circuit afin d’améliorer la qualité du test;

méthodes d’auto test (BIST, « Built In Self Test »): Le circuit se teste essentiellement tout seul, en utilisant des générateurs de stimuli pseudos aléatoires ou exhaustifs et vérifiant l’exactitude des résultats (avec un support minimal d’un testeur externe);

méthodes basées sur l’insertion des chaînes de registres à balayage : lors de la conception, des éléments de mémoire synchrones appelés registres à balayage (« scan registers ») connectés en chaîne sont ajoutés au circuit pour augmenter l’observabilité et la contrôlabilité de ce dernier. Une approche très utilisée est le test à balayage en série illustré dans la Figure 1.3 (Rabaey, 1996). Les registres sont modifiés pour supporter deux modes : un mode normal où ils opèrent comme des registres synchrones normaux et un mode de test où ils sont enchainés ensemble pour former un seul (ou plusieurs) registre(s) de décalage en série appelé chaine de registres à balayage ou chaine de scan. Une procédure de test s’effectue alors de la manière suivante :

Vérification transactionnelle

Une des tâches les plus longues et ardues de la vérification réside dans la génération des bancs d’essai. La vérification transactionnelle (Brahme, 2000) cherche à simplifier la production du banc d’essai d’une part et permettre sa réutilisation dans la vérification des modèles à différents niveaux d’abstraction d’une autre part (Boland, 2007), et ceci en se basant sur le principe de transactions. Une transaction est un transfert de données ou de contrôle entre le banc d’essai et le DUV à travers une interface. Elle modélise les données utiles pour un scénario de vérification, sans se soucier des différents signaux et des séries de bits nécessaires pour lancer ces stimuli au niveau d’abstraction du DUV. Ainsi, ce principe permet au concepteur de modéliser les bancs d’essai à un niveau d’abstraction plus haut d’une façon plus intuitive, et un adaptateur se charge de traduire les transactions de haut niveau en une série de signaux envoyés vers le DUV. Le principe est décrit à la Figure 2.2 (Brahme, 2000).

La figure montre la séparation du banc d’essai (« Testbench ») en deux couches. La couche supérieure est formée par l’ensemble des scénarios qui génèrent des transactions au niveau système sans tenir compte des détails des protocoles de communication au niveau signal, et la couche inferieure est l’adaptateur ou aussi appelé le modèle de vérification transactionnelle (TVM, « Transaction Verification Model »). Cette séparation des responsabilités en deux couches permet d’une part le développement de plusieurs scénarios complexes de vérification et d’une autre part la réutilisation de certaines composantes du banc d’essai. De même que les méthodologies définies dans cette section, ce type de vérification requiert une bonne connaissance du comportement et de la fonctionnalité du design afin de définir la liste de scénarios de vérification possibles. De plus une étape d’apprentissage et de familiarisation avec les langages dédiés à ce type de vérification est nécessaire afin d’implémenter les adaptateurs requis et les transactions modélisant les différents scénarios.

Combinaison du test et de la vérification

Les phases de test et de vérification sont généralement considérées comme deux phases indépendantes. Mais les problèmes auxquels font face ces deux phases présentent plusieurs similarités ce qui a conduit au développement de certaines méthodologies combinant les deux. Le test fonctionnel (Rabaey, 1996), par exemple, utilise des vecteurs de vérification appelés aussi des vecteurs fonctionnels pour tester le design afin de couvrir les pannes n’appartenant à aucun modèle. Le design est simulé comme une boite noire, les tests fonctionnels sont forcés sur les entrées et les sorties sont observées pour la détection d’erreur. De plus, les approches ATPG ont été adaptées et utilisées au niveau de la vérification statique pour remédier aux problèmes rencontrés lors de la vérification d’équivalence et de propriété (Varma, 2003) telles l’explosion de l’espace d’états des designs et la croissance de la complexité des algorithmes. En effet, certaines méthodologies de vérification d’équivalence utilisent les techniques ATPG combinatoires pour vérifier l’équivalence de deux représentations données, alors que d’autres méthodologies de vérification de propriété utilisent les techniques séquentielles pour vérifier si une propriété est satisfaite sur un nombre limité de cycles pour une implémentation donnée. Dans (Varma, 2003), l’auteur souligne le besoin d’investiguer l’exploitation du test dans la vérification dynamique, qui est la technique la plus utilisée de nos jours, tout en soulevant certains enjeux :

les tests manufacturiers visent le niveau porte logique alors que la vérification se fait généralement à des niveaux d’abstraction plus haut;

il existe certains vecteurs de tests manufacturiers invalides ne pouvant pas simuler la fonctionnalité du design.

Dans (Abadir, 1988) les auteurs montrent qu’un ensemble de test « stuck-at » est capable de détecter des erreurs fonctionnelles. Ils utilisent les vecteurs de test « stuck-at » pour vérifier qu’une implémentation d’un design au niveau logique est structurellement équivalente aux spécifications, mais la simulation est effectuée au niveau porte logique seulement et les erreurs détectés sont de type structurels tels l’ajout, la suppression ou la substitution de portes logiques et de bus etc.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport gratuit propose le téléchargement des modèles gratuits de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

INTRODUCTION
CHAPITRE 1 TEST ET VÉRIFICATION
1.1 Introduction
1.2 Notions de base de la vérification
1.2.1 Méthodologie de vérification
1.2.2 Vérification dynamique
1.2.3 Vérification statique
1.3 Notions de base du test
1.3.1 Modèles de panne
1.3.2 Génération automatique de vecteurs de test
1.3.3 Conception en vue du test
1.3.4 Tests de transition avec insertion des registres à balayage
1.4 Conclusion
CHAPITRE 2 REVUE DE LITTÉRATURE
2.1 Vérification dynamique
2.1.1 Vérification aléatoire basée sur les contraintes
2.1.2 Vérification basée sur les assertions
2.1.3 Vérification transactionnelle
2.2 Combinaison du test et de la vérification
2.3 Les modèles d’erreurs RTL
2.4 États illégaux d’un design
2.5 Conclusion
CHAPITRE 3 UTILISATION DES TESTS STRUCTURELS DANS LA SIMULATION
3.1 Introduction
3.2 Pannes cachées versus coins sombres
3.2.1 Pannes cachées
3.2.2 Coins sombres
3.2.3 Corrélation entre les coins sombres et les pannes cachées
3.3 Le choix des tests structurels
3.4 Utilisation des vecteurs de test structurels dans la vérification RTL
3.4.1 Génération des vecteurs de test structurels
3.4.2 Application des tests de transition LOC avec registres à balayage au modèle RTL
3.5 Premiers résultats expérimentaux
3.5.1 Corrélation entre les coins sombres et les pannes cachées
3.5.1.1 Expériences
3.5.1.2 Conceptions
3.5.1.3 Les résultats expérimentaux
3.5.2 Utilisation des vecteurs de test dans la vérification
3.6 Conclusion
CHAPITRE 4 ÉTUDE THÉORIQUE DE LA DÉTECTION DES ERREURS DU DESIGN AU NIVEAU RTL À L’AIDE DES TESTS DE TRANSITION LOC
4.1 Introduction
4.2 Hypothèses
4.3 Détection des erreurs RTL à l’aide des vecteurs structurels LOC et limitations
4.3.1 Le modèle BOE
4.3.2 Le modèle BSE
4.3.3 Le modèle BDE
4.3.4 Le modèle MSE
4.3.5 Le modèle BCE
4.3.6 Le modèle MCE
4.3.7 Le modèle LCE
4.3.8 Le modèle ESE
4.3.9 Les erreurs FSM
4.3.9.1 Le modèle SCE
4.3.9.2 Le modèle NSE
4.4 Test de transition versus stuck-at
4.5 Les états illégaux
4.5.1 Effet des états illégaux
4.5.2 Exemple : compteur
4.5.3 Les fausses erreurs
4.6 Conclusion
CHAPITRE 5 EXTRACTION AUTOMATIQUE DES CONTRAINTES FONCTIONNELLES À PARTIR D’UN MODÈLE RTL
5.1 Introduction
5.2 Grammaire d’analyse d’expression VHDL
5.2.1 VHDL
5.2.2 Grammaire d’analyse d’expression
5.2.3 La PEG VHDL
5.3 Approche proposée
5.4 Implémentation détaillée
5.4.1 Analyse du VHDL et identification des différentes structures
5.4.1.1 Identification des structures VHDL
5.4.1.2 Identification des valeurs initiales des différents signaux d’états
5.4.1.3 Identification des HLS
5.4.2 Extraction des HLS des module
5.4.2.1 Évaluation des opérations
5.4.2.2 Implémentation détaillée
5.4.3 Analyse hiérarchique du design
5.4.3.1 Analyse de connectivité des modules
5.4.3.2 Modèle aplati
5.4.4 Extraction des HLS du design
5.4.5 Extraction des contraintes fonctionnelles
5.5 Résultats expérimentaux
5.5.1 La vérification
5.5.2 Le test
5.6 Conclusion
CHAPITRE 6 ENVIRONNEMENT DE VÉRIFICATION COMPLET PROPOSÉ
6.1 Introduction
6.2 Environnement de vérification proposé
6.2.1 Le générateur automatique du banc d’essai
6.2.2 Le détecteur d’erreurs
6.3 Résultats expérimentaux
6.4 Conclusion
CONCLUSION
RECOMMANDATIONS
ANNEXE I LES MODÈLES D’UN SYSTÈME
ANNEXE II CODE PERL DU GÉNÉRATEUR DU BANC D’ESSAI
ANNEXE III CODE PERL DU DÉTECTEUR D’ERREURS
ANNEXE IV CODE PERL DE L’EXTRACTEUR DES CONTRAINTES
FONCTIONNELLES
LISTE DE RÉFÉRENCES BIBLIOGRAPHIQUES