FR2836734A1

FR2836734A1 - Procede d'extraction de la topologie d'un systeme a partir de sa description textuelle

Info

Publication number: FR2836734A1
Application number: FR0202641A
Authority: FR
Inventors: Emmanuel Vaumorin; Vasyl Baranetskyy; Marcel Saussay
Original assignee: Prosilog S A
Current assignee: Prosilog S A
Priority date: 2002-03-01
Filing date: 2002-03-01
Publication date: 2003-09-05
Anticipated expiration: 2022-03-01
Also published as: AU2003248860A1; WO2003075188A1; FR2836734B1

Abstract

Pour permettre la production de données représentant la topologie d'un système qui comprend un ou plusieurs modules à partir de la description textuelle du système dans un langage orienté objet, une fonction de connexion de chaque port de chaque module, d'une part, réalise (44) la connexion à ce port du signal dont l'identifiant est spécifié en paramètre, et d'autre part envoie (42) l'adresse de ce signal à un objet d'extraction de topologie si une fonction d'initialisation du module a déjà été appelée ou enregistre (43) cette adresse dans la structure de stockage associée audit port si la fonction d'initialisation du module n'a pas encore été appelée.

Description

PROCEDE D'EXTRACTION DE LA TOPOLOGIE D'UN SYSTEME
A PARTIR DE SA DESCRIPTION TEXTUELLE
La présente invention concerne un procédé de production de données représentant la topologie d'un système, à partir de la description textuelle du système dans un langage orienté objet, notamment le langage SystemC.

Elle se rapporte au domaine des techniques de description de systèmes dans un langage formel, de simulation des systèmes et plus généralement de la conception de systèmes assistée par ordinateur (CAO).

Des langages formels tels que VHDL, Verilog ou SystemC permettent de décrire textuellement, avec une approche orientée objet, un système comprenant un ou plusieurs modules matériels (hardware) et/ou logiciels (software). Chaque module du système est représenté par un objet ayant un nombre déterminé de ports d'entrée et un nombre déterminé de ports de sortie, voire des ports d'entrée/sortie dans certaines applications. Les modules sont raccordés entre eux par des signaux qui relient au moins un port de sortie d'un module à au moins un port d'entrée d'un autre module, voire du même module (en cas de bouclage d'une sortie avec une entrée du module). Dans le langage de l'homme du métier et dans la suite, l'association entre un port et un signal qui lui est relié est appelée une connexion.

La description textuelle du système prend la forme d'un code (ou programme) suivant la syntaxe propre au langage formel. Le code est enregistré sur un support de mémorisation quelconque, éventuellement après une opération de compilation, et peut être chargé dans la mémoire d'un ordinateur. Il peut alors être exécuté par l'ordinateur, notamment pour simuler le fonctionnement du système.

Dans le jargon de l'homme du métier, la description textuelle du système, c'est-à-dire le code dans le langage formel, est appelée"netlist". Le concepteur d'un système fabrique la description textuelle du système en programmant dans un langage formel. Dans la suite, on considère seulement l'exemple de SystemeC, bien que l'invention ne se limite pas à ce langage formel particulier.

SystemC a été récemment introduit pour la description des systèmes.

C'est un langage unique capable de décrire les systèmes à tous les niveaux d'abstraction, qui offre de nombreuses opportunités pour utiliser les concepts

de la programmation orientée objet. SystemC est inspiré du langage C++ et en utilise avantageusement l'expressivité pour la modélisation des systèmes.

Mais SystemC est aussi une bibliothèque d'objets pré-codés (aussi appelés classes ), et un noyau de simulation, utilisables pour modéliser et simuler le fonctionnement d'un système. Chaque module du système est représenté par un objet C++ qui caractérise ses ports d'entrée et/ou de sortie, ainsi que le principe de son fonctionnement via des fonctions (aussi appelées méthodes ou processus ) qui pilotent la variation des signaux reliés aux sorties du module en fonction de la variation des signaux reliés aux entrées du module. Dit autrement, le noyau de simulation exécute le code du système.

Un objet de l'invention est de proposer une méthode permettant, de façon la plus transparente possible pour le concepteur, d'obtenir dynamiquement la topologie d'un système à partir de la netlist de ce système écrite en langage formel, notamment mais pas exclusivement SystemC. Par l'adverbe"dynamiquement", on entend"au fur et à mesure"de l'exécution du code du système. On dispose ainsi automatiquement et immédiatement de la topologie du système, pour une utilisation ultérieure.

Par topologie du système, on entend la connaissance des modules qui le composent et de leurs raccordements via les signaux précités. Cette topologie est entièrement définie par la liste des connexions du système. Des données représentant cette topologie peuvent être produites à partir de la netlist elle-même (puisque cette netlist décrit la structure du système dans sa globalité). Elles peuvent être stockées en mémoire sous des formes diverses, notamment dans un ou plusieurs fichiers formant une structure mémoire appropriée.

Ces données permettent de disposer de l'ensemble des informations sur la topologie du système : informations sur tous ses composants et leurs raccordements entre eux. Cela peut s'avérer très utile pour de nombreuses applications, par exemple la génération d'une représentation graphique du système (sur un écran ou sur du papier), la mise en oeuvre d'un logiciel de placement/routage des modules du système en vue de son implantation vers le matériel cible, etc., indirectement à partir de la seule description textuelle du système.

L'invention propose ainsi un procédé de production de données représentant la topologie d'un système qui comprend un ou plusieurs modules ayant chacun un nombre déterminé de ports d'entrées et un nombre déterminé de ports de sortie et reliés entre eux par des signaux déterminés, à partir de la description textuelle du système dans un langage orienté objet
Suivant l'invention, on introduit dans la déclaration de chaque module du système : - la déclaration d'une fonction d'initialisation du module comprenant en paramètre un identifiant d'un objet d'extraction de topologie et recevant, lorsqu'elle est appelée, l'adresse dudit objet d'extraction de topologie ; - la déclaration de fonctions de connexion respectives pour chacun des ports d'entrée et des ports de sortie du module comprenant en paramètre un identifiant d'un signal relié audit port, et recevant, lorsqu'elle est appelée, l'adresse dudit signal ; - la déclaration d'une première variable interne adaptée pour stocker l'adresse de l'objet d'extraction de topologie ; - la déclaration d'autres variables internes respectivement associées à chacun des ports d'entrée et des ports de sortie du module, et adaptées pour contenir l'adresse d'une structure de stockage associée ; et, - l'initialisation desdites première et autres variables internes à une valeur initiale déterminée respective.

De plus, on introduit, dans la description textuelle du système et dans un ordre quelconque : - l'appel de la fonction d'initialisation de chaque module, avec un identifiant de l'objet d'extraction de topologie en paramètre ; - l'appel de la fonction de connexion de chaque port de chaque module, autant de fois qu'il y a de signaux respectifs reliés à ce port, avec à chaque fois un identifiant du signal concerné en paramètre.

La fonction de connexion de chaque port de chaque module, d'une part réalise la connexion à ce port du signal dont l'identifiant est spécifié en paramètre. D'autre part, elle envoie l'adresse de ce signal à l'objet d'extraction de topologie si la fonction d'initialisation du module a déjà été appelée ou

enregistre cette adresse dans la structure de stockage associée audit port si la fonction d'initialisation du module n'a pas encore été appelée.

La fonction d'initialisation de chaque module enregistre l'adresse de l'objet d'extraction de topologie dont l'identifiant est spécifié en paramètre dans ladite première variable interne du module, envoie l'adresse et le type fonctionnel du module à l'objet d'extraction de topologie, et, le cas échéant, envoie pour chaque port du module les adresses respectives de chaque signal relié à ce port qui ont été préalablement stockées dans la structure de stockage associée audit port.

L'objet d'extraction de topologie reçoit l'adresse de chaque module, et l'adresse de chaque signal relié à chaque port de chaque module, et les stocke dans une structure de stockage de topologie déterminée.

Ainsi, les données représentant la topologie du système sont extraites au fur et à mesure de l'exécution de la netlist. On obtient ainsi, directement, une structure mémoire (par exemple un tableau et/ou une liste) dans laquelle les informations sur la typologie du système sont stockées.

Avantageusement, le concepteur du système n'a pas à se soucier de l'ordre relatif des appels des fonctions d'initialisation de chacun des modules d'une part et des fonctions de connexion d'un des ports de ce module d'autre part.

D'autres caractéristiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels : - la figure 1 est un schéma d'exemple de système qui est utilisé pour illustrer le principe de l'invention ; - la figure 2 est organigramme des étapes d'un procédé selon l'invention ; - la figure 3 est un organigramme des étapes de traitement des instructions contenues dans la description textuelle (netlist) du système ; - la figure 4 est un organigramme des étapes exécutées lors de l'appel d'une fonction de connexion d'un port déterminé du système ; - la figure 5 est un organigramme des étapes exécutées lors de l'appel de la fonction d'initialisation d'un module déterminé ;

- la figure 6 est un organigramme des étapes exécutées pour l'envoi vers l'objet d'extraction de topologie des informations sur les connexions qui ont été stockées dans la structure de stockage associée à un port déterminé ; - la figure 7 est un schéma illustrant un tableau compris dans une première structure de stockage de topologie ; - la figure 8 est un schéma illustrant une liste comprise dans la première structure de stockage de topologie ; - la figure 9 est un schéma illustrant une deuxième structure de stockage de topologie ; - la figure 10 est un schéma illustrant une troisième structure de stockage de topologie ; et, - la figure 11 est un organigramme illustrant les étapes d'un procédé d'enregistrement des informations de topologie dans la deuxième ou la troisième structure de stockage de topologie à partir des informations stockées dans la première structure de stockage de topologie.

La description qui suit est donnée en référence à un exemple dans lequel on utilise, pour la description textuelle du système, le langage de programmation de SystemC, qui est inspiré du langage C++.

En général, le concepteur adopte la stratégie qui consiste à décrire chaque module par deux fichiers. D'une part un fichier dont le nom possède l'extension". h" (fichier appelé"Header"dans le jargon de l'homme du métier), qui contient la déclaration des modules. Et d'autre part un fichier ayant le même nom avec l'extension". cpp", qui contient la définition des différentes fonctions des modules. En général, le système est alors décrit dans un fichier principal (classiquement appelé"main. cpp") qui incorpore les instructions qui sont exécutées par l'ordinateur pour la simulation sous SystemC du fonctionnement du système, et qui accède aux fichiers d'extension". h" et". cpp" de chaque module lorsque c'est nécessaire. Seul ce fichier"main. cpp" est compilé pour l'exécution de la netlist du système.

Les ports du système peuvent être soit des ports d'entrée, soit des ports de sortie, soit des ports d'entrée/sortie. On considère qu'il a été déclaré le type"Port"dont les valeurs énumérées sont les suivantes : ENTREE , SORTIE et ENTREE/SORTIE respectivement.

Les noms des ports d'entrée d'un module sont préfixés par"in". De même les noms des ports de sortie ont "out" comme préfixe, et les ports d'entrées/sortie ont"inout"comme préfixe.

Dans les Annexes 1 à 6, on a donné des portions de code en langage SystemC correspondant à des parties de la déclaration des modules (dans le fichier d'extension". h") et/ou de la description textuelle du système (dans le fichier d'extension". cpp") qui sont utiles à la compréhension de l'invention. Par souci de clarté, des commentaires sont introduits dans ces portions de code, après les caractères"//"et en caractères italiques.

A la figure 1, on a représenté le schéma d'un exemple de système utilisé dans la description ci-après pour illustrer l'invention.

Ce système comprend onze modules M1 à M11. Chaque module comprend au moins un port d'entrée et/ou au moins un port de sortie. Par soucis de simplification du présent exposé, il n'est pas décrit de port d'entrée/sortie. L'invention s'applique toutefois aux systèmes comprenant des modules ayant également de tels ports. Les ports d'entrée et de sortie d'un module déterminé, sont représentés par un rectangle noir respectivement sur la gauche ou sur la droite du module.

On constate que certains modules n'ont pas de ports d'entrée. C'est le cas par exemple des modules M1, M2, Ml, M8 et M9. De tels modules ont une fonction de générateur de données. On constate également que d'autres modules n'ont pas de ports de sortie. Il s'agit dans l'exemple des modules M5, M10 et M11. De tels modules ont pour fonction de traiter des données reçues sans produire eux-mêmes de nouvelles données. Un tel traitement comprend par exemple l'affichage de la donnée. On constate en outre que certains modules comprennent plusieurs ports d'entrée (comme les modules M3 et M6 qui en comportent respectivement deux et trois) et/ou plusieurs ports de sortie (comme le module M6 qui en comporte deux).

Dans le cas général, on considérera dans la suite que chaque module comprend un nombre déterminé n de ports d'entrée et un nombre déterminé m de ports de sortie, où n et m sont des nombres entiers éventuellement nuls.

Les ports d'entrée d'un module déterminé sont notés in~i dans la suite et à la figure 1, où i peut varier entre 1 et n. De même, les ports de sortie d'un module

déterminé sont notés outj dans la suite et à la figure 1, où j est un indice compris entre 1 et m. Toutefois, par souci de simplicité, lorsqu'un module déterminé n'a qu'un port d'entrée ce port est notée in, et lorsqu'un module déterminé n'a qu'un port de sortie ce port est noté out.

Pour les onze modules M1 à M11 du système représenté à la figure 1, le nombre n de ports d'entrée et le nombre m de ports de sortie de chaque module est donné par le Tableau 1 ci-dessous :

<tb>
<tb> Module <SEP> : <SEP> M1 <SEP> M2 <SEP> M3 <SEP> M4 <SEP> M5 <SEP> M6 <SEP> M7 <SEP> M8 <SEP> M9 <SEP> M10 <SEP> M11
<tb> n <SEP> : <SEP> 0 <SEP> 0 <SEP> 2 <SEP> 1 <SEP> 1 <SEP> 3 <SEP> 0 <SEP> 0 <SEP> 0 <SEP> 1 <SEP> 1
<tb> m <SEP> : <SEP> 1 <SEP> 1 <SEP> 1 <SEP> 1 <SEP> 0 <SEP> 2 <SEP> 1 <SEP> 1 <SEP> 1 <SEP> 0 <SEP> 0
<tb>

Tableau 1
Les modules M1 à M11 sont reliés entre eux par l'intermédiaire de dix signaux f1 à f10, ces signaux relient plus particulièrement :

- pour le signal f1 : la sortie out de M1 à l'entrée in~1 de M3 ; - pour le signal f2 : la sortie out de M2 à l'entrée in~2 de M3 ; - pour le signal f3 : la sortie out de M3 à l'entrée in de M4 ; - pour le signal f4 : la sortie out de M3 à l'entrée in~1 de M6 ; - pour le signal f5 : la sortie out de M4 à l'entrée in de M5 ; - pour le signal f6 : la sortie out de M7 à l'entrée in~1 de M6 ; - pour le signal f7 : la sortie out de M8 à l'entrée in~2 de M6 ; - pour le signal f8 : la sortie out de M9 à l'entrée in~3 de M6 ; - pour le signal f9 : la sortie out~1 de M6 à l'entrée in de M10 ; et, - pour le signal f10 : la sortie out~2 de M6 à l'entrée in de M11.

Dans le jargon de l'homme du métier et dans la suite, l'association entre un signal d'une part et un port d'un module déterminé auquel ce signal est relié d'autre part, est appelé une connexion du système.

Pour décrire le système représenté à la figure 1, il faut tout d'abord

définir un certain nombre de types de modules. On définit ainsi : - un type Source pour les modules M1, M2, M7, M8 et M9 ; - un type Display pour les modules M5, M10 et M11 ; - un type Add pour le module M3 ; - un type Mult pour le module M4 ; et,

- un type Dec pour le module M6.

La définition d'un type de module particulier se fait dans le langage SystemC, grâce à la fonction SC~MODULE qui est une fonction prédéfinie de ce langage. Bien entendu, les noms donnés aux types de modules précités sont tout à fait arbitraires et ne sauraient être interprétés comme une caractéristique limitative de l'invention.

L'Annexe 1 donne la description textuelle, en langage SystemC, de la déclaration d'un type de module déterminé appelé module~x , selon l'art antérieur. La déclaration du module comprend notamment : - la déclaration des ports d'entrée in~i du module, pour i compris entre 1 et n, grâce à la fonction scjn qui est une fonction prédéfinie du langage SystemC ; - la déclaration des ports de sortie outj du module, pour j compris entre 1 et m, grâce à la fonction scout qui est également une fonction prédéfinie du langage SystemC ; - la déclaration des variables privées du module et des méthodes ou fonctions privées du module, qui suit l'expression private : ; - la déclaration des variables publiques du module et des méthodes ou fonctions publiques du module qui suit l'expression public : ; - la définition du constructeur du module grâce a la fonction "SCCTOR"qui est également une fonction prédéfinie du langage SystemC ; cette définition du constructeur comprend l'initialisation des variables du module d'une part, et la déclaration des sensitivités des méthodes du module d'autre part.

Le vocable" < type > "donné à l'Annexe 1 est mentionné à titre indicatif pour respecter la syntaxe du langage SystemC, et ne préjuge pas du type même de chaque port concerné qui peut être choisi parmi les types disponibles du langage C++.

A l'Annexe 2, on a donné la description de la déclaration d'un module selon l'invention. Par souci de clarté, les éléments ajoutés par rapport à la déclaration classique d'un module telle que rappelée à l'Annexe 1, sont présentés en caractères gras.

On suppose que le fichier d'extension". h" comprend par ailleurs la définition de types de variables déterminés, appelés"structurejiste"d'une part, et"c ! asserecup" d'autre part.

Une variable du type"structurejiste"est destinée à contenir l'adresse d'une structure de stockage de données associée à l'un des ports d'un module déterminé. Cette structure de stockage associée a pour fonction de stocker les adresses des signaux reliés à ce port. Dans un exemple préféré pour sa simplicité, cette structure de stockage est une liste chaînée. D'autres exemples de structure de stockage sont bien entendu envisageables, tel qu'un arbre ou un tableau, ou la combinaison de tels éléments.

Une variable de type"classe~recup"est destinée à contenir l'adresse d'un objet d'extraction de topologie associé au système. Cet objet est spécifique de la mise en oeuvre de l'invention. Il s'agit d'un objet particulier ayant pour fonction d'extraire, de la description textuelle du système (c'est-àdire de la netlist écrite en langage SystemC dans l'exemple), les données relatives à la topologie de ce système et de les stocker sous une forme appropriée dans une mémoire ad-hoc de l'ordinateur, en vue d'une utilisation ultérieure et/ou de leur enregistrement sur un support de données externe.

Bien entendu, les noms donnés aux deux types de variables précités sont tout à fait arbitraires et ne sauraient être interprétés comme une caractéristique limitative de l'invention.

Les étapes de la déclaration de chaque module qui sont spécifiques de l'invention (c'est-à-dire qui sont nécessaires à la mise en oeuvre du procédé d'extraction de données relatives à la topologie du système) sont illustrées par l'organigramme de la figure 2.

La déclaration du module (par la fonction SC~MODULE de SystemC) comprend tout d'abord la déclaration 21 d'une fonction d'initialisation du module, appelée fonction"dojnit"dans un exemple. Cette fonction n'est pas en soi spécifique à la mise en oeuvre de l'invention. Néanmoins, selon l'invention, elle comprend en paramètre un identifiant de l'objet d'extraction de topologie. Naturellement, elle peut aussi recevoir d'autres paramètres qui n'apparaissent pas ici dès lorsqu'ils sont sans rapport avec l'invention. Elle reçoit, lorsqu'elle est appelée, l'adresse de l'objet d'extraction de topologie dont

un identifiant lui est fourni en paramètre. Sa description est incluse dans le fichier d'extension". cpp" et sera explicitée plus loin en regard du diagramme d'étapes de la figure 5.

Cette déclaration 21 prend la forme de l'instruction suivante, visible à l'annexe 2 :

void do~init (classe~recup & , et types des autres paramètres) où le vocable "void" signifie que la fonction"dojnit"ne retourne aucune information lorsqu'elle est appelée, et où ! e type"dasserecup"entre parenthèses spécifie que la fonction reçoit, lorsqu'elle est appelée, une donnée de type"c ! asserecup", qui est une adresse. On trouve ensuite les types des autres paramètres de la fonction dojnit, qui ne concernent pas la topologie du système mais se réfèrent à la description fonctionnelle du module et ne sont donc pas explicités ici.

De plus, la présence du symbole" & "après te type"ctasserecup"entre parenthèses permet à la fonction dojnit de recevoir directement l'adresse de la variable dont seul le nom (et non l'adresse) est spécifié en paramètre. Dit autrement, on peut appeler la fonction do-init avec en paramètre un identifiant qui est le nom de la variable et, pour autant, l'objet qui appelle cette fonction recevra l'adresse de cette variable. Sans la présence du symbole" & " après le type du paramètre de la fonction dojnit)) spécifié entre parenthèses dans la déclaration de cette fonction, il faudrait, pour parvenir au même résultat, ajouter le symbole" & "devant le nom de la variable passée en paramètre lors de l'appel de la fonction do-init afin de transmettre l'adresse de cette variable. Dit autrement, l'identifiant de la variable passée en paramètre ne serait pas son nom, mais un pointeur donnant l'adresse de la variable. Cette disposition de l'invention permet donc d'utiliser le nom de l'objet d'extraction de topologie comme identifiant dudit objet spécifié en paramètre lors de l'appel de la fonction d'initialisation de chaque module. L'avantage est de simplifier l'écriture de la netlist par le concepteur du système.

Cette déclaration 21 de la fonction est comprise dans la partie réservée à la déclaration des fonctions publiques du module, c'est-à-dire après l'expression "public : ". " s'ensuit que la fonction do-init du module concerné peut être appelée de n'importe quel endroit de la netlist (après toutefois

l'occurrence de l'instruction déclarant ce module (dite instruction d'instanciation ou de déclaration de ce module).

Bien entendu, le nom donné à la fonction d'initialisation précitée est tout à fait arbitraire et ne saurait être interprété comme une caractéristique limitative de l'invention.

La déclaration du module comprend aussi la déclaration 22 de fonctions de connexion respectives pour chacun des ports d'entrée in~i (avec i compris entre 1 et n) et des ports de sortie outj (avec j compris entre 1 et m)

du module. Ces fonctions de connexion sont de préférence appelées respectivement ln~i (avec i compris entre 1 et n) et Outj (avec j compris entre 1 et m). Ces fonctions comprennent en paramètre un identifiant d'un signal relié au port correspondant. Elles reçoivent, lorsqu'elles sont appelées, l'adresse de ce signal. Ces déclarations prennent ainsi la forme

suivante, visible à l'Annexe 2 ; void In~i c~signal < type > & ) et void Outj (sc~signal < type > & ) , pour i compris entre 1 et n, et j compris entre 1 et m, où "void" signifie que la fonction concernée ne retourne aucune information lorsqu'elle est appelée, et où l'expression"scsigna ! < type > "entre parenthèses permet, de façon classique dans le langage SystemC, de spécifier que la fonction reçoit, lorsqu'elle est appelée, un signal de type"type".

Le symbole" & ", quant à lui, permet là-aussi à la fonction de recevoir l'adresse du signal dont l'identifiant est passé en paramètre lors de l'appel de la fonction, même lorsque cet identifiant est le nom du signal (par exemple "f1" pour le signal f1) et non pas l'adresse de ce signal (c'est-à-dire " & f1 If). Dit autrement, l'identifiant du signal spécifié en paramètre lors de l'appel de la fonction de connexion de chaque port de chaque module peut alors être le nom de ce signal.

On notera que, avantageusement, la fonction de connexion (In~i ou Outj) de chaque port (d'entrée ou de sortie, respectivement) de chaque

module a pour nom le nom dudit port (in~i ou outj, respectivement) avec la première lettre en majuscule et les lettres suivantes en minuscules.

Les mesures qui précèdent (à savoir la présence du symbole" & "entre parenthèses dans la déclaration des fonctions de connexion d'une part, et l'utilisation du nom du port avec une majuscule en première lettre comme nom de la fonction de connexion, d'autre part) ne sont pas de simples fantaisies de rédaction de la netlist, mais sont des choix préférés en raison des avantages pratiques suivants, qu'ils procurent. D'une part, cela permet de réduire les changements dans la rédaction de la netlist décrivant le système par rapport aux habitudes actuelles des concepteurs de systèmes en langage SystemC.

En effet, au lieu de réaliser une connexion entre le port in~i (par exemple) et un signal f déterminé en insérant une instruction du type in~i (f) dans la description du système comme dans l'art antérieur, il réalisera cette connexion

par l'appel à la fonction Inj en insérant une instruction du type (Inj (f) , qui est identique à la majuscule près. D'autre part, cela permet aussi d'envisager une modification automatisée de la description textuelle des modules précodés actuellement disponibles dans les bibliothèques SystemC, avec de ce fait un risque d'erreurs minimal et des recompilations éventuelles limitées à ce qui est juste nécessaire. Une telle modification automatisée peut en effet être réalisée à l'aide d'un interpréteur syntaxique. On obtiendrai ainsi une mise à niveau des bibliothèques disponibles.

La déclaration du module comprend aussi la déclaration 23 d'une variable de type"dasserecup", appe) ée"Circuit"dans t'exempte. Ainsi qu'il a été dit plus haut, une telle variable est adaptée pour stocker l'adresse de l'objet d'extraction de topologie associé au système. Cette déclaration prend la forme de l'instruction suivante, visible à l'Annexe 2 :

classerecup *Circuit La déclaration de chaque module comprend encore la déclaration 24 de variables de type"structurejiste"respectivement associées à chacun des ports du module. Les variables sont adaptées pour contenir l'adresse d'une structure de stockage associée à ce port. Ainsi, les variables"hdln~i" (avec i compris entre 1 et n) et"hdOutj" (avec j compris entre 1 et m) sont déclarées pour chacun des ports d'entrée et des ports de sortie respectivement. Cette déclaration prend la forme de l'instruction suivante, visible à l'Annexe 2 : structure~liste *hdin-i et,

structure~liste *hdOut. , pour i compris entre 1 et n, et j compris entre 1 et m.

Le symbole étoile présent devant le nom des variables "Circuit", "hd~ln~i"et et hd~Outj" indique que ces variables sont des pointeurs sur une cellule, au sens informatique du terme. Cela signifie que la variable correspondante contient l'adresse de l'emplacement dans la mémoire de l'ordinateur où la cellule est mémorisée, et non directement la cellule ellemême.

Bien entendu, les noms donnés aux variables précitées sont tout à fait arbitraires et ne sauraient être interprétés comme une caractéristique limitative de l'invention.

La déclaration du module comprend encore l'initialisation 25 des variables"hdln~i" (avec i compris entre 1 et n),"hdOutJ" (avec j compris entre 1 et m) et"Circuit", à une valeur initiale déterminée respective. Dans un exemple, cette valeur initiale est la valeur nulle pour chacune de ces variables. Cette initialisation est réalisée dans la partie de la déclaration du module appelée déclaration du constructeur du module, c'est-à-dire grâce à la fonction SC~CTOR précitée. Cette initialisation prend la forme suivante, visible à l'Annexe 2 :

Circuit = 0, hdin-i=O et, hdOut/=O , pour i compris entre 1 et n, et j compris entre 1 et m.

La déclaration du module comprend aussi la déclaration d'une fonction d'envoi des informations de topologie vers l'objet d'extraction de topologie.

Cette fonction est appelée do~sendinfo dans l'exemple, le choix de ce nom étant purement arbitraire et donc nullement limitatif. Cette fonction est une fonction privée du module. Elle est déclarée dans la partie de la fonction

SCMODULE qui suit l'expression private : . Cette déclaration prend la forme suivante : void do-send info (void) .

A titre d'exemple plus concret, l'Annexe 3 fournit la déclaration partielle du module M6 du système représenté à la figure 1, qui apparaît comme étant

le plus complexe du point de vue de la topologie, c'est-à-dire du point de vue du nombre de ses ports. On rappelle qu'il s'agit d'un module de type appelé "Dec"dans l'exemple.

L'Annexe 4 et l'Annexe 5 contiennent une portion de la netlist correspondant à la description textuelle du système de la figure 1, respectivement selon l'art antérieur et selon l'invention. Cette portion de la netlist, qui est écrite en langage SystemC, est incluse dans le fichier d'extension". cpp". Dans ces annexes, seules les instructions se rapportant à la description de la topologie du système ont été mentionnées. Il est bien entendu que d'autres instructions sont nécessaires à la description du fonctionnement du système, mais n'apparaissent pas ici car elles ne sont pas utiles à la compréhension de l'invention.

En bref, les instructions nécessaires à la description du système comprennent les instructions de déclaration des modules M1 à M11 (on parle en général d'instructions d'instanciation des modules dans le jargon de l'homme du métier, pour désigner ces instructions), les instructions de connexion des ports d'entrée et des ports de sortie des modules, et les instructions d'initialisation des modules par appel de la fonction"dojnit"de chacun des modules.

Ainsi qu'il apparaît en comparant les Annexes 4 et 5, seules les instructions de connexion diffèrent entre le cas selon l'art antérieur et le cas selon l'invention. En effet les instructions de connexion des ports d'entrée et des ports de sortie des modules se font, selon l'invention, par appel de la fonction"In~i" ou"OutJ"correspondante.

L'organigramme de la figure 3 illustre de façon schématique les étapes d'un procédé d'exécution de la netlist de l'Annexe 5, qui consiste à exécuter séquentiellement les instructions qu'elle contient. Ces opérations sont exécutées par le noyau de simulation (processeur piloté par un programme adhoc) de SystemC.

Dans une étape 31, on se demande si la netlist contient encore une instruction à exécuter. Si la réponse est non, alors, dans une étape 32, on lance la simulation du système et/ou le traitement de la topologie. Cette étape 32 correspond à l'essence même des applications pour la conception et la

simulation de système en SystemC. Sinon, et pour chaque instruction contenue dans la netlist, on se demande dans une étape 33 quel est le type de l'instruction concernée.

S'il s'agit d'une instruction d'instanciation d'un nouveau module, par exemple l'instruction Dec M6 ("M6") pour l'instanciation du module M6, alors, dans une étape 34, on construit le module concerné. Ceci consiste à exécuter la fonction"SCMODULE"pour ce module. En particulier, cette exécution initialise les variables"Circuit","hdln~i" (pour i compris entre 1 et n) et"hdOutJ" (opur j compris entre 1 et n) du module.

S'il s'agit d'une instruction de connexion d'un port d'entrée ou de sortie d'un module, par exemple l'instruction M6. 1n1 (f4) pour relier l'entrée in~1 du module M6 au signal f4, alors, dans une étape 35, on appelle la fonction inti ou la fonction Out correspondante. L'étape 35 sera détaillée ci-dessous en regard de l'organigramme de la figure 4.

S'il s'agit d'une instruction d'initialisation d'un module, par exemple l'instruction M6. doinit (Circuit) pour l'initialisation du module M6, alors, dans une étape 36, on exécute l'initialisation de ce module. Ceci est effectué par appel de la fonction"dojnit"de ce module. L'étape 36 sera détaillée cidessous en regard de l'organigramme de la figure 5.

S'il s'agit d'une autre instruction (sans rapport avec la topologie du système, donc non visible dans la netlist de l'Annexe 5), alors, dans une étape 37, on exécute l'instruction concernée.

On notera que l'ordre d'apparition des différentes instructions précitées dans la netlist décrivant le système en langage SystemC peut être quelconque.

En particulier, il est possible qu'une instruction de connexion d'un port d'entrée ou de sortie d'un module déterminé soit appelée avant que la fonction d'initialisation de ce module n'ait été appelée. Il s'ensuit que l'adresse de l'objet d'extraction de topologie associé au système auquel appartient ce module peut encore être indéterminée lors de l'appel de l'instruction de connexion. Ainsi qu'il va maintenant être explicité, l'invention permet de s'affranchir des inconvénients d'une telle situation, grâce à la mise en oeuvre des structures de stockage des informations de topologie associées à chaque port de chaque module.

L'organigramme de la figure 4 illustre le détail de l'étape 35, qui consiste à exécuter une instruction de connexion Inj ou Outj d'un port respectivement d'entrée ou de sortie d'un module déterminé. On rappelle que réaliser une connexion consiste à associer un signal à un port auquel ce signal est relié. Le code de l'implémentation des fonctions Inj et Out du module M6 est fourni à l'Annexe 6
Dans ce qui suit, on illustre le déroulement des étapes de cette implémentation en considérant par exemple le cas où on a appelé la fonction de connexion In~1 pour connecter un signal p quelconque à l'entrée in~1 du module M6. Cet appel peut prendre la forme suivante, visible à l'Annexe 5 :

M6. ln-1 (fl) pour la connexion du signal f1 à l'entrée in~1 du module M6.

Dans une étape 41, on se demande si la fonction d'initialisation "do~init" de ce module a déjà été appelée. Un tel test est par exemple réalisé par une instruction telle que if (Circuit ! = 0) ou, ce qui revient au même, if (Circuit) . Dit autrement, on se demande si la variable "Circuit" du module est non nulle (c'est-à-dire si elle a perdu la valeur nulle qui lui a été attribuée lors de son initialisation).

Si la réponse est oui, cela signifie que la fonction"dojnit"du module a déjà été appelée. En effet, l'adresse non nulle de l'objet d'extraction de topologie associé au système auquel appartient le module est alors contenue dans la variable"Circuit". Alors, dans une étape 42, on envoie l'adresse du signal p à l'objet d'extraction de topologie, par exemple au moyen d'une fonction appelée"SetLien"utilisée par exemple de la façon ci-dessous : Circuit- > SetLien (this, & p, Port type, q)
La méthode"SetLien"est définie pour les objets de type "classe~recup". Elle permet l'enregistrement d'une connexion par l'objet d'extraction de topologie. Cette connexion est définie par l'adresse du module concerné (donnée par le vocable"this"qui est un vocable prédéfini du langage SystemC), l'adresse du signal connecté (soit" & p"dans l'exemple), le type "Porttype" (par exemple la valeur"ENTREE"ou la valeur"SORTIE"selon qu'il s'agit d'un port d'entrée ou d'un port de sortie, respectivement), et le numéro d'ordre de ce port dans son type, noté q (qui correspond à l'ordre d'apparition

du port dans la liste de déclaration des ports du module, les ports d'entrée et les ports de sortie étant distingués et comptés séparément). C'est pourquoi les informations ci-dessus sont passées en paramètres lors de l'appel de la fonction"SetLien".

L'implémentation de la méthode"SetLien"varie en fonction de la nature de la structure de stockage de topologie choisie pour la représentation en mémoire de la topologie. Si l'on considère l'exemple d'une liste chaînée (voir plus loin, description de la figure 8), la fonction"SetLien"crée une nouvelle cellule à ajouter à la liste des cellules existantes par exemple selon une approche, connue en soi, d'ajout en tête de liste. La cellule créée est définie grâce aux informations passées en paramètres pour les champs suivants : adresse du module concerné, adresse du signal connecté, type du port concerné, numéro de ce port dans le type.

L'implémentation de la fonction SetLien est à la portée de l'homme du métier. Un exemple d'implémentation de cette fonction en langage SystemC est donné à l'Annexe 7. Dans cet exemple, la structure de stockage de topologie choisie pour la représentation en mémoire de la topologie est une liste chaînée. La fonction"SetLien", lorsqu'elle est appelée pour un objet de récupération de topologie déterminé, crée une nouvelle cellule à ajouter aux cellules existantes de la liste. Cette nouvelle cellule est renseignée grâce aux informations passée en paramètres, pour les champs suivants : adresse du module concerné, adresse du signal connecté, type du port concerné, numéro de ce port dans son type. La liste stockant les informations sur les connexions du circuit déjà réalisées est ainsi enrichie d'une nouvelle cellule, par conséquent, d'une nouvelle connexion. Dans l'exemple d'implémentation donnée à l'Annexe 7, on note"ListeStockageTopologie"la liste qui permet à l'objet d'extraction de topologie de stocker en mémoire la liste des connexions déjà réalisées. Cette liste, qui initialisée à l'adresse nulle"NIL", est enrichie à chaque appel de la fonction"SetLien", d'une nouvelle cellule correspondant à une nouvelle connexion.

Si, à l'étape 41, la réponse est non, cela signifie que la fonction "do~init"du module n'a pas encore été appelée. Alors, dans une étape 43, on enregistre l'adresse du signal concerné dans la structure de stockage associée

au port concerné. Ceci est par exemple réalisé en appelant une fonction "AddLien", qui est déclarée de la façon suivante : void AddLien (structure~liste **, sc~signal < type > *)
La fonction"AddLien"est une fonction accessible à tous les modules.

Dans un exemple, elle est appelée de la façon ci-dessous pour connecter un signal au port d'entrée in~1 du module M6 :

AddLien ( & hdin & p)
Elle permet d'ajouter l'adresse d'un signal ( & p dans cet exemple) en tête d'une liste de type "structure~liste" (celle repérée par l'adresse & hdln~1 dans l'exemple), soit la liste chaînée qui contient toutes les adresses des signaux déjà connectés au port d'entrée in~1 du module. Dit autrement, la fonction"AddLien"permet de stocker l'adresse & p du signal dans la liste chaînée qui contient toutes les adresses des signaux déjà connectés au port concerné du module. Cette liste chaînée sera ensuite utilisée, lors de l'appel de la fonction"do~sendinfo"pour l'enregistrement des connexions stockées par le module.

Après l'étape 42 comme après l'étape 43, on effectue alors, dans une étape 44, la connexion proprement dite du signal au port concerné. Ceci est réalisé, selon la manière habituelle en langage SystemC, par l'instruction suivante :

ion~1 (p) A la figure 5, on a représenté un organigramme qui donne le détail des étapes mise en oeuvre lors de l'étape 36 (figure 3) à laquelle on appelle la fonction d'initialisation"dojnit"d'un module déterminé. Toujours à titre d'exemple, on considèrera dans ce qui suit le cas de l'appel de la fonction d'initialisation du module M6, par l'instruction suivante : M6. do~init (Circuit)
Cette méthode reçoit en argument l'identifiant de l'objet d'extraction de topologie du système, c'est-à-dire la variable "Circuit" du module. La méthode commence par effectuer un test 51 pour savoir si la fonction"dojnit"a déjà été appelée auparavant, ce qui serait une erreur. A cet effet on teste la valeur de la variable interne"Circuit"qui doit avoir la valeur nulle (c'est-à-dire la valeur qui

lui a été attribuée lors de son initialisation par le constructeur du module). Un tel test est réalisé par exemple par l'instruction suivante : if (Circuit ! =0)
Si la fonction"do~init"a déjà été appelée, alors, dans une étape 52, on gère l'erreur. Par exemple, on génère une interruption.

Si au contraire la fonction"dojnit"n'a pas été appelée auparavant, c'est-à-dire si c'est le premier appel de cette fonction pour le module concerné, alors, dans une étape 53, on stocke l'adresse de l'objet d'extraction de topologie dans la variable interne"Circuit"du module. Ceci se fait par exemple par une instruction telle que Circuit = & c
Ensuite, dans une étape 54, on envoie à l'objet d'extraction de topologie toutes les infirmations sur les connexions déjà réalisées pour ce module, et qui ont été stockées dans les structures de stockage associées à chacun des ports d'entrée et/ou de sortie du module.

A cet effet, on appelle une méthode"do-send~info"permet d'envoyer vers l'objet d'extraction de topologie toutes les informations sur les connexions qui ont pu être réalisées auparavant par des appels antérieurs aux fonctions de connexion Inj et/ou Outj pour ce module.

Le détail de l'exécution de la fonction "do send info" va maintenant être explicité en regard de l'organigramme de la figure 6.

Dans une étape 61, on vérifie que le module appartient bien à un système et que l'on peut donc envoyer des informations vers l'objet d'extraction de topologie associé à ce système. Ceci est réalisé en testant la valeur de la variable "Circuit", par une instruction déjà présentée plus haut, du type if (Circuit ! = 0) .

Si la réponse est non, alors, dans une étape 62, on gère l'erreur par exemple en introduisant une interruption.

Si au contraire la réponse est oui, alors, dans une étape 63, on envoie l'adresse du module (donnée par le vocable this qui est un vocable prédéfini du langage C++) ainsi que son type fonctionnel ("Dec"pour le module M6) à l'objet d'extraction de topologie. Ceci est par exemple réalisé grâce à une méthode"MakeModule", par une instruction du type ci-dessous :

Circuit- > MakeModule (this,"Dec")
On verra plus loin comment est gérée la mémoire pour enregistrer la liste des modules qui constituent le système.

Il s'agit ensuite d'enregistrer toutes les connexions qui ont été stockées pour chaque port du module. Pour cela, on parcourt la liste de pointeurs correspondant à la structure de stockage associée à chaque port du module, et on envoie vers l'objet d'extraction de topologie les adresses contenues dans cette structure de stockage, c'est-à-dire l'adresse de chacun des signaux connectés au port concerné déjà répertoriés.

Plus spécifiquement, dans une étape 64 on se demande si on a parcouru tous les ports du module. Tant qu'il en reste un non encore traité, on se demande dans une étape 65 si la structure de stockage associée à ce port est vide. Si la réponse est oui, c'est qu'aucun signal n'a encore été relié à ce port, et on retourne à l'étape 64. Si au contraire la réponse est non, c'est que au moins un signal a été relié à ce port pour réaliser une connexion. Pour chaque adresse de signal ainsi stockée (étape 66), on envoie dans une étape 67, l'adresse de ce signal à l'objet d'extraction de topologie grâce à la fonction "SetLien"déjà présentée plus haut.

A titre d'exemple, on peut considérer l'implémentation de la fonction "dosendinfo"qui est donnée à l'Annexe 6 en se limitant à la partie

concernant le port d'entrée in~1 du module M6. Pour le port in~1, on va parcourir la liste repérée par la variable "hdln~1" grâce à la variable temporaire "ptr"qui est un pointeur sur liste de type"structure~liste". Chaque adresse de signal contenue dans cette liste sera enregistrée vers et enregistrée par l'objet d'extraction de topologie dont l'adresse est contenue dans la variable"Circuit" grâce à l'utilisation de la méthode"SetLien"qui a été décrite précédemment.

L'on parcourt ainsi toutes les listes correspondant aux ports d'entrée et de sortie du module (pour l'exemple du module M6 de type"Dec", il y a cinq listes : celles repérées par les pointeurs & hdln~1, & hdln~2, & hdln~3, & hdOut~1 et & hdOuC2)
Une fois que toutes les informations relatives aux connexions réalisées antérieurement à l'appel de la fonction d'initialisation ont été envoyées vers l'objet d'extraction de topologie (c'est-à-dire lorsque le test de l'étape 64 donne

une réponse négative), les listes sont ensuite détruites, dans une étape 68, grâce à une fonction"DeleteListe"dont l'implémentation est à la portée de l'homme du métier et qui fait partie d'une bibliothèque accessible par les modules. Ceci est réalisé, par exemple pour la liste de stockage des

connexions associés au port d'entrée in~1 du module M6, par une instruction du type suivant : DeleteListe ( & hdln~1)))
Cette fonction"DeleteListe"permet de libérer l'espace mémoire réservé pour l'ensemble des éléments d'une structure de stockage associée à un port. Son implémentation est à la portée de l'homme du métier.

Il reste à exposer le traitement mis en oeuvre au niveau de l'objet d'extraction de topologie.

L'objet d'extraction de topologie reçoit l'adresse de chaque module qui lui est passée lors de l'appel de la fonction"MakeModule". Il reçoit aussi l'adresse de chaque signal relié à chaque port de chaque module, lors des appels aux fonctions de connexion inti et Outj respectives pour chacun de ces ports. Il stocke ces différentes adresses dans une structure de stockage de topologie déterminée. Dans un exemple, cette structure de stockage de topologie comprend un tableau et une liste générés dynamiquement par l'objet d'extraction de topologie. Lorsque l'ensemble des informations de topologie se rapportant au système ont été extraites, le tableau comporte autant de cellules renseignées qu'il y a de modules présents dans le système. Il est appelé tableau des modules dans la suite. De plus, la liste contient autant de cellules qu'il y a de connexions port/signal dans le système. Elle est appelée liste des connexions dans la suite.

Le tableau des modules, dans son état final (c'est-à-dire après l'exécution complète de la netlist décrivant le système), est illustré à la figure 7. Chaque cellule du tableau est représentée par une de ses lignes. On distingue ainsi onze cellules CO à C10, une par module du système de la figure 1. Les cellules sont renseignées dynamiquement, à chaque appel de la fonction "MakeModule". Sur la figure, la première cellule CO, d'indice 0 dans le tableau, a été créée en premier, et la onzième cellule C10, d'indice 10 dans le tableau, a été créée en dernier.

Chaque cellule comprend (de gauche à droite) : - un premier champ FC1 contenant l'adresse du module concerné ; - un deuxième champ FC2 contenant le type du module concerné ; et, - un troisième champ FC3 contenant une liste de paramètres ; ces paramètres sont constitués par toutes informations qui pourraient caractériser le module, et qui seraient transmises en paramètre par la fonction"dojnit".

Dans un exemple, la liste de paramètres a une longueur qui dépend du type du module. Ainsi, dans un exemple : - pour le type "Source", on a k paramètres notés Param~1 à Param~k ; - pour le type"Display", on a d paramètres notés Param~1 à Param~d ; - pour le type "Add", on a p paramètres notés Param~1 à Param~p ; - pour le type"Mult", on a q paramètres notés Param~1 à Param~q ; et, - pour le type"Dec", on a r paramètres notés Param~1 à Param~r.

L'ordre des cellules C0 à C10 est repéré en mémoire par un indice compris entre 0 et 10. Sur la figure 7, cet ordre correspond à l'ordre d'apparition des fonctions d'instanciation des modules M1 à M11 tel qu'il apparaît dans la netlist de l'Annexe 5.

La liste des connexions, dans son état final, est illustrée à la figure 8.

Elle comprend ici vingt cellules chaînées, une par connexion du système de la figure 1. Les cellules sont graphiquement représentées par des tableaux à une colonne et cinq lignes. Elles contiennent toutes les données nécessaires à la définition d'une connexion. Les cellules sont créées dynamiquement, à chaque appel de la fonction"SetLien", afin de ne pas réserver inutilement d'espace mémoire.

Ainsi que pour des raisons de clarté il est indiqué en regard de la cellule L4 seulement, chaque cellule comprend (de haut en bas) : - un premier champ FL1 contenant l'adresse du module concerné ; - un deuxième FL2 champ contenant l'adresse du signal concerné ; - un troisième champ FL3 contenant le type du port concerné (ENTREE ou SORTIE) ; et, - un quatrième champ FL4 contenant le numéro d'ordre du port dans le type pour le module concerné, et un cinquième champ contenant l'adresse de la cellule suivante de la liste.

L'ordre des cellules L0 à L19 de la liste telle que représentée sur la figure 8, correspond à l'ordre respectif des appels des fonctions inti et Out tel qu'il apparaît dans la netlist de l'Annexe 5. L'adresse T de la première cellule LO, appelée tête de liste dans la suite, est contenue dans une cellule mémoire particulière notée HL à la figure. A la figure 8, le cinquième champ de chacune des cellules LO à L18 contient symboliquement le vocable"next"pour désigner l'adresse de la cellule suivante dans la liste. Le cinquième champ de la dernière cellule L19 contient un pointeur vers une cellule mémoire particulière qui contient la valeur"NIL"pour indiquer qu'il n'y a pas de cellule suivante dans la liste.

Le tableau des modules représenté à la figure 7 et la liste des connexions représentées à la figure 8 contiennent à eux deux l'ensemble des informations nécessaires et suffisantes pour décrire la topologie du système. le tableau comprend une cellule par module, cette cellule contenant des informations caractérisant un module déterminé du système, et la liste contient une cellule par connexion, cette cellule contenant des informations caractérisant une connexion déterminée.

Les informations de topologie peuvent ensuite être lues dans la structure de stockage constitué de ce tableau et de cette liste par tout dispositif matériel et/ou logiciel en vue d'un traitement spécifique. En particulier ces informations peuvent être utilisées par un module de placement/routage pour concevoir l'implantation du système sur silicium, lorsque le système est un système microélectronique. Elles peuvent aussi être fournies en entrée d'un module d'affichage permettant de fournir une représentation graphique du système sur un écran, et/ou d'un module d'impression permettant d'imprimer un document tel qu'un schéma du système.

A partir de la structure de stockage de topologie comprenant le tableau et la liste représentés aux figures 7 et 8, on peut aussi créer une deuxième structure de stockage liste qui comprend un unique tableau contenant les informations sur les connexions entre les modules du système.

Un tel tableau est représenté par le schéma de la figure 9. Dans l'exemple, il comprend dix cellules notées TO à T9, une par signal du système.

Une cellule correspond à une colonne du tableau. Elle comprend quatre champs. Le tableau est donc un tableau à dix colonnes et quatre lignes.

Dans ce qui suit, on désigne par module entrant et module sortant, le module dont respectivement un port d'entrée ou un port de sortie est relié au signal. De plus, on désigne par numéro de port d'entrée et numéro de port de sortie le numéro dans son type, respectivement"ENTREE"ou"SORTIE"du port d'entrée et du port de sortie auquel ce signal est relié. Les quatre champs d'une cellule sont les suivants : - un premier champ FT1 contenant l'indice du module sortant tel que défini par l'ordre d'apparition de la fonction d'instanciation du module dans la netlist ; cet indice est l'indice est l'indice de la cellule correspondant à ce module dans le tableau des modules de la figure 7 ; - un deuxième FT2 champ contenant le numéro du port d'entrée ; - un troisième FT3 champ contenant l'indice du module entrant ; et, - un quatrième FT4 champ contenant le numéro du port d'entrée.

En résumé, la deuxième structure de stockage de topologie représentée à la figure 9 est un tableau comprenant une cellule par signal, chaque cellule contenant des informations caractérisant la liaison entre deux modules via ce signal.

Cette structure de stockage de topologie permet de répertorier toutes les connexions du circuit. En liaison avec le tableau des modules, on dispose alors de toutes les information sur la topologie du système (modules, paramètres et connexions).

Elle ne permet cependant pas, par exemple, de connaître rapidement les modules voisins de chaque module, ou de reconstituer le parcours d'une donnée déterminée dans le système. Pour ce faire on a besoin d'une représentation de la topologie qui soit une représentation orientée module.

A cet effet, on peut générer une troisième structure de stockage de topologie à partir de la première structure de stockage de topologie. Par exemple, on peut ajouter aux cellules du tableau des modules représenté à la figure 7, des champs supplémentaires qui renseignent sur les modules voisins immédiats du module, ou, de façon plus spécifique encore, sur la position du module dans la topologie du circuit.

Dans l'exemple représenté à la figure 10, on a ajouté à chaque cellule C0 à C11 du tableau des modules un quatrième champ FC4 qui contient un pointeur sur liste. Ce pointeur désigne l'adresse de la tête d'une liste de connexions associée au module, notée V0 à V11 respectivement. Cette liste est composée d'autant de cellules que le module présente de connexions, à raison d'une cellule par connexion.

Pour chaque cellule c à C11 du tableau des modules, chaque cellule de la liste associée respectivement V0 à V11, contient les six champs suivants (de gauche à droite) : - un premier champ FV1 qui contient le type du port du module concerné qui est connecté ; - un deuxième champ FV2 qui contient le numéro (dans son type) du port du module concerné qui est connecté ; - un troisième champ FV3 qui contient l'indice du module voisin auquel le port du module concerné est connecté ; - un quatrième champ FV4 qui contient le type du port du module voisin auquel le port du module concerné est connecté ; - un cinquième champ FV5 qui contient le numéro (dans son type) du port du module voisin auquel le port du module concerné est connecté ; et, - un sixième champ FV6 qui contient l'adresse de la cellule suivante dans la liste associée ; pour la dernière cellule de la liste associée, ce sixième champ FV6 contient un pointeur vers une cellule mémoire particulière qui contient la valeur"NIL"pour indiquer qu'il n'y a pas de cellule suivante dans la liste.

En résumé la troisième structure de stockage de topologie représentée à la figure 10 comprend un tableau comprenant une cellule par module du système, et dont chaque cellule comprend un champ FC4 contenant un pointeur sur liste, qui désigne une liste (VO à V10) des liaisons de ce module avec d'autres modules du système.

D'autres types de structure de stockage de topologie peuvent être imaginées, de complexités variables, selon l'application à laquelle on destine son utilisation (placement/routage, tracé de signaux, étude de la propagation des signaux, etc.).

On va maintenant décrire comment à partir des informations qui sont stockées dynamiquement dans la première structure de stockage de topologie (c'est-à-dire dans le tableau des modules de la figure 7 et dans la liste de la figure 8), on peut, au terme de la description du système, reconstituer la topologie de celui-ci, c'est à dire disposer de la liste des modules du circuit, ainsi que pour chacun d'entre eux, le détail de leurs liaison avec les autres modules (port à port). Nous nous bornerons ici à détailler le processus de reconstitution de la topologie, sachant que celle-ci peut être stockée de multiples façons, notamment dans la deuxième ou dans troisième structure de stockage de topologie décrites plus haut.

Le mécanisme de reconstitution est le suivant. Dans une étape 110, on accède à la cellule de tête de liste, dont l'adresse T est contenue dans la cellule mémoire HL. Cette cellule de tête de liste contient les informations caractérisant une connexion entre un port et un signal.

On va alors parcourir le reste de la liste à la recherche des cellules qui caractérisent des connexions sur le même signal. Dans un test 120, on se demande si la liste est vide (c'est-à-dire, en pratique, si l'adresse T est égale à NIL). Si la réponse est oui, alors le processus est terminé.

Si la réponse est non, alors, dans une étape 130, on stocke l'adresse du module concerné ainsi que le type du port et son numéro dans le type. Puis, dans une étape 140, on lit dans le champ FL2 de la cellule de tête de liste, l'adresse du signal concerné par la connexion. Dans une étape 150, on se demande ensuite si la cellule suivante dans la liste est la cellule NIL. Si la réponse est oui, cela signifie que le port du module concerné par la connexion n'est relié à aucun autre module, ce qui constitue une erreur. On traite alors cette erreur dans une étape 151, par exemple en générant une interruption 152.

Si la réponse est non, alors, dans une étape 160, on accède à la cellule suivante dans la liste. Ensuite, dans une étape 170, on lit l'adresse dans le champ FL2 de cette cellule suivante dans la liste, l'adresse du signal concerné par la connexion correspondante. Si les adresses des signaux concernés par les connexions de la cellule de tête de liste et de la cellule suivante, qui ont été lues aux étapes 140 et 170 respectivement, sont égales,

alors, dans une étape 180, on stocke l'adresse du module concerné ainsi que le type du port et son numéro dans le type.

Dans une étape 190, on se demande ensuite si la cellule suivante dans la liste est la cellule nulle. Si la réponse est non, alors on saute à l'étape 160 où l'on accède à cette cellule suivante non nulle.

Si au contraire la réponse est oui, alors, dans une étape 200, on stocke sous la forme désirée les informations relatives aux liaisons entre les différents modules reliés entre eux par le signal concerné par les connexions identifiées.

Par exemple, on peut stocker ces informations dans la deuxième ou la troisième structure de stockage de topologie présentées plus haut en regard des figures 9 et 10 respectivement.

Enfin, dans une étape 210, on supprime les cellules de la liste qui ont été traitées, et on saute à l'étape 110 pour accéder à la nouvelle cellule de tête de liste et répéter le processus.

ANNEXE 1 //------------------- déclaration du module-x

SC~MODULE (modutex) { //déclaration des ports d'entrée sc~in < type > in~1 ; sc~in < type > in2 ; suc-in < type > inn ; //déclaration des ports de sorties scout < type > out~1 ; sc~out < type > out~1 ; scout < type > out~m ; private : //ici la déclarations des variables privées du module //ici la déclaration des méthodes et fonctions privées du module //exemple : void do~init (types des paramètres) public : //ici la déclaration des variables publiques du module //ici la déclarations des fonctions publiques du module //exemple : do~init (paramètres par défaut) //-------------------------constructeur----------------------------

SCCTOR (module~x) { //ici l'initialisation des variables du module //ici la déclaration des sensitivités des méthodes du module

} } ; //------------------ fin de déclaration du module~x -----------------

//------déclaration du module~x-------SC~MODULE (module~x) { //déclaration des ports d'entrée suc-in < type > in~1 ; suc-in < type > in~2 ; suc-in < type > in~n- Ildéclaration des ports de sorties sc~out < type > out~1 ; sc~out < type > out~1 ; scout < type > out~m ; //déclaration liste de stockage des connexions des ports du module : structure~liste *hdln~1 ;

structure~liste *hdln~2 ; structure~liste *hdln~n ; structure~liste*hdOut~1 ; structure~liste *hdOut~2; ... structure~liste *hdOut~m ; //déclaration de l'objet d'extraction de topologie : classe~recup #Circuit ;

private : Il déclaration fonction d'envoi des infos de topologie : void do~send~info (void) ; //ici la déclaration des variables privées du module

//ici la déclaration des méthodes et fonctions privées du module public : /déclaration de la fonction d'initialisation du module : void do~init (classe~recup & , types des autres paramètres) ; //déclaration fonctions de connexion des ports du module : void In~1 (sc~signal < type > & ) ;

void In~2 (sc~signal < type > & ) ; void In~n (sc~signal < type > & ) ; void Out~1 (sc~signal < type > & ) ; void Out~2 (sc~signal < type > & ) ; ... void Out~m (sc~signal < type > & );

//ici la déclaration des variables publiques du module //ici la déclaration des fonctions publiques du module //----------------------------constructeur--------------------------SC~CTOR (modulex) f //initialisation des variables internes de stockage de topologie : hdln 1 = 0 ; hdln 2 = 0 ; -, hdln n = 0 ; hdOut~1 = 0 ; hdOut~2 = 0 ; hdOut = 0 ; //initialisation de la variable interne de stockage de l'objet //d'extraction de topologie : Circuit = 0 ; //ici l'initialisations des autres variables du module //ici la déclaration des sensitivités des méthodes du module } } ; //.------fin de déclaration du module~x------

SC~MODULE (Dec) { //déclaration des ports d'entrée du module :

scin < type > in~1 ;//Entrée in~1 du module scin < type > in~2 ;//Entrée in~2 du module scjn < type > in~3 ;//Entrée in~3 du module //déclaration des ports de sortie du module : scout < type > out~1; //Sortie out~1 du module scout < type > out~2; //Sortie out~2 du module //déclaration des variables de stockage de topologie :

structure-liste *hdln~1 ; structure-liste *hdln~2 ; structure-liste *hdln~3 ; structure~liste *hdOut~1 ; structure~liste *hdOut~2 ; //déclaration de l'objet d'extraction de topologie :

classe~recup *Circuit ; private : //déclaration de la fonction d'envoi des informations de topologie : void dosendjnfo (void) ; //ici la déclarations des variables privées du module //ici la déclaration des méthodes et fonctions privées du module public : //déclaration de la fonction d'initialisation du module : void do~init (classe~recup & , types des autres paramètres) ; //déclaration de la fonction de connexion sur in~1 :

void In~1 (sc~signal < double > & ) ; //déclaration de la fonction de connexion sur in~2 void In~2 (sc~signal < double > & ) ; //déclaration de la fonction de connexion sur in~3 void In~3 (sc~signal < double > & ) ; //déclaration de la fonction de connexion sur out 1 : void Out~1 (sc~signal < double > & ) ; //déclaration de la fonction de connexion sur out2 : void Out~2 (sc~signal < double > & ) ; //ici la déclaration des variables publiques du module //ici la déclaration des fonctions publiques du module //----------------------contructeur----------------------------SC~CTOR (Dec) {

//initialisation des variables internes de stockage de topologie : hdln 1 =0 ; hdln 2 =0 ; hdln = 0 ; hdOut 1 = 0 ; hdOut~2 = 0 ; //initialisation de la variable interne de stockage de l'objet //d'extraction de topologie : Circuit = 0 ; //ici l'initialisation des autres variables du module //ici la déclaration des sensitivités des méthodes du module } } ;

ANNEXE 4 //déclaration des signaux : sc~signal < type > f1, f2, f3, f4, f5, f6, f7, f8, f9, f10 //déclaration de l'objet d'extraction de topologie : classe~recup Circuit (paramètres) ; //déclaration des modules

Source M1 ("M1") ; Source M2 ("M2") ; Source M7 ("M7") ; Source M8 ("M8") ; Source M9 ("M9") ;

Display M5 ("M5") ; Display M10 ("mao") Display M11 ("M11") ; Add M3 ("M3") ; Mult M4 ("M4") ; Dec M6 ("M6") ; //itialisation des modules :

MI. do-init (paramètres) M2. dojnit (paramètres) ; M7. do-inuit (paramètres) ; M8. do!nit(paraées) M9. do-init (paramètres) M5. doinit (paramètres) ; M10.d0~init(paramètres) ; M11.do~init(paramètres) ;
M3. do~init (paramètres) ; M4. do~init(paramètres)

M6. doinit (paramètres) ; //connexion des modules aux signaux : M1. out (f1) ; M2. out (f2) ; M7. out (f6) ; M8. out (f7) ; M9. out (f8) ; M5. in (f5) ; M10. in (f9) ; M11. in (f10) ;

M3. in~1 (f1) ; M3. in~2 (f2) ; M3. out (f3) ; M3. out (f4) ; M4. in (f3) ; M4. out (f5) ; M6. ion~1 (4) ; M6. ion~1 (6) ;

M6. in 2 (7) ; M6. in~3 (f8) ; M6. out~1 (f9) ; M6. out~2 (f10) ;

ANNEXE 5 Ildéclaration des signaux : sclsignai < type > fl, f2, f3, f4, f5, f6, f7, f8, f9, f 10 //déclaration de l'objet d'extraction de topologie : classe~recup Circuit (paramètres) ; //déclaration des modules Source M1 ("M1") ; Source M2 ("M2") ; Source M7 ("M7") ; Source M8 ("M8") ; Source M9 ("M9") ; Display M5 ("M5") ; Display M10 ("M10") ; Display M11 ("M11") ; Add M3 ("M3") ; Mult M4 ("M4") ; Dec M6 ("M6") ; /initialisation des modules : Ml do-in it (C ircu it, autres paramètres) M2. do~init (Circuit, autres paramètres) ; M7. do-init (Circuit, autres paramètres) M8. do-in it (Circu it, autres paramètres) M9. do~init (Circuit, autres paramètres) ; M5. do~init (Circuit, autres paramètres) ; MIO. do-init (Circuit, autres paramètres) M11. dojnit (Circuit, autres paramètres) ; M3. do init (Circuit, autres paramètres) ; M4. dojnit (Circuit, autres paramètres) ; M6. dojnit (Circuit, autres paramètres) ; /connexion des modules aux signaux : M1. 0ut (f1) ; M2. 0ut (f2) ; M7. 0ut (f6) ; M8. 0ut (f7) ; M9. 0ut (f8) ; M5. 1n (f5) ; M10. h (f9) ; M11. ln (f10) ; M3. ln~1 (f1) ; M3. 2 (f2) ; M3. 0ut (f3) ; M3. 0ut (f4) ; M4. n (f3) ; M4. 0ut (f5) ; M6. 1n~1 (f4) ; M6. ln~1 (f6) ; M6. ln~2 (f7) ; M6. 3 (f8) ; M6. 0ut~1 (f9) ; M6. 0ut~2 (f10) ;

ANNEXE 6 //------------------------fonctionIn~1------------------------ void Dec : : In~1 (scsignal < type > & p) { //si le module appartient à un système if (Circuit) //alors on envoie l'info de connexion à l'objet Circuit
Circuit- > SetLien (this, & p, ENTREE, 0) ; else //sinon on stocke l'adresse du signal connecté
AddLien ( & hdln~1, & p) ;

in~1 (p) ;//réalisation de la connexion du signal p au port in~1 } //----------------------fin fonction In~1--------------------------- 11-------------------------- c2o---n2--------void Dec : : In~2 (sc~signal < type > & p) { Iisi le module appartient à un système if (Circuit) //alors on envoie l'info de connexion à l'objet Circuit
Circuit- > SetLien (this, & p, ENTREE, 1) ; else //sinon on stocke l'adresse du signal connecté
AddLien ( & hdln~2, & p) ; in~2 (p) ;/réalisation de la connexion du signal p au port in~2 } //finfonctionIn~2------------------------ //-------fonction In3--------- void Dec : : In~3 (sc~signal < type > & p) { //si le module appartient à un système if (Circuit) //alors on envoie l'info de connexion à l'objet Circuit
Circuit- > SetLien (this, & p, ENTREE, 2) ; else //sinon on stocke l'adresse du signal connecté
AddLien ( & hdln~3, & p) ; in~3 (p) ; //réalisation de la connexion du signal p au port in~3 } //------------------------finfonctionIn~3------------------------

//------------------------fonctionOut~1------------------------ void Dec : : Out~1 (sc~signal < type > & p) { //si le module appartient à un système if (Circuit)
Ilalors on envoie l'info de connexion à l'objet Circuit Circuit- > SetLien (this, & p, SORTIE, 0) ; else

//sinon on stocke l'adresse du signal connecté AddLien ( & hdOut~1, & p) ; out~1 (p) ;//réalisation de la connexion du signal p au port out 1 } //------------------------fin fonction Out 1------------------------- //----------------bnction Out~2--------- void Dec : : Out~2 (sc~signal < type > & p) { Iisi le module appartient à un système if (Circuit) Ilalors on envoie l'info de connexion à l'objet Circuit Circuit- > SetLien (this, & p, SORTIE, 1) ; else //sinon on stocke l'adresse du signal connecté

AddLien ( & hdOut~2, & p) ; //réalisation de la connexion du signal p au port out 2 out-2 (p }

//-------------------------fin foncfion Ou2------- //-----------------------fonction do-send info---------------------- void Dec : : do~send~info (void) { if (Circuit ! = 0) {//si le module appartient à un système Il envoi de l'adresse du module

Circuit- > MakeModule (this,"Dec") ; Iienvoi des infos de connexion stockées pour ce module Ilpour le port d'entrée in~1 : if (hdln~1) { structrue-liste *ptr ; for (ptr = hdln~1 ; ptr ! = 0 ; ptr = ptr- > next)

Circuit SetLien (this, ptr- > adresse, ENTREE, 0) ; } ; Ilpour le port d'entrée in~2 ; if (hdln~2) { structure~liste *ptr ; for (ptr = hdln~2 ; ptr ! = 0 ; ptr = ptr- > next) Circuit SetLien (this, ptr- > adresse, ENTREE, 1) ; } ; Ilpour le port d'entrée in~3 :

if (hdln~3) { structure-liste *ptr ; for (ptr = din~3 ; ptr ! = 0 ; ptr = ptr- > next) Circuit- > SetLien (this, ptr- > adresse, ENTREE, 2) ; } ; Ilpour le port de sortie out 1 : if (hdOut~1) { structure~liste *ptr ; for (ptr = hdOut~1 ; ptr ! = 0 ; ptr = ptr- > next)

Circuit SetLien (this, ptr- > adresse, SORTIE, 0) ; } ; Ilpour le port de sortie out 2 : if (hdOut~2) { structure~liste *ptr ; for (ptr = hdOut~2 ; ptr ! = 0 ; ptr = ptr- > next)
Circuit- > SetLien (this, ptr- > adresse, SORTIE, 1) ; } ; } else { //gestion erreur

} ; //liberation des variables de stockage des informations de topologie : DeleteListe ( & hdln~1) ; DeleteListe ( & hdln~2) ; DeleteListe ( & hdln~3) ; DeleteListe ( & hdOut~1) ; DeleteListe ( & hdOut~2) ; } //----------------------fin fonction do-send info-------------------- //---------bnction do~init-------------------------void Dec : : dojnit (classerecup & c) { lion teste si la fonction do~init a déjà été appelée if (Circuit ! = 0) Ilici gestion de l'erreur : do-init appelée plusieurs fois else

Il mise en mémoire de l'adresse de l'objet circuit
Circuit = & c ; //envoi de infos de topologie vers l'objet circuit do~send~info () ; }

//----------------------fin fonction do~init------------------------

ANNEXE 7 classerecup : : SetLien (void* adresse~module, sc~signal < type > * adresse~signal, Port~type type~du~port, int portnum) { //définition d'un pointeur sur une nouvelle cellule :

stock~cellule *nouvelle~cellule ; //réservation de l'espace mémoire pour la nouvelle cellule : nouvelle~cellule = new (stock~cellule) ; //renseignement de la nouvelle cellule : nouvelle-cellule- > AddModule = adresse~module ; nouvelle~cellule- > AddSignal = adresse~signal ; nouvelle cellule PortType = type~du~port ; nouvelle cellule PortNum = port~num ; nouvelle~cellule- > next = HeadList ; //ajout en tête de la liste ListeStockageTopologie, qui est une //variable de l'objet classe-recup, de la nouvelle cellule //constituée et renseignée :

AddCellule (ListeStockageTopologie, nouvelle-cellule) ; //ou plus simplement"addCellule".

}

Claims

REVENDICATIONS

1. Procédé de production de données représentant la topologie d'un système qui comprend un ou plusieurs modules (M1-M11) ayant chacun un nombre déterminé de ports d'entrées et un nombre déterminé de ports de sortie et reliés entre eux par des signaux déterminés (f1-f10), à partir de la description textuelle du système dans un langage orienté objet, suivant lequel : a) on introduit dans la déclaration de chaque module du système : - la déclaration (21) d'une fonction d'initialisation du module comprenant en paramètre un identifiant d'un objet d'extraction de topologie et recevant, lorsqu'elle est appelée, l'adresse dudit objet d'extraction de topologie ; - la déclaration (22) de fonctions de connexion respectives (in. Out) pour chacun des ports d'entrée (in~i) et des ports de sortie (outj) du module comprenant en paramètre un identifiant d'un signal relié audit port, et recevant, lorsqu'elle est appelée, l'adresse dudit signal ; - la déclaration (23) d'une première variable interne adaptée pour stocker l'adresse de l'objet d'extraction de topologie ; - la déclaration (24) d'autres variables internes respectivement associées à chacun des ports d'entrée et des ports de sortie du module, et adaptées pour contenir l'adresse d'une structure de stockage associée ; - l'initialisation (25) desdites première et autres variables internes à une valeur initiale déterminée respective ; b) on introduit, dans la description textuelle du système et dans un ordre quelconque : - l'appel de la fonction d'initialisation (36) de chaque module, avec un identifiant de l'objet d'extraction de topologie en paramètre ; - l'appel de la fonction de connexion (35) de chaque port de chaque module, autant de fois qu'il y a de signaux respectifs reliés à ce port, avec à chaque fois un identifiant du signal concerné en paramètre ;

c) la fonction de connexion de chaque port de chaque module, d'une part, réalise (44) la connexion à ce port du signal dont l'identifiant est spécifié en paramètre, et d'autre part envoie (42) l'adresse de ce signal à l'objet d'extraction de topologie si la fonction d'initialisation du module a déjà été appelée ou enregistre (43) cette adresse dans la structure de stockage associée audit port si la fonction d'initialisation du module n'a pas encore été appelée ; d) la fonction d'initialisation de chaque module enregistre (53) l'adresse de l'objet d'extraction de topologie dont l'identifiant est spécifié en paramètre dans ladite première variable interne du module, envoie (54) l'adresse et le type fonctionnel du module à l'objet d'extraction de topologie, et, le cas échéant, envoie (67) pour chaque port du module les adresses respectives de chaque signal relié à ce port qui ont été préalablement stockées dans la structure de stockage associée audit port ; e) l'objet d'extraction de topologie reçoit l'adresse de chaque module, et l'adresse de chaque signal relié à chaque port de chaque module, et les stocke dans une structure de stockage de topologie déterminée.

2. Procédé selon la revendication 1, suivant lequel la fonction de connexion de chaque port de chaque module a pour nom le nom dudit port avec la première lettre en majuscule et les lettres suivantes en minuscules.

3. Procédé selon la revendication 1 ou la revendication 2, suivant lequel l'identifiant du signal spécifié en paramètre lors de l'appel de la fonction de connexion de chaque port de chaque module est le nom dudit signal.

4. Procédé selon l'une quelconque des revendications précédentes, suivant lequel l'identifiant de l'objet d'extraction de topologie spécifié en paramètre de l'appel de la fonction d'initialisation de chaque module est le nom dudit objet.

5. Procédé selon l'une quelconque des revendications précédentes, suivant lequel la structure de stockage associée à chacun des ports de chaque module est une liste.

6. Procédé selon l'une quelconque des revendications précédentes, suivant lequel la structure de stockage de topologie comprend un tableau (Figure 7) et une liste (Figure 8), le tableau comprenant une cellule par module chacune contenant des informations caractérisant un module déterminé du système, et la liste contenant une cellule par connexion chacune contenant des informations caractérisant une connexion déterminée.

7. Procédé selon l'une quelconque des revendications 1 à 5, suivant lequel la structure de stockage de topologie est un tableau (Figure 9) comprenant une cellule par signal, chaque cellule (TO-T9) contenant des informations caractérisant la liaison entre deux modules via ce signal.

8. Procédé selon l'une quelconque des revendications 1 à 5, suivant lequel la structure de stockage de topologie (Figure 10) comprend un tableau comprenant une cellule par module du système, et dont chaque cellule comprend un champ (FC4) contenant un pointeur sur liste, qui désigne une liste (V0-V10) des liaisons de ce module avec d'autres modules du système.