partag´ee et le logiciel H264 pour la simulation
3.2.3 Validation, ex´ ecution de la plateforme mat´erielle et logicielle
Cette validation se s´epare en deux ´etapes, lors des simulations natives puis sur ISS.
Les simulations natives ont permis la correction de multiples erreurs: – oublis de zones m´emoires partag´ees;
– erreurs dans les m´ecanismes de synchronisation; – initialisation des composants mat´eriels.
Puis les simulations avec ISS ont pu commencer. L’utilisation de code de bas niveau g´en´er´e et juste par construction a permis d’´eviter de nombreuses erreurs complexes. Deux erreurs r´esiduelles ont tout de mˆeme du ˆetre corri-g´ees:
– La premi`ere est due `a la compilation. En effet, le compilateur sur la
Le compilateur crois´e les consid`ere comme non sign´es. Les tests de comparaison d’´egalit´e avec la valeur -1 donnent des r´esultats diff´erents, ce qui change le comportement du programme. Ceci aurait pu ˆetre ´evit´e en utilisant des r`egles de codage plus stricte.
– La seconde s’est r´ev´el´ee ˆetre une erreur d’alignement dans la primitive d’allocation dynamique dans les m´emoires partag´ees. Cette fonction avait due ˆetre ´ecrite lors du portage multi-niveaux `a la section 1.3.3.3. Cette erreur aurait ´et´e trouv´ee avec une simulation native avec redirec-tion totale.
3.2.3.1 R´esultats d’ex´ecutions
Les r´esultats d’ex´ecutions sont de plusieurs ordres, validation fonction-nelle de l’ensemble et visualisation du r´esultat premi`eres estimations en si-mulation native puis les mesures de performances avec l’utilisation d’ISS.
La plateforme utilis´ee permet en natif et avec ISS de visualiser les flux vid´eos grˆace `a des contrˆoleurs d’´ecran. Dans la plateforme finale les flux ne sont pas affich´es, les p´eriph´eriques sont donc ´elimin´es lors des mesures de performances. Le logiciel est param´etr´e vis-`a-vis de leurs pr´esences.
Fig. 3.2.1 – Visualisation1
lors de l’ex´ecution de la plateforme logicielle et mat´erielle
Travaux r´ealis´es sur l’architecture multi-processeurs h´et´erog`ene `a m´emoire partag´ee et le logiciel H264 pour la simulation
La sp´ecification de l’encodage H264 laisse de nombreuses variables de configuration au choix du concepteur et selon ses possibilit´es de calcul. Il est donc particuli`erement important de pouvoir visualiser les pertes amen´ees par l’encodage. Dans la figure 3.2.1 la qualit´e de l’encodage rend la diff´erence difficilement visible, mais par exemple des volutes sont visibles sur l’´ecran central d’arri`ere plan sur la vid´eo de gauche, elles sont liss´ees et ne sont donc plus visibles sur celle de droite.
3.2.3.2 Possibilit´es d’´evaluation du logiciel embarqu´e
en simulation native et limitations
Les possibilit´es d’´evaluation du logiciel embarqu´e en simulation native et les limitations sont de deux ordres, la recherche d’erreurs, les premi`eres ´evaluations de performances.
Au niveau de la recherche d’erreurs, il est plus simple de lister les erreurs qui ne peuvent pas ˆetre trouv´ees:
– Les erreurs dans les codes de bas niveau, ou assembleur. En effet, ils ne sont pas interpr´et´es mais ´emul´e par un code source diff´erent.
– Des erreurs de temporisation, par exemple des proc´edures d’interrup-tions trop longues qui ne permettent pas au programme principal de s’ex´ecuter.
– Des erreurs de synchronisation, notamment des acc`es multiples non prot´eg´es `a des variables partag´ees.
– Des erreurs dues `a des interruptions hors de points de synchronisation. Il est aussi possible de r´ealiser de premi`eres ´evaluations de performances en simulation native, mais avec des limitations tr`es importantes. Lors de si-mulations natives avec redirection des communications, voir section 1.2.2.3, il est possible de r´ealiser un profil d’ex´ecution des codes sources sur les diff´erents processeurs natifs. Cette manipulation permet d’estimer si la r´epartition entre des processeurs identiques est correcte ou non. Dans l’exp´erimentation H264 la r´epartition s’est av´er´ee mauvaise avec des processeurs en sous charge.
L’ins-trumentation est r´ealis´ee via le logiciel de recherche d’erreu :Valgrind [62],
et l’interpr´etation des r´esultats via le logiciel de visualisatio :KCachegrind
[63]. Un exemple de visualisation des r´esultats de profilage viaKCachegrind
Fig. 3.2.2 – Profilage de code en simulation native
En ex´ecutant une simulation native avec redirection de toutes les com-munications vers la simulation, des mesures de trafics de donn´ees auraient ´et´e possibles. Dans notre cas, il est n´ecessaire d’attendre les simulations avec ISS.
3.2.3.3 Possibilit´es d’´evaluation du logiciel embarqu´e
avec simulateur d’instructions et limitations
Les possibilit´es de mesures de performances avec des simulations pr´ecises de processeurs (pour l’instant des ISS) sont nombreuses. Les deux principales sont la mesure des trafics sur les r´eseaux et le nombre d’instructions ex´ecut´ees sur chaque processeur pour effectuer une fonction pr´ecise.Pour la mesure des trafics du r´eseau, un m´ecanisme d’enregistrement des transactions est mis en œuvre. Toutes les donn´ees concernant une transac-tion, moment, dur´ee, adresse, donn´ees, types, connexion sont enregistr´es dans une base de donn´ees. Il est ensuite possible de visualiser, figure 3.2.3, les tran-sactions pour chaque connexion de l’architecture.
Travaux r´ealis´es sur l’architecture multi-processeurs h´et´erog`ene `a m´emoire partag´ee et le logiciel H264 pour la simulation
Fig. 3.2.3 – Visualisation1
des traces lors d’une simulation avec ISS Des outils suppl´ementaires permettent aux concepteurs d’architectures de faire des tris, des calculs ou statistiques sur ces transactions.
Le d´eveloppement de mod`ele TLM avec temporisations ´etant en cours, les mod`eles utilis´es pour cette exp´erience, `a part le processeur, n’ont pas de pr´ecisions temporelles. Au mieux il est possible de configurer des temps d’acc`es moyens aux p´eriph´eriques et aux r´eseaux.