FR 2764406 A1 19981211 FR 9803910 A 19980330 ANNEXES Le présent document contient les annexes suivantes lesquelles sont incorporées à la présente description et en constituent une partie intégrante et sont citées à titre de référence: 1) L'annexe A contient un listage écrit en code Verilog décrivant la fonctionnalité d'un contrôleur dans un sous-système d'analyse logique d'un mode de réalisation préféré de la présente invention. 2) L'annexe B contient une description supplémentaire des détails d'un contrôleur de l'annexe A. DEMANDES DE BREVETS CONNEXES La présente demande de brevet est apparentée aux demandes de brevet en cours suivantes citées dans le présent mémoire à titre de référence: 1. Demande de brevet des Etats Unis d'Amérique N Serial 08/197 430 intitulée " Method and Apparatus for a Trace Buffer in an Emulation System (Procédé et appareil pour un tampon d'analyse dans un système d'émulation)" déposée par Kuijsten le 16 février 1994; 2. Demande de brevet des Etats Unis d'Amérique N Serial 08/242 164 intitulée " Emulation System Having Multiple Emulator Clock Cycles Per Emulated Clock Cycle (Système d'émulation ayant des cycles d'horloge d'émulateur multiples par cycle d'horloge émule)", déposée par Kuijsten le 13 mai 1994; 3. Demande de brevet des Etats Unis d'Amérique N Serial 08/496 239 intitulée " Emulation System Having Multiple Emulator Clock Cycles Per Emulated Clock Cycle and Improved Signal Routing (Système d'émulation ayant des cycles d'horloge d'émulateur multiples par cycle d'horloge émulé et un routage amélioré des signaux)", déposée par Chilton et al. le 28 juin 1995; et 4. Demande de brevet des Etats Unis d'Amérique N Serial 08/597 197 intitulée " System and Method for emulating Memory (Système et procédé pour émuler une mémoire)", déposée par Chilton et al. le 6 février 1996. DOMAINE DE L'INVENTION La présente invention se rapporte à la simulation de circuits numériques via un émulateur matériel et, plus particulièrement, à un procédé et un appareil pour implémenter un sous-système d'analyse logique destiné au déboguage des circuits dans un tel émulateur. ARRIERE-PLAN DE L'INVENTION Au fur et à mesure que les modèles de circuits continuent d'augmenter en vitesse et complexité, il devient plus que jamais crucial de tester les modèles de circuits en cours de développement à divers stades du développement. Les émulateurs matériels fournissent un moyen pour tester des modèles de circuits complexes au fur et à mesure que les modèles sont développés. De tels émulateurs fournissent d'une manière typique un matériel configurable qui est commandé par logiciel afin d'exécuter les fonctions d'un circuit en cours de conception. Le modèle de circuit est spécifié par un jeu de données qui définit la structure et le comportement du circuit. L'émulateur est souvent connecté à un "système cible" qui est le circuit réel avec lequel le modèle de circuit fonctionnera en définitive. Les émulateurs fonctionnent sous contrôle logiciel. Le modèle de circuit est "compilé" pour produire le programme qui contrôle l'émulateur. Du fait qu'un émulateur doit exécuter les fonctionnalités d'une large gamme de modèles de circuits, il doit être aussi flexible que possible. Ce qui signifie que le système d'émulation doit contenir du matériel de traitement logique qui soit réutilisable pour différents modèles. Un tel système d'émulation devra contenir un grand nombre d'éléments de traitement universels qui seront utilisés pour exécuter indirectement le circuit qui est émulé. Par exemple, un émulateur universel devra traiter des équations booléennes logiques pour émuler un circuit multiplieur plutôt que d'utiliser un multiplieur matériel dédié dans le même but, lequel deviendrait inutilisable dans l'émulation de modèles de circuits ne contenant aucune fonction multiplieur. Afin de résoudre ces équations, un grand nombre de portes ou d'autres dispositifs, doivent être pourvus de signaux dans l'émulateur. De plus, les sorties des portes ou d'autres composants doivent être routées de manière efficace parmi les divers composants de l'émulateur. Les émulateurs usuels sont employés pour développer et tester des modèles. A cette fin, il est souhaitable d'être en mesure de contrôler divers signaux au cours du processus d'émulation. Dans les émulateurs usuels, cependant, certains signaux ne sont pas disponibles pour le monitorage du fait qu'ils sont perdus au cours du processus de compilation. Le compilateur prend une description du modèle à émuler et la transforme en instructions de commande pour l'émulateur. Ce processus "réduit" certains groupes de signaux dans le modèle. Les signaux réduits ne sont pas disponibles pour l'observation au cours du processus d'émulation. Ce qui est nécessaire, c'est un moyen permettant à l'utilisateur de "voir" les signaux réduits. Une telle fonction améliorerait la capacité de l'utilisateur à déboguer et tester le circuit en cours d'émulation. De plus, il est souhaitable de permettre à l'utilisateur de définir des points d'arrêt et des déclencheurs au cours du processus d'émulation. Il est également souhaitable de permettre à l'utilisateur de vider le contenu des signaux dans l'émulateur vers un ordinateur ou une station de travail extérieur pendant l'émulation. RESUME DE L'INVENTION La présente invention surmonte les problèmes et inconvénients de l'art antérieur en implémentant un sous-système d'analyse logique (également appelé sous-système de dépistage) dans un émulateur à tranches de temps. Le sous-système d'analyse logique "reconstruit" les signaux qui ont été antérieurement réduits par le compilateur et permet à l'utilisateur de fixer des points d'arrêt et des déclencheurs en utilisant ces signaux et d'autres signaux du circuit émulé. Un mode de réalisation préféré de la présente invention comporte "un compilateur de sous-système d'analyse logique" et un "matériel de sous- système d'analyse logique". Le compilateur de sous-système d'analyse logique est soit un sous-ensemble du compilateur régulier de l'émulateur soit un compilateur autonome. Il compile le modèle devant être émulé en génère des instructions de commande pour le matériel de sous-système d'analyse logique. Le matériel de sous-système d'analyse logique se raccorde à l'émulateur à tranches de temps pour recevoir des signaux générés par émulateur pendant I'émulation. Lorsque le sous-système d'analyse logique opère, les instructions de commande générées par le compilateur du sous-système d'analyse logique conduit le sous-système d'analyse logique à reconstruire les signaux précédemment réduits reçus de l'émulateur. Ces signaux (de même que d'autres signaux reçus de l'émulateur) peuvent être utilisés pour fixer des points d'arrêt et des déclencheurs dans le sous-système d'analyse logique. Un mode de réalisation préféré de la présente invention est couplé à une station de travail ou autre ordinateur universel et permet à l'utilisateur de gérer la configuration du sous-système d'analyse logique. Le sous-système d'analyse logique délivre un signal d'interruption à la station de travail à la survenance d'un point d'arrêt ou une condition de déclenchement défini par l'utilisateur ou lorsque la mémoire de dépistage est pleine (et que le sous-système d'analyse logique n'est pas dans un mode lui permettant d'écraser par réécriture sa mémoire lorsque celle-ci est pleine). Un émulateur avec lequel un sous-système d'analyse logique selon la présente invention opère contient jusqu'à quatre châssis. Chaque châssis contient jusqu'à huit cartes émulateur. Chaque carte émulateur contient jusqu'à douze puces processeur d'émulation et intègre également une partie du sous- système d'analyse logique. Chacune des huit cartes est couplée à un bus 384 bits de l'émulateur à tranches de temps. Pendant chaque cycle d'horloge utilisateur, la sortie de l'émulateur est également envoyée au sous-système d'analyse logique via ce bus. Conformément au but de la présente invention telle que réalisée et décrite ici, I'invention est un sous-système d'analyse logique couplé à un système d'émulation, le sous-système d'analyse logique comprenant: des lignes d'entrée recevant des sorties du système d'émulation; au moins une puce processeur implémentant une fonction sonde selon des signaux reçus sur 2764406 les lignes d'entrée; et un contrôleur contrôlant le fonctionnement de la fonction sonde selon des instructions reçues d'au moins une puce processeur. De plus, conformément au but de la présente invention telle que réalisée et décrite dans le présent mémoire, I'invention est un procédé de compilation d'un modèle de circuit fonctionnel de manière qu'il puisse être pisté par un sous-système d'analyse logique, le procédé, exécuté par un système de traitement de données, comprenant les étapes consistant à: stocker dans une mémoire, une pluralité de signaux de sortie qui seront disponibles à partir d'un système émulateur pendant l'émulation; recevoir une description d'un signal réduit requis par le sous-système d'analyse logique lorsque le signal réduit inclut une description de la manière dont les signaux de sortie sont utilisés pour générer le signal réduit; déterminer les contenus d'un second circuit qui reçoit les signaux de sortie et génère le signal réduit en fonction de la description du signal réduit; et compiler le second circuit de manière qu'il puisse être implémenté par le sous-système d'analyse logique pour reconstruire le signal réduit. Les avantages de la présente invention sont pour une partie exposés dans la description qui suit et sont pour une autre partie évidents d'après la description ou peuvent être acquis par la mise en oeuvre de l'invention. Les objets et avantages de l'invention seront réalisés et atteints au moyen des éléments et combinaisons particulièrement mis en évidence dans les modes de réalisation décrits ci-après et variantes dans le cadre de l'invention. BREVE DESCRIPTION DES DESSINS Les dessins déposés à l'appui de la présente demande et qui sont incorporés dans le présent mémoire et en constituent une partie intégrante, illustrent plusieurs modes de réalisation de l'invention et, conjointement avec la description, servent à expliquer les principes de l'invention. La figure 1 est un diagramme synoptique au niveau système d'un émulateur avec lequel un mode de réalisation préféré de l'invention opère. La figure 2 est un diagramme synoptique dans lequel une carte de l'émulateur de la figure 1 est représentée connectée à une partie d'un sous- système d'analyse logique selon la présente invention. La figure 3(a) est un diagramme synoptique du sous-système d'analyse logique de la figure 2. La figure 3(b) est un diagramme synoptique montrant avec plus de détails, un contrôleur du sous-système analyseur de la figure 3(a). La figure 4 est un diagramme synoptique montrant les entrées et les sorties d'un compilateur d'émulateur et un compilateur de sous-système d'analyse logique dans un premier mode de réalisation préféré de la présente invention. La figure 5 est un diagramme synoptique montrant les entrées et les sorties d'un compilateur d'émulateur dans un second mode de réalisation préféré de la présente invention. La figure 6 montre un exemple d'un modèle de circuit devant être émule. La figure 7 montre l'exemple de la figure 6 après que le compilateur de l'émulateur a réduit les signaux dans le modèle. La figure 8 montre un exemple de la manière dont les signaux non réduits de la figure 7 sont entrés dans les processeurs de l'émulateur. Les figures 9(a) à 9(f) montrent les circuits compilés qui nécessitent d'être reconstruits par le compilateur du sous-système d'analyse logique de manière que le sous-système d'analyse logique puisse reconstruire les signaux précédemment réduits et y accéder pendant l'émulation. La figure 10 est un schéma montrant un exemple d'un circuit compilé généré par le compilateur du sous-système d'analyse logique de manière que le sous-système d'analyse logique puisse générer un point d'arrêt. La figure 11 est un schéma montrant un exemple d'un circuit compilé généré par le compilateur du sous-système d'analyse logique de manière que le sous-système d'analyse logique puisse générer un signal de notification. La figure 12(a) est un schéma montrant un exemple d'un circuit compilé généré par le compilateur du sous-système d'analyse logique de manière que le sous-système d'analyse logique puisse générer un signal déclencheur. La figure 12(b) montre un exemple d'un circuit compilé généré par un compilateur dans un système qui permet aux points d'arrêt d'être changés en cours de fonctionnement de l'émulateur. La figure 13 est un diagramme synoptique au niveau système d'un circuit intégré unique dans le sous-système d'analyse logique de la présente invention. La figure 14 montre un diagramme développé du routage de certains blocs fonctionnels de la figure 13. La figure 15 montre davantage de détails du circuit des premiers blocs fonctionnels de la figure 13. La figure 16 montre un diagramme synoptique développé du bloc unité logique de la figure 13. La figure 17 montre plus de détails concernant la circuiterie du lecteur d'entrée. La figure 18 montre davantage de détails du bloc mémoire d'émulation de la figure 13. La figure 19 montre une configuration au niveau carte de douze puces processeur "Hydra" et une partie du sous-système d'analyse logique. DESCRIPTION DETAILLEE DE PLUSIEURS MODES DE REALISATION PREFERES On se réfère à présent en détail aux modes de réalisation préférés de l'invention dont des exemples sont illustrés par les dessins ci-joints. Là o cela a été possible, les mêmes numéros de référence ont été utilisés dans les dessins pour désigner les mêmes éléments ou les éléments similaires. Les paragraphes suivants fournissent une vue globale du matériel d'un émulateur utilisable conjointement avec la présente invention et une vue globale d'un sous-système d'analyse logique selon la présente invention. La figure 1 est un diagramme synoptique au niveau système d'un émulateur 100 avec lequel un mode de réalisation préféré de la présente invention opère. Un tel émulateur peut-être, par exemple, un émulateur à tranches de temps tel que décrit dans le brevet des Etats Unis d'Amérique N Serial 08/496 239 intitulée" Emulation System Having Multiple Emulator Clock Cycles Per Emulated Clock Cycle and Improved Signal Routing (Système d'émulation ayant des cycles d'horloge d'émulateur multiples par cycle d'horloge émule et un routage amélioré des signaux)", déposée par Chilton et al. le 28 juin 1995, lequel est cité dans ce mémoire à titre de référence. L'émulateur 100 comporte de préférence un nombre (C) de châssis dont chacun, comme montré sur la figure 1, contient M cartes 102...106 couplées via un bus 384 bits. Dans une version de l'émulateur, C=4 et M=8. Ainsi, il y a quatre châssis et huit cartes dans chaque châssis. L'émulateur 100 permet l'implémentation d'un modèle utilisateur à mappage technologique sur une série de tranches de temps ou de pas de programme. Un processus de mappage technologique (compilateur) convertit des parties du modèle utilisateur (par exemple un schéma logique dit "netlist") en une forme qui peut être placée dans les éléments de traitement du matériel physique. Après ce processus, les noeuds du modèle qui sont disponibles soit aux entrées soit aux sorties des éléments de traitement dans l'émulateur sont visibles au matériel externe pour le prélèvement. La figure 1 comporte également un carte CT (contrôleur) 107, comme celle décrite dans le brevet des Etats Unis d'Amérique N Serial 08/496 239, et une station de travail 101, qui est connectée à la carte CT 107 via un bus hôte 356. La figure 2 est un diagramme synoptique d'une carte 102 de l'émulateur de la figure 1. Dans un mode de réalisation préféré de la présente invention, chaque carte 1..M contient une partie du sous-système d'analyse logique 202. La carte 102 comporte une portion du sous-système d'analyse logique 202 et un système de traitement logique 203. Chaque carte dans le sous- système de l'émulateur 203 comporte N puces processeur 204 à 208, N étant égal à 12. Chaque portion du sous-système d'analyse logique 202 comporte deux puces processeur 302 et 304 ("puces processeur de dépistage") et une mémoire contrôleur/dépistage 306. Chaque puce processeur dans l'émulateur 203 est connectée par le bus d'émulateur 384 bits. Les puces processeur de dépistage 302 et 304 dans le sous-système d'analyse logique reçoivent également le bus d'émulateur 384 bits. Le sous-système émulateur 203 calcule les sorties primaires d'un modèle utilisateur à partir des entrées primaires du modèle et l'état interne du modèle sur le bus 384 bits. Pendant la compilation de l'émulateur 203, les valeurs générées par les sorties des puces apparaissent sur le bus logique 384 bits. En utilisant ces valeurs intermédiaires comme entrées, le sous-système d'analyse logique 202 implémente des caractéristiques de déboguage flexibles et puissantes sans réduire la capacité ou performance logique de l'émulateur 203. Ceci est accompli en utilisant les ressources additionnelles de tranches de temps dans le sous-système d'analyse logique 202 (c'est-à-dire, les puces processeur 302 et 304). En programmant le sous-système d'analyse logique 202, les caractéristiques suivantes peuvent être ajoutées: 1) Les noeuds utilisateur qui ne sont pas encore disponibles sur le bus logique pour un prélèvement direct du fait qu'ils ont été retirés lors de la compilation/mappage technologique, peuvent être reconstruits. Ceci signifie que lorsqu'un utilisateur choisit un noeud pour le prélèvement et qu'il n'est pas disponible sur le bus logique, la logique requise pour créer le noeud à partir des entrées qui sont disponibles sur le bus sera générée (au moment de la compilation) et implémentée dans le sous-système d'analyse logique 202. 2) En plus de la reconstruction du noeud, les ressources dans le sous- système d'analyse logique peuvent être programmées avec diverses logiques requises pour générer des déclencheurs de saisie de dépistage, des points d'arrêt, et des signaux d'interruption de station de travail. La logique associée à ces signaux est également générée au moment de la compilation et peut être arbitrairement complexe dans les limites des ressources logiques disponibles et peut contenir des éléments séquentiels et/ou des valeurs mémoire. Les points d'arrêt, les déclencheurs, les événements de notification, etc. sont désignés par le terme général "fonctions sonde". Une version légèrement plus détaillée de la figure 2 est représentée sur la figure 19. La figure 3(a) est un diagramme synoptique du sous-système d'analyse logique 202 de la figure 2. Le sous-système 202 comporte deux puces processeur de dépistage 302 et 304 dont chacune reçoit 320 entrées du bus d'émulateur 384 bits (256 bits du bus sont envoyés aux deux et les 128 bits restants sont divisés de manière égale entre les puces processeur de dépistage). D'autres implémentations de la présente invention peuvent inclure un nombre différent de puces processeur. Les puces processeur de dépistage 302 et 304 fonctionnent d'une manière essentiellement identique aux puces processeur 1..N dans le sous-système 203 de la figure 2 qui sont décrites en détail ci-dessous. La mémoire de dépistage qui est une mémoire de 128 K x 64 et le contrôleur 306 sont également décrits en détail ci-dessous. Le contrôleur 306 est couplé à un bus hôte 60 bits 356 qui constitue I'interface (via la carte CT 107 de l'émulateur) avec la station de travail 101. Le bus hôte utilise de préférence une interface MXI définie et fabriquée par la firme National Instruments Corporation mais peut utiliser n'importe quelle interface permettant au contrôleur de communiquer avec une station de travail ou avec quelque autre dispositif ou contrôleur externe. L'ensemble contrôleur/mémoire 306 délivre également une pluralité d'autres signaux. Ces signaux comprennent un signal NOTIFICATION 360 qui est généré en effectuant une réunion logique (opération logique OU) entre un signal de POINT D'ARRET généré à partir de la puce processeur de dépistage 302 et un signal MEMOIRE DE DÉPISTAGE PLEINE généré par le contrôleur 306. Le signal de notification est envoyé à la carte CT 107, et de là vers la station de travail 101. Ainsi, le signal NOTIFICATION est activé lorsqu'une condition de point d'arrêt se produit ou lorsque la mémoire 306 est pleine (et la mémoire n'est pas configurée dans un mode pouvant écraser par réécriture la mémoire). L'effet du signal NOTIFICATION dépend de la fonctionnalité de la station de travail. Par exemple, la station de travail peut envoyer des commandes à la mémoire/contrôleur via une interface 310 lorsqu'elle reçoit une notification. De manière similaire, la station de travail peut sélectionner de nouveaux points l1 d'arrêt, déclencheurs et de nouvelles conditions de notification (comme décrit ci-dessous en regard de la figure 12(b)) en réaction à un signal de notification. A titre d'un autre exemple, la station de travail peut envoyer une commande de lecture de la mémoire lorsqu'elle reçoit un signal de mémoire de dépistage pleine. Dans un mode de réalisation préféré, la station de travail stoppe le sous-système d'analyse logique et envoie une commande sur le bus hôte 356 pour lire la mémoire 306. En réponse à une telle commande, le contrôleur envoie le contenu de la mémoire 306 à la station de travail sur l'interface de bus MXI. Le sous-système d'analyse logique envoie également le signal POINT D'ARRET lui-même à la carte CT 107. Le signal DECLENCHEMENT est envoyé à chacune des autres cartes dans l'émulateur 203. Le signal DECLENCHEMENT peut amener les sous-systèmes de la mémoire de dépistage à saisir les données de sonde. La configuration exacte des signaux de sonde envoyés par le sous-système d'analyse logique diffère dans les divers modes de réalisation de la présente invention. De manière similaire, les signaux de sonde peuvent avoir des noms ou des désignations différents et peuvent avoir des points d'origine ou de destination différents, aussi longtemps qu'ils sont définis par l'exécution d'un schéma "netlist" compilé par une ou plus d'une des puces processeur de dépistage dans le sous-système d'analyse logique. La figure 3(b) est un diagramme synoptique montrant davantage de détails d'un contrôleur du sous-système d'analyse logique de la figure 3(a). La figure 3(b) montre les puces processeur de dépistage 302 et 304 avec des détails de l'ensemble contrôleur/mémoire 306. L'ensemble contrôleur/mémoire 306 comporte de préférence deux contrôleurs 372 et 374 dont chacun est respectivement couplé aux puces processeur de dépistage 302 et 304 par une ligne de données 32 bits et une ligne de déclenchement 352 (comme montré sur la figure 3(a)). Chaque contrôleur 372, 374 est respectivement connecté à une mémoire telle qu'une mémoire vive 382, 384 de 128K x 32. Dans le mode de réalisation décrit, chaque contrôleur 372, 374 est implémenté sous forme d'un FPGA (Field Programmable Gate Array ou réseau de portes programmable). Chaque FPGA comporte un compteur d'adresses 392 et implémente une fonction comme décrit dans le code Verilog de l'annexe A. L'annexe B décrit des fonctionnalités additionnelles des contrôleurs 372, 374. D'autres modes de réalisation de l'invention peuvent implémenter la fonctionnalité des contrôleurs 372, 374 en utilisant une autre technologie telle que celle des ASIC (Application-Specific Integrated Circuit ou circuit intégré spécifique à des applications). Une partie de la fonctionnalité implémentée dans les contrôleurs 372, 374 est représentée dans la section éclatée 394 de la figure 3(b). La fonctionnalité comprend un sélecteur 397 qui choisit entre une donnée 32 bits émanant de la puce processeur de dépistage et une donnée 32 bits provenant du bus hôte; un sélecteur 398 qui choisit entre une donnée d'adresse 17 bits émanant de la puce processeur de dépistage et une donnée d'adresse 17 bits provenant du bus hôte; et un sélecteur 399 qui choisit une donnée de validation de lecture/écriture 1 bit et une donnée de validation de sortie 1 bit provenant soit de l'hôte soit d'une machine d'état des contrôleurs 372 et 374. Chaque contrôleur 372, 374 implémente également une machine d'état 396 contrôlée par le compteur d'adresses 392, comme fonctionnalité décrite dans l'annexe A. Comme montré sur la figure, la machine d'état gère le fonctionnement des sélecteurs dans la section 394. La figure 4 est un diagramme synoptique montrant les entrées et les sorties d'un compilateur d'émulateur et un compilateur de sous-système d'analyse logique dans un premier mode de réalisation préféré de la présente invention. La compilation comporte deux étapes indépendantes. D'abord, un schéma dit "netlist" 402, décrivant un modèle devant être émulé est compilé par le compilateur d'émulateur 404 pour donner un modèle compilé qui sera exécuté par l'émulateur 203 dans l'élément 406. Une seconde étape de compilation peut être soit implémentée en tant que partie de la compilation de l'émulateur soit exécutée séparément. Lorsque le compilateur 404 compile le modèle pour l'émulateur, il génère un "schéma "netlist" mappé" qui contient les signaux assignés aux entrées et sorties des puces processeur de l'émulateur sur le bus 384 bits. Le schéma "netlist" mappé contient également des informations spécifiant les signaux qui ont été réduits par le compilateur ( de manière qu'il puisse être déterminé quels sont les signaux à reconstruire). Pendant la seconde phase de compilation, le schéma "netlist" mappé et un schéma "netlist" de Flux de Contrôle d'Exécution (ecf) est envoyé au compilateur 408 qui génère des circuits compilés qui, respectivement, 1) reconstruisent les signaux réduits par le compilateur 404 et 2) implémentent les points d'arrêt, déclencheurs, notifications, etc. spécifiés par l'utilisateur au moment de la compilation. Ces circuits compilés additionnels sont implémentés par le sous-système d'analyse logique 202, comme montré dans l'élément 410. Le schéma "netlist" ecf est un schéma "netlist" destiné à un circuit implémentant les circonstances dans lesquelles les points d'arrêt, etc. doivent être définis. Un tel circuit peut contenir, par exemple, les éléments 1008 et 1010 de la figure 10 qui effectuent une opération logique ET sur les signaux provenant de l'émulateur et activent le signal POINT D'ARRET. Le schéma "netlist" ecf peut être, par exemple, un schéma "netlist" écrit en Verilog généré par n'importe quelle méthode appropriée, telle que celle utilisant le Design Compiler (Compilateur de Modèle), disponible auprès de la firme Synopsys, Inc. de Mountain View, Californie. En variante, une interface utilisateur spécialisée peut permettre àl'utilisateur de spécifier les points d'arrêt, etc. de manière graphique et peut générer le schéma "netlist" ecf à partir de l'entrée utilisateur. Comme également montré sur la figure, l'émulateur et le sous-système d'analyse logique échangent des informations pendant l'exécution, telles que l'information sur le bus d'émulateur 384 bits et les signaux de sonde. La figure 5 est un diagramme synoptique montrant les entrées et sorties d'un compilateur d'émulateur dans un second mode de réalisation préféré de la présente invention. Dans le mode de réalisation de la figure 5, le compilateur 404' ne génère pas de schéma "netlist" pour exécuter la reconstruction mais, au lieu de cela, permet à l'utilisateur d'entrer une "liste de noeuds préservée" dans le compilateur 404' qui indique quels signaux ne doivent pas être réduits. Ceci génère un plus grand modèle, mais rend les signaux disponibles pour le sous-système d'analyse logique afin de définir les points d'arrêt, déclencheurs, notifications, etc. Comme également montré sur la figure, l'émulateur et le sous- système d'analyse logique échangent des informations pendant l'exécution, comme décrit ci-dessus. Les paragraphes suivants décrivent un exemple d'un modèle devant être émulé, lorsque certains signaux sont perdus (c'est-à-dire réduits) lors de la compilation par le compilateur 404. Dans l'exemple, I'utilisateur définit divers points d'arrêt, déclencheurs, et événements de notification qui requièrent la reconstruction des signaux réduits. La figure 6 montre un exemple de modèle utilisateur devant être émulé. Les circuits contiennent seize signaux différents, dont les entrées A, B, C, D, E, F, G et H; les sorties P et O; et les signaux internes N, 1, J, K, L et M. La figure 7 montre l'exemple de la figure 6 après que le compilateur de l'émulateur 404 a réduit les signaux dans le modèle. Dans l'exemple, le processus de mappage exécuté par le compilateur retirent les signaux internes. La figure 8 représente un exemple de la manière dont les signaux non réduits de la figure 7 sont entrés dans un premier processeur tandis que les signaux C, D, E, F, G et H sont entrés dans un second processeur. Il faut noter que, à moins que la reconstruction soit effectuée, seuls les signaux d'entrée et de sortie seront disponibles pour le sous-système d'analyse logique via le bus 384 bits. Les figures 9(a) à 9(f) montrent les schémas "netlist" qui nécessitent d'être reconstruits par le compilateur du sous-système d'analyse logique de manière que le sous-système d'analyse logique puisse reconstruire les signaux précédemment réduits et accéder à ces derniers. Ces schémas "netlist" sont générés et compilés par le compilateur 404 de la figure 4 et implémentés par les puces processeur de dépistage 302 et 304 de la figure 3(a). Chaque circuit compilé sur la figure 9 utilise l'information contenue dans le schéma netlist mappé pour reconstruire les signaux internes retirés par le compilateur 404. Dans un mode de réalisation préféré de la présente invention, la reconstruction logique pour un signal tient dans un seul processeur. La figure 10 est un vue schématique montrant un exemple d'un circuit compilé généré par le compilateur du sous-système d'analyse logique de manière que le sous-système d'analyse logique puisse générer un signal de point d'arrêt. Dans l'exemple, I'utilisateur a défini un point d'arrêt à survenir lorsque (J ET N) est vraie. Ainsi, le sous-système d'analyse logique implémente les circuits compilés pour reconstruire les signaux J et N, pour effectuer une opération ET logique sur les signaux reconstruits, et pour fixer le signal NOTIFICATION à l'état actif si le résultat de l'opération ET logique est vraie. La figure 12(a) est une vue schématique montrant un exemple d'un circuit compilé généré par le compilateur du sous-système d'analyse logique de manière que le sous-système d'analyse logique puisse générer un signal déclencheur. Dans l'exemple, I'utilisateur a indiqué qu'un événement déclencheur survient quand (J ET N) est vraie. Ainsi, le sous-système d'analyse logique implémente un circuits compilé pour reconstruire les signaux J et N, pour effectuer une opération ET logique sur les signaux reconstruits, et pour fixer le signal DECLENCHEMENT à l'état actif si le résultat de l'opération ET logique est vraie. La figure 12(b) montre un exemple d'un circuit compilé généré par un compilateur dans un système qui permet aux points d'arrêt d'être changés au cours du fonctionnement de l'émulateur. Ainsi, le circuit compilé de la figure 12(b) est construit (comme un schéma "netlist" ecf) par l'utilisateur, compilé, et implémenté par le matériel du sous-système d'analyse logique dans le cas o l'utilisateur va vouloir commuter les points d'arrêt, etc. sans stopper en cours d'émulation. Le circuit compilé contient des circuits compilés plus petits 1002, 1304, etc. dont les sorties sont appliquées à un sélecteur de compilateur 1306. Le sélecteur de compilateur 1306 choisit l'une des sorties, en fonction d'un signal 1308, qui peut être, par exemple, une valeur fixée à partir de station de travail (via le mappage mémoire) ou une valeur entrée à partir du modèle en cours d'émulation, ou à partir d'une broche d'entrée du modèle. (Dans ce dernier cas, le modèle en cours d'émulation devra être modifié pour générer une telle valeur). Les paragraphes suivants fournissent des détails supplémentaires concernant l'émulateur utilisé avec la présente invention. Les puces processeur de dépistage 302 et 304 dans le sous-système d'analyse logique 202 sur chaque carte émulateur sont essentiellement les mêmes que la puce processeur "Hydra" décrite ci-dessous. La figure 13 est un diagramme synoptique au niveau système d'une "puce" unique dans un émulateur utilisé avec un mode de réalisation préféré de la présente invention. L'exemple décrit ici est destiné à être produit sous forme d'un produit industriel connu durant le développement tel que le système "Hydra Logic Emulation System ( Système d'Emulation Logique Hydra)" et auquel il est fait référence ici en tant que le "système d'émulation logique", développé par la firme Arkos Design, Inc. Le modèle représenté au niveau système en tant que puce 100 sur la figure 13 est fabriquée sur un boîtier à circuit intégré (IC) unique auquel on se réfère sous le terme Puce Hydra. Les figures additionnelles 14 à 19 montre des détails niveau carte et niveau bloc du système d'émulation logique. Bien qu'un mode de réalisation spécifique d'un émulateur soit décrit à titre illustratif, la portée de l'invention n'est pas limitée à ce mode de réalisation spécifique. Sur la figure 13, la puce 100 comporte divers sous-circuits pour exécuter des fonctions spécifiques. Les sous-circuits sont représentés sous forme de blocs sur la figure 13 tels que la donnée de commande 102. En décrivant le système d'émulation, I'architecture du système d'émulation logique est présentée dans la section immédiatement ci-dessous. Ensuite, une description détaillée des sous-circuits sélectionnés dans le système d'émulation logique est présentée en se concentrant sur les sous-circuits 106-112 qui concernent le sélecteur et le routage par le registre à décalage des données vers les unités logiques Hydra ("HLU") qui donnent au système d'émulation logique un avantage spécial dans son aptitude à router de manière universelle et uniforme les données variables parmi les HLU. Dans une section suivante du texte, un exemple de compilation d'un circuit pour exécution dans le système d'émulation est donné. a. Architecture du Système d'Emulation Logique Sur la figure 13, une donnée de commande 102 est utilisée pour stocker les mots de commande en microcode qui dirigent le fonctionnement de la Puce Hydra ("puce"). Dans le mode de réalisation décrit, la donnée de commande 102 pourvoit à 64 mots de commande, chacun ayant une largeur d'approximativement 10 000 bits. Des nombres divers de bits dans chaque mot de commande sont routes au moyen de lignes de commande, vers d'autres blocs fonctionnels sur la puce afin de commander, par exemple, sélecteurs n:1, registres à décalage, portes de passage, inversion de signaux, comme décrit ci- dessous. Pour faciliter l'illustration, les lignes de commande ont été omises sur la figure 13. Cependant, il sera évident que les mots de commande peuvent être utilisés de diverses manières bien connues dans le domaine pour commander les divers dispositifs et blocs fonctionnels. La donnée de commande 102 est chargée avec jusqu'à 64 mots de commande du programme de commande généré par le compilateur. Le compilateur est un logiciel qui reçoit, comme entrée, une spécification d'un circuit à émuler et délivre un programme de commande sous la forme d'équations et de logique de commande pour amener la puce à émuler le circuit souhaité. Les mots du programme de commande sont exécutés à chaque cycle d'émulation, un cycle d'émulation étant un cycle du circuit émule. En d'autres termes, si un circuit en cours d'émulation fonctionne à 1 MHz, le cycle d'émulation est de 1,0 ps. Ceci signifie que tous les pas du programme doivent être achevés en 1,0 ps. Etant donné qu'il y a un maximum de 64 pas de programme, l'horloge de l'émulateur devrait fonctionner à 64 MHz au maximum. S'il y a moins de 64 pas de programme, la vitesse d'émulation croît en conséquence. Une description détaillée de l'approche consistant à utiliser des cycles d'horloge d'émulateur multiples par cycle d'horloge émulé, et les avantages de procéder ainsi, peuvent être trouvés dans la demande de brevet en cours des Etats Unis d'Amérique connexe N Serial 08/242 164. L'émulateur comporte la capacité de prolonger n'importe lequel des pas de programme d'une durée allant jusqu'à trois cycles d'horloge d'émulateur additionnels. Ceci est utile pour interfacer l'émulateur avec du matériel cible nécessitant des temps d'accès plus longs. Lorsque les pas de programme sont prolongés, cela étend naturellement le cycle global du programme en conséquence. La mémoire RAM à sorties programmables est une mémoire à accès direct (RAM) de 16K x 256 bits destinée à fournir à la puce un moyen d'envoyer des valeurs de sortie prédéfinies vers la circuiterie externe. Comme représenté sur la figure 13, 12 bits sortent de la puce vers le monde extérieur pour être utilisés dans l'interfaçage avec les circuits externes. Les quatre autres bits de chaque mot sont des bits à "usage interne" utilisés pour commander les fonctions de la puce. La mémoire RAM à sorties programmables 104 permet au compilateur de définir des valeurs de sortie "en boîte" pour une sortie à des temps spécifiés à l'intérieur d'un cycle d'horloge émule. Il existe 256 adresses qui sont séquencées en ordre selon l'horloge d'émulateur. Il y a quatre fois autant d'emplacements de mot dans la RAM 104 qu'il y a d'emplacements de mot de donnée dans la donnée de commande 102 du fait que la puce permet aux cycles de données de commande d'être étendus d'une durée allant jusqu'à trois cycles additionnels. Ainsi, chacun des 64 mots de commande peut être maintenu sur les lignes de sortie de la donnée de commande 102 pendant une durée allant jusqu'à quatre cycles. Entre-temps, les emplacements d'adresse de la RAM 104 sont encore incrémentées. Ceci permet aux valeurs provenant de la RAM d'être sorties à l'intérieur d'un cycle de mot de commande lorsque le mot de commande est en cours d'extension. La vitesse à laquelle la RAM 104 est séquencée, en utilisant le présent exemple, est de 64 MHz. Les blocs fonctionnels 106-112 forment le coeur de la capacité de routage et de traitement de la puce. Ces blocs sont décrits en détail cidessous. Essentiellement, les blocs 106-110 assurent la capacité de multiplexage et de registre à décalage/stockage pour des valeurs variables qui sont fournies aux HLU 112 pour traitement. Le bloc fonctionnel 112 comporte 8 unités logiques, chacune consistant en puces Processeur Logiques Hydra avec quatre sorties, pour un total de 32 sorties. Ces sorties provenant des 8 unités logiques internes sont incluses comme entrées au sélecteur 3:1 (114). Les autres entrées du sélecteur 3:1 (114) comprennent des signaux de la face arrière (désignée par Bplane in) via des sélecteurs 32:1 (112). Ceci permet à n'importe lequel des 32 signaux de face arrière d'être route vers n'importe laquelle des entrées du sélecteur 3:1 (114). Les signaux de face arrière sont des signaux inter-cartes. Le modèle au niveau carte du système d'émulation logique est décrit ci-dessous en référence à la figure 19. Le troisième jeu d'entrées vers le sélecteur 3:1 (114) provient de la mémoire 124. La mémoire 124 est connectée à la sortie du sélecteur 3:1 (114) pour permettre au système d'émulation d'émuler une mémoire RAM, ou des mémoires RAM multiples, dans le modèle de circuit de l'utilisateur. Les sorties du sélecteur 3:1 (114) sont fournies au sélecteur 2:1 (120) et aux paves de broches dans la puce. Le sélecteur 2:1 (120) agit pour retourner les signaux vers les entrées des HLU via l'agencement de routage des blocs 106-110. Ainsi, le sélecteur 3:1 (114) permet au système de choisir à partir de trois sources de signaux séparées à délivrer vers les puces à la fois à l'intérieur et à I'extérieur de la puce sur laquelle la fonction processeur du système d'émulation de la présente invention est fabriquée. Dans un mode de réalisation préféré, la mémoire 124 est une mémoire RAM de 4K x 32 bits. La mémoire RAM est adressée à partir des signaux générés par les HLU locales à la puce, et externes à la puce, via la face arrière. Un ou plus d'un bits de l'adresse peuvent être obtenus, et stockés pour utilisation à chaque cycle d'émulateur. L'adresse est construite et verrouillée par morceaux sur un ou plusieurs cycles de manière que le système ait une grande souplesse dans l'émulation de la logique d'adresse dans le modèle de circuit en train d'être émule. Les structures pour le verrouillage et l'application de I'adresse ne sont pas représentées sur la figure 13. Les valeurs de données pour la mémoire RAM sont obtenues à partir des sorties des HLU, à partir de la face arrière, ou à partir de la RAM elle-même. Le registre 116 assure le stockage des valeurs de sortie à partir des HLU de manière qu'elles puissent être retardées d'un cycle d'émulateur ou plus. Le fait que ce sont les valeurs variables courantes ou les valeurs variables stockées à partir du registre 116, qui sont sorties est déterminé par un bit 118 de mode unique attaché à la ligne de commande du sélecteur 2:1 (120). Le bit 118 de mode unique est obtenu à partir des quatre bits à "usage interne" de la RAM 104 décrits ci-dessus, ainsi il peut être changé à chaque cycle d'horloge d'émulateur. Les sélecteurs 32:1 (126), les portes ET (128) et la mémoire RAM 130 permettent aux signaux provenant des HLU d'être sélectivement sortis sur la face arrière pour une utilisation par les processeurs sur d'autres cartes. Les signaux sont placés sur le bus de face arrière en utilisant des circuits d'attaque à collecteur ouvert de manière que les signaux provenant de chaque puce soit effectivement soumis à une opération logique OU "câblée" sur la face arrière. La RAM 130 est chargée par le compilateur et est utilisée pour valider les signaux spécifiques appliqués sur la face arrière à chaque cycle d'horloge émule étant donné que chacun des mots de commande utilisés dans la RAM est adressé consécutivement une fois à chaque cycle d'horloge émulé. Les sélecteurs 32:1 (132) sont utilisés conjointement avec les circuits d'attaque134 et la RAM 136 pour émettre des signaux de commande de point d'arrêt. La mémoire RAM fonctionne de manière similaire à la RAM 130 en ce qu'elle est chargée par le compilateur en tant que partie du programme d'émulateur et que son adresse est incrémentée une fois tous les cycles d'horloge émulés. Les points d'arrêt sont implémentés en faisant évaluer par les HLU des équations pour vérifier les états des signaux (c'est-à-dire variables) et, sur détection de la combinaison souhaitée, délivrant un signal haut qui est sélectionné par le sélecteur 32:1 (132). Le sélecteur 32:1 (132) est commandé comme le sont les autres sélecteurs de la figure 13 sauf le sélecteur 120, par des signaux de commande provenant de la donnée de commande 102. Le routage et le traitement des blocs 106-112 est décrit ci-après en détail. 1. Routage Les blocs fonctionnels 106-112 sont le coeur du routage et du traitement de la Puce Hydra 100. Etant donné que les puces reposent sur des cycles d'émulateur multiples par cycle émulé, il est crucial que les données puissent être rapidement et aisément routées entre les divers processeurs locaux et distants (c'est-à-dire sur puce et hors puce) de manière que plusieurs itérations du traitement des données avec les mêmes unités logiques (décrites ci- dessous) puissent être accomplies avec efficacité. Sur la figure 13, 256 sélecteurs 48:1 sont utilisés pour choisir parmi 32 lignes de signaux internes et 352 lignes de signaux externes. Les 32 lignes de signaux internes sont alimentées en retour à partir des sorties des 8 HLUs 112 tandis que les 32 lignes de signaux externes proviennent de 11 processeurs externes, chacun étant identique au diagramme de la figure 13, pour fournir 11 x 32 = 352 signaux. Ainsi, le nombre total de signaux entrant dans les 256 sélecteurs 48:1 (106) est de 352 + 32 = 384. Chacun des 384 signaux est réparti vers 32 entrées dans les 256 sélecteurs 48:1. De ce fait, le nombre total d'entrées dans le groupe des sélecteurs 48:1 est de 32 x 384 = 12 228. Les sélecteurs 48:1 délivrent 256 signaux aux 256 registres à décalage 108. Le routage s'effectue un-à-un avec chaque sortie de sélecteur 48:1 alimentant une entrée de registre à décalage unique à 64 étages ou 64 bits. On se réfère à la combinaison du sélecteur 48:1 et du registre à décalage comme à un "tuyau". Chaque étage de chaque registre à décalage est délivré de manière que le nombre de sorties du groupe de registres à décalage soit de 64 x 256 = 16 384 sorties. Les 16 384 sorties sont fournies aux 128 sélecteurs 1K:1. Les sorties des sélecteurs 1K:1 sont envoyées au 8 HLU 112. Chaque HLU reçoit les sorties de 16 sélecteurs 1K: 1. La figure 14 montre un diagramme développé du routage des blocs 106-112. Sur la figure 14, 384 signaux en 150 sont fournis aux tuyaux en 154. Les interconnexions entre les 384 signaux et les tuyaux sont en 152. Un schéma d'interconnexion préféré distribue chacun des 384 signaux à 32 entrées différentes des sélecteurs 48:1. L'interconnexion décrite permet de router chaque signal à 16 paires de registres à décalage 64 bits. Les paires sont séparées de manière que les sortances des signaux d'entrée aient le plus faible chevauchement possible. Les connexions exactes sont montrées dans la demande de brevet des Etats Unis d'Amérique N Serial 08/496 239 intitulée " Emulation System Having Multiple Emulator Clock Cycles Per Emulated Clock Cycle and Improved Signal Routing (Système d'émulation ayant des cycles d'horloge d'émulateur multiples par cycle d'horloge émulé et un routage amélioré des signaux)", déposée par Chilton et al. le 28 juin 1995, citée ici à titre de référence. Les connexions entre tuyaux en 154 et sélecteurs en 158 sont telles que des groupes consécutifs de 8 sélecteurs 1K:1 reçoivent les mêmes 1024 sorties à partir d'un groupe de 16 registres à décalage. Par exemple, dans le premier groupe de 8 sélecteurs 1K:1 (sélecteurs 0-7), chaque sélecteur reçoit les mêmes 1024 sorties des registres à décalage 0-15. Dans le groupe suivant de 8 sélecteurs 1K:1 (sélecteurs 8-15), chaque sélecteur reçoit les mêmes 1024 sorties à partir des 16 registres à décalage suivants (numéros de registres à décalage 16-31) et ainsi de suite. Les connexions en 160 entre les sélecteurs 1K:1 en 158 et les HLU en 162 sont assignées en prenant seize des sélecteurs 1K:1 modulo 16. Par exemple la HLU 0 est connectée aux sélecteurs 1K:1 0, 16, 32, 48,...,. 112. La HLU 1 est connectée aux sélecteurs 1 K:I 1,17, 33, 49,.... 113. La figure 15 montre plus de détails de la circuiterie des blocs fonctionnels 106 et 108 de la figure 13. Spécifiquement, la figure 15 montre l'inclusion d'un registre à décalage "masque" 180, un sélecteur 64:1 (182) et d'un sélecteur 2:1 (184). Le sélecteur 48:1 186 et le registre à décalage 188 sont les mêmes composants décrits ci-dessus et montré sur la figure 13 en 106 et 108, respectivement. L'utilisation du registre à décalage "masque" 180 procure des avantages distincts concernant la capacité du système d'émulation de la présente invention à gérer les éléments logiques tels que les bascules o l'état de l'élément logique qui a été calculé au cours du cycle d'horloge émulé courant n'est pas requis en tant qu'entrée vers d'autres éléments logiques jusqu'au cycle d'horloge émulé suivant. Le registre à décalage 188 est utilisé pour stocker les résultats des calculs dans chacun des 64 (maximum) étages dans le programme d'émulation. Cependant, un cas particulier survient lorsque, par exemple, une sortie de bascule, ou un quelconque autre signal "enregistré", n'est pas requis jusqu'au cycle suivant. Ces signaux enregistrés ne doivent pas être mis à jour pour l'utilisation jusqu'à la fin du cycle d'horloge émulé courant. Ainsi, le registre "masque" est utilisé pour stocker les valeurs de ces types de variables enregistrées à partir du moment o ils ont été générés jusqu'au moment o ils sont requis en tant qu'entrées vers des fonctions logiques. A la fin du cycle de programme, c'est-à-dire après que tous les pas du programme ont été exécutés pour le cycle courant, les valeurs à partir du registre à décalage masque 180 sont copiées dans le registre à décalage 188 de manière que les nouvelles valeurs pour ces variables enregistrées soient disponibles pour une utilisation en tant qu'entrées vers le cycle de programme suivant. La copie est effectuée en chargeant le registre à décalage 188 avec les sorties parallèles du registre à décalage masque 180. Ceci permet un routage indépendant du temps de tous les signaux "enregistrés" par l'émulateur étant donné que les signaux ne sont pas requis jusqu'au cycle de programme suivant. Comme on peut le voir sur la figure 15, les valeurs à partir du sélecteur 48:1 186 sont routées à la fois vers le registre à décalage masque 180 et, sélectivement, vers le registre à décalage 188 via le sélecteur 2:1 184. Là o la valeur à partir du sélecteur 48:1 186 est une valeur enregistrée, la variable enregistrée est copiée vers le registre à décalage masque 180, seulement, et non pas vers le registre à décalage 188. En revanche, le registre à décalage 188 reçoit une valeur à partir du sélecteur 64:1 182 qui est générée pendant le cycle de programme précédent de manière que toutes variables enregistrées qui changent au cours du cycle de programme courant ne sont pas mises à jour jusqu'au cycle de programme suivant. Le sélecteur 64:1 182 permet aux valeurs émanant de n'importe quel emplacement à l'intérieur du registre à décalage 188 d'être routées en retour vers l'étage 0 du registre à décalage. Ceci permet un accès flexible aux valeurs variables qui sont calculées à l'intérieur d'un cycle de programme. La sélection de variable à travers le sélecteur 64:1 182 s'effectue par les six lignes de commande montrées comme étant connectées au sélecteur 64:1 182 et qui sont commandées à partir de la donnée de commande. D'autres signaux de commande tels que les cinq lignes de multiplexeur (MUX) d'entrée vers le sélecteur 48:1 186 et la ligne de commande unique vers le sélecteur 2:1 184 également issue de la donnée de commande. 2. Traitement Ensuite, les figures 16 et 17 sont décrites pour illustrer des détails des unités logiques Hydra utilisées pour le traitement dans le système d'émulation de la présente invention. La figure 16 montre un diagramme développé de la logique dans le bloc 112 de la figure 13. Sur la figure 16, une ou 8 HLU sur la puce sont montrées. Seize entrées à partir de 16 des sélecteurs 1K:1 entrent dans la HLU en 202. Les signaux inversés sont également fournis de manière qu'un total de 32 signaux soit représenté par la ligne en ombre foncée. Les 16 signaux sont couplés par des inverseurs et des portes de passage, également appelés "mots d'entrée", 11 étant représenté à échelle agrandie et plus en détail sur la figure 17, vers les portes OU 206-212. Chacun des 16 signaux peut être passé par chacun des lecteurs d'entrée de manière que n'importe lequel des signaux puisse être appliqué à n'importe laquelle des entrées des portes 206-212. Il faut noter que chacune des lignes vers les portes OU est équipée d'une porte NI (NOR) telle que la porte NI 214 de manière que chaque entrée vers les portes NI puisse être sélectivement invalidée par l'application d'un signal zéro ou bas. Les portes NI 206-212 sont utilisées pour calculer les termes de somme- de-produits pour résoudre les équations booléennes qui émulent les fonctions du modèle de circuit de l'utilisateur. Le compilateur convertit le modèle de circuit utilisateur en équation booléenne qui sont ensuite convertis en pas de programme multiples. Les pas de programme sont chargés dans l'architecture d'émulation sous la forme de mots de microcode dans la donnée de commande 102 de la figure 13 et de signaux de commande dans diverses mémoires RAM de sélection à travers le système. A ce propos, le système de la présente invention est similaire au système de la demande de brevets des Etats-Unis d'Amérique n 08/242 164 en cours. * En revenant à la figure 16, la logique d'émulation de registre 220 est fournie à la sortie de chacune des portes OU. La logique d'émulation de registre 220 fournit des signaux de commande spécialisés pour permettre à l'émulateur de gérer l'émulation d'éléments séquentiels, tels que des registres et des bascules, de manière efficace. Des signaux tels que "Reset", "Preset, 11 "Clock et "IQ-111" représentent des signaux de leurs contreparties bien connus dans les dispositifs séquentiels classiques. Ces signaux sont obtenus à partir des seize signaux d'entrée et leurs signaux inversés en utilisant les sélecteurs 34:1 comme représentés, par exemple, en 222. Il faut noter que les sélecteurs 34:1 permettent à un signal haut ou bas d'être sélectionnés en plus des seize signaux d'entrée et leurs inversions. Le signal "Q-1" est normalement la valeur précédente de ce qui a été stocké dans un registre en cours d'émulation. Le bit de commande inverse de la logique d'émulation de registre 220 permet l'inversion du signal de donnée selon la donnée de commande. Les signaux de commande P/R déterminent si une initialisation ou une réinitialisation commandera lorsque à la fois une initialisation et une réinitialisation surviendront au même moment. Les lignes de commande P/R sont couplées pour commander la RAM comme le sont les deux bits de commande vers le sélecteur 2:1 de la logique d'émulation de registre 220.Le sélecteur 2:1 assure un contournement de la logique d'émulation de registre lorsqu'elle n'est pas requise. La figure 18 représente plus en détail dans le bloc fonctionnel 124, la mémoire d'émulation de la figure 13. La circuiterie de la mémoire d'émulation constitue un moyen efficace pour les valeurs générées à partir des HLU à stocker et utiliser dans l'adressage de la mémoire d'émulation. Il faut noter que le sous-système d'analyse logique 202 est couplé au bus 384 bits d'une manière similaire aux puces de l'émulateur. La figure 19 représente une configuration au niveau carte de douze puces processeur Hydra et une partie du sous-système d'analyse logique. La figure 19 inclut une face arrière 250 qui peut loger des cartes similaires additionnelles. Les dispositifs (162 652) sont des émetteurs- récepteurs de registre tandis que les dispositifs (74FB2033) sont des émetteurs-récepteurs d'interface de face arrière. Résumé Les modes de réalisation décrits de la présente invention permettent à l'utilisateur de définir des points d'arrêt, des déclencheurs, et des événements de notification en utilisant n'importe lequel des signaux d'entrée et de sortie disponibles à partir de l'émulateur via le bus 384 bits. De plus, le sous-système d'analyse logique implémente des circuits compilés additionnels qui reconstruisent des signaux "perdus" ou "réduits" au cours de la phase de compilation. Ces signaux peuvent également être utilisés pour définir des points d'arrêt, des déclencheurs, et des événements de notification, Enfin, le sous- système d'analyse logique est connecté à une station de travail ou un contrôleur similaire externe via un bus connu de manière que le contrôleur puisse influer sur le fonctionnement du sous-système d'analyse logique pendant l'émulation. D'autres modes de réalisation seront évidents à l'homme de l'art en regard de la description et de la mise en pratique de l'invention décrite ici. Il va de soi que la description et les exemples sont à considérer à titre purement illustratif, la portée réelle de l'invention étant définie par les revendications ci- après. ANNEXE A // // Contrôleur d'analyse (de dépistage) // Commande la lecture et l'écriture de la mémoire RAM d'analyse // // define SELVERSION 3'hO define SEL CTL 3'hl define SEL ADDR CNTR 3'h2 define SELADDRCNTR SAVE 3'h3 define SEL_RESETADDRCNTR 3'h4 module trc_ctl( a, // adresse hôte verrouillée à partir de bus_pld d, // bus de données hôte ds, // sonde de données hôte sel, // adresse hôte [23:20] = lXXX mclk, // trc contrôleur clk resetb, // remet tous les registres à O wr, // écrire à partir de l'hôte hydrahout, // données de hydra à stocker dans ram hydra_ep, // valider étape trc, prog[ll:8] pmode, // l=hydrahout est chainé,0=hydra_hout n'est pas chaîné 1 tr en,_ // valider trc local ctren, // valider trc châssis g_tren, // valider trc global tcyc_end, // fin cycle utilisateur trc thrun, // indique quand les hydras tournent emul_th, // 1 = mode émulation, O = mode configuration then, // valider trc hydra; non utilisé run, // non utilisé strap, // sélectionner FPGA trcctl dtack_in, // dtack à partir autre FPGA bogus_out, // sortie logique fantoche pour entrées non utilisées dtack, // dtack vers buspld trc_done, // interruption vers bus_pld ram io, // bus données ram ram_addr, // compteur adr(esse) ramaddr2, // adresse à partir de hôte ram_cs0b, // sélection banque a[18] ou compteur_adr [16]=0 ram cslb, // sélection banque a[18] ou compteur adr [16]= 1 ram_oeb, // O=lecture, l=écriture ram_adscb, // sonde adr ram wb // valider écriture input (23:0] a; inout [31:0] d; input ds; input sel; input mclk; input resetb; input wr; input (31:0] hydra_hout; input [3:0] hydraep; input pmode; input 1 tren; input ctr_en; input g_tr en; input tcyc_end; input thrun; input emul_th; input th_en; input run; input strap; input dtack in; output bogus out; output dtack7 output trc_done; inout [31:0] ram io; output [15:0J ram-addr; output [15:0] ramaddr2; output ram csOb; output ramcslb; output ram_oeb; output ram_adscb; output ramwb; reg early_dtacklp; reg dtack; req 131:0] dinp; reg doutstrobep; reg doutstrobe_2p; reg doutstrobe_3p; reg [31:0] dout, reg [31:0] dout_raw; reg (7:0] ctl_reg; reg [3:0] hydra_ep_p; reg [3:0] hydra_ep_pl; reg tcycendp; reg tcyc_end_2p; reg tcyc_end_3p; reg th_run_p; reg thrun 2p; reg thrun_3p; reg thrun_4p; reg th_run_Sp; reg th_run_6p; reg th run_7p; reg th_run-8p; reg thr'un9p; reg th runlop; reg th_run_llp; reg thrun_4or5p; reg gatedtrcen; tri [31:0] d; tri (31:0] ram_io; tri [15:03 ramaddr; tri [15:0] ram_addr2; wire [16:0] addrcntr; wire addrcntr 17; wire [16:0] addr-cntrsave; wire addrcntrsave_17; wire [1:0] chassis _type; wire [1:0] mode_select; wire [1:0] trc step en select; wire [1:0] lcgselect; wire reset addrcntr; wire reset, wire gatedtrcstep_en; wire gated trc_stepenl; wire mux sell; wire muxsel2; wire [31:0] ram d; wire bufoe; wire early_dtack2; wire ramasb; wire ram web; wire stop; wire (2:0] lcg; wire [3:0] hydra_ep_muxout; wire [3:0] hydra_ep_muxoutl; wire dtack mux out; wire earlydtackl; /* REGISTRE DE VERSIONS */ wire [2:0] versionreg; assign version reg - 3'bO; /* Définition REGISTRE de COMMANDE */ assign chassis type - ctlreg[7:6]; assign mode seIect = ctlreg[5:41; assign trc step _en_ select = ctlreg[3:2]; assign lcgselect - ctlreg[l:0]; assign dtackmuxout strap ? early dtackl: earlydtacklp; assign lcg = {l tren, c tren, g_tr_en); assign hydra_ep_muxout - pmode ? hydra ep_p: hydraep; assign hydra_ep_muxoutl = pmode ? hydra ep_pl: hydra_ep; assign gatedtrcstep_en - hydra_ep_muxout[trcstepen select] &th_run_4or5p && emul th; assign gated trcstep_enl hydra_ep_muxoutl[trc_stepenselect] && thrun_4or5p && emul th; assign reset - Tresetb; assign ram addr - mux sell ? addr cntr[15:0]: 16'bz; assign ramaddr2 mux-sel2 ? a(17.2]: 16'bz; assign ramd - mux-sel2 ? dinp: hydra hout; assign ram_io - bufoe, ? ram _d: 32'bz; // lignes jusqu'à données 1 cycle plus tard que dtack assign d[31:0] = (doutstrobe_3p &&!wr) ? dout[31:0]: 32'bz; assign resetaddrcntr = a(21] && wr && early dtack2 && (a(4:2] == SEL RESET ADDR CNTR); assign ram cs0b - mux sel2 ? a[18]: addr cntrl[16]; assign ramcslb e mux sel2 ?!al18]:!addr_cntr[16]; assign ramadscb - muxsel2 ? ram asb:! (gatedtrc_step_enl && !stop); assign ramwb - muxsel2 ? ramweb:! (gated_trc_step enl && !stop); assign bogus_out = a(23] Il &a[20:19] Il &a(l1:0] Il run; rw rw0(mclk, reset, ds, !(sel && (a[22] =- strap)), wr, a[21], mux_sell, muxsel2, doutstrobel, dout-strobe2, dout strobe3, doutstrobe4, early_dtackl, earlydtack2, bufoe, ramweb, ram oeb, ramasb); trc sm trcsmO(mclk, reset, resetaddr cntr, gated_trcstepen, gatedtrc_en,- tcyc_end_3p, addr cntr, addr_ cntr 17, addr cntr save, addrcntr save 17, trc done, mode-select, stop, a, wr, early_dtack2, dln_p); always @(posedge mclk or posedge reset) begin if (reset) begin dtack ) // synopsys parallel case 3'bxxl: crc done ≤ 1; //single fill- 3'bOOO: trc done ≤ (stop && tcyc end 3p && (seentrcen Il gatedtrC_en]); //wrap around 3'bOlO: trc_done ≤ (seentrc en twice Il (seentrcen && gatedtrcen)) && tcyc end_4p; //sngl fill int 3'blOO: trc done ≤ (seen trc en Il gatedtrc_en) && tcyc_end_3p; 3'bllO: trc-done ≤ O; endcase end end endmodule // // Machine d'état lecture/écriture hôte // module rw(mclk, reset, ds, csb, wr, reg_ormemN, mux sell, muxsel2, dout strobel, doutstrobe2, doutstrobe3, dout strobe4, early_dtackl, early dtack2, bufoe, ramweb, ramoeb, ram_asb); input mclk; input reset; input ds; input csb; input wr; input reg or memN; // a(21] output mux-sell; output muxsel2; output dout strobel; output dout strobe2; output doutstrobe3; output dout strobe4; output earlydtackl; output early dtack2; output bufoe; output ram web; output ramoeb; output ram-asb; parameter RWIDLE = 3'hO, RW READ = 3'hl, RWREAD2 = 3'h2, RW READ3 = 3'h3, RW WRITE = 3'h4, RW WRITE2 = 3'h5, RWWRITE3 = 3'h6; reg (6:0] rwstate; reg muxsell; reg mux-sel2; reg dout strobel; reg dout strobe2; reg dout strobe3; reg doutstrobe4; reg early_dtackl; reg early_dtack2; reg bufoe; reg ramweb; reg ram -oeb; reg readasb; reg [6:0] nextrwstate; reg next muxsell; reg nextmuxsel2; reg next doutstrobe; reg nextearly_dtack; reg next bufoe; reg next ram web; reg next ram oeb; reg next-read asb; assign ramasb = readasb && ramweb; always e(posedge mclk or posedge reset) begin if (reset) begin rwstate 38 2764406 ANNEXE B Dimensions/Limitations Physiques: Dimension Physique 3000 x 5750 rmils2 Epaisseur carte Processeur = 123 mils Espacement Carte Processeur = 4sm = 1570 mils Epaisseur Carte Tracemem (Mémoire d'Analyse ou de Dépistage) = 62 mils Comp le plus élevé sous carte Tracemem = 80 (comp) + 240 (hsink)= 320 mils Distance de la surface de la carte processeur à la surface de la tracemem = 738 mils - Comp le plus élevé sur l'autre carte processeur opposée à la tracemem = 200 mils - Dégagement en dessous de la carte tracemem: 738 - 320 = 418 mils - Dégagement au- dessus de la carte tracemem: 1570 -123 -738 -62 -200 = 447 mils - Taille 7C1032 = 761 x 761 mils - Taille QL24x32B = 1214 x 1214 mils Notes: - Trace (Hydra TH) (Trace= d'analyse ou dépistage) 12 reçoit les sorties des Hydras suivantes: 0, 1,2, 13,5,6,7,8,9, 10, 11 - Trace Hydra (Trace= d'analyse ou dépistage) 13 reçoit les sorties des Hydras suivantes: 0,1,2,3,4,5,6, 12,9, 10,11 - Les sorties des TH 12 vont aux entrées de TH13 (et vice versa) si bien que TH13 peut obtenir l'accès aux sorties de LH 7 et LH 8 auxquelles elle n'est pas directement connectée. Ceci est nécessaire pour générer la condition de Point-d'Arrêt (Valider Analyse). - De multiples morceaux de 32 bits peuvent être analysés dans un cycle utilisateur (par Trace Hydra) Les bits sont disponibles à des tranches de temps différentes at à des positions binaires différentes. Il revient à la Trace Hydra de collecter ces bits dans un mot de 32 bits et de confirmer à TRACE_STEPEN d'enregistrer ce mot dans la mémoire SRAM. - La relation entre TRACE_EN, TRACE_STEP_EN, et TCYC_END dans un cycle utilisateur est décrite ci-dessous: TRACE EN /^\ TRACE STEP EN /"\ /"\ /"\ /"\ TCYC_END ' ^ __ TRACE_EN est long d'un cycle d'horloge et peut être affirmé à tout endroit dans le cycle utilisateur. Ici, TRACE_STEP_EN montre qu'il y a 4 mots de 32 bits en cours de stockage dans la SRAM. Ce nombre n'a pas besoin d'être le même pour chaque Trace Hydra. Le compteur d'adresses dans le FPGA (réseau de portes programmable) est incrémenté chaque fois que l'on voit un TRACE STEP_EN. TCYC_END indiquait la fmin d'un cycle utilisateur. Si TRACEEN avait été affirmé dans ce cycle utilisateur, alors on aurait voulu sauvegarder 4 mots, sinon on veut rétracter le compteur. - Implémentation du Compteur d'Adresses: 39 2764406 r----- -- -- ------------ - -_--___--__-_-____-________---_ I t I I _ __ _ _____ E _ ________ I. I REG CTR '.....> VersADDR RAM CP, cP Cas 1: Stocker données pour ce cycle utilisateur - Si on obtient TCYC_END et on a vu TRACEEN dans ce cycle utilisateur alors REG ≤ CTR; Cas 1: Ne pas stocker données pour ce cycle utilisateur - Si on obtient TCYC_END et on n'a pas vu TRACE_EN dans ce cycle utilisateur alors CTR ≤ REG; - Mappe des Adresses A22 = Choisir Puce (ce bit est comparé avec le STRAP; la puce répond si A22=STRAP). Ceci est utilisé pour différencier les 2 FPGA sur la carte SRAM d'analyse (Trace SRAM). A21 = Choisir Espace Adressage Mémoire/Registre 0 signifie mémoire et 1 signifie registre A20:A2 = Entités d'adresses à l'intérieur de l'espace d'adressage au dessus. Notez qu'on a IMmot d'espace d'adressage pour la mémoire, ainsi on a besoin d'ajouter registre de fenêtre si l'on veut supporter plus de 512 Kmot de mémoire d'analyse. Al: A0 = ignorée par la puce - Adresse des Registres: (A21 = 1) A20: A0 = 0xOO Registre de Versions 3 bits R A20: A0 = 0x04 Registre de commande 8 bits R/W A20: A0 = 0x08 Compteur d'adresses 17 bits R A20: A0 = 0x0c Sauvegarde Compteur d'adresses 17 bits R A20: A0 = 0x10O Remise à 0 Compteur d'adresses 1 bit W - Remise à 0 Compteur d'adresses Une écriture avec n'importe quelle valeur à cette adresse provoque la remise à zéro du Registre de Sauvegarde Compteur d'adresses et du Compteur d'adresses. - Registre de Versions bit [2:0] RevA = 3'bO - Registre de commande - Type Châssis bit [7:6] 00 = châssis simple 00 = cluster (groupe) simple 00 = super cluster (groupe) - Registre Modes bit [5:4] -WRAP AROUNDFILL bOl Continuer de remplir la mémoire SRAM et d"'enrouler" l'adresse. Affirmer TRCDONE à la fmin du cycle utilisateur et arrêter l'analyse si TRACE EN est long de 2 cycles. - SINGLEFILL bOO Affirmer TRCDONE à la fmin du cycle utilisateur si vu TRACEEN et que SRAM est pleine. - SINGLEFILL_INT blO Ceci est utilisé s'il y a une longue pause entre 2 remplissages successifs de SRAM. Dans ce cas TRC_DONE est affirmée à la fmin d'un cycle utilisateur là o on stocke en réalité un ou des mots dans la SRAM. 2764406 - TraceStep_En Select bit[3:2] 00 - PROG(8] 01 - PROG[9] = PROGt10] 11 - PROG[11] - G/C/L TRACE EN select bit(l:0] 00 G TRACE EN (global) 01 - C TRACE EN (chassis) L-TRACE-EN (local) - Rythme de Lecture/Ecriture à partir de la Carte Processeur Rythme d'Ecriture SEL /A...... AA........................\ WR _... ADDR...x...A......x.A+i... DS /\ /\\ DATA c== ====== = ---====xxxxxxxx=--== ==- = -- xxxxx DTACK /^^\ /^^\ Rythme de Lecture SEL / A..........AA......AAA.AA......AAAAAA.....\ WR ADDR -=...x=.==. =..=A..=..=x==..A+ 1.=.--.--- DS /^^\ / ^^\ DATA xxxxxxxxxxxxxxxxxxxxxxx=-==xxxxxxxxxxxxxxxxxxx===-xxxx DTACK / ^^\ / \ _^ - Rythme de Lecture/Ecriture à partir du FPGA (Réseau de Porte Programnmable) vers SRAM Rythme d'Ecriture (Utiliser un seul cycle d'Ecriture initialisé par ADSC*) CLK L /.............\ / A..............\ CS*.......\ /^AA^^^AAA^^AAA ^^^^^ ADDR xxxxxxxx====--==== -=à= ==---======xxxxxxxxxxxxxxxxxxxx ADSC*......\ / A................. WH*/WL*......\ / A.................. DIN N à- x=====-= -======-=====c=xà-...... ....DTD: OE* / A........AA...AA...AAA..AAA.\ Rythme de Lecture (Utiliser un seul cycle de Lecture initialisé par ADSC*) CLK / ^^^.... \ /........ CS*.......\ /I A..A...A.......AA. ADDR xxxxxxxx-====--===-====-== -==- =xxxxxxxxxxxxxxxxxxxx ADSC* ^^^^^^\ / A................. ADV ^A^ A WH /WGAAAAAAIm. AAAAAAAA*AA AAAAAA AAAAA AA AAAAA AAAAA AAAAAA AAAAA AAA WH*/WL*^^^^^^^^^^^^^^^^............................. DOUT à----xà -------x, OE* _______________ 41 2764406 REVENDICATIONS 1. Sous-système d'analyse logique (202) couplé à un système d'émulation, le sous-système d'analyse logique (202) comprenant: des lignes d'entrée recevant des valeurs délivrées à partir du système d'émulation; au moins une puce processeur (302,304) implémentant une fonction sonde en conformité avec les signaux reçus sur les lignes d'entrée; et un contrôleur (372) commandant l'opération de la fonction sonde selon des instructions reçues à partir de la au moins une puce processeur. 2. Sous-système d'analyse logique (202) selon la revendication 1, dans lequel la puce processeur (302,304) comporte: des circuits logiques configurables pour implémenter une circuiterie afin de reconstruire des signaux qui ont été réduits au cours d'un processus de compilation, la reconstruction étant effectuée en conformité avec les signaux reçus sur les lignes d'entrée. 3. Sous-système d'analyse logique (202) selon la revendication 1, dans lequel la puce processeur (302,304) comporte: des circuits logiques configurables pour implémenter une circuiterie afin d'activer un signal de sonde, le signal de sonde étant fixé en conformité avec les signaux reçus sur les lignes d'entrée. 4. Sous-système d'analyse logique (202) selon la revendication 1, dans lequel le contrôleur (372) comporte une interface (356) vers une station de travail (101) externe pour recevoir des commandes à partir de la station de travail. 5. Sous-système d'analyse logique (202) selon la revendication 1, dans lequel le contrôleur (372) comporte une interface (356) vers une station de travail (101) externe pour envoyer des données de la mémoire vers la station de travail. 6. Sous-système d'analyse logique (202) selon la revendication 1, dans lequel la puce processeur (302,304) comporte: 42 2764406 des circuits logiques configurables pour implémenter une circuiterie afin d'activer un signal de point d'arrêt en conformité avec les signaux d'entrée reçus. 7. Sous-système d'analyse logique (202) selon la revendication 1, dans lequel la puce processeur (302,304) comporte: des circuits logiques configurables pour implémenter une circuiterie afin d'activer un signal déclencheur en conformité avec les signaux d'entrée reçus. 8. Sous-système d'analyse logique (202) selon la revendication 1, dans lequel la puce processeur (302,304) comporte: des circuits logiques configurables pour implémenter une circuiterie afin d'activer un signal de point d'arrêt en conformité avec les signaux reconstruits. 9. Sous-système d'analyse logique (202) selon la revendication 1, dans lequel la puce processeur (302,304) comporte: des circuits logiques configurables pour implémenter une circuiterie afin d'activer un signal déclencheur en conformité avec les signaux reconstruits. 10. Sous-système d'analyse logique (202) selon la revendication 1, dans lequel le sous-système d'analyse logique (202) envoie un signal de notification en conformité avec un signal de point d'arrêt émanant de la puce processeur (302,304) et un signal de mémoire de dépistage pleine émanant de la mémoire dépistage. 11. Procédé de compilation d'un modèle de circuit fonctionnel de manière qu'il puisse être tracé par un sous-système d'analyse logique, le procédé effectué par un système de traitement de données, comprenant les étapes consistant à: stocker, dans une mémoire, une pluralité de signaux de sortie qui seront disponibles à partir d'un système émulateur pendant l'émulation; recevoir une description d'un signal réduit requis par le sous-système logique, le signal réduit comportant une description de la manière dont les signaux de sortie sont utilisés pour générer le signal réduit; déterminer le contenu d'un second circuit qui reçoit les signaux de sortie et génère le signal réduit en conformité avec la description du signal réduit; et 43 2764406 compiler le second circuit de manière qu'il puisse être implémenté par le sous-système d'analyse logique (202) pour reconstruire le signal réduit. 12. Procédé selon la revendication 11, comprenant de plus les étapes consistant à: recevoir une description d'un signal de sonde requis par le sous-système d'analyse logique, le signal de sonde comportant une description de la manière dont le signal réduit est utilisé pour générer le signal de sonde; déterminer le contenu d'un troisième circuit qui reçoit le signal réduit et génère le signal de sonde en conformité avec la description du signal de sonde; et compiler le troisième circuit de manière qu'il puisse être implémenté par le sous-système d'analyse logique (202) pour générer le signal de sonde. 13. Procédé de compilation d'un modèle de circuit fonctionnel de manière qu'il puisse être tracé par un sous-système d'analyse logique, le procédé effectué par un système de traitement de données, comprenant les étapes consistant à: stocker, dans une mémoire, une pluralité de signaux de sortie qui seront disponibles à partir d'un système émulateur durant l'émulation; recevoir une description d'un signal de sonde requis par le sous-système d'analyse logique, le signal de sonde comportant une description de la manière dont les signaux de sortie sont utilisés pour générer le signal de sonde; déterminer le contenu d'un second circuit qui reçoit les signaux de sortie et génère le signal de sonde en conformité avec la description du signal de sonde; et compiler le second circuit de manière qu'il puisse être implémenté par le sous-système d'analyse logique (202) pour générer le signal de sonde.