plateformes mat´erielles
1.2.2 Simulation native des processeurs
La simulation native permet de simuler le comportement d’un processeur. Elle utilise `a la fois les codes sources des programmes embarqu´es qu’il doit ex´ecuter, et certaines sp´ecifications fonctionnelles du processeur, tels que les ports, les interruptions et leur gestion, contenues dans un composant sp´eci-fique.
Elle permet une simulation tr`es rapide. Les inconv´enients sont l’absence de pr´ecision des mesures de performance et l’obligation d’avoir l’ensemble des codes sources en langage de haut niveau (au moins C). Des recherches ont lieu pour donner de la pr´ecision aux simulations natives [26][27].
1.2.2.1 Concept de simulation native
Le but d’un grand nombre de simulations est de tester des composants. Si ces composants sont configur´es par des logiciels embarqu´es, ceux-ci doivent ˆetre simul´es. Une grande partie de la simulation calcule l’ex´ecution du mo-d`ele du processeur alors que seules ses communications vers l’ext´erieur sont importantes. Dans ce but le code embarqu´e est compil´e pour le processeur
´
Etat de l’art des techniques de simulation des logiciels dans les mod`eles ex´ecutables de plateformes mat´erielles
de l’ordinateur simulant (en anglais : HOST), les op´erations d’´ecritures et
de lectures vers l’ext´erieur sont redirig´ees vers la simulation. Il n’y a pas de d´ecodage d’instruction ni d’ISS `a ex´ecuter. La simulation est plus rapide.
Avec un style de codage d´efini, l’usage de fonctions pour les acc`es ext´e-rieurs ainsi que la gestion par le simulateur natif des fonctionnalit´es assem-bleur utilis´ees (autorisation et interdiction des interruptions), il est possible d’utiliser le mˆeme code source pour une simulation native et une simulation avec un ISS.
La simulation native peut aussi permettre, de tester fonctionnellement des algorithmes ou une premi`ere validation des codes sources.
1.2.2.2 Simulation native avec redirection totale des
entr´ees/sorties
La simulation native avec redirection totale des entr´ees/sorties demande la compilation des logiciels embarqu´es pour le processeur simulant. Cepen-dant l’´edition des liens utilise les sp´ecifications m´emoires de l’architecture simul´ee. Toutes les adresses m´emoires utilis´ees dans les programmes sont celles de l’architecture.
Fig. 1.2.2 – Simulation native avec redirection totale
sur le processeur hˆote. Le code du programme est donc contenu dans la m´emoire de la machine hˆote en temps que code ex´ecutable. D`es qu’une lecture ou une ´ecriture m´emoire (de donn´ees) survient l’acc`es est transform´e en une transaction sur le mod`ele ex´ecutable d’architecture simul´ee. Cette m´ethode permet l’usage sans modifications de programmes qui n’incluent pas de code assembleur.
La cosimulation entre des simulations natives de processeurs de ce type et des simulations sous forme d’ISS est automatique. Cette simulation permet l’´evaluation des transits de donn´ees sur les r´eseaux[28] ainsi que la v´erification des besoins en tailles de m´emoires. Attention, seuls les transferts de donn´ees sont visibles, les transferts d’instructions ne le sont pas.
1.2.2.3 Simulation native avec redirection des
commu-nications mat´erielles ou logicielles
Avec la technique de simulation native avec redirection des communica-tions mat´erielles ou logicielles seules les donn´ees n´ecessaires aux synchronisa-tions et aux communicasynchronisa-tions transitent par la simulation. La mise en œuvre est tr`es simple et rapide. Elle consiste en l’utilisation de fonctions de redi-rection pour la lecture et l’´ecriture. Cependant, elle demande une r´eflexion sur les structures de donn´ees partag´ees, les diff´erentes communications et les points de synchronisation.
Le nombre de transactions plus faible rend la simulation plus rapide et la recherche d’erreurs plus simple.
´
Etat de l’art des techniques de simulation des logiciels dans les mod`eles ex´ecutables de plateformes mat´erielles
Fig. 1.2.3 – Simulation native avec redirection des communications
unique-ment
Lors de la simulation, figure 1.2.3, le code du logiciel embarqu´e est ex´ecut´e sur le processeur hˆote. Le code du programme est donc contenu dans la m´e-moire de la machine hˆote en temps que ex´ecutable. D`es qu’une lecture ou une ´ecriture m´emoire de donn´ees survient, celle-ci est effectu´ee dans la m´emoire du processeur hˆote. Ce transfert ne transite donc pas par la simulation et ne modifie aucune m´emoire ou composant simul´e. Les transferts de donn´ees partag´ees ou les acc`es aux composants mat´eriels doivent ˆetre explicit´es via des fonctions de lecture et d’´ecritures. Ces fonctions sont transform´es par le mod`ele du processeur en transactions TLM.
Un point particulier sp´ecifique `a la communication entre deux processeurs est l’allocation dynamique de m´emoire et le partage des donn´ees. Si un pro-gramme embarqu´e utilise une primitive d’allocation standard, par exemple
de lalibc, l’espace m´emoire sera allou´ee dans la m´emoire de la machine hˆote
comme une donn´ee locale. Cependant l’adresse m´emoire correspondant `a cette zone peut ˆetre ´ecrite dans une m´emoire TLM simul´ee, puis lue par un autre programme embarqu´e sur un autre processeur simul´e. Ce programme aura alors acc`es aux donn´ees en utilisant directement le pointeur.