Méthodologie de co-simulation distribuée

Notre méthodologie de génération de modèles de co-simulation distribués est principalement composée de deux étapes. Ainsi, à partir de la description des interfaces de communication, des modules SystemC, composant le système, on trouve une affectation optimale de ces modules sur les hôtes de simulation disponibles. Puis nous transformons le code pour adapter le modèle de simulation au contexte de l’exécution sur un réseau distribué.

La première étape est basée sur une méthode d’optimisation combinatoire. Elle consiste à générer une affectation optimale des modules simulés sur les différents hôtes de simulation disponibles. La seconde étape consiste à transformer le code initial de l'application, afin de l'adapter à la plate-forme de simulation distribuée, trouvée lors de l'étape précédente.

3.3.2.1. Optimisation de la simulation distribuée

Ma contribution sur ce point consiste en la proposition d'une nouvelle méthodologie permettant une distribution optimisée des IPs SystemC constituant un SoC sur simulateurs distribués et géographiquement distants. La principale originalité de ce travail est l'utilisation d'une formulation mathématique exacte pour résoudre le problème de distribution d’IPs. Ainsi, cela peut accélérer considérablement la simulation et par conséquent réduit le temps de mise sur le marché.

A partir de la spécification de SystemC de chacun des modules constituant le système, un parseur analyse le code pour extraire certains paramètres liés à l'application. Ces paramètres sont essentiellement les caractéristiques des signaux échangés entre les modules (types et tailles des signaux). Ensuite, une simulation rapide du système sur un seul hôte permet d'extraire d'autres informations comme la quantité de données échangées entre chaque paire de modules et la charge CPU nécessaire pour exécuter chaque module.

Après cette étape d'extraction de paramètres, le flot a besoin de certaines autres informations du concepteur. Ce sont principalement: la vitesse de transmission et de la bande passante entre toutes les paires de machines hôtes connectées via le réseau.

Ces paramètres et informations permettent d’instancier un programme linaire en nombres entiers. Ce dernier est résolu automatiquement et de façon transparente pour le concepteur. Il fournit en sortie une affectation optimale des différents modules composant le système sur les machines de simulation. Cette affectation constitue l’entrée d’un second flot, permettant d’adapter automatiquement les codes des IPs de simulation pour prendre en compte les hôtes qui leurs sont attribués. Cette transformation de code permet de rajouter toute la couche de communication réseau, de façon à ce que le concepteur se comporte exactement comme si la simulation était sur une seule machine locale.

47

La formulation mathématique du problème d’affectation, ainsi que le flot permettant l’instanciation et la résolution du modèle sont décrits avec détails dans [MeDe04c, MVD06].

3.3.2.2. Communication via le réseau

La seconde étape de notre flot de génération de modèles de simulation distribués est la production du code permettant la communication des différents modules de simulation, affectés aux machines distribuées. En effet, la co-simulation dans un environnement constitué de plusieurs hôtes implique une synchronisation des différents simulateurs.

Voulant répondre en même temps au problème de l’hétérogénéité, en termes de langages, dans les spécifications de SoCs complexes, je me suis imposé dans mes travaux la contrainte de rendre l’environnement de simulation assez flexible pour supporter des descriptions multi-langages.

3.3.2.2.1. SystemC et des réseaux

La norme API SystemC ne permet pas les simulations distribuées sur un réseau. Ainsi, afin de rendre possible cette fonctionnalité, nous avons défini deux nouveaux concepts: enveloppes de distribution et objets de transport.

3.3.2.2.2. Pourquoi utiliser CORBA ?

CORBA (Common Object Request Broker Architecture), est une solution proposée par l'OMG (Object Management Group) pour résoudre le problème d'interopérabilité dans le cas de logiciels multi langages distribuées. Ainsi, l'OMG spécifie le standard de description d’interfaces (IDL) et les APIs permettant l'interaction entre les objets distribués en utilisant l’ORB (bus CORBA).

L'ORB assure l'interconnexion des applications situées sur des machines distantes, dans un environnement hétérogène distribué. Dans une application traditionnelle de type Client/Serveur, le programmeur doit définir son propre protocole de communication entre les objets composant son application. Le rôle de l'ORB est de simplifier cette tâche, en rendant la couche protocole complètement transparente pour le développeur. Ainsi, le protocole est défini par l'interface de l'application en utilisant un seul langage de spécification, indépendant de la mise en œuvre (IDL).

L'utilisation de CORBA est donc ainsi justifiée. En plus, il fournit plusieurs services par défaut, comme les services de nommage, d'authentification, etc. L'ensemble des services proposés peuvent être très pratiques pour mettre des IPs, à disposition des concepteurs, sur des machines distantes.

3.3.2.2.3. Comment cela fonctionne ?

L'idée principale de ce travail est de permettre aux concepteurs d'utiliser des IPs, disponibles dans des hôtes éloignés, appartenant à différents fournisseurs. Donc, nous devons être capables de simuler un système conçu en utilisant des IPs distribués. En effet, Il arrive assez souvent, lors de la conception d’un SoC complexe, que le concepteur ait besoin d’utiliser certains IPs répartis sur plusieurs sites distants (pour des raisons de propriété intellectuelle notamment). Ainsi, notre solution est capable de simuler un système utilisant plusieurs simulateurs SystemC, s’exécutant sur des machines distantes, communiquant en utilisant l'ORB.

Le principe consiste à intégrer au système à concevoir des IPs lointains. Ainsi, l'utilisation du service de nommage CORBA permet, à l'outil, de localiser un IP distant en utilisant simplement son nom ou sa description. Ce mécanisme est complètement transparent pour le concepteur.

48

Toute la couche relative à la communication réseau entre les simulateurs est générée de façon totalement automatique, à partir des spécifications initiales des IPs à simuler. Les détails de cette approche sont décrits dans [MeDe04b, MVD03b ].