L’approche par composants

Nous avons donc, cherché une méthode plus directe permettant de construire un modèle équivalent en VHDL de manière directe avec les mêmes éléments de base des réseaux de Petri, c’est à dire en utilisant des places et des transitions. Pour ce faire, nous avons pris, sur une suggestion de notre collègue du LAAS, A. NKETSA [CEN04], une approche par composants [ABG04] présentée par l’équipe de monsieur David ANDREU du LIRMM. Dans cette approche, deux composants de base sont utilisés pour générer la totalité de l’ensemble.

Dans le schéma de la Figure 3-13, nous présentons la méthode que nous avons implémenté dans HiLeS Designer pour convertir la représentation graphique des réseaux de Petri en une représentation écrite en langage VHDL-AMS. De la même manière que nous l’avons fait pour générer la netlist de TINA, nous parcourons d’abord la totalité du projet à la recherche des places, des transitions et des arcs. Avec ces éléments et en utilisant un composant VHDL pour les Places et un autre pour les transitions nous construisons un fichier .vhd équivalent. Nous reproduisons la topologie entièrement sur ce fichier. Il est nécessaire de préciser que le modèle utilise des signaux supplémentaires pour assurer la gestion des jetons dans le réseau : Ajouter et/ou enlever. Nous avons réalisé cette deuxième implémentation en utilisant le logiciel SystemVision de Mentor Graphics.

Le fonctionnement des composants représente bien celui des réseaux de Pétri. Les transitions attendent que toutes leurs places amont soient marquées pour ensuite être franchies et, ainsi, placer un jeton sur chacun des jetons en aval. Pour réaliser cette gestion des jetons, le modèle dispose des signaux qui « remontent » dans le réseau afin d’enlever les jetons de leurs places en amont une fois que les transitions son franchies. Le modèle prévoit aussi une indication permanente du marquage du réseau.

SystemVision SystemVision Simulation Simulation HiLes DesignerHiLes Designer Composants VHDL équivalents E x tr a c tio n d u r é se a u , g é n é ra tio n d u c o d e V H D L

Figure 3-13. Schéma de fonctionnement du mécanisme d’extraction des réseaux de Petri vers VHDL-AMS.

Par rapport aux interconnexions entre objets, du modèle de composants de nos collègues du LAAS et du LIRMM [ABG04], les places et les transitions comportent des entrées et des sorties de taille variable, elles sont construites avec des vecteurs de taille n qu’il faut initialiser selon la topologie du réseau. Par exemple, une transition avec deux arcs d’entrée et trois arcs de sortie aura un vecteur d’entrée de deux positions et un vecteur de sortie de trois, ce principe est aussi appliqué pour les places. Cette caractéristique donne une bonne capacité de configuration et de la flexibilité à l’approche. En revanche, elle la rend difficile au moment de l’utiliser directement avec des outils de saisie schématique.

Suivant le principe considéré précédemment (§3.5.2.1), en modifiant la méthode CoNPAR, nous avons tenté de modéliser le fonctionnement de base des réseaux. De cette manière, il est possible de concevoir un modèle asynchrone, dans la mesure où c’est la présence ou non d’un jeton et la possibilité ou non de franchissement de transition qui fait fonctionner le modèle et non le cadencement d’une horloge extérieure. Malgré tout, il est évident que rares sont les systèmes en électronique qui ne disposent pas d’horloge. Donc, selon les besoins de l’utilisateur, il est intéressant d’avoir le choix des deux modèles.

Quel que soit le modèle choisi, la démarche a été la même, c'est-à-dire l’encapsulation. De fait, après avoir créé les deux composants, on appelle ces derniers depuis un autre fichier, que nous pouvons considérer comme un macro composant qui a pour rôle la description complète de la topologie du réseau à modéliser. Puis on utilise un testbench afin de pouvoir gérer les paramètres du réseau (les conditions de franchissement des transitions, la génération de l’horloge, l’initialisation du

réseau...). Nous présentons ci-dessous les détails des composants utilisés, leur version asynchrone et synchrone :

Composant place asynchrone

Le signal init permet d’imposer ou non un marquage initial de la place. Si init est à ‘1’ alors la marque de la place prend la valeur de ini_jetons. Sinon on rentre dans une boucle de calcul de la marque en tenant compte du nombre de jetons qui arrivent sur la place (aj_jetons) et ceux qu’on enlève (ret_jetons). Ensuite la valeur logique du résultat est chargée dans marque.

Figure 3-14 Composant place

asynchrone

Composant transition asynchrone

Figure 3-15. Composant

transition asynchrone

c_t : condition associée à la transition ; type_transit_e & type-transit_s : précise le type d’arc d’entrée de la transition (arc normal, inhibiteur, test) ; marque_tie : marquage des places d'entrées ; ret_amont : marque à retirer des places amont de la transition ; aj_aval : marque a ajouter dans les places aval de la transition

Pour le modèle asynchrone, nous rajoutons le paramètre générique temporel (t) sur les composants place et transition. En fait celui ci correspond au temps minimum pour calculer la marque de la place. Pour ce faire, il faut imposer ce temps soit sur le composant place soit sur le composant transition. C’est à nous de l’utiliser sur l’un ou sur l’autre en fonction du besoin.

Composant place synchrone

Figure 3-16. Composant place

Composant transition synchrone

Figure 3-17 Composant

transition synchrone

Pour le modèle synchrone nous supprimons le paramètre générique temporel (t). En revanche, nous rajoutons une entrée supplémentaire pour l’horloge sur le composant place et nous modifions légèrement les fichiers.

Pour l’implémentation du modèle sous SystemVision, nous avons dû faire une modification sur les composants de base. Dans le modèle initial un package avait été créé pour pouvoir gérer facilement le type d’arc attaquant les transitions. Le package déclarait un tableau de vecteur de deux bits et de longueur le nombre d’arcs entrant (voir ci-dessous).

library ieee;

use ieee.std_logic_1164.all;

package rdp is

type typ_arc_vector is array(natural range <>) of std_logic_vector(1 downto 0); component place ….. end component; component transition ……… end component; end rdp;

Les trois types d’arcs existants sont définis de la manière suivante :

constant arc_classique :std_logic_vector(1 downto 0) :="00"; constant arc_test :std_logic_vector(1 downto 0) :="10"; constant arc_inhibiteur :std_logic_vector(1 downto 0) :="11";

Parmi eux, uniquement l’arc classique est utilisé dans HiLeS. Nous avons gardé les autres en tant que constituants du modèle de base.

Pour décrire l’arc qui arrive sur la transition, on utilise donc les deux vecteurs : type_transit_e : in std_logic_vector((nb_entrees-1) downto 0); type_transit_s : in std_logic_vector((nb_entrees-1) downto 0);

Le premier bit des signaux arc_classique, arc_test, arc_inhibiteur correspond au vecteur type_transit_e et le deuxième bit correspond à type_transit_s.

Aussi pour mettre en œuvre le modèle asynchrone, nous avons utilisé l’instruction « wait on » sur le composant place. En fait cette l’utilisation des « wait on »’ permet d’attendre un évènement sur le signal déclaré. Ainsi le calcul de marquage ne se fait pas avant un changement de celui-ci.

Cependant l’insertion d’un délai (after) a été nécessaire pour assurer la prise en compte de tous les événements.

Ainsi donc le composant place a un paramètre générique temporel qui doit être absolument en adéquation avec le temps imposé pour l’initialisation du réseau via le signal “init’’. Cependant ce facteur possède un large domaine de validité, il peut varier entre une dizaine de microsecondes et une centaine de picosecondes. La seule obligation est la cohérence entre les deux paramètres temporels, celui du composant place et celui du testbench. L’annexe B illustre un exemple de traduction d’un reseau de Petri en VHDL simulé sous un outil VHDL-AMS et généré automatiquement par HiLeS Designer0.

3.5.3 Connexion des modèles équivalents des blocs et des réseaux de