Architecture des bibliothèques de Cosimulation

Les ports à cosimuler, déclarés dans les modèles, sont liés à des bibliothèques fournies par

l’environnement de MCI. Ces bibliothèques permettent en effet, aux ports déclarés de

com-muniquer avec l’environnement de la cosimulation. Elles sont propres à chaque simulateur et

leur principe de fonctionnement doit être simple. Plus le développement d’une bibliothèque est

court, plus la réalisation de l’intégration d’un nouvel outil est rapide (“plugin”). C’est une des

raisons pour lesquelles les primitives d’accès à l’environnement de cosimulation sont de la plus

grande simplicité et revêtent la forme suivante :

– AddNewCosimPort : Insertion d’un nouveau port à l’initialisation d’un simulateur,

– WriteValue (Ecrire une valeur) ReadValue (Lire une valeur )

– WriteEvent (Ecrire un événement) ReadEvent (Lire un événement)

– EndTimedStep (Fin de pas de simulation pour la cosimulation temporelle à plus bas

ni-veau)

Principe de Fonctionnement de l’Outil 81

Ces primitives sont proposées par une bibliothèque propre à MCI (bibliothèque dynamique

libliste.so) et sont utilisées pour toutes les nouvelles bibliothèques qui doivent être réalisées.

La construction des bibliothèques ne suit pas un schéma spécifique, elles dépendent des

simulateurs. Pour chaque langage, nous présentons les aspects principaux de la construction

des différentes bibliothèques :

1. Le langage C

La bibliothèque du langage C est la plus simple à concevoir. Elle consiste à définir dans un

programme C les fonctions associées aux primitives (CPort<Type>Decl, Output<Type>,

etc..). Ce programme C sera ensuite compilé en une bibliothèque statique ou dynamique

libexinexoutc.a qui est utilisée pour chaque modèle C de l’environnement de

cosimula-tion. L’association de la bibliothèque au modèle se fera lors de l’édition de lien avant la

simulation.

2. Le langage VHDL

La bibliothèque est réalisée par l’intermédiaire de l’outil cli pour VSS de Synopsys, et

par le compilateur C gcc pour Leapfrog. Dans les deux cas, la construction est similaire.

Elle consiste pour Synopsys à créer une bibliothèque libCLI.so et pour Leapfrog à générer

une bibliothèque libfmi.so. Ces deux bibliothèques sont liées aux modèles à simuler lors

de l’élaboration. Pour fabriquer la bibliothèque dynamique, il faut réaliser un programme

C à partir de fonctions prototypes fixées par les distributeurs des logiciels. Ces

primi-tives diffèrent suivant les fournisseurs, mais utilisent un formalisme qui doit être respecté

pour chaque port réalisé ( cf. Documentation CLI et/ou Documentation FMI). VSS, le

simulateur de Synopsys, utilise trois primitives principales : EXINEXOUT_Open pour

l’ouverture du modèle à simuler par le simulateur, EXINEXOUT_Eval lors de

l’appa-rition d’un événement sur le port et EXINEXOUT_close pour terminer la simulation.

Leapfrog en utilise deux : C_init appelé à chaque nouveau statut du simulateur

(démar-rage, sauvegarde, restitution du contexte, etc..) et C_stim à chaque événement sur un port

(premier appel, événement, passage à zéro, etc..). En plus, un très grand nombre de

fonc-tions peut être utilisé dans le but d’extraire des informafonc-tions du simulateur.

De plus, il faut établir un paquetage

¹⁰

VHDL décrivant les différents ports accessibles et

permettant aux compilateurs de lier l’exécutable de la simulation avec les bibliothèques

libfmi.so ou libCLI.so, lors de l’élaboration. Ce fichier contient la déclaration des

ins-tances Exin, Exout et Exinout pour tous les types. Les architectures, quant à elles, sont

déclarées comme étrangères afin de faire les liens avec les bibliothèques (libfmi ou

lib-CLI). Ainsi, pour chaque port du paquetage, la déclaration des architectures porte la

men-tion “FOREIGN” .

Citons ci-dessous l’exemple de déclaration de l’Exout entier dans le paquetage EXINS

-EXOUTS pour Leapfrog ou Synopsys :

library IEEE ;

use ieee.std_logic_arith.all ;

entity EXOUT_INTEGER is Generic ( NOM : string ) ;

Port ( PORTOUT : in INTEGER ) ;

Principe de Fonctionnement de l’Outil 82

architecture C_EXOUT_INTEGER_Model of EXOUT_INTEGER is

attribute FOREIGN of C_EXOUT_INTEGER_Model :

architecture is "clib :EXOUT_INTEGER" ;

begin

end C_EXOUT_INTEGER_Model ;

Dans le cas du simulateur VHDL, ceci signifie qu’à la mise à jour d’un port instancié

sur un Exout entier, le simulateur appelle la procédure EXOUT_INTEGER_eval pour

VSS ou EXOUT_INTEGERC_stim pour Leapfrog respectivement de la bibliothèque

libCLI.so ou libfmi.so avec les paramètres de ce port. Ainsi, cet appel réalise la mise à

jour des données vers l’environnement de cosimulation en appelant les primitives offertes

par la bibliothèque libliste.so de MCI.

La manière d’utiliser ce paquetage consiste en une simple déclaration au début du modèle

par la directive use.

3. Pour MATLAB, il faut de même créer une bibliothèque dynamique pour chaque port

(exin_integer.mexsol et exout_integer.mexsol par exemple). Elle est utilisée lors de

l’exécution de la simulation du modèle. La référence à ces bibliothèques est introduite

lorsque que l’on ajoute un port Exin ou Exout sur le schéma graphique du modèle. Pour

établir ces ports, il faut créer un programme C contenant des fonctions prototypes fixées

par le constructeur, les compléter et les compiler par l’outil cmex fourni par MATLAB.

Les différents prototypes qui peuvent être utilisés lors de la construction de la bibliothèque

sont relatifs aux phases d’exécution de la simulation. Il en existe plusieurs pour

l’initia-lisation : mdlInitializeSizes, mdlInitializeSampleTimes, mdlInitializeConditions. Les

autres prototypes disponibles décrivent le déroulement de la simulation : mdlStart,

md-lOutputs, mdlUpdate, mdlDerivatives, et mdlTerminate. A l’exécution de la

simula-tion, le simulateur fait appel à toutes ces procédures et ceci pour tous les ports déclarés.

Il consiste donc, pour la cosimulation, à spécifier l’initialisation des ports

(mdlInitialize-Conditions) et la mise à jour de leurs données à travers la primitive mdlOutputs. A

l’in-térieur de ces primitives MATLAB redéfinies, l’utilisateur doit se servir des primitives de

la bibliothèque libliste.so de MCI.

4. Pour COSSAP et SABER, le principe est pratiquement le même que pour MATLAB, à

l’exception que les prototypes disponibles sont limités à trois. En effet, ici les prototypes

sont minimaux, ils se limitent à Init, Eval, et Close. Ensuite, la compilation de ces

pri-mitives doit être contenue dans une bibliothèque statique pour COSSAP et dans trois

bi-bliothèques dynamiques pour SABER (un prototype par bibliothèque). Ces bibi-bliothèques

sont référencées de la même façon que MATLAB lorsqu’on ajoute graphiquement un port

Exin ou Exout dans le modèle. La mise à jour des valeurs pour la cosimulation se fait par

les primitives de MCI dans la procédure Eval appelée à chaque évaluation de port par le

simulateur.

5. Pour SDL, le cas est particulier. Nous aurions pu entreprendre la même opération que

pour les autres modèles en référençant les bibliothèques par des prototypes déclarés sous

forme d’ADT.

11

Néanmoins, cela implique de propager, comme dans le langage C, les

primitives d’échanges de données dans toute la description SDL (Ajout de prototype à

toutes les entrées-sorties de la cosimulation). Cette opération est délicate, car elle modifie

Principe de Fonctionnement de l’Outil 83

énormément la description du modèle.

Nous avons donc choisi d’utiliser les canaux abstraits connectés à l’environnement. Afin

de réaliser la connexion avec l’environnement de cosimulation, nous avons remodelé le

client SDL à notre convenance. Ce client est une API fournie par Object_Geode pour

communiquer vers l’extérieur. MCI le lance lui-même et communique avec lui en utilisant

ses primitives et celles de l’API Object_Geode.

Toutes ces bibliothèques communiquent avec l’environnement de cosimulation par

l’inter-médiaire de primitives offertes par MCI. Ces primitives sont simples et permettent juste

d’ex-traire et de lire les données des simulateurs dans une mémoire partagée. Cette mémoire est

un tampon de données entre les simulateurs et l’environnement de cosimulation. L’ajout d’un

nouvel outil consiste donc à étudier les possibilités dont il dispose pour utiliser les primitives

offertes par MCI. Plus la réalisation de la bibliothèque est simple, plus l’introduction du

si-mulateur dans l’environnement est rapide. Parfois, la mise en oeuvre d’une bibliothèque est

longue.

La raison majeure provient bien souvent de la pauvreté de la documentation !

Afin que le fonctionnement du processus soit correct, MCI doit créer les mémoires

par-tagées avant que les simulateurs n’utilisent les primitives de lecture/écriture. Ainsi, MCI doit

réguler l’ordre des opérations et lancer lui-même les différents simulateurs. Nous présentons

maintenant, ce schéma d’exécution pour bien comprendre le déroulement des opérations.

Dans le document Cosimulation multiniveaux dans un flot de conception multilangage (Page 82-85)