Le rôle de la co-simulation

Avec la croissante complexité des systèmes dans des domaines comme l’automobile et l’aéronautique, l’intégration de logiciels et de matériels devient une problématique de plus en plus difficile à résoudre. La conception de systèmes complexes requiert souvent la coopération de plusieurs équipes avec des domaines d’expertise différents mettant en jeu des outils de développement et de validation variés. Il devient maintenant nécessaire de pouvoir valider l’ensemble du comportement d’un système très tôt dans son cycle de conception. Cela amène donc à des problèmes survenant lors de l’intégration au sein de la modélisation du système, par plusieurs modèles écrits dans des langages de modélisation différents et utilisant des outils de simulation différents.

Dans notre optique de modélisation de systèmes hétérogènes, nous souhaitons favoriser l’utilisation d’un seul et unique langage, et un seul et unique outil de simulation. La transformation de modèle est alors une étape inévitable si certains modèles provenant de certains domaines d’application sont écrits dans des langages de modélisations différents. Cependant, il existe aussi d’autres alternatives qui peuvent s’avérer, suivant les cas, plus rapides à mettre en place et plus adaptées pour répondre à certaines contraintes liées à la conception système comme la contrainte temporelle du "Time To Market" 239H[Her02].

1.3.2.1 La cosimulation Système

La cosimulation permet de simuler un système complet, tout en ayant des modèles et des outils de simulation différents : L’étape de transformation de modèle n’est alors plus indispensable.

Les outils et les langages sont de plus souvent très adaptés et spécifiques à leur domaine d’application. Ils sont généralement développés et utilisés par les mêmes personnes et répondent ainsi parfaitement à leurs besoins. La cosimulation permet de garder intacts ces environnements, mais nécessite par contre le développement d’interface entre les outils, entre les modèles, mais aussi de créer des modules de conversion et d’interfaçage.

Il arrive souvent que soient intégrées, par défaut, dans certains outils des interfaces possibles avec d’autres outils. Par exemple le logiciel SABER 15F[Sab] autorise une cosimulation avec les logiciels MATLAB 16F[Mat] et ModelSim 17F[Mod]. Cette solution permet de profiter des performances des outils dans chacun de leurs domaines d’application. Ainsi, dans le cas d’une cosimulation SABER – MODELSIM, l’intérêt est de profiter des nombreux modèles numériques et du cœur de simulation performant de MODELSIM. Cependant, cette solution reste assez lourde à mettre en place et est moins performante en terme de temps de simulation et de précision des résultats qu’une solution avec un unique outil de simulation.

Le développement d’interface entre outils peut aussi être réalisé par l’utilisateur mais cela dépend des possibilités prévues par chacun des éditeurs des outils. En général cela se traduit par la présence ou non d’API (Application Programming Interface), accessibles par l’utilisateur du logiciel avec ou sans accord tacite de l’éditeur de l’outil.

En général, la cosimulation s’effectue entre deux simulateurs de façon point à point. Néanmoins il existe d’autres solutions qui fonctionnent grâce à la mise en place d’un bus de cosimulation et d’une architecture ouverte permettant la communication entre plusieurs simulateurs hétérogènes. Il n’est pas nécessaire d’avoir tout le matériel en local, le bus de cosimulation peut très bien passer par le réseau. On peut ainsi optimiser les ressources CPU et améliorer les temps de simulation en partitionnant le système en vue de la simulation sur plusieurs machines (cf. 240HFigure 9).

Figure 10 : Partitionnement du Système sur plusieurs outils en vue de la simulation (Source 18F[Cos06])

Pour illustrer ce type de cosimulation, nous pouvons citer la technologie de cosimulation SVX utilisée par la société MENTOR GRAPHICS notamment dans le logiciel SystemVision 19F[Sys50] pour effectuer des cosimulation avec le logiciel MatLab Simulink

241H

[Mat] (cf.242HFigure 10), mais aussi pour partitionner une modélisation VHDL-AMS d’un système entre plusieurs ordinateurs et outils SystemVision et ainsi améliorer les temps de simulation.

Figure 11 : Technologie de Cosimulation SVX

Pour la même problématique de cosimulation, nous pouvons aussi citer la solution proposée par la société CHIASTEK qui a aussi ce type de service basé sur un bus de cosimulation dans son outil COSIMATE 243H[Cos06] (cf.244HFigure 11).

1.3.2.2 Cosimulation matériel-logiciel

Nous nous focalisons dans cette partie sur la cosimulation dans le cadre de la validation logicielle. Dans le flot de conception classique, le logiciel embarqué est, en général, validé tardivement dû à la nécessité de disposer du modèle matériel réel du processeur embarqué. L’intérêt est alors de pouvoir exécuter conjointement logiciel et matériel au cours d’une simulation. J.Rowson propose deux définitions de la cosimulation 20F[Row94] :

• Une cosimulation de bas niveau qui fait intervenir la forme assembleur (binaire) du logiciel embarqué,

• une cosimulation de haut niveau qui ne nécessite que le modèle écrit en C du logiciel embarqué. Avec l’application écrite en C, la lecture et le débogage fonctionnel sont bien plus aisés qu’avec le code binaire. Il n’est plus nécessaire de réaliser l’architecture du processeur, ni le jeu d’instruction. Par contre seule la validation fonctionnelle de l’algorithme est effectuée. On peut voir sur la 245HFigure 12, l’enchaînement des étapes aboutissant à la validation complète du logiciel et à l’intégration du processeur dans le système (cf. 21F[NVH00]).

Figure 13 : Etapes de validation du logiciel dans le cadre d’une cosimulation C-VHDL (Source 246H[NVH00])

Dans ce cadre de cosimulation matériel-logiciel au niveau assembleur, il existe par exemple l’outil Seamless de MENTOR GRAPHICS 22F[Sea] qui fournit une interface de co-simulation pour connecter un simulateur de jeu d’instructions à un simulateur matériel (VHDL, Verilog, System Verilog, System C).

La co-simulation est donc une alternative possible qui peut s’avérer plus adaptée à la situation lorsque les moyens, en terme de temps de conception et de ressources disponibles (modèles, outils, expertises des concepteurs), le permettent. C’est une possibilité à intégrer dans notre démarche de conception, même si notre problématique principale est de pouvoir modéliser un système hétérogène avec un seul et même langage de modélisation.