tion et de synchronisation
1.3.3 Contraintes de mod´ elisation pour une simulation multi-niveaux efficace
Le but premier est de pouvoir ex´ecuter des simulations multi-niveaux efficaces `a partir du mˆeme code source des logiciels embarqu´es. Par efficace, s’entend d’effectuer des ex´ecutions avec simulation natives des processeurs tr`es rapides, mais aussi de faire apparaˆıtre le plus d’erreurs possible avant de commencer les ex´ecutions de mod`ele incluant logiciel et mat´eriel avec les mesures de performance.
Les contraintes de mod´elisation pour une simulation multi-niveaux effi-cace peuvent se classer en cinq cat´egories : les points de synchronisation, les acc`es par blocs, les structures de donn´ees partag´ees, l’initialisation des p´eriph´eriques mat´eriels et des r`egles de codage sp´ecifiques.
1.3.3.1 Les points de synchronisation entre tˆaches
lo-gicielles/mat´erielles
Les points de synchronisation entre tˆaches servent `a rendre la main ex-plicitement `a l’environnement de simulation. Celui-ci va ´evaluer les tˆaches `a ex´ecuter, puis choisir celle qui a le niveau de priorit´e le plus ´elev´e.
Ce m´ecanisme induit deux changements de contexte, tˆaches vers environ-nement de simulation puis vice versa, et un calcul d’ordonnancement. Il est
si n´ecessaire, il doit ˆetre appel´e lors des synchronisation avec le mat´eriel ou d’autres logiciels.
Pour la synchronisation mat´erielle, on d´eclare un point de synchronisa-tion par exemple, changement de valeur d’un registre ou lors de l’attente d’interruptions. On peut remarquer que le m´ecanisme d’un processeur qui lui permet de se mettre en veille jusqu’`a la prochaine interruption permet une impl´ementation tr`es efficace. Ces attentes ont souvent lieu soit dans le syst`eme d’exploitation soit dans des primitives logicielles de synchroni-sation, telles que signaux logiciels, m´ecanismes de barri`eres ou d’exclusions mutuelles. Pour les synchronisations logicielles, le m´ecanisme est celui des attentes actives sur des donn´ees partag´ees. En vue d’am´eliorer les perfor-mances ces attentes sont souvent coupl´ees `a des attentes d’interruptions ce qui ram`ene au cas pr´ec´edent.
1.3.3.2 Les transactions par bloc de donn´ees
L’utilisation de ces transactions par blocs est tr`es importante pour la vitesse de simulation. En effet, il est possible de transf´erer en une seule fois des donn´ees qui auraient demand´ees de multiples transferts sur le composant r´eel.
Ces transactions peuvent se classer en deux sous cat´egories :
– communication de blocs de donn´ees entre une tˆache logicielle et un composant mat´eriel;
– communication de blocs de donn´ees entre deux tˆaches logicielles. La communication de donn´ees entre un processeur en simulation native et un processeur simul´e par ISS est vue comme une communication entre la simulation native et le composant mat´eriel de la m´emoire partag´ee, ou du composant de communication.
Pour la communication entre processeurs en simulation native et du ma-t´eriel, deux primitives de communications par bloc sont `a utiliser, lecture et ´ecriture. L’ensemble des donn´ees est transf´er´e en une seule fois par le r´e-seau. Le destinataire g`ere le bloc comme une suite d’acc`es. Une attention particuli`ere doit ˆetre port´ee aux ´ecritures de blocs de donn´ees qui ont des tailles inf´erieures aux mots du protocole de communication. Les octets acti-v´es doivent ˆetre pr´ecis´es.
La communication entre processeurs en simulation native est encore plus simple. Il suffit d’´echanger les donn´ees dans la m´emoire du processeur si-mulant. L’adresse vers cette zone m´emoire est transmise par une m´emoire partag´ee simul´ee. Lors du passage en simulation ISS l’adresse transmise doit pointer vers une zone d’une m´emoire partag´ee simul´ee. Si les deux processeurs
Simulations multi-niveaux des logiciels et leur mise en place
ne voient pas la m´emoire `a la mˆeme adresse un m´ecanisme suppl´ementaire de modification doit ˆetre ajout´e.
L’utilisation de tel transfert par pointeur rend impossible toute analyse du trafic. Cette limitation est cependant peu gˆenante car l’´evaluation du trafic est d´ej`a fauss´ee par la simulation native.
1.3.3.3 Gestion des structures de donn´ees destin´ees
aux m´emoires partag´ees
Le probl`eme de la gestion des structures de donn´ees destin´ees aux m´e-moires partag´ees g´en´eralise celui des communications directes, utilisant seule-ment une m´emoire, entre programmes ex´ecut´es sur des simulations natives de processeurs.
Le style de codage le plus efficace consiste `a cr´eer une structure de don-n´ees. Cette structure contient l’ensemble des donn´ees `a partager entre les deux tˆaches sous forme de pointeurs. Dans le cas de simulation native avec redirection des communications tous les acc`es `a cette structure doivent ˆetre d´eclar´ees via des primitives de l’interface de communication.
Ces modifications concernent des grandes parties du code. De plus elles peuvent ˆetre complexes dans le cas de structures de donn´ees acc`ed´ees par pointeurs. La solution consiste `a communiquer le pointeur vers cette struc-ture dans la m´emoire partag´ee. La strucstruc-ture elle mˆeme et ses donn´ees sont dans la m´emoire hˆote. Les m´ecanismes de synchronisation des acc`es `a ses donn´ees sont g´er´es via la plateforme. Les modifications du code sont moins importantes et la simulation est plus rapide.
Enfin les primitives d’allocation m´emoire, new/delete ou malloc/free ne
concernent g´en´eralement que la zone de m´emoire de donn´ees, souvent locale, d´eclar´ee dans le script d’´edition des liens. Les primitives d’allocation dans les m´emoires partag´ees doivent ˆetre ´ecrites pour les simulations natives avec redirection totale ou lors de l’utilisation d’ISS.
1.3.3.4 Probl`eme de l’initialisation des p´eriph´eriques
et des m´emoires
Le probl`eme de l’initialisation des p´eriph´eriques et des m´emoires est g´e-n´eral aux plateformes multi-processeurs. Il concerne aussi les simulations na-tives de ces plateformes. Un m´ecanisme de synchronisation explicite et des r`egles concernant les initialisations permettent d’´eviter ces erreurs dont l’ori-gine est complexe `a d´eterminer.
les p´eriph´eriques partag´es, notamment les m´emoires. Si le temps de lance-ment n’est pas un facteur limitant, une seule tˆache peut initialiser tous les composants, ce qui limite encore les probl`emes d’interactions lors de l’initia-lisation.
De plus, la fin des initialisations est un point de synchronisation entre les
tˆaches. Un m´ecanisme d’attente de stylebarri`ere est conseill´e.
1.3.3.5 R`egles suppl´ementaires de codage pour limiter
les erreurs de changement de niveau
Des erreurs peuvent apparaˆıtre entre la simulation native et la simula-tion avec ISS. Certaines d´ependent directement du niveau d’abstracsimula-tion et ne peuvent pas ˆetre r´esolues. D’autres d´ependent des processeurs et des com-pilateurs, elles demandent de figer certaines r`egles. De mani`ere plus g´en´erale le langage de programmation est sens´e prot´eger le programmeur de ces va-riations. Or, pour des raisons d’efficacit´e des choix ne sont pas sp´ecifi´es.
Quelques exemples :
– le caract`ere sign´e ou non de certain type, en langage c le char, r´esolu
en sp´ecifiant signed char ouunsigned char;
– l’alignement des adresses, souvent configurable dans le compilateur;
– la taille des pointeurs et des types, en langage c leint sur 2 ou 4 octets;
– l’ordre d’´evaluation des arguments des appels de fonction;
– l’ordre de rangement des variables dans les structures de donn´ees
(no-tamment les bit field en langage C);
– l’impact du boutisme du processeur sur les donn´ees acc´ed´ees selon plu-sieurs types;
– le nombre d’octet utilis´e pour stocker un type, int sur deux, quatre ou
huit octets.
Toutes les erreurs engendr´ees par ces choix, non sp´ecifi´ees peuvent ˆetre r´esolues par des r`egles de codages strictes et des options de compilation ad´e-quates.