Annotation temporelle d’une simulation TLM

La performance d’un syst`eme embarqu´e peut ˆetre ´evalu´ee en co-simulant son logiciel sur un ISS (ou un ensemble d’ISS si il contient plusieurs processeurs) avec son architecture mat´erielle au niveau RTL. Cependant, une telle co-simulation demande un temps important. Cette simulation peut ˆetre acc´el´er´ee en rempla¸cant les mod`eles RTL des composants g´en´eriques tel que les bus, les m´emoires et les p´eriph´eriques par des mod`eles TLM pr´ecis au cycle pr`es (Cai et Gajski, 2003). Cependant, un tel syst`eme peut contenir un code logiciel et des acc´el´erateurs mat´eriels sp´ecifiques `a l’application et pour lesquels il n’existe pas de mod`eles TLM pr´ecis´ement temporis´es. Le probl`eme qui se pose est donc de trouver comment g´en´erer automatiquement de tels mod`eles TLM afin d’obtenir une co-simulation au niveau TLM qui soit grandement acc´el´er´ee et qui permette d’estimer ad´equatement le temps d’ex´ecution qu’on obtiendrait suite `a une co-simulation pr´ecise au cycle pr`es. L’avantage de cette estimation par simulation est que, contrairement `a l’analyse statique, elle peut s’appliquer `a des tˆaches qui

effectuent des communications `a des endroits arbitraires dans le CFG et selon des d´ependances de contrˆole arbitraires entre les tˆaches. L’annotation temporelle d’un mod`ele TLM peut se faire `a l’aide d’une analyse statique ou d’une analyse dynamique du code de l’application mod´elis´ee.

2.4.2.1 Annotation temporelle par analyse statique

Diff´erents travaux d´eterminent par une analyse statique le temps d’ex´ecution de chaque op´eration ou de chaque bloc de base du CFG d’un logiciel embarqu´e. Le code original, ou un code ´equivalent `a celui-ci, est ensuite instrument´e statiquement avec des annotations tempo- relles pour produire un mod`ele TLM temporis´e du logiciel. Cette instrumentation accumule le temps d’ex´ecution correspondant `a chaque bloc de base ex´ecut´e lors de la simulation. Le mod`ele TLM du logiciel se synchronise avec le reste de la plate-forme mat´erielle, selon le temps d’ex´ecution accumul´e depuis la derni`ere synchronisation, seulement lorsqu’il doit com- muniquer avec celle-ci. Cela permet de limiter le nombre de synchronisations et d’acc´el´erer la simulation. En effet, un bout de code se trouvant entre deux communications, qui est appel´e un segment de programme (Wolf et Ernst, 2001; Posadas et al., 2004), peut contenir plusieurs blocs de base.

Ainsi, dans (Posadas et al., 2004), l’instrumentation statique est impl´ement´ee par une surcharge des op´erateurs C/C++ (addition, multiplication, etc.) `A chaque fois qu’un tel op´erateur est appel´e dans le code source d’un module TLM SystemC, le temps d’ex´ecution du module est incr´ement´e du temps d’ex´ecution associ´e `a l’op´erateur. La caract´erisation d’un processeur cible donn´e consiste donc `a associer `a chaque op´erateur C/C++ un temps d’ex´ecution sur le processeur cible. L’estimation r´ealis´ee par (Hwang et al., 2008) suit des principes similaires. Un CFG est d’abord extrait d’un code C `a l’aide de l’infrastructure de compilation LLVM (Lattner et Adve, 2004). Le temps d’ex´ecution de chaque bloc de base est ensuite estim´e statiquement, pour le processeur MicroBlaze pr´ealablement caract´eris´e, selon les op´erateurs qu’il contient et le pipeline du processeur. Des taux fixes de d´efaut (miss) de cache et d’erreur de pr´ediction de branchement sont utilis´es pour estimer les p´enalit´es associ´ees `a ces ´ev`enements. Le code C est ensuite annot´e avec les d´elais associ´es aux blocs de base, puis encapsul´e dans un module SystemC. Le probl`eme avec une telle approche est que le temps d’ex´ecution sur un processeur cible est connu pour les instructions assembleur et non pour les op´erateurs d’un langage `a haut niveau tel C/C++. Rien ne garantit que les compilateurs pour un processeur cible donn´e g´en`ereront toujours la mˆeme s´erie d’instructions assembleur pour un mˆeme op´erateur. De plus, les appels `a certains op´erateurs pr´esents dans le code source pourraient ˆetre ´elimin´es par les optimisations du compilateur.

processeur cible Infineon TriCore (Infineon Technologies AG, 2000), qui a pr´ealablement ´et´e caract´eris´e. Le temps d’ex´ecution de chaque bloc de base est d´etermin´e statiquement selon les instructions assembleur correspondant au bloc de base et en tenant compte du pipeline du processeur. Les temps d’ex´ecution extraits sont alors annot´es pour chaque bloc de base dans le code C original, qui est ensuite encapsul´e en un module SystemC. Cette m´ethode suppose donc que le CFG du code source C est identique au CFG obtenu suite `a la compilation crois´ee, ce qui n’est pas n´ecessairement le cas en raison des optimisations du compilateur. Le code du module SystemC est ´egalement annot´e pour faire appel `a un mod`ele de cache d’instructions et un mod`ele de pr´ediction dynamique de branchement. Cela permet d’ajouter dynamiquement les p´enalit´es de d´efauts (miss) de cache et d’erreur de pr´ediction de branchement au temps d’ex´ecution du logiciel.

Dans (Gerin et al., 2009), un code C/C++ est d’abord converti en une repr´esentation interm´ediaire (IR : Intermediate Representation) lors d’une compilation crois´ee avec LLVM. L’IR obtenue tient donc compte des optimisations de compilation, que celles-ci d´ependent du processeur cible ou non, ´etant donn´e que c’est l’IR qui est directement utilis´ee pour la g´en´eration du code assembleur cible. Le temps d’ex´ecution de chaque bloc de base de cette IR est analys´e statiquement, pour un processeur cible ARM9 pr´ealablement caract´eris´e, en te- nant compte du pipeline. Des appels `a une fonction d’instrumentation accumulant ces temps d’ex´ecution sont ajout´es aux blocs de base de cette IR, puis elle est utilis´ee pour g´en´erer directement un code assembleur pour le processeur hˆote. Cela assure que l’assembleur hˆote instrument´e et l’assembleur cible ont le mˆeme CFG. Cet assembleur hˆote est ex´ecut´e native- ment sur un mod`ele TLM de processeur, qui impl´emente une couche d’abstraction mat´erielle (HAL : Hardware Abstraction Layer) permettant au logiciel simul´e de communiquer avec la plate-forme mat´erielle. Ce mod`ele utilise ´egalement un taux fixe de d´efauts de cache d’ins- tructions pour en estimer les p´enalit´es.

Il est possible que plusieurs tˆaches logicielles soient assign´ees `a un mˆeme processeur et ordonnanc´ees par un RTOS. Pour ´eviter des erreurs importantes d’estimation, il est alors n´ecessaire de tenir compte non seulement de la politique d’ordonnancement du RTOS, qui s´erialise l’ex´ecution des tˆaches logicielles, mais ´egalement du temps d’ex´ecution du RTOS lui-mˆeme (Hwang et al., 2009). Les travaux pr´esent´es ci-dessus le font `a divers degr´es. Ainsi, (Schnerr et al., 2008) supporte une mod´elisation TLM de l’ordonnancement et des change- ments de contexte, mais ne tient pas compte de leur temps d’ex´ecution. Quant `a (Posadas et al., 2004) et (Hwang et al., 2009) (qui ´etend (Hwang et al., 2008)), ils int`egrent une mo- d´elisation TLM temporis´ee du RTOS, mais seul (Hwang et al., 2009) pr´esente une mani`ere de caract´eriser le temps d’ex´ecution du RTOS. Cette caract´erisation consiste en un profi- lage intrusif d’une application qui exerce les diff´erentes primitives du RTOS dans un ordre

d´etermin´e. Cela permet d’extraire le temps d’ex´ecution des primitives du RTOS, tel qu’un changement de contexte ou l’utilisation d’un s´emaphore. Dans (Gerin et al., 2009), une m´e- thode diff´erente est utilis´ee pour un RTOS dont le code source est disponible : celui-ci est instrument´e statiquement comme les tˆaches logicielles et le tout est ex´ecut´e sur la HAL fourni par un mod`ele TLM du processeur. Par contre, le temps d’ex´ecution de la HAL elle-mˆeme, qui comprend notamment les changements de contexte, n’est pas pris en compte.

Notre m´ethode d’estimation tient compte des temps d’ex´ecution des tˆaches logicielles, du RTOS et de la HAL, qui sont automatiquement caract´eris´es. La caract´erisation du RTOS est similaire `a celle de (Hwang et al., 2009) mais l’am´eliore en utilisant un profilage non-intrusif et en tenant compte de l’´etat du RTOS lorsqu’une de ses primitives est exerc´ee (par exemple, lib´erer un s´emaphore prend un temps suppl´ementaire si une tˆache attend apr`es celui-ci mˆeme si cela ne produit pas de changement de contexte). Notre m´ethode automatise ´egalement la caract´erisation du temps d’ex´ecution des acc´el´erateurs mat´eriels g´en´er´es `a l’aide de la synth`ese comportementale alors que les travaux pr´esent´es ci-dessus permettent de g´en´erer des mod`eles TLM temporis´es seulement pour les tˆaches logicielles. Cependant, la diff´erence plus fondamentale entre ces travaux et notre m´ethode d’estimation est que celle-ci effectue plutˆot une analyse des traces extraites d’un ensemble de simulations initiales d’une mˆeme ap- plication donn´ee. Cela permet d’´evaluer rapidement une grande quantit´e d’impl´ementations possibles de cette application sans avoir `a simuler sa fonctionnalit´e `a chaque fois. Les m´e- thodes d’instrumentation statique pr´esent´ees ci-dessus pourraient ˆetre utilis´ees pour acc´el´erer les simulations initiales n´ecessaires `a la production des traces et sont donc compl´ementaires `a notre m´ethode d’estimation.

2.4.2.2 Annotation temporelle par analyse dynamique

Il est possible d’ins´erer des annotations temporelles dans les mod`eles TLM des tˆaches de l’application non pas au niveau de leurs op´erateurs C/C++ ou de leurs blocs de base, mais plutˆot au niveau de leurs segments de programme, soit entre deux communications externes aux tˆaches. Cependant, un segment de programme peut contenir plusieurs blocs de base et constitue un CFG qui est un sous-graphe du CFG de la tˆache. Le temps d’ex´ecution d’un segment de programme peut donc varier selon le chemin parcouru dans son CFG. Il serait possible d’effectuer une analyse statique du WCET d’un segment de programme `a l’aide des m´ethodes pr´esent´ees `a la section 2.4.1.2 et d’annoter le mod`ele TLM de la tˆache en cons´e- quence, mais `a notre connaissance cette approche n’a pas ´et´e propos´ee dans la litt´erature et elle risquerait d’ˆetre pessimiste et de demander une intervention de l’utilisateur. L’autre m´e- thode est de profiler le temps d’ex´ecution de chaque segment de programme sur le processeur cible alors que l’application est exerc´ee par un banc d’essai. Une telle approche se justifie

dans le cadre d’une m´ethodologie d’exploration architecturale, o`u la caract´erisation initiale d’une application permettra d’acc´el´erer les simulations d’une grande quantit´e d’architectures impl´ementant celle-ci.

Ainsi, les simulateurs VPC (Streubuhr et al., 2009) et Sesame (Pimentel et al., 2006) sont respectivement utilis´es par les m´ethodologies d’exploration architecturale SystemCoDesigner (Keinert et al., 2009) et Daedalus (Nikolov et al., 2008c) pour estimer la performance des solutions possibles. Ces deux simulateurs ex´ecutent un mod`ele non temporis´e de l’application qui g´en`ere des ´ev`enements de communications et de calculs sur un mod`ele TLM temporis´e d’une architecture qui r´epond `a ces ´ev`enements. Une couche d’assignation relie entre eux les mod`eles de l’application et de l’architecture et associe notamment `a chaque segment de programme un temps d’ex´ecution donn´e. VPC mod´elise l’application comme un ensemble d’acteurs `a ´etats finis SysteMoC (Falk et al., 2006) et simule l’ensemble des couches `a l’aide de SystemC. Sesame effectue plutˆot une co-simulation : un mod`ele d’application sous la forme d’un KPN est ex´ecut´e nativement avec la librairie C/C++ pthreads alors que la couche d’assignation et les mod`eles d’architecture sont simul´es avec le simulateur `a ´ev`enements discrets Pearl (Muller, 1993).

(Keinert et al., 2009) obtient le temps d’ex´ecution sur un processeur MicroBlaze des actions d’un acteur SysteMoC (essentiellement des segments de programme) `a l’aide d’un profilage du PC sur FPGA semblable aux m´ethodes pr´esent´ees `a la section 2.3.1.1. Ainsi, l’utilisateur doit extraire l’adresse du point d’entr´ee et du point de sortie de chaque segment `a profiler, configurer le profileur FPGA avec ces adresses, ex´ecuter le profilage puis configurer la couche d’assignation de VPC selon les r´esultats recueillis lors du profilage. Dans (Pimen- tel et al., 2008), le temps d’ex´ecution logiciel des segments de programme d’un processus KPN mod´elis´e avec Sesame est extrait `a l’aide d’une co-simulation du mod`ele d’application KPN avec un ISS SimpleScalar qui ex´ecute le code du processus. Ainsi, l’utilisateur doit d’abord annoter le code C/C++ du processus `a caract´eriser pour identifier les segments de programme. Une compilation crois´ee du processus vers le processeur cible est ensuite r´ealis´ee, puis l’utilisateur doit instrumenter le code assembleur produit pour que le logiciel mesure le nombre de cycles ´ecoul´es pendant l’ex´ecution d’un segment de programme. Cette m´ethode est donc intrusive. Un profilage du processus sur l’ISS est ensuite r´ealis´e et, pour chaque seg- ment de programme profil´e, la valeur moyenne du temps d’ex´ecution est extraite. Ces valeurs peuvent ˆetre utilis´ees par l’utilisateur pour configurer la couche d’assignation.

Alors que ces m´ethodes de caract´erisation logicielle des segments de programme par pro- filage sont semi-manuelles, notre m´ethode par profilage sur ISS automatise pleinement toutes les ´etapes de la caract´erisation logicielle. Notre m´ethode automatise ´egalement la caract´e- risation du temps d’ex´ecution mat´eriel des segments de programme par le profilage d’une

simulation SystemC mixte de l’application au niveau TLM avec le module RTL `a caract´eri- ser. Elle automatise aussi la caract´erisation du temps d’ex´ecution des op´erations du RTOS afin d’en tenir compte lors de l’estimation. Cette automatisation de la caract´erisation per- met d’adapter facilement l’estimation aux changements dans le code de l’application ou aux mises `a jour du RTOS. Bien que VPC et Sesame tiennent compte de l’ordonnancement des tˆaches, ils ne tiennent pas compte du temps d’ex´ecution de l’ordonnancement dynamique, ce qui peut causer d’importantes erreurs d’estimation (Streubuhr et al., 2009; Pimentel et al., 2008). Finalement, notre estimation par trace se base sur le temps de chaque ex´ecution de chaque segment de programme au lieu de se baser seulement sur leur temps moyen, ce qui permet de mieux estimer la performance de ceux-ci.