Brevet FR2805366A1 — publié le 20010824

La présente invention concerne d'une manière générale la vérification et test de circuits et plus particulièrement un contrôle d'équivalence langage transfert de registre (RTL)/schéma de circuits. Historiquement, on contrôlait et on vérifiait des circuits intégrés complexes par comparaison à un modèle du circuit en langage de transfert de registres (RTL). De façon typique, il existe des modèles séparés, basés sur le langage RTL et sur le circuit (ou un schéma), du circuit intégré physique. Chaque modèle fonctionne de façon indépendante pour émuler ou simuler l'agencement. De façon typique, le modèle RTL est activé et des vecteurs sont extraits de ce modèle et utilisés pour simuler et vérifier les résultats du modèle basé sur le schéma. Cette technique requiert une certaine quantité de maturité a la fois en ce qui concerne le modèle RTL et en ce qui concerne le modèle basé sur un schéma, avant que les modèles puissent être comparés entre Le but de la comparaison est de prouver que les deux modèles sont fonctionnellement équivalents. Ceci est réalisé de façon typique au moyen de l'application exhaustive de vecteurs, extraits du modèle RTL sur le modèle basé sur le schéma, et par contrôle régulier des résultats au moyen de la simulation, habituellement à la fin de chaque phase d'horloge. Un certain niveau de maturité et de détail est nécessaire dans les deux modèles avant que des comparaisons puissent commencer afin d'éviter des défaillances dues à une modélisation incomplète ou imprécise et qui peuvent masquer des différences réelles entre les modèles. Des inconvénients des procédés antérieurs incluent le fait d'avoir à attendre qu'à la fois le langage RTL et le schéma de circuit soient matures. C'est pourquoi le processus de conception peut progresser d'une manière considérable au cours du cycle de conception avant qu'un contrôle d'équi valence fonctionnelle même rudimentaire puisse commencer. Des défauts et d'autres erreurs peuvent être restés inaperçus dans le circuit pendant des mois même des années avant d'être découverts. De même le modèle RTL doit contenir des détails substantiels de circuits pour reproduire des conditions ou mises en oeuvre spécifique du circuit. Par exemple des distinctions entre des circuits statiques et dynamiques doivent être modélisées de façon appropriée dans le modèle RTL si des comparaisons détaillées doivent être faites. D'autres inconvénients incluent le fait qu'il existe de façon typique de nombreuses personnes sont impliquées dans la modélisation et les tests. Une personne peut posséder le modèle RTL et une autre personne peut être responsable de la réalisation du circuit. Fréquemment une troisième personne peut écrire des cas de test pour le choix des modèles. C'est pourquoi trois ou un plus grand nombre de personnes peuvent être impliquées, ce qui conduit à des délais aller et retour plus longs et/ou à des temps de réponse plus longs pour que les éléments soient fixés, changés ou modifiés. La répartition des tâches entre plusieurs personnes allonge également la durée de débogage, étant donné que l'expérience requise est diluée et diffusée entre différents groupes. C'est pourquoi il existe un besoin de disposer d'un protocole d'un système de test, qui permettent une conception progressive, un développe ment et une vérification fonctionnelle de circuits intégrés complexes. Il existe un autre besoin de disposer d'un procédé et d'un système d'émulation de circuits pour valider une fonctionnalité de circuits à niveau haut avant de disposer d'une description détaillée du circuit du niveau II existe un autre besoin de disposer d'un procédé de développement d'un circuit et d'une technique de test de circuits, qui permette de controler le fonctionnement correct de circuits lorsque de nouvelles parties du schéma du circuit sont conçues. Ces buts, caractéristiques et avantages techniques et d'autres, buts, caractéristiques et avantages techniques sont atteints à l'aide d'un système et d'un procédé qui permettent un test progressif et incrémentai d'un agence ment de circuit par subdivision du circuit en unités fonctionnelles, émulation de la fonction définie ou effectuée par chaque unité et production de vecteurs de test aléatoires appropriés et de signaux à partir d'unités associées. On contrôle le signal de sortie de chaque unité pour obtenir la confirmation du fonctionnement correct de l'unité et du caractère approprié des vecteurs de test. Des erreurs d'émulation sont identifiées, corrigées et reproduites dans un émulateur révisé. Des erreurs imputables à des problèmes de production de vecteurs de test ou à une analyse fonctionnelle et une vérification sont également identifiées et reproduites sous la forme de modifications apportées à l'émulateur. Des modifications de la définition fonctionnelle de chaque unité sont consignées et reproduites dans des révisions ultérieures du circuit et des émulations de ce dernier moyennant l'utilisation d'une modélisation, basée sur le modèle RTL, de l'ensemble du dispositif. De façon similaire des systèmes validation sont développés sur la base d'une expérience acquise pendant le test fonctionnel afin d'améliorer les tests, identifier des cas particuliers et éviter conditions de test non reproductives ou erronées. C'est pourquoi l'invention peut impliquer une personne, de façon typique concepteur du circuit, l'écriture d'une partie de logiciel qui est soi un émulateur du modèle RTL et sa réalisation schématique en utilisant (i) le modèle non encore stabilisé, (il) la description de l'architecture, (iii) d'autres descriptions à niveau haut de ce que le circuit doit exécuter, et (iv) la connaissance intime, par le concepteur du circuit, de l'agencement final désiré du circuit physique. Un code de programmation en logiciel est alors écrit, ce code émulant de façon précise les éléments individuels de la micro-architecture et produisant à la fois des incitations et le déclenchement du contrôle de partie circuit qui est conçue et est construite. Cela permet au concepteur de poursuivre la conception et la vérification du circuit à l'allure de conception d'un circuit plutôt que d'avoir à attendre que le modèle RTL, les outils et le schéma du circuit soient entièrement matures. En soi l'émulateur est développé en parallèle avec le circuit d'une manière "en temps opportun" de sorte que le débogage et le test peuvent être exécutés alors que le circuit évolue, plutôt que d'attendre un certain niveau requis de maturité requis pour émuler complètement et de façon exhaustive toutes les fonctions du circuit utilisant modèle RTL. Certains avantages du procédé selon l'invention incluent la capacité produite a la fois des stimuli et des contrôles appropriés du circuit d'une manière précoce au cours du cycle de conception. Ceci fournit d'une maniere plus précoce des circuits stables étant donné que les circuits sont choisis débogués lorsqu'ils sont conçus de sorte que des tests sont exécutés lorsque le circuit se développe, même s'ils sont incomplets. Un autre avantage réside dans le fait que le développement de ce module ou du logiciel requiert de façon typique uniquement l'entrée d'une seule personne pour développer et écrire le logiciel, c'est-à-dire un personnel technique ayant l'expérience du circuit de la micro-architecture. De façon similaire le système selon l'invention fait intervenir une seule personne pour la production des vecteurs qui sont utilisés pour stimuler et vérifier le circuit en cours de développement, plutôt que d'utiliser une personne écrivant un cas de test et autre personne ecrivant le modèle RTL associé. Un autre avantage du procédé selon l'invention est qu'il peut être mis en oeuvre avec une exécution très rapide. Des défauts peuvent être identifiés et localisés avec quelques modifications mineures (c'est-à-dire "une doublure") apportées code et avec un fonctionnement à nouveau pendant minutes, plutôt qu'avec une attente d'une semaine ou deux pour que le modèle RTL pour l'ensemble de la plaquette soit fixé, à nouveau compilé et testé par régression. autre avantage réside dans le fait qu'il n'est pas nécessaire de disposer de cas de test comme cela était requis dans des procédés antérieurs. L'émulateur produit ses propres entrées d'une manière aléatoire, tout en satisfaisant à des contraintes indiquées par la micro-architecture, le modèle RTL ou le concepteur du circuit, ce qui permet de travailler dans la continuation et de produire des résultats attendus sur la base entrées aléatoires. C'est pourquoi l'exigence de l'écriture de cas de test est supprimée. À nouveau un autre avantage réside dans le fait que l'émulation est développée ou perfectionnée en temps opportun de sorte que la conception de l'émulateur est seulement faiblement en retard par rapport à la conception du circuit. Si un concepteur du circuit pense mettre en oeuvre caracté ristique particulière dans un futur proche, le concepteur de l'émulateur doit travailler de manière à préparer la capacité correspondante de l'émulateur précisément lorsque le circuit est prêt, plutôt que d'avoir à attendre a nouveau le modèle RTL. Un autre avantage réside dans le fait que les données aléatoires peuvent être focalisées sur l'examen de faiblesses perçues dans le circuit. Le concepteur du circuit possède des indications concernant les points forts et les faiblesses présents dans le circuit et peut avertir la personne développant l'émulateur de ces faiblesses de manière à exploiter directement les points faibles plutôt qu'à avoir à examiner le circuit à partir d'un niveau de cas de test abstrait plus élevé. Un autre avantage de l'exécution de tests selon l'invention est que ces derniers doivent être beaucoup plus rapides étant donné que l'émulateur émule seulement une partie de la plaquette en cours de développement. Précédemment, le modèle RTL simulait l'ensemble de la plaquette, et des vecteurs pour le ou les circuits intéressant(s) étaient extraits. Un émulateur selon l'invention émule uniquement la partie de la plaquette qui est disponible est choisie pour le test. En émulant seulement une partie de la plaquette, l'émulateur peut fonctionner plus rapidement que le modèle RTL de plaquette complète de sorte que des vecteurs et des contrôles peuvent être produits et appliquer à l'ensemble du modèle du circuit testé beaucoup plus rapidement dans le cas de l'utilisation de techniques classiques. Un autre avantage pour effectuer des tests conformément à l'invention que les erreurs et le diagnostic, qui sont produits lorsque des problèmes sont trouvés, peuvent fournir beaucoup plus d'informations. Étant donné que l'émulateur est plus focalisé, il est réalisé d'une manière spécifique au circuit testé et peut isoler et identifier (i) ce qui se produit à l'intérieur du circuit, (ü) ce qui a déjà indiqué au circuit de faire, et (iii) ce à quoi s'attend comme réponse. Par exemple, étant donné qu'il émule un circuit spécifique ou un ensemble de circuits, il peut indiquer beaucoup plus à l'ingénieur en ce qui concerne le contexte ou l'état du circuit, plutôt que d'indiquer simplement à l'ingénieur qu'un signal était défaillant, sans autre information, comme ce indiquaient des techniques antérieures. Un autre avantage réside dans le fait que l'émulateur du circuit selon l'invention peut réaliser une meilleure isolation des erreurs. Étant donné que l'émulateur est spécifique pour les détails du circuit, c'est-à-dire qu'il "connaît" détails, il peut vérifier un nombre quelconque de points internes dans un circuit, même s'ils ne sont pas représentés dans le modèle Le concepteur du circuit peut alors déterminer quels points doivent être contrôlés et ajouter une granularité ou visibilité de plus en plus grande comme cela s'avère nécessaire pour faciliter une identification rapide la source défaillances. Selon un aspect de l'invention, un procédé de conception d'un circuit logique consiste à définir une fonctionnalité globale désirée devant être mise en oeuvre par le circuit logique, puis répartir la fonctionnalité globale entre ses circuits constitutifs. Les circuits constitutifs peuvent être émulés et testés séparément pour que leurs fonctionnements soient validés. Sur la base des tests et de la procédure de validation, le circuit logique et/ou l'émulateur sont modifiés sélectivement et remis en fonctionnement. Sous l'effet de ces proce- dures d'émulation partielle/de test partiel concernant des fonctions spécifiques, l'ensemble du circuit logique est affiné pour traiter des défauts identifiés par procédé, ce qui conduit à une définition du circuit logique révisé. La définition du circuit révisé peut être alors utilisée pour affiner le modèle de langage transfert de registre (RTL), qui fournit une formulation du circuit logique révisé et de la validation extérieure. Conformément à d'autres aspects de l'invention, un système pour concevoir un circuit logique inclut un émulateur du circuit servant à émuler chacune des fonctions devant être exécutées par le circuit logique. L'émulateur produit un stimulus d'entrée et effectue des contrôles de sortie pour chacune des fonctions pour laquelle des formes de réalisation du circuit sont disponi bles. Des défaillances dans les simulations ultérieures font l'objet d'un débogage permettant de déterminer la cause, et soit l'émulateur, soit le circuit, soit les deux sont corrigés. D'autres aspects de l'invention incluent la conception et la production d'un circuit en utilisant le procédé de développement décrit et une mise en oeuvre du procédé dans un système logiciel. De façon plus précise, l'invention concerne un procédé de conception d'un circuit logique, caractérisé en ce qu'il comprend les étapes consistant à - définir des fonctions du circuit à tester ; - répartir lesdites fonctions dans une pluralité de blocs ; - émuler séparément chacun de ladite pluralité de blocs ; valider des opérations de certains desdits blocs en coopération avec ladite étape d'émulation séparée ; modifier sélectivement et répéter ladite étape d'émulation en réponse à ladite étape de validation ; affiner le circuit logique en réponse à ladite étape de modification sélective pour former un circuit logique révisé ; réviser un modèle de niveau de transfert de registre dudit circuit logique révisé résultant de ladite étape d'affinage ; simuler ledit circuit logique révisé ; et - valider un fonctionnement dudit circuit logique révisé réponse à ladite étape d'émulation dudit circuit logique révisé. Selon une autre caractéristique de l'invention, ladite etape de simulation dudit circuit logique révisé comprend en outre une étape de codage dudit circuit logique révisé dans un langage de description du materiel. Selon une autre caractéristique de l'invention, le procédé comporte en outre les étapes d'enregistrement, dans un langage naturel, de résultats obtenus à partir de ladite étape de validation d'opérations de certains respectifs desdits processus constitutifs. Selon une autre caractéristique de l'invention, le procédé comprend en outre une étape de création de description des niveaux de commande dudit circuit logique révisé. Selon une autre caractéristique de l'invention, le procédé comporte en outre une étape consistant à définir une configuration de blocs logiques fonctionnels mettant en oeuvre chacun de ladite pluralité de processus constitutifs. Selon une autre caractéristique de l'invention, le procédé comporte en outre un ensemble de création d'une description de niveaux de commande dudit circuit logique révisé sur la base desdits blocs logiques fonctionnels. Dans ce qui précède, on a indiqué d'une manière assez générale les caractéristiques et avantages techniques de la présente invention de manière à permettre une meilleure compréhension de la description détaillée de l'invention qui va suivre. Les spécialistes de la technique noteront que la conception et la forme de réalisation spécifique décrites peuvent être utilisées en tant que base pour modifier ou concevoir d'autres structures pour la mise en oeuvre des mêmes buts de la présente invention. Les spécialistes de la technique noteront également que de tels systèmes équivalents restent dans le cadre de la présente invention. D'autres caractéristiques et avantages de la présente invention ressortiront de la description donnée ci-après prise en référence aux dessins annexés, sur lesquels - la Figure 1 représente un schéma-bloc d'un circuit typique devant être émulé, testé et vérifier ; - la Figure 2 représente un schéma logique d'un procédé de test de vérification précoces de circuits ; - la Figure 3 représente un organigramme d'un procédé selon l'invention pour exécuter et mettre en oeuvre une procédure de test incrémentale, suivie par un test exhaustif de validation du système ; et - la Figure 4 représente un schéma-bloc d'un système d'ordinateur est adapté pour la mise en oeuvre de la présente invention. On va maintenant décrire un procédé selon l'invention pour tester un fichier de registres et un pipeline d'une unité arithmétique et logique (ALU) comme représenté sur la Figure 1. L'émulateur produit une suite d'instructions par exemple pour exécuter et ajouter une instruction suivie par une instruction de décalage, devant être exécutée séquentiellement. L'ému(ateur décode alors les instructions en les signaux dont le circuit ALU soumis au traitement (c'est- à-dire est testé) a besoin pour exécuter ces instructions. En soi, il émule le matériel voisin qui n'est pas représenté par le circuit. L'émulateur assume le rôle matériel manquant (c'est-à-dire le décodeur d'instructions, etc.) au moyen de la production de signaux d'entrée appropriés et de données, en controlant des signaux délivrés par le circuit testé. Dans chaque cycle, I'émulateur délivre de nouvelles instructions, décodées en un niveau de signal servant à maintenir l'évaluation du circuit et l'avance d'un état à un autre. En plus de la stimulation du circuit, l'émulateur contrôle et vérifie les résultats intermédiaires, y compris les valeurs à la fois de données et de signaux de commande dans le circuit. Par exemple l'émulateur vérifie les lignes de sélection multiplexeurs MUX ; il pourrait contrôler les données arrivant des multiplexeurs MUX 22, 24 de l'unité ALU 30 ou de n'importe lequel des circuits verrouillage ; il pourrait vérifier le contenu du fichier de registres. Des détails des signaux spécifiques contrôlés sont laissés au choix la personne ' écrit I'émulateur et/ou du concepteur du circuit. C'est pourquoi l'émulateur fournirait les différents signaux de commande au fichier de registres, aux multiplexeurs MUX 22, 24, aux cycles de verrouillage 26, 28, 30 et 34 et à l'unité ALU 30, y compris tous les signaux de commande qui sont produits localement. Si des signaux doivent être produits par un certain matériel voisin, l'émulateur produit de façon similaire et délivre ces signaux. D'autre part si la commande a été produite localement sur la base autre stimulus lui est envoyé, l'émulateur serait chargé de contrôler également la commande. L'émulateur peut également vérifier d'autres caractéristiques du circuit, comme par exemple une précharge aux instants corrects, mise au repos lorsqu'il n'est pas utilisé, etc. En référence à la Figure 1, on y voit représenté un schéma de base d'un trajet de circulation de données d'exécution d'instructions pipeline. fichier de registres 10 contient tous les registres à usage général 12. Dans chaque cycle, deux opérandes sont extraits de façon typique du fichier de registres et traversent un ensemble de multiplexeurs MUX 22, 24 constituant un réseau de dérivation 20, et pénètrent dans un couple de circuits de verrouillage 26, 28. Lors cycle d'horloge suivant, les opérandes délivrés par les circuits de verrouillage 26, 28 sont envoyés à l'unité ALU 30 qui exécute une addition, un décalage ou une autre instruction appropriée et produit un résultat Dans les deux cycles suivants, ce résultat est transmis en mode pipeline et traverse deux circuits de verrouillage supplémentaires 32, 34 branchés en série pour être finalement écrits en retour dans le fichier de registres 10. Le réseau de dérivation permet l'échantillonnage de résultats qui sont envoyés au fichier de registres 10, puis qui sont renvoyés dans l'unité ALU 10 l'inter médiaire des multiplexeurs 22 et 24 comme cela est représenté. Ceci permet à l'unité ALU d'utiliser (c'est-à-dire d'échantillonner) des résultats précédents de l'unité ALU avant qu'ils soient effectivement écrits dans le fichier de registres, ceci accélère par conséquent l'exécution. Inversement, cette configuration ajoute une complexité, qui améliore plus encore la nécessité d'effectuer contrôle exhaustif pour s'assurer que la dérivation est effectuée correctement tout en ajoutant et en mémorisant le fichier de registres et la performance de fonctions de base similaires. Un procédé d'écriture d'un émulateur pour le circuit selon l'invention commence avec le langage RTL disponible, aussi mature qu'il puisse être, conjointement avec une information concernant la façon dont le langage RTL est destiné à fonctionner. Dans l'exemple indiqué ci-dessus, le concepteur lit également et comprend les spécifications de micro-architecture pour com prendre de façon précise comment l'instruction d'addition est supposée travailler, ou toute autre instruction dont l'unité ALU a besoin pour fonctionner, et pour comprendre combien d'étages pipeline sont présents et utilisés. Un exemple du langage RTL serait une simple phrase telle que "le résultat de l'unité ALU et la somme des opérandes A et B". Aucun détail de circuit au-delà de cela ne serait indiqué. L'étape suivante consiste à évaluer la conception du circuit disponible, ou bien des plans que le concepteur du circuit possède pour réaliser cet élément de langage RTL. Ainsi le concepteur doit comprendre ce à quoi ressemble l'unité ALU elle-même, c' -à-dire sa structure et son fonctionnement. La personne développant l'émulateur doit comprendre les détails du point de vue micro-architecture, électriques et physiques de la structure des opérations de l'unité ALU. Ces éléments étant en place, circuits sont émulés ou "modélisés" sous forme logicielle manière à amener l'ingénieur à convertir effectivement la conception du circuit ou la conception prévue du circuit en logiciel. Ainsi les unités ALU et détails du circuit sont convertis en des composants de logiciel comme par exemple des structures de données, des réseaux, des fonctions, des procédures et d'autres techniques logicielles et mécanismes logiciels utilisés pour modéliser la conception réelle du circuit ou la conception prévue du circuit. Une fois que la modélisation de base des circuits est achevée, l'étape suivante consiste à définir des contrôles appropriés et à commencer l'exécution des contrôles spécifiés en rapport avec le circuit. Les stimuli et les produits et les contrôles sont écrits de manière à exposer et cibler les aspects vulnérables du circuit, au cours de la formation de l'ensemble du circuit. On notera que l'ensemble contrôles n'est nécessairement une liste exhaustive de noeuds dans un circuit. Au lieu de cela, la personne développant l'émulateur sélectionne des points appro priés dans un circuit constituant l'ensemble minimum de noeuds requis pour échantillonner des signaux de sortie des circuits et vérifier que fonction nement est correct. Par exemple, on peut vérifier soit l'entrée, soit la sortie d'un inverseur ; les deux vérifications sont rarement nécessaires. Les points et noeuds d'échantillonnage de test sont choisis à discrétion soit de la personne développant l'émulateur, soit du concepteur du circuit. Lors de la définition des stimuli et contrôles appropriés, le concepteur du circuit dispose du contexte correspondant. Lorsque les vecteurs traversent les circuits, le concepteur du circuit peut observer les signaux de sortie (c'est-à- dire des "zéros" et "uns"), qui traversent le circuit et déterminer ce que l'émulateur essaie de réaliser. Pour faire une économie de temps, l'émulateur annexe au contexte des stimuli et des contrôles, des commentaires sont destinés à permettre au concepteur de mieux comprendre ce que l'émulateur effectue dans le circuit. Ainsi avec l'envoi de signaux de test d'entrée, est-à- dire l'envoi de zéros et de uns dans le circuit, une zone accompagnatrice de commentaire peut inclure par exemple "cette suite de bits représente une instruction d'addition délivrée au circuit ; ce contrôle de zéros et uns représente en réalité le résultat de 14 sortant de l'additionneur". Ceci permet une économie de temps lors du débogage d'une défaillance dans le circuit et/ou dans l'émulateur. Si une défaillance est alors trouvée pendant la stimulation, le concepteur du circuit peut simplement revenir sur un cycle ou deux et imaginer ce que l'émulateur essayait d'accomplir, et supposer ce contexte, plutôt que d'avoir à l'obtenir à partir d'un brouillon par analyse de l'état du circuit par observation uniquement des valeurs de ces signaux. L'étape suivante consiste à déboguer simultanément à la fois le circuit et l'émulateur. La plupart des défaillances sont observées à la fois par le concepteur du circuit et le concepteur de l'émulateur pour identifier des problèmes ou des erreurs qui proviennent du circuit de stimulation ou du logiciel de l'émulateur ou sont provoqués par l'un ou l'autre. De façon typique les problèmes de logiciel de l'émulateur tendent à diminuer, c'est-à-dire que le nombre et la gravité des erreurs diminuent, alors que les problèmes du circuit tendent à augmenter. Finalement, l'émulateur logiciel est affiné et perfectionné etant donné qu'une plus grande quantité d'informations et d'états deviennent disponibles à partir du langage RTL et de la réalisation du circuit. L'innovation plus récente et les modifications les plus récentes sont alors incorporées à la fois dans le langage RTL et dans les circuits, ainsi que dans la spécification de la micro-architecture, s'il s'avère que cette spécification change au cours du projet. Par conséquent l'émulateur doit être maintenu au courant des concep tions physiques actuelles. Toutes ces étapes sont répétées et itérées. Chaque itération est d'essayer d'améliorer l'émulateur en corrigeant les pannes, en fournissant un contexte plus important pour faciliter de façon supplémentaire des efforts de débogage, modéliser de façon plus précise le circuit en question ou ajouter une capacité pour vérifier des circuits nouvellement complétés. La granularité est également améliorée. Si certains types de pannes s'avèrent difficiles à dépanner, un plus grand nombre de contrôles peuvent être exécutés autour de circuits critiques ou sensibles, tandis que des contrôles inutiles ou redondants peuvent être éliminés. Le but est de mettre en oeuvre l'émulateur de manière qu'il soit aussi rapide et aussi soigneux et efficace que possible ou de l'amener ' faciliter le dépannage autant que cela est possible. En définitive, ce processus itératif est répété jusqu'à ce qu'à la fois le langage RTL et le circuit soient matures et suffisamment équivalents pour utiliser les outils et techniques existants traditionnels d'extraction de vecteurs. Les outils, qui exis tent, requièrent un degré substantiel d'équivalence. En général ils ne sont pas d'une utilisation suffisamment souple pour s'adapter facilement à des diffé rences subtiles entre le langage RTL et des formes de réalisation du circuit. On notera que le processus d'obtention de la réponse correcte à la fois dans le langage RTL et dans le circuit est fréquemment complexe. Le circuit peut prendre certaines libertés (c'est-à-dire avoir certaines particularités et modalités ou bien différer du langage RTL par exemple dans des états "indifférent"), qui restent non spécifiés dans le langage RTL, et pour que les outils existants travaillent, la plupart de ces libertés ou de ces imprécisions dans la réalisation doivent être identifiés et traités. La présente invention et la solution itérative se poursuivent jusqu'à ce qu'à la fois le langage RTL et les modes de mise en oeuvre du circuit soient matures au point où des défaillances d'équivalence réelle identifiées par des outils d'équivalence existants dénombrent des fausses défaillances dues à une modélisation imprécise en langage RTL des formes de réalisation circuit, à la suite de quoi son utilité diminue rapidement. Comme cela a été indiqué de façon détaillée, l'émulateur selon l'inven tion est une abstraction logicielle du circuit. Cette abstraction logicielle est comparée à un modèle du niveau de transistor ou de porte, qui est dérivé directement des diagrammes et représentations schématiques du circuit. En utilisant le modèle extrait du niveau de transistor, une comparaison est exécutée par rapport à la technique selon la présente invention de construction d'un modèle abstrait de niveau plus élevé à partir de la description du circuit. Pour exécuter la comparaison entre le modèle du niveau de transistor et l'émulateur, l'émulateur produit les stimuli et les contrôles, qui sont envoyés à un stimulateur fonctionnant sur la base du modèle de niveau de transistor. Par exemple l'émulateur selon l'invention décompose une instruction d'addition, envoie tous les signaux de commande pour l'addition dans ce modèle de niveau de transistor et analyse la sortie de l'additionneur pour vérifier que les résultats sont corrects. En réalité, l'émulateur indique "je m'attends à voir ce résultat et si ne le vois pas, veuillez me le faire savoir". L'émulateur produit à la fois les stimuli et les contrôles de résultats attendus, qui sont exécutés sur le modèle au niveau du transistor. L'émulateur produit les stimuli d'entrée ou les vecteurs d'entrée de façon aléatoire, y compris des instructions aléatoires et des données, et décompose et envoie ces signaux d'entrée au modèle niveau de transistor. L'émulateur calcule simultanément ses propres résultats qui sont attendus. Par conséquent l'émulateur calcule les résultats attendus n'importe quel point donné et en n'importe quel instant donné dans le circuit. Étant donné que l'émulateur est programmé avec les détails de réalisation du circuit, il peut calculer les résultats attendus en un point quelconque du circuit. Ces résultats attendus sont également introduits dans le modèle de niveau du transistor, que le stimulateur permet au concepteur de contrôler manuel lement, ou stimulateur comporte automatiquement les résultats attendus aux résultats réelles et notifie tout écart au concepteur. Des ensembles d'outils existants disponibles pour l'utilisation de tech niques RTL classiques peuvent vérifier virtuellement toute capacité ou fonction disponible une plaquette. Cependant l'utilisateur doit attendre que le modèle basés sur le langage RTL et sur le circuit soient raisonnablement équivalents. autre inconvénient réside dans le fait que les outils RTL ou les outils d'équivalence RTL stimule immédiatement l'ensemble de la plaquette. Bien que l'utilisation du modèle RTL soit efficace pour la stimulation et le débogage situations ou de conditions complexes ou ésotériques, il peut ne pas être souhaitable ni nécessaire d'utiliser le modèle de l'ensemble de la plaquette simplement pour établir par exemple que l'additionneur peut additionner deux nombres correctement. L'émulateur selon l'invention émule seulement une partie d'une plaquette, et par conséquent fonctionne plus rapidement que ne le fait un modèle de plaquette complet ou un émulateur. L'émulateur peut également se focaliser sur le fonctionnement banal de base du circuit. Par conséquent des vecteurs multiples, par exemple de nombreuses instructions d'addition traversant l'unité ALU, peuvent être transmis de manière à établir que l'additionneur fonctionne correctement sans le temps système de simulation des autres parties de la plaquette, qui n'affecteraient pas les résultats de l'additionneur. Par conséquent, l'ensemble du fonctionnement normal du circuit se déroule très rapidement. C'est pourquoi, un avantage de l'émulateur selon la présente invention est que le système de test résultant est plus petit, plus rapide et plus compatible avec le fonctionnement standard du circuit cible. D'autre part, étant donné que l'émulateur est plus compact et plus simple que les modèles basés sur un langage RTL de plaquette complète, il traite pas certains des cas limites se présentant lors du fonctionnement dans l'environnement de la plaquette complète. Par exemple si d'autres parties de la plaquette doivent passer à des arrêts globaux ou des interruptions globales ou etre le siège d'autres conditions exceptionnelles dans le circuit testé, ces conditions sont mieux testées dans le contexte d'un environnement basé sur le langage RTL pour une plaquette complète. La plaquette complète peut très efficacement rechercher et trouver des problèmes se présentant dans une communication ou une interaction globale entre des parties de la plaquette. Des modèles basés sur le langage RTL pour la plaquette complète présentent également l'avantage de nécessiter un personnel spécialisé, dont le travail est de comprendre comment toutes les conditions exceptionnelles travaillent conjointement et d'essayer d'écrire des cas de test pour tester ces conditions. Le temps système dans l'utilisation de l'outil existant pour verifier simplement que l'additionneur fonctionne correctement est considérable - de tels cas sont particulièrement bien adaptés pour un test utilisant l'émulateur selon la présente invention. Ainsi, bien que la présente invention soit adaptée pour l'exécution en masse d'opérations courantes relativement ordinaires pour établir une fonctionnalité de base, les tests plus rigoureux en oeuvre par des systèmes basés sur le langage RTL impliquent des situations plus exotiques, moins communes, et impliquent l'interaction avec le reste de la plaquette. Ainsi l'émulateur selon l'invention fournit des capacités complémentaires à celles de tests classiques basés sur un langage RTL pour la plaquette complète. La Figure 2 représente un organigramme d'un procédé selon l'invention. Lors d'un premier pas 202, un langage RTL disponible, des spécifications de micro-architecture et d'autres exigences requises sont obtenus pour former la base de l'émulateur du circuit et formuler des tests appropriés pour l'émulation. Lors du pas 204, des détails du circuit sont fournis pour faciliter plus encore la réalisation de l'émulation du circuit. Les circuits sont modélisés en utilisant un logiciel pour formuler le pas 206 de l'émulateur, et des contrôles appropriés sont définis lors du pas 208, puis sont exécutés en rapport avec l'émulation du circuit. Le pas 2l0 ajoute ou améliore le contexte en fournissant une description détaillée, qui décrit l'état de l'émulateur, les opérations, les modifications et d'autres paramètres utiles pour faciliter le dépannage et la modification et la maintenance ultérieures du logiciel. Le dépannage du circuit du logiciel est exécuté simultanément lors du pas 12 et, lors du pas 214, le logiciel est affiné comme lorsque des modes de mise en oeuvre appropriés du langage RTL et/ou du circuit évoluent. Comme cela est décrit lors du pas 216, les pas décrits précédemment 206-2l4 sont répétés et, dans la mesure où une information supplémentaire est disponible, pas 202 et 204 sont en outre inclus jusqu'à ce que le circuit et le langage RTL soient suffisamment matures et équivalents pour permettre l'utilisation d'outils existants pour continuer les tests. La Figure 3 montre un organigramme d'un procédé selon l'invention pour la mise en oeuvre d'une procédure de test incrémentale suivie par test exhaustif validation du système. Lors du pas initial 302, les fonctions du circuit devant être émulé et testé sont identifiées. Cette définition peut être extraite la documentation existante ou d'intentions du concepteur incluant toutes les définitions initiales du langage RTL, tous les dessins, tous les schémas approximatifs, etc. Des blocs fonctionnels individuels ou des parties fonc tionnelles individuelles du circuit, qui travaillent logiquement sous forme d'une unité, sont divisés lors du pas 304. Cette division peut être basée sur des ressources, le temps nécessaire pour développer certains composants ou une certaine autre stratégie définie pour l'effort de conception. Le début d'un processus itératif pour émuler les blocs individuels, produire stimuli nécessaires et appropriés et vérifier le fonctionnement correct est exécuté au moyen pas 306, 308 et 310. Pour chaque écart entre des resultats attendus provenant de l'émulateur et des résultats de stimulation du circuit, une entree est enregistrée avec toutes les descriptions du contexte du circuit fournies par l'émulateur lors du pas 312. Des modifications sont apportées à l'émulateur et/ou au circuit sur la base de résultats conflictuels lors pas 314. Lorsque cela est nécessaire, les 306-31 4 sont répétés jusqu'à ce que le fonctionnement correct de chacun éléments constitutifs soit obtenu. Si les résultats sont acceptables, alors le traitement se poursuit par le pas de décision 316 pour déterminer si totalité des capacités désirées du circuit ont été émulées. S'il existe une capacité supplémentaire ou s'il existe des blocs fonctionnels supplémentaires testés, la procédure revient au pas 306 pour ajouter une capacité d'émulation. Sinon, lorsque les objectifs d'émulation et de test sont satisfaits, le circuit logique global est affiné comme cela est nécessaire lors du pas 318 pour incorporer et reproduire des modifications nécessaires pour les éléments constitutifs de manière à créer un circuit logique révisé. Sinon le pas 316 peut être exécuté lors de l'achèvement du test de chaque élément constitutif de manière à redéfinir de façon dynamique l'architecture du circuit au cours du test. En tant que résultat du test, de la révision et de la validation du circuit, le modèle de langage RTL peut être révisé pour la modélisation plus précise de la réalisation du circuit ou pour la reproduction de certaines des modifications du circuit lors du pas 320 et est utilisé pour simuler le circuit lors du pas 322. Lors du pas de décision 324, une détermination est effectuée pour déterminer si le circuit révisé est correct du point de vue fonctionnel, c'est-à-dire si les tests de régression sont encore satisfaits. Si les tests ne fournissent pas un résultat satisfaisant, alors le circuit logique est affiné lors du pas 326 et est à nouveau testé en commençant au niveau du pas 320. Sinon, une nouvelle conception d'un circuit particulier peut conduire à un retour supplémentaire par exemple au pas 306 pour le test de la fonctionnalité révisée. Sinon, si le test de simulation basé sur le langage RTL valide le fonctionnement du circuit, alors la procédure s'arrête lors du pas 328. La Figure 4 représente un système d'ordinateur 400 adapté pour utiliser la présente invention. Bien que l'invention ait été développée en tant que partie d'effort visant à développer nouveau microprocesseur comme le montrent des exemples précédents, l'utilité des techniques décrites n'est pas limitée aux plaquettes de microprocesseurs. Un nombre quelconque de circuits complexes peuvent bénéficier de l'invention. L'unité centrale de traitement (CPU) 401 est couplée au bus 402 du système. L'unité centrale CPU 401 peut être n'importe quelle unité CPU à usage général, comme par exemple un processeur HP PA-8200 ou un processeur Intel Pentium Il. Cependant la présente invention n'est pas limitée par l'architecture de l'unité centrale CPU 401 dans la mesure où l'unité centrale CPU 401 supporte les opérations selon l'invention, telles que décrites ici. Le bus 402 est couplé une mémoire à action directe (RAM) 403, qui peut être une mémoire SRAM, DRAM ou SDRAM. La mémoire ROM 404 est également couplée au bus 402, cette mémoire pouvant être une mémoire PROM, EPROM ou EEPROM. Une mémoire RAM 403 et une mémoire ROM 404 conservent les données d'utilisateur et du système et les programmes comme cela est bien connu dans la technique. Le bus 402 est également couplé à la carte de contrôleur d'entrée/sortie (1/O) 405, la carte 411 d'adaptateur de communications, à la carte 408 d'interface d'utilisateurs et à la carte d'affichage 409. La carte 1/O 405 est connectée à des dispositifs de mémoire 406, comme par exemple une ou plusieurs unités de disque dur, unités de disque compact, unités de disquettes, unités à bandes, et au système d'ordinateur. La carte de communication 401 est adaptée pour coupler le système d'ordinateur 400 à un réseau 412, qui peut être un ou plusieurs réseaux locaux (LAN), réseaux de surface étendue (WAN), le réseau Ethernet ou le réseau Internet. La carte de communications 411 peut également utiliser un système d'ordinateur d'interface 400 de liaison à un dispositif de test pour envoyer et recevoir des signaux en direction et en provenance d'un dispositif prototype construit à base de silicium, une fois achevés le test et la validation, en utilisant une émulation conformément à l'invention. La carte d'interface d'utilisateurs 408 couple des dispositifs d'entrée d'utilisateurs, comme par exemple un clavier 413 un dispositif de pointage 407, au système d'ordinateur 400. La carte d'affichage 409 est pilotée par l'unité centrale CPU 401 pour commander l'affichage sur le dispositif d'affichage 410. Bien que la présente invention et ses avantages aient éte décrits de façon détaillée, on comprendra que différents changements, substitutions et modifications peuvent y être apportés sans sortir du cadre de l'invention. En outre le cadre de la présente demande n'est pas censé être limité à des modes de mise en oeuvre et formes de réalisation particulières de procédés, de machines ou de fabrications, de compositions matérielles, de moyens, de procédés et de pas décrits dans la présente description. Comme le notera aisément le spécialiste ordinaire de la technique à la lecture de la description de fa présente invention, des procédés, machines, fabrication, compositions matérielles, moyens, procédés ou pas existent actuellement ou seront développés ultérieurement et qui mettent en oeuvre essentiellement la même fonction ou fournissent essentiellement le même résultat que les modes de mise en oeuvre et formes de réalisation correspondantes décrits ici, peuvent être utilisés conformément à la présente invention. REVENDICATIONS 1. Procédé de conception d'un circuit logique, caractérisé en ce qu'il comprend les étapes consistant à définir (302) des fonctions du circuit à tester ; - répartir (304) lesdites fonctions dans une pluralité de blocs ; émuler séparément (306) chacun de ladite pluralité de blocs ; valider (310) des opérations de certains desdits blocs en coopération avec ladite étape d'émulation séparée ; modifier sélectivement et répéter (314) ladite étape d'émulation en réponse à ladite étape de validation ; affiner (318) le circuit logique en réponse à ladite étape de modification sélective pour former un circuit logique révisé ; - réviser (320) un modèle de niveau de transfert de registre dudit circuit logique révisé résultant de ladite étape d'affinage ; simuler (322) ledit circuit logique révisé ; et valider (324) un fonctionnement dudit circuit logique révisé en réponse à ladite étape d'émulation dudit circuit logique révisé. 2. Procédé selon la revendication 1, caractérisé en ce que ladite étape de simulation (322) dudit circuit logique révisé comprend outre une étape de codage dudit circuit logique révisé dans un langage de description du matériel. 3. Procédé selon la revendication 1, caractérisé en qu'il comporte en outre l'étape d'enregistrement (312), dans un langage naturel, de résultats obtenus à partir de ladite étape de validation d'opérations de certains respectifs desdits processus constitutifs. 4. Procédé selon fa revendication 1, caractérisé en qu'il comprend en outre une étape de création d'une description de niveau de commande dudit circuit logique révisé. 5. Procédé selon la revendication 1, caractérisé en ce qu'il comporte en outre une étape consistant à définir une configuration de blocs logiques fonc tionnels mettant en oeuvre chacun de ladite pluralité de processus constitutifs. 6. Procédé selon la revendication 5, caractérisé en ce qu'il comporte en outre une étape de création d'une description de niveau de commande dudit circuit logique révisé sur la base desdits blocs logiques fonctionnels.