Brevet FR2947359A1 — publié le 20101231

i PROCEDE ET DISPOSITIF DE SIMULATION D'UN SIGNAL DE REINITIALISATION DANS UN SYSTEME SUR PUCE SIMULE La présente invention concerne la concerne la simulation d'un système tel qu'un système sur puce SOC (System On Chip) comportant au moins un processeur et une ou plusieurs unités périphériques interconnectées en réseau. Les systèmes sur puce SOC (System On Chip) tendent de plus en plus à regrouper dans un même circuit intégré des composants matériels tels que des coeurs de processeur hétérogènes, des circuits spécialisés, et des mémoires, ainsi qu'une architecture de communication complexe appelée "réseau sur puce" NOC, reliant entre eux ces composants. Un réseau sur io puce comporte couramment plusieurs liaisons de données point à point reliant les composants matériels du système sur puce. En raison de la complexité grandissante des systèmes sur puce, il est souhaitable de mettre en oeuvre d'outils de conception, de modélisation et de simulation permettant de tester un système à différentes étapes de 15 conception, ceci afin de pouvoir valider le système à chacune de ces étapes. Généralement le développement d'un système complexe tel qu'un système sur puce commence par une étape de définition de spécifications écrites en langage informel. Vient ensuite une étape de définition ou de sélection d'algorithmes permettant de répondre aux spécifications. Les 20 algorithmes peuvent être définis à l'aide d'un langage de haut niveau tel que Matlab ou C++. La définition des algorithmes permet de passer à une étape de définition de modèles d'un premier niveau d'abstraction appelé "niveau transactionnel" TLM (Transaction Level Model) décrivant une architecture et donc spécifiant une répartition entre matériel et logiciel (définition des 25 composants matériels et des logiciels exécutés par les composants matériels). Le niveau transactionnel peut regrouper des modèles fonctionnels PV (Programmer View) et des modèles temporisés PVT (Programmer View + Timing). Un modèle fonctionnel permet par exemple de simuler un logiciel embarqué dans un composant matériel du système. Dans 30 un modèle fonctionnel, les transferts de données entre les composants matériels peuvent être simulés par un canal de communication unique idéal, c'est-à-dire non limité en débit. Les modèles temporisés permettent d'évaluer de manière précoce un choix d'architecture et de répartition de traitements entre matériels et logiciels. Des contraintes temporelles à respecter par les composants matériels du système sont induites par un choix de taille de mots transportés et de débit de canaux de communication. Un modèle du niveau transactionnel peut être défini à l'aide d'un langage de modélisation de systèmes matériels tel que SystemC, permettant de représenter des composants matériels par des modules qui sont reliés entre eux par des ports connectés à des canaux de communication. Les comportements des io composants matériels et des logiciels sont décrits par des modules logiciels écrits en un langage de programmation tel que C++ et exécutables par un simulateur. SystemC est un langage de description de matériel et de logiciel faisant l'objet du standard IEEE 1666-2005 développé par l'Open SystemC Initiative (OSCI). Tous les composants matériels et logiciels d'un système 15 peuvent ainsi être modélisés à l'aide de SystemC, quels que soient leur nature et leur niveau d'abstraction. Une étape de développement suivante consiste à ajouter la notion d'horloge pour créer un modèle à la précision du cycle BCA (Bus Cycle Accurate) précisant le comportement du système à chaque cycle d'une 20 horloge cadençant le système. Vient ensuite une étape de définition du niveau transfert de registre RTL (Register Transfer Level) qui permet ensuite une synthèse rapide et efficace d'un circuit intégré. Le niveau RTL définit la valeur de chaque bit à chaque coup d'horloge à l'aide d'un langage tel que VHDL ou Verilog. Le niveau RTL permet ensuite de définir des réseaux de 25 portes logiques qui peuvent être traités par des outils de placement et de routage pour obtenir une structure à deux dimensions qui sert de base à la réalisation de masques de fabrication d'un circuit intégré. Les niveaux d'abstraction TLM, BCA et RTL permettent une étude approfondie des performances d'une architecture de système bien avant la 30 mise en oeuvre du système et son implantation dans un circuit intégré. Toutefois, les outils de simulation existants ne permettent de simuler la propagation d'un signal de réinitialisation (reset) dans un système sur puce simulé qu'au niveau d'abstraction RTL. Il est pourtant souhaitable de pouvoir analyser la propagation et le traitement d'un signal de réinitialisation 35 dans tout ou partie d'un système simulé dès le niveau d'abstraction TLM. Plus précisément, un système est modélisé au niveau d'abstraction TLM, par des composants ou modules imbriqués et/ou des processus. Les modules communiquent entre eux par ports qui peuvent être interconnectés par des canaux. Un module peut comprendre un ou plusieurs ports constituant des points d'entrée et/ou de sortie du module. Un port est associé à une ou plusieurs interfaces constituées d'une déclaration de fonction (ou méthode dans la terminologie C++) qui peut être appelée par le module auquel appartient le port ou d'autres modules reliés au port par un canal. Les canaux sont des moyens de communication entre les modules. Ils io peuvent modéliser aussi bien de simples signaux que des moyens de communication plus complexes et ainsi comprendre d'autres canaux ou même des modules. Les canaux contiennent le code C++ des fonctions des interfaces des ports. Les modules peuvent comprendre des méthodes, des processus et d'autres modules. Les méthodes comprennent des fonctions 15 qui sont exécutées à l'initialisation du système ou lors de l'arrivée d'un événement par exemple sur l'un des ports du module. Les processus (threads) décrivent une fonctionnalité du système ou un comportement et sont activés exclusivement par le simulateur lors de l'apparition d'événements particuliers. Les processus sont lancés une seule fois par 20 exemple à l'initialisation du système et comprennent une boucle infinie avec une ou plusieurs instructions d'attente d'un événement. Si un processus se termine, il ne s'exécute plus. Le simulateur comprend un noyau assurant notamment la notification d'événements, et l'activation des méthodes et des processus. 25 La simulation d'un signal de réinitialisation implique de pouvoir arrêter les processus et de réinitialiser les méthodes et les processus. Or un simulateur tel que systèmeC ne permet uniquement d'initialiser un système entier, c'est-à-dire de relancer l'ensemble d'une simulation. Il n'est donc pas possible de simuler une réinitialisation partielle d'un système. II n'est pas non 30 plus possible de tester une partie du système à un niveau d'abstraction plus détaillé ou un logiciel embarqué dans un composant du système, pendant une réinitialisation car une réinitialisation nécessite d'arrêter complètement une simulation. II est donc souhaitable de pouvoir simuler un signal de réinitialisation 35 partiel et son traitement dans un système simulé au moins en partie au niveau d'abstraction TLM, et ce sans modifier le noyau du simulateur. Il est également souhaitable de pouvoir réinitialiser certains processus internes à des modules. II est aussi souhaitable de pouvoir simuler plusieurs signaux de réinitialisation agissant sur des parties différentes d'un système. Un mode de réalisation concerne un procédé de simulation d'un signal de réinitialisation dans un système modélisé comprenant un module de contrôle de réinitialisation et un module à réinitialiser, le procédé comprenant des étapes d'émission par un processus de contrôle du module de contrôle d'un signal de réinitialisation, et de réception par le module à io réinitialiser du signal de réinitialisation. Selon un mode de réalisation, le procédé comprend des étapes consistant à : réveiller un processus du module à réinitialiser, en attente d'un signal de réinitialisation, si le processus du module à réinitialiser est réveillé par le signal de réinitialisation, lever une exception de réinitialisation par le processus du module à réinitialiser, et si 15 une exception de réinitialisation est levée, mettre le processus du module à réinitialiser en attente d'un signal de redémarrage, émettre le signal de redémarrage par le processus de contrôle, qui est transmis au module de contrôle, et à la suite de la réception par le module à réinitialiser du signal de redémarrage, activer le processus du module à réinitialiser, qui s'exécute et 20 se met en attente du signal de réinitialisation. Selon un mode de réalisation, le procédé comprend des étapes consistant à : déclarer une méthode du module à réinitialiser, sensible au signal de réinitialisation, à la suite de la réception par le module du signal d'initialisation, déclarer la méthode à réinitialiser sensible au signal de 25 redémarrage, et à la suite de la réception par le module du signal de redémarrage, exécuter la méthode et la déclarer sensible à un signal de réinitialisation. Selon un mode de réalisation, le procédé comprend une étape d'exécution d'une fonction d'initialisation du module, à la suite de la 30 réception par le module du signal d'initialisation. Selon un mode de réalisation, chaque processus du système est inséré dans une boucle sans fin comprenant une instruction d'attente du signal de réinitialisation, suivie d'une instruction de levée d'une exception de réinitialisation, d'une instruction d'entrée dans une procédure de traitement 35 d'exception comprenant une instruction d'attente du signal de redémarrage. Selon un mode de réalisation, le procédé comprend une étape de remplacement d'une instruction d'attente dans un processus par une instruction d'attente, suivie d'une instruction de levée de l'exception de réinitialisation exécutée si le signal de réinitialisation a été reçu par le module auquel appartient le processus. Selon un mode de réalisation, le procédé comprend une étape d'ajout dans une liste d'événements d'une instruction de définition d'une liste d'événements activant l'exécution de la méthode, d'un événement de réception du signal de réinitialisation par le module auquel appartient la méthode. Selon un mode de réalisation, le procédé comprend l'émission dans io le système d'un premier signal de réinitialisation pour réinitialiser une partie des modules du système, et l'émission dans le système d'un second signal de réinitialisation pour réinitialiser une autre partie des modules du système. Selon un mode de réalisation, le procédé comprend des étapes de définition d'un port d'émission de signal de réinitialisation dans le module de 15 contrôle, de définition d'un port de réception de signal de réinitialisation du module à réinitialiser, et de connexion du port d'émission de signal de réinitialisation au port de réception de signal de réinitialisation. Un mode de réalisation concerne également un système simulé comprenant un module de contrôle de réinitialisation et un module à 20 réinitialiser, le module de contrôle comprenant un processus configuré pour émettre des signaux de réinitialisation, le module à réinitialiser comprenant un processus à réinitialiser à la suite de la réception par le module d'un signal de réinitialisation. Selon un mode de réalisation, le système est configuré pour mettre en oeuvre le procédé défini précédemment. 25 Selon un mode de réalisation, le module à réinitialiser comprend une méthode à réinitialiser déclarée sensible au signal de réinitialisation, déclarée sensible au signal de redémarrage à la suite de la réception du signal de réinitialisation, et exécutée et déclarée sensible au signal de réinitialisation à la suite de la réception du signal de redémarrage. 30 Selon un mode de réalisation, le module comprend une fonction d'initialisation exécutée à la suite de la réception par le module du signal de réinitialisation. Selon un mode de réalisation, le module de contrôle comprend un port d'émission de signal de réinitialisation, et le module à réinitialiser 35 comprend un port de réception de signal de réinitialisation connecté au port d'émission du module de contrôle. L'invention concerne également un programme enregistré sur un support lisible et exécutable par un ordinateur, configuré pour mettre en oeuvre le procédé défini précédemment, lorsqu'il est exécuté par un ordinateur. Des exemples de réalisation de l'invention seront décrits dans ce qui suit, à titre non limitatif en relation avec les figures jointes parmi lesquelles : - la figure 1 représente schématiquement un exemple de système, - la figure 2 représente schématiquement un exemple de module du io système, - la figure 3 est un diagramme temporel représentant des opérations déclenchées dans un système à la suite de l'émission d'un signal de réinitialisation, - la figure 4 représente schématiquement un autre exemple de système 15 pouvant être réinitialisé partiellement. La figure 1 représente un système simulé au niveau d'abstraction TLM (Transaction Level Mode!) comprenant plusieurs modules TMR, MEM, CP1, CP2 reliés entre eux par un bus ADB. Les modules TMR et MEM simulent par exemple un compteur et une mémoire. Les modules CP1 et 20 CP2 simulent par exemple un processeur et un générateur. Le module TMR est relié au module CP1 par une liaison d'interruption. Selon un mode de réalisation, le système comprend un module de contrôle d'un signal de réinitialisation RCTL simulant un circuit de gestion de signal de réinitialisation. Le module RCTL comprend un port d'émission d'un 25 signal de réinitialisation RST connecté à un port d'initialisation de modules à réinitialiser TMR, MEM, CP1, CP2. La figure 2 représente un exemple de module CP comprenant plusieurs ports d'entrée et/ou de sortie et un processus PRC. Le processus PRC comprend plusieurs opérations dont une opération d'initialisation Init, et 30 des opérations 01-04, W qui sont exécutées à la suite de l'opération Init. Les opérations 01-04, W forment entre elles une boucle infinie comportant une instruction d'attente W de déclenchement par le simulateur. L'instruction W peut spécifier un ou plusieurs événements qui doivent réactiver le processus. La figure 3 représente des étapes de propagation et de traitement d'un signal de réinitialisation, dans un système comprenant deux modules CP et RCTL, dont un module de contrôle de signal de réinitialisation RCTL. Le module RCTL comprend un processus IPR qui est activé au lancement d'une simulation du système. Le module CP comprenant une méthode MTH et un processus qui sont configurés pour être lancés à l'initialisation du module CP. Le module RCTL comprend un port d'émission P1 d'un signal de réinitialisation et le module CP comprend un port de réception P2 du signal de réinitialisation. io A la réception par le module RCTL d'un ordre de réinitialisation, le processus IPR exécute des étapes SI, S2. A l'étape SI, le processus IPR envoie un signal de réinitialisation RST sur le port de réinitialisation du module CP. A l'étape S2, le processus IPR se met en attente pendant un certain temps suffisant pour permettre l'exécution de traitements 15 d'initialisation par les modules à initialiser du système. La réception par le module CP du signal RST déclenche des traitements dans les processus et dans les méthodes du module CP, à exécuter à l'initialisation du système. A la réception du signal RST par le module CP, le noyau du simulateur exécute les méthodes du module sensibles à cet événement, 20 réveille les processus en attente de cet événement, et exécute les fonctions de réinitialisation du module. La méthode MTH exécute des étapes S2 et S3. A l'étape S2, si la méthode MTH est à activer à l'initialisation du module CP, la méthode MTH se déclare activable uniquement par un événement de redémarrage SU du 25 module CP (étape S4). Par ailleurs, le processus PRC est réveillé à la réception par le module CP du signal RST et exécute les étapes S5 à S8. Aux étapes S5 et S6, si l'événement reçu est un événement de réinitialisation RST, le processus PRC lève une exception liée à l'événement RST. Les étapes S7 et S8 sont exécutées si une exception est levée. A 30 l'étape S7, le processus PRC teste la nature de l'exception. A l'étape S8, le processus PRC se met en attente d'un événement de redémarrage SU si l'exception levée est liée à l'événement RST. A l'étape S9 déclenchée à la fin des traitements de réinitialisation, le module CP exécute une fonction d'initialisation de variables locales au module. A l'étape S10, le processus d'initialisation IPR du module RCTL sort de son attente et exécute les étapes S10 et S11. A l'étape S10, le processus IPR envoie un événement de redémarrage SU du système. Cet événement est transmis au port de réinitialisation du module CP. La réception de cet événement active la méthode MTH qui s'exécute à l'étape S12. A l'étape S13, la méthode MTH se déclare sensible à l'événement de réinitialisation RST. La réception de l'événement STT réveille également le processus PRC qui s'exécute à l'étape S14 jusqu'à atteindre une instruction d'attente d'un nouvel événement RST à l'étape S15. La levée d'une exception permet de remonter automatiquement la pile des appels successifs de fonctions dans le modèle, ce qui permet de réinitialiser les processus. Dans un mode de réalisation, les étapes SI à S15 décrites précédemment peuvent être mises en oeuvre avec un simulateur en 15 SystemC de la manière suivante. Le module CP d'un système est classiquement défini comme détaillé dans l'annexe 1. L'annexe 1 décrit une manière de coder le module CP simulé avec SystemC. Le module CP est défini comme un bloc structurel à l'intérieur duquel sont instanciés notamment des processus et des 20 méthodes. Le module CP peut comprendre des ports d'entrée et/ou de sortie pour communiquer avec l'extérieur, des processus, des méthodes, des variables, et un constructeur. Le constructeur du module permet de réaliser toutes les initialisations dont a besoin le module. Le module CP comprend également une partie d'instantiation des éléments du module, et en 25 particulier des méthodes et processus. Ainsi, dans l'exemple de l'annexe 1, le module CP comprend la méthode MTH et le processus PRC. L'instantiation d'une méthode ou d'un processus est effectuée par une déclaration et un enregistrement de la méthode ou du processus. L'activation d'une méthode ou d'un processus est effectuée par un 30 ordonnanceur du noyau de SystemC. Une liste de sensibilité par défaut est attribuée à chaque méthode et processus, définissant les événements activant la méthode ou le processus. Dans l'exemple de l'annexe 1, la liste de sensibilité de la méthode MTH comprend un événement ev1. L'instantiation d'une méthode ou d'un processus comprend également les 35 traitements effectués par la méthode "void CP::MTHO" et le processus "void CP::PRC()" sous la forme d'une séquence d'instructions. Un processus comprend généralement une boucle infinie incluant une ou plusieurs instructions d'attente d'un événement (instruction wait), de sorte qu'une fois que le processus est lancé par le noyau, il ne s'arrête que lors de ces instructions d'attente. Une méthode est lancée par le noyau à l'arrivée d'un événement appartenant à la liste de sensibilité de la méthode. La fonction next_trigger() permet soit de modifier la liste de sensibilité de la méthode lorsqu'une nouvelle liste d'événements est passée en paramètre de la fonction, soit de reprendre la liste d'événement déclarée lorsque la fonction lo est appelée sans paramètre. Pour pouvoir traiter un ordre de réinitialisation, le module CP est modifié comme détaillé dans l'annexe 2. Dans l'annexe 2, le code du module CP est modifié pour inclure l'inclusion d'une bibliothèque spécifique de gestion d'un signal de réinitialisation RST. Le module CP comprend 15 également une instruction d'héritage sur une classe de gestion du signal de réinitialisation "public dvk_tlm_reset::tlm_reset". Le code du module CP comprend également l'ajout de la déclaration d'un port de réception "reset" de signaux RST et SU, et dans les déclarations des méthodes et processus du module, de la déclaration d'un processus à lancer lors de l'apparition du 20 signal RST TLM_RESET SC THREAD_IMPLEMENT(PRC) pour chaque processus PRC du module. Le module CP comprend également une fonction d'initialisation reset_initialize() de variables du module à appeler à la fin du traitement du signal RST. Dans sa partie constructeur, le module CP comprend une instruction de construction d'une classe de gestion du signal 25 de réinitialisation avec le port "reset" en paramètre "dvk_tlm_reset::tlm_reset(reset)", une instruction de construction du port "reset" "reset("reset")", et une instruction de connexion du port "reset" "reset(*this)". La partie instantiation des méthodes et processus comprend également l'ajout de la sensibilité de la méthode à l'événement RST et une 30 macro instruction modifiée de déclaration du processus PRC "TLM RESET SC THREAD(PRC)" avec en paramètre le nom du processus. Dans le traitement du processus PRC, l'instruction wait() est remplacée par une instruction tlm wait(). Le traitement de la méthode MTH est également modifié par l'ajout de l'appel à une fonction 35 tlm_reset sc method_start(bool) avec en paramètre un booléen à vrai ou i0 faux selon que la méthode doit ou non être initialisée à chaque réception du signal RST. Les éventuels appels à la fonction next_trigger() de la méthode MTH sont remplacés par l'appel à la fonction tlm_next trigger(). Le processus TLM_RESET SC THREAD_IMPLEMENT(PRC) insère dans une boucle infinie le traitement du processus PRC, suivi d'un appel à la fonction TLM_wait(RST). La fonction TLM_wait(RST) appelle la fonction wait(RST) pour se mettre en attente de l'événement RST, puis lève une exception de réinitialisation si une procédure de réinitialisation a été activée (instruction throw). L'appel de la fonction TLM_wait(RST) dans le processus io TLM_RESET SC THREAD_IMPLEMENT(PRC) est suivi d'une instruction de traitement de l'exception de réinitialisation (instruction catch) qui est exécutée dès qu'une exception a été levée et qui déclenche l'exécution d'une séquence de traitement de réinitialisation si l'exception levée est liée à l'événement de réinitialisation RST. La séquence de traitement de 15 réinitialisation comptabilise le nombre de processus réinitialisés et si tous les processus du module ont été réinitialisés, le traitement de réinitialisation du module est considéré terminé. La séquence de traitement de réinitialisation se termine par un appel à la fonction wait(STT) pour se mettre en attente de l'événement de démarrage SU. La prévision du processus 20 TLM RESET SC THREAD IMPLEMENT englobant chaque processus du module permet d'éviter qu'un processus ayant terminé son traitement en étant sorti de sa boucle infinie interne, ne puisse pas être réactivé à la réception par le module CP d'un signal de réinitialisation. La prévision de la levée d'une exception à la suite de la détection de l'apparition du signal RST 25 permet de centraliser le traitement de réinitialisation d'un processus quel que soit l'emplacement dans le traitement du processus de l'instruction d'attente du signal RST. La fonction tlm_reset_sc_method_start(bool) appelée par la méthode MTH teste si l'événement RST est en cours de traitement et si la méthode 30 doit être initialisée. Si tel est le cas, l'événement SU est placé dans la liste de sensibilité de la méthode par un appel à la fonction next trigger(). Il en résulte qu'à la réception de l'événement SU par le module CP, le processus PRC est réactivé à son point de démarrage et la méthode MTH est exécutée si elle doit l'être au lancement de la simulation. Les modifications apportées au module, indiquées dans l'annexe 2 sont réalisées dans tous les modules, processus et méthodes devant être réinitialisés, à la suite de l'émission par le module RCTL de l'événement RST. Ainsi, il est possible de simuler la propagation et le traitement d'un signal de réinitialisation dans un système modélisé au niveau transactionnel TLM sans avoir à modifier le noyau du simulateur. Plusieurs chemins de signaux de réinitialisation peuvent également être définis dans un système, en définissant plusieurs signaux de réinitialisation émis par un ou plusieurs module de contrôle de réinitialisation, et en connectant des ports d'émission de signal de réinitialisation à des ports de réception de tels signaux prévus sur les modules à réinitialiser. Ainsi, la figure 4 représente un système qui diffère du système représenté sur la figure 2 en ce qu'il comprend deux modules de contrôle de réinitialisation RCTL1 et RCTL2, chacun des modules RCTL1 et RCTL2 comportant un port d'émission de signal de réinitialisation. Le port d'émission de signal de réinitialisation du module RCTL1 est connecté aux modules TMR et MEM et émet un signal de réinitialisation RS1. Le port d'émission de signal de réinitialisation du module RCTL2 est connecté aux modules CP1 et CP2 et émet un signal de réinitialisation RS2. L'annexe 3 fournit un exemple de réalisation du processus modifié par la macro instruction TLM_RESET SC THREAD_IMPLEMENT. La macro instruction TLM RESET SC THREAD IMPLEMENT reçoit en paramètre le nom du processus du module, PRC dans l'exemple de la figure 3. La macro instruction crée une nouvelle fonction dont le nom est celui du processus passé en paramètre de la macro instruction, précédé de "tlm_reset_", soit tlm_reset PRC dans l'exemple de la figure 3. Le processus créé par la macro instruction TLM RESET SC THREAD IMPLEMENT commence par une instruction de boucle infinie "do" qui fonctionne avec l'instruction "while(1)" à la fin du processus délimitant la fin de la boucle infinie. Le processus comprend ensuite une instruction "try" délimitant une séquence d'instructions sensible à la levée d'une exception. Cette séquence d'instructions comprend une instruction d'appel "narre()" du processus dont le nom "name" est passé en paramètre du processus TLM_RESET SC THREAD_IMPLEMENT, une instruction d'attente de l'événement RST "wait(RST)", et une instruction de test de la présence d'un traitement de réinitialisation en cours. Dans l'exemple de la figure 3, "name" est PRC. Si un traitement de réinitialisation est en cours, une instruction de levée d'exception "throw" est exécutée pour levée l'exception de réinitialisation "reset_exception". Le processus TLM RESET SC THREAD IMPLEMENT comprend ensuite une instruction "catch" introduisant une séquence d'instructions exécutée si une exception est levée. Cette séquence d'instruction comprend une instruction d'attente du signal de redémarrage SU. Conformément au principe connu de fonctionnement d'une exception, l'instruction "catch" est exécutée dès la levée d'exception et quelle que soit la position dans le code du processus TLM RESET SC THREAD IMPLEMENT de l'instruction de levée d'exception "throw". En d'autres termes, le processus "name" est ainsi placé dans une boucle infinie dans laquelle il est appelé et se met en attente du signal de réinitialisation RST. En sortie d'attente, si le signal d'initialisation est apparu, l'exception de réinitialisation est levée. Dans la séquence de traitement de l'exception de réinitialisation, le processus se met en attente du signal de redémarrage SU. Une nouvelle itération de la boucle infinie est ensuite exécutée. Il apparaîtra clairement à l'homme de l'art que la présente invention est susceptible de diverses variantes de réalisation. Ainsi l'invention n'est pas limitée à l'utilisation de SystemC. En effet, l'invention peut être mise en oeuvre avec d'autres simulateurs, et dans un système modélisé à un autre niveau d'abstraction.25 13 Annexe 1 // Inclusion de la bibliothèque de SystemC #include "systemc.h" SC_MODULE(CP) { // déclaration des ports, signaux, variables du module unsigned int my variable; // constructeur (pour réaliser les initialisations nécessaires du module) mon module(sc module name CP) : sc module(CP) { 15 my_variable(0x1234) // Valeur de mise en service de la // variable } 20 // déclaration des méthodes et processus du module void MTH () ; void PRC(); // Instantiation de méthodes et processus dans le module 25 SCHASPROCESS(CP); //Liste des méthodes et processus du module : // Enregistrement du processus comme un SCMETHOD SC_METHOD(MTH); // Déclaration de sa liste de sensibilité ou liste 30 d'événements réactivant l'exécution de la méthode sensitive � evl; // Enregistrement du processus PRC SC THREAD(PRC); } }; void CP::PRC() { 40 // Boucle infinie avec instruction d'attente : while (true) { ... // traitements du processus wait ( ) ; } 45 } void CP::MTH() { ... // traitements de la méthode next_trigger(); 50 ... // autres traitements de la méthode 10 } Annexe 2 // Inclusion de la bibliothèque de SystemC #include "systemc.h" // Inclusion de la bibliothèque de gestion d'un signal de réinitialisation RST #include "tlm reset.h" 10 SC_MODULE (CP) // Ajout de l'héritage sur une classe de gestion du // signal RST public dvk tlm reset::tlm reset { 15 // déclaration des ports, signaux, variables unsigned int my variable; // Ajout de la déclaration du port de connexion pour la 20 // réception des signaux RST et STT dvk tlm reset::tlm reset target port reset; // déclaration des méthodes et processus du module 25 void MTH ( ) ; //Declaration du processus PRC comme processus à // réinitialiser lors du traitement d'un ordre de // réinitialisation TLMRESETSCTHREADIMPLEMENT(PRC); 30 void PRO(); //Ajout d'une fonction d'initialisation de variables // lors d'une réinitialisation, appelée // automatiquement en fin de réinitialisation 35 virtual void reset initialize() { my_variable = 0x1234; // Valeur initiale de la // variable 1 40 // constructeur (pour réaliser les initialisations nécessaires du module) mon_module(sc module_name CP) : sc_module(CP) // Construction de la classe de gestion du signal de 45 // réinitialisation avec le port réception du signal // RST en paramètre : dvk_tlm_reset::tlm_reset(reset), // Construction du port reset reset("reset"), 50 { my_variable(0x1234) // Valeur initiale de la // variable5 // Connexion au port reset reset(*this); } // Instantiation de méthodes et processus dans le module SCHASPROCESS(CP); //Liste des méthodes et processus du module : // Enregistrement du processus comme un SCMETHOD SC_METHOD(MTH); // Déclaration de sa liste de sensibilité : // ajout de la sensibilité de la méthode à l'événement // de réinitialisation : sensitive � evl � dvk tlm reset::tlm reset::reset event; // Enregistrement du processus PRC TLM_RESET_SC_THREAD(PRC); // la Macro de déclaration du processus est modifiée } } ; void CP:: PRC () { while (true) { ... // traitements du processus TLM_wait () ; // l'appel de la fonction d'attente wait() a été // remplacé par l'appel de la fonction TLM wait() } void CP::MTH() { // les traitements de la méthode commencent par un appel // de fonction de gestion de la réinitialisation avec en // paramètre "true" si la méthode doit être activée à // chaque initialisation sinon "false" : tlm_reset scmethodstart(false); ... // traitements de la méthode TLM_next_trigger O ; // l'appel à la fonction next_trigger() a été remplacé 40 //par un appel à une fonction TLM next_trigger() ... // autres traitements de la méthode } } Annexe 3 #define TLM RESET SC THREAD IMPLEMENT(name) void tlm reset ##name() { do { try { name () ; wait (RST) ; if (in reset) throw reset exception(); } catch(reset exception &e) { wait (STT) ; } } \ while(l); } 17 REVENDICATIONS1. Procédé de simulation d'un signal de réinitialisation dans un système modélisé comprenant un module de contrôle de réinitialisation (RCTL) et un module à réinitialiser (CP), le procédé comprenant des étapes d'émission par un processus de contrôle (IPR) du module de contrôle d'un signal de réinitialisation (RST), et de réception par le module à réinitialiser du signal de réinitialisation, caractérisé en ce qu'il comprend des étapes consistant à : réveiller un processus (PRC) du module à réinitialiser (CP), en attente d'un signal de réinitialisation, ~o si le processus du module à réinitialiser est réveillé par le signal de réinitialisation (RST), lever une exception de réinitialisation par le processus du module à réinitialiser, et si une exception de réinitialisation est levée, mettre le processus du module à réinitialiser en attente d'un signal de redémarrage (STT), 15 émettre le signal de redémarrage par le processus de contrôle (IPR), qui est transmis au module à réinitialiser, et à la suite de la réception par le module à réinitialiser du signal de redémarrage, activer le processus du module à réinitialiser, qui s'exécute et se met en attente du signal de réinitialisation. 20 2. Procédé selon la revendication 1, comprenant des étapes consistant à : déclarer une méthode (MTH) du module à réinitialiser (CP), sensible au signal de réinitialisation (RST), 25 à la suite de la réception par le module à réinitialiser du signal d'initialisation (RST), déclarer la méthode à réinitialiser sensible au signal de redémarrage (STT), et à la suite de la réception par le module à réinitialiser du signal de redémarrage, exécuter la méthode et la déclarer sensible à un signal de 30 réinitialisation. 3. Procédé selon la revendication 1 ou 2, comprenant une étape d'exécution d'une fonction d'initialisation du module à réinitialiser, à la suite de la réception par le module du signal d'initialisation (RST). 4. Procédé selon l'une des revendications 1 à 3, dans lequel chaque processus du système est inséré dans une boucle sans fin comprenant une instruction d'attente du signal de réinitialisation (RST), suivie d'une instruction de levée d'une exception de réinitialisation, d'une instruction d'entrée dans une procédure de traitement d'exception comprenant une instruction d'attente du signal de redémarrage (STT). 5. Procédé selon l'une des revendications 1 à 4, comprenant une étape de remplacement d'une instruction d'attente dans un processus par une instruction d'attente, suivie d'une instruction de'levée de l'exception de réinitialisation exécutée si le signal de réinitialisation a été reçu par le module auquel appartient le processus. 6. Procédé selon l'une des revendications 1 à 5, comprenant des étapes de déclaration d'une méthode (MTH) du module à réinitialiser (CP), sensible au signal de réinitialisation (RST), et d'ajout dans une liste d'événements activant l'exécution de la méthode, d'un événement de réception du signal de réinitialisation par le module à réinitialiser. 7. Procédé selon l'une des revendications 1 à 6, comprenant l'émission dans le système d'un premier signal de réinitialisation (RS1) pour réinitialiser une partie (TMR, MEM) des modules du système, et l'émission dans le système d'un second signal de réinitialisation (RS2) pour réinitialiser une autre partie (CP1, CP2) des modules du système. 8. Procédé selon l'une des revendications 1 à 7, comprenant des étapes de définition d'un port d'émission de signal de réinitialisation (P1) dans le module de contrôle (RCTL), de définition d'un port de réception de signal de réinitialisation (P2) du module à réinitialiser (CP), et de connexion du port d'émission de signal de réinitialisation au port de réception de signal de réinitialisation. 19 9. Système simulé comprenant un module de contrôle de réinitialisation (RCTL) et un module à réinitialiser (CP), le module de contrôle comprenant un processus (IPR) configuré pour émettre des signaux de réinitialisation (RST, STT), le module à réinitialiser comprenant un processus à réinitialiser (PRC) à la suite de la réception par le module d'un signal de réinitialisation, caractérisé en ce qu'il est configuré pour mettre en oeuvre le procédé selon l'une des revendications 1 à 8. io 10. Système simulé selon la revendication 9, dans lequel le module à réinitialiser (CP) comprend une méthode à réinitialiser (MTH) déclarée sensible au signal de réinitialisation (RST), déclarée sensible au signal de redémarrage (STT) à la suite de la réception du signal de réinitialisation, et 15 exécutée et déclarée sensible au signal de réinitialisation à la suite de la réception du signal de redémarrage. 11. Système simulé selon la revendication 9 ou 10, dans lequel le module à réinitialiser (CP) comprend une fonction d'initialisation exécutée à 20 la suite de la réception par le module à réinitialiser du signal de réinitialisation (RST). 12. Système simulé selon l'une des revendications 9 à 11, dans lequel le module de contrôle (RCTL) comprend un port d'émission de signal 25 de réinitialisation (P1), et le module à réinitialiser (CP) comprend un port de réception de signal de réinitialisation (P2) connecté au port d'émission du module de contrôle. 13. Programme enregistré sur un support lisible et exécutable par un 30 ordinateur, caractérisé en ce qu'il est configuré pour mettre en oeuvre le procédé selon l'une des revendications 1 à 8, lorsqu'il est exécuté par un ordinateur.