3.3 Principe de Fonctionnement de l’Outil
3.3.5 Algorithmes pour la Constitution de l’Environnement de MCI
La cosimulation se déroule en trois étapes importantes :
– La première est la constitution de la structure de données à partir du fichier de
coordina-tion. Elle met en place un routeur qui se réfère à cette structure pour aiguiller l’ensemble
des données qui transitent entre les modules.
– La seconde étape est l’exécution des différentes interfaces avec leurs paramètres,
l’éta-blissement des connexions avec le routeur. Les interfaces (une par simulateur) ont un rôle
de gestion des données entre le simulateur et une mémoire partagée servant de tampon.
Elles s’occupent d’échanger correctement les données entre le routeur et le simulateur
conformément aux règles de synchronisations et en fonction du simulateur.
– La dernière étape est l’opération de routage consistant à orienter les données en fonction
du fichier d’interconnexion, de vérifier et de faire les éventuelles concordances de types,
de réaliser les adressages multiples, les conversions et les résolutions de types. Cette étape
est appelée le mode établi.
3.3.5.1 Initialisation de la Cosimulation
Le processus de lancement de la cosimulation est schématisé sur la figure 3.6. Le premier
processus lancé par l’utilisateur (symbolisé par 1 sur la figure 3.6a) est MCI. Nous appelons ce
processus le routeur, car son rôle principal en mode établi est le routage des données. Il lit le
fichier de coordination (2) et construit une structure de données adaptée qui sera utilisée tout
au long de l’exécution par le routeur des données. Une fois sa structure constituée, le routeur
10
Un fichier “package” est une bibliothèque pour le VHDL. C’est un fichier contenant des déclarations de types,
de procédures, d’instances, etc.. Pour l’utiliser, il faut le référencer par la directive “use”.
Principe de Fonctionnement de l’Outil 84
exécute autant de processus interfaces (3) qu’il y a de modules dans le fichier de coordination.
Dans le cas où le module doit être exécuté sur une autre machine, le lancement de l’interface
doivent s’effectué sur la machine cible. Le routeur créé deux “sockets” :
– une “socket” locale proposant une connexion aux interfaces (modules) s’exécutant sur la
machine locale du routeur,
– une “socket” de domaine Internet pour proposer la connexion des interfaces distantes.
Après un moment d’attente, le routeur établit enfin la connexion entre lui même et les différentes
interfaces qu’il a exécutées. Toutes les informations communiquées entre le routeur et les
in-terfaces sont désormais transmises via ce support de communication. Le routeur se met alors
en veille dans l’attente d’une identification de ses différentes interfaces via la “socket”. Cette
identification précise que l’interface a bien fonctionné, que le simulateur s’est bien exécuté, que
l’échange des données est bien opérationnel et que la simulation peut donc démarrer.
Avant de démarrer, les interfaces communiquent au routeur la liste des ports qu’elles ont
détectée. En échange, le routeur vérifie la cohérence de ces ports et transmet aux interfaces des
numéros associés à chaque port. Ces numéros permettent d’accélérer la vitesse des échanges
entre le routeur et les interfaces, en référençant les données modifiées uniquement par ces
nu-méros.
La relation qui existe entre le routeur et ses interfaces se résume en une adaptation et une
synchronisation des modules, quelque soit leur type et leur distance. C’est la modélisation du
bus de cosimulation. Les interfaces sont des processus qui permettent de relier les simulateurs
et le bus de cosimulation. Elles ont aussi pour rôle de créer la mémoire tampon et de lancer les
simulateurs pour enfin échanger les données vers le routeur.
Le flot d’exécution de l’interface, représenté sur la figure 3.6b, se compose tout d’abord
d’un sémaphore de synchronisation général (4) qui se bloque au premier appel. Ce sémaphore
permet d’exécuter une à une les interfaces, s’il est nécessaire de lancer plusieurs interfaces sur la
même machine. Ceci est très important si l’on veut éviter d’avoir des problèmes de connexions
entre un simulateur et une interface qui ne lui est pas associée. L’interface crée ensuite une
mémoire partagée (5) qui lui sert d’intermédiaire avec le simulateur et lance le simulateur avec
le modèle à simuler (6). L’interface se met en veille et attend la modification de la mémoire
partagée qui doit se faire par le simulateur. Si cette modification n’intervient pas au bout d’un
certain temps, l’interface considère, soit que le simulateur ne contient pas d’EXINS-EXOUTS,
soit qu’il n’arrive pas à se connecter à cette mémoire partagée pour quelque raison que ce soit.
Dans ce cas l’environnement de cosimulation s’arrête et tue tous les processus et simulateurs
lancés.
Lors de son initialisation, le simulateur appelle la primitive d’initialisation des EXINS
-EXOUTS. Cette procédure se connecte simplement sur la mémoire crée par l’interface (7) et
écrit les ports à cosimuler dans la mémoire partagée. Elle débloque donc l’interface qui s’était
mise en veille (8).
L’interface, qui a désormais détecté la présence de données dans la mémoire, communique
les ports inscrits vers le routeur (étape d’identification), lève le sémaphore global (9) et se
pré-pare au début des échanges.
Les interfaces se servent de la mémoire partagée (fig. 3.7) comme de mémoire tampon
entre les simulateurs et les interfaces. Elles créent également des sémaphores qui se chargent
de synchroniser les lectures et écritures des données dans cette mémoire. Les références des
sémaphores sont inscrites dans la mémoire partagée par l’interface qui les crée. Ces références
Principe de Fonctionnement de l’Outil 85
1
Fichier
de
coordination
Interface Interface Interface
Envoit Recoit Envoit Recoit Envoit Recoit
Envoit Recoit
Routeur
3
3
3
2
(a)
Interface
Exin Exout
Modèle simulé
Simulateur
Envoit Recoit4
5
6
7
8 8
9
(b)
CréationConnection Inscription Inscription
Mémoire Partagée
Ouvre sémaphore
Ferme Sémaphore
FIG. 3.6 – Ordre d’exécution des processus
Numéro Type Taille valeur Ptr valeur Nom port ’\0’ Valeur
Status
Ptr suivant Ptr premier
Entete de controle List des ports
Temps courant Temps imposé Numéro Element 1 Element 2 Element N
Constitution d’un port dans la mémoire Num SEM
Principe de Fonctionnement de l’Outil 86
ê êë êë êë êë êë êë ì ì ì ì ì ì í í í í í íInterface
Interface
Exin
Mémoire partagée
Modèle simulé
Exout
Mémoire partagée
Ecrit Int Int LitModèle simulé
Routeur
Conversion Aiguillage RésolutionFIG. 3.8 – Flot de transfert d’une donnée modifiée
peuvent être utilisées à tout moment par un simulateur pour se connecter au sémaphore de
syn-chronisation des lectures et écritures de cette mémoire.
3.3.5.2 Schéma Explicatif du Fonctionnement de MCI durant l’Exécution de la
simula-tion
En mode établi, c’est à dire lorsque l’ensemble des processus interfaces et simulateurs
fonc-tionne correctement, le routeur de MCI se charge d’aiguiller les données modifiées. La figure
3.8 représente le parcours complet d’une donnée lorsqu’elle est modifiée entre deux modules.
Dans le cas présenté, ces deux modules sont distants, mais le fonctionnement reste similaire
si ces deux modules fonctionnent sur la même machine. Tout d’abord, chaque simulateur est
lancé et a créé, à son initialisation, l’ensemble des ports cosimulés dans la mémoire partagée.
Les interfaces sont en mode veille lorsqu’aucune donnée ne transite dans l’environnement. Si
un simulateur modifie une donnée en écriture, celle-ci est écrite dans la mémoire partagée via
l’Exout. Aussitôt, l’interface se réveille et intercepte la donnée pour la communiquer au routeur
via la “socket”. Le premier mécanisme de synchronisation consiste à lire toutes les données
modifiées sans en perdre une seule et s’assurer que les données sont transitées dans l’ordre de
leur modification. Par sa structure, le routeur reconnaît le port qui communique la donnée et
élabore la liste des connexions pour ce port. Pour tous les ports connectés, le routeur écrit la
donnée traitée dans les “socket” correspondantes. L’arrivée d’une donnée réveille l’interface qui
se trouve en réception et l’écrit au bon emplacement dans la mémoire partagée, pour enfin se
remettre en veille. Le modèle récepteur (le simulateur destinataire) peut alors lire cette donnée
modifiée à sa demande via un port Exin.
Afin de gérer un parallélisme dans l’arrivée des données, le routeur utilise des “threads”.
Il crée autant de “threads”, qu’il y a d’interfaces. Les “threads” sont très pratiques car ils ont
la particularité d’être multi-processus tout en partageant la même structure de données. Un
système de synchronisation entre “threads” est utile si le routeur doit traiter des résolutions
multiples ou des priorités dans les signaux qui transitent.
On s’aperçoit que le routage des données doit respecter un chemin particulier. Il convient
donc à l’utilisateur de définir ce ou ces chemins dans un format suffisamment complet pour
définir les interconnexions et toutes les propriétés nécessaires au bon fonctionnement de
l’envi-Coordination Inter-Modules 87
ronnement. L’ensemble de ces informations forme la structure de données du routeur et provient
du fichier de coordination écrit en SOLAR [JO94].
Dans le document
Cosimulation multiniveaux dans un flot de conception multilangage
(Page 85-89)