La coordination des modules entre eux doit être décrite de la manière la plus précise
pos-sible. C’est pourquoi, il est important d’utiliser un langage cohérent, capable de modéliser un
système sous forme d’instance et de connexions. De plus, il doit être capable de représenter
les types utilisés par l’ensemble des langages qui sont impliqués dans l’environnement de
co-simulation. Ce langage de coordination peut posséder une syntaxe très simple, car seules les
interconnexions des différents modules doivent être représentées et en aucun cas le fichier de
coordination ne devra décrire l’architecture d’un module. Dans le cadre des travaux sur MCI,
nous avons choisi d’utiliser le langage SOLAR développé au laboratoire TIMA. Ce langage
de modélisation possède une syntaxe complète pour la description des systèmes et est donc
très adapté pour ce type de description, à la fois pour décrire les modules mais aussi pour ses
possibilités de définition de types.
3.4.1 Utilisation du Langage Intermédiaire SOLAR
La syntaxe de description SOLAR est suffisamment complète et très bien adaptée pour
construire un fichier de coordination comportant des propriétés, des listes de modules ou
ins-tances, des ports, des descriptions de types et surtout des interconnexions ou des “nets”.
La description de l’environnement de cosimulation, par l’intermédiaire de ce fichier de
coor-dination, est nécessaire pour MCI. La syntaxe SOLAR, est donc utilisée en entrée de l’outil. Les
informations contenues dans le fichier de coordination peuvent être décrites manuellement ou
de façon automatique par un outil de “co-design”. Une description manuelle du fichier consiste
à inclure :
– les modules, à l’aide du mot clé Instance en SOLAR. Le paramètre associé à l’instance
définit le nom du fichier contenant le modèle à exécuter par le simulateur. L’instance doit
aussi contenir les propriétés
12suivantes :
– le type de module (logiciel, matériel, mécanique, etc..). Il permet de définir le mode
à adopter pour le traitement et la synchronisation des données. De plus, il permet de
connaître, sauf cas particulier, le simulateur qui doit être exécuté pour le modèle du
module,
– une propriété nom de machine qui permet de spécifier la machine sur laquelle le
mo-dule va être attitré. Cette propriété est utilisée par l’environnement lors de l’exécution
des processus et permet de connaître le type de support de communication à utiliser
(“socket” Internet ou locale).
– la liste des ports du module. Elle regroupe uniquement le nom des ports à cosimuler des
différents modèles de l’environnement. Ceci correspond à la définition des ports d’une
entité en langage VHDL (mot clé “portinstance”),
– la liste des interconnexions des instances et de leurs ports. Pour cela on utilise les mots
clés “net”, “joined”, “portref ”et “instanceref ”,
– la description des types et directions des différents ports déclarés. Cette description est
utile pour les conversions et les résolutions. En SOLAR, il est nécessaire de représenter
Coordination Inter-Modules 88
Simulateur 1 Simulateur 2 χ κ ο η γ φ π λ µ β ν α δ ι ϕ ε Simulateur 3 Application 1 Modèle C Application 2 Modèle Vhdl Application 3 Modèle MatlabFIG. 3.9 – Schéma d’interconnexions
des architectures sommaires(“DesignUnit” en SOLAR) pour chaque modules pour
repré-senter les types des ports.
3.4.2 Description des Interconnexions
La description des interconnexions des modules (“instances”) entre-elles est réalisée par
les “nets” de SOLAR. Dans un “net” il suffit de spécifier une liste de ports pour les connecter
ensemble. On peut donc spécifier le(s) port(s) source(s) et le(s) port(s) destination(s) qui lui
est(sont) connecté(s). La figure 3.9 illustre un système à cosimuler, et pour bien comprendre
la modélisation SOLAR, nous avons décrit le fichier de coordination équivalent (figure 3.10).
Le couple modèle + simulateur est représenté en “instances” et le nom de “l’instance” porte le
nom du modèle à simuler (figure 3.10b). Les ports à échanger
î,
ï,
ð, etc.. se retrouvent dans
la définition des “instances”, car ils représentent les connexions extérieures aux modèles. Les
types de ces ports sont déclarés dans les architectures (“designunit”) associées aux “instances”
(figure 3.10c). Et les connexions des ports entre eux sont définies par un ensemble de “nets”
(figure 3.10b).
Cette étape d’écriture du fichier de coordination peut se faire de façon automatique en
reli-sant les modèles. Dans ce cas, seules les interconnexions doivent être spécifiées. Ce fichier de
coordination est lue au début de l’exécution de l’environnement et sert à construire la structure
de donnée de l’environnement de cosimulation, utilisée par le routeur pour aiguiller les données.
3.4.3 Vérification des Interconnexions et Types de Données
Les données du fichier de coordination permettent, dans un premier temps, de vérifier la
cohérence des interconnexions et les types propres aux ports afin d’éviter toutes erreurs. Pour
cela, un certain nombre de tests sont effectués :
1. le parcours de la “netlist” d’interconnexions en :
– contrôlant l’ensemble des références “d’instances” dans chaque net,
– contrôlant si les ports de chaque nets sont bien déclarés dans les “instances” associées
par les “instanceref ”,
– vérifiant qu’il n’existe pas de port non connecté.
2. Parcourir l’ensemble des architectures (“DesignUnit”) et de la “netlist” d’interconnexions
en parallèle :
Coordination Inter-Modules 89
(DESIGNUNIT ModeleVhdl (VIEW Architecture (VIEWTYPE "comportement") (INTERFACE
(PORT (IN) (INTEGER)) (PORT (IN) (INTEGER)) (PORT (IN) (INTEGER)) (PORT (IN) (INTEGER))
(PORT (OUT) (INTEGER))
(DESIGNUNIT ModeleMatlab (VIEW Architecture (VIEWTYPE "comportement") (INTERFACE
(PORT (OUT) (INTEGER)) (PORT (IN) (INTEGER)) (PORT (OUT) (INTEGER)) (PORT (IN) (INTEGER))
) ) ) ) ) ) (DESIGNUNIT ModeleC (VIEW Architecture (VIEWTYPE "comportement") (INTERFACE
(PORT (OUT) (INTEGER)) (PORT (IN) (INTEGER)) (PORT (OUT) (INTEGER)) (PORT (OUT) (INTEGER)) (PORT (IN) (INTEGER))
) ) ) ν β δ χ λ
(PORT (OUT) (INTEGER))α µ
κ ϕ ε ι
(PORT (IN) (INTEGER))ο η γ φ π (SOLAR Systeme (DESIGNUNIT Composition (VIEW structure_systeme (VIEWTYPE "structure") (CONTENTS ν (INSTANCE ModeleC
(VIEWREF Architecture ModeleC) (PROPERTY DESIGN SOFTWARE) (PROPERTY HOST "localhost") (PORTINSTANCE (PORTINSTANCE (PORTINSTANCE (PORTINSTANCE (PORTINSTANCE ) (INSTANCE ModeleVhdl
(VIEWREF Architecture ModeleVhdl) (PROPERTY DESIGN HARDWARE) (PROPERTY HOST "localhost") (PORTINSTANCE (PORTINSTANCE (PORTINSTANCE (PORTINSTANCE (PORTINSTANCE β δ λ χ α µ ι κ ) (PORTINSTANCE εϕ (INSTANCE ModeleMatlab
(VIEWREF Architecture ModeleMatlab) (PROPERTY LANGUAGE MATLAB) (PROPERTY HOST "localhost") (PORTINSTANCE (PORTINSTANCE (PORTINSTANCE (PORTINSTANCE (PORTINSTANCE ) ο φ π η γ (PORTREFβ (PORTREFδ (PORTREFµ (PORTREFφ (PORTREFχ (PORTREF ι (PORTREF κ (PORTREF α (PORTREF ν (PORTREF ε (PORTREF ο (PORTREF γ (PORTREFϕ ) ) (PORTREF (INSTANCEREF ModeleC ))λ (INSTANCEREF ModeleMatlab )) (NET NetNumero7 (JOINED (PORTREF ) ) π (INSTANCEREF ModeleVhdl )) (INSTANCEREF ModeleMatlab )) (NET NetNumero6 (JOINED ) ) (INSTANCEREF ModeleMatlab )) (INSTANCEREF ModeleVhdl )) (NET NetNumero5 (JOINED ) ) (INSTANCEREF ModeleC )) ) ) (INSTANCEREF ModeleVhdl )) (NET NetNumero4 (JOINED (INSTANCEREF ModeleVhdl )) (INSTANCEREF ModeleVhdl )) (INSTANCEREF ModeleMatlab )) (NET NetNumero3 (JOINED ) ) (INSTANCEREF ModeleC )) (INSTANCEREF ModeleVhdl )) (NET NetNumero2 (JOINED (INSTANCEREF ModeleC )) ) ) (PORTREFη (INSTANCEREF ModeleMatlab )) (INSTANCEREF ModeleC )) (NET NetNumero1 (JOINED (c) (b) (a)
Coordination Inter-Modules 90
Représentation SOLAR C VHDL MATLAB COSSAP SDL SABER
BIT char(1) bit(1)
ñchar
ñ ñCHAR char(1)
ñ ñchar char
ñINTEGER int integer
ñinteger integer
ñREAL float real double(8) float real double(8)
STD_LOGIC (_V..)
ñstd_logic(1)
ñ ñ ñ ñSIGNED || UNSIGNED
ñsigned || unsigned(8)
ñ ñ ñ ññ
: Représentation non supporté par MCI pour le langage
STD_LOGIC(_V..) : std_logic et std_logic_vector
(n) : Taille physique réservée du type dans la mémoire partagée en octets
TAB. 3.3 – Représentation des types disponibles
– pour vérifier la bonne connexion d’un port de sortie (OUT ou INOUT) sur un port en
entrée (IN ou INOUT),
– vérifier l’écriture des types,
– contrôler la compatibilité et les conversions des types interconnectés.
Les types simples disponibles pour l’environnement de cosimulation MCI sont représentés dans
le tableau 3.3. Nous décrivons ici les types possibles de représentation pour chaque langage dans
le format unifié SOLAR, mais aussi le format des types tels qu’ils sont interprétés au niveau des
ports de cosimulation EXIN-EXOUTS à la sortie des simulateurs. En plus, nous indiquons la
taille physique des valeurs en octets, lorsqu’elle n’est pas dépendante de l’architecture de la
machine qui simule. Pour les modules distants, les interfaces effectuent localement les
conver-sions nécessaires pour les types de données dépendants de l’architecture de la machine utilisée.
MCI, via le routeur, contrôle les types de connexions avant de réellement démarrer sa
co-simulation . Un module cosimulé écrit, dans sa phase d’initialisation, les ports à cosimuler
(EXINS-EXOUTS) dans une mémoire partagée réservée. Il crée ainsi un champ dans la
mé-moire partagée, correspondant au type et à la taille de la donnée qui est échangée (fig. 3.7).
Pendant l’identification de ses interfaces (cf. §3.3.5), le routeur établit une communication entre
lui-même et ses interfaces et vérifie la compatibilité entre les types écrits dans les différentes
mémoires partagées et ceux définis dans le fichier de coordination. Pour ce faire, il se conforme
au tableau 3.3.
3.4.3.1 Echange de Données Particulières
Le traitement des types est un atout important de l’outil MCI. En plus des types simples, il
permet maintenant de modéliser des tableaux et de définir plus précisément la taille des types.
Il permet aussi de connecter des types différents.
Il est capable de convertir les types entre eux en tenant compte si nécessaire du tableau 3.4.
Cependant, il convient d’être vigilant quant à ces conversions. C’est pourquoi, le routeur avertit
l’utilisateur de toutes ces modifications. En effet, même si un type converti a une signification
au niveau simulation, comme par exemple un Bit connecté sur un STD_LOGIC, il nécessite
une adaptation particulière à plus bas niveau, comme la synthèse d’interfaces ou le ciblage en
fonction de l’architecture.
Méthodes de Synchronisation 91
Types Destination
BIT CHAR INTEGER REAL STD_LOGIC(_V..) (UN)SIGNED
BIT o x x x o - x x
CHAR x o o o x - o o
INTEGER x o o o x - o o
REAL x x o o x - x x
STD_LOGIC(_V..) o - x x - o x - o x - x o x - o
(UN)SIGNED x o o x o - o o - o
ñ