• Aucun résultat trouvé

2.3 Les plates-formes d’outils disponibles pour le DSE

2.3.1 Plate-formes d’outils au niveau syst`eme

Les outils de cette cat´egorie permettent de mod´eliser et d’´evaluer les architectures et des applications sur diff´erents niveaux d’abstraction en utilisant diff´erents mod`eles de description. Ils vont donc aussi sou- vent permettre de coupler des outils d’´evaluation de diff´erentes sources et fournisseurs afin de permettre l’´evaluation des architectures h´et´erog`enes au niveau syst`eme.

Metropolis [10]. Universit´e de Californie `a Berkeley, Politecnico di Torino, et Cadence Berkeley Labs. Metropolis est un framework qui permet la description et le raffinement d’un design `a diff´erents niveaux d’abstraction et int`egre la mod´elisation, la simulation, la synth`ese et les outils de v´erification. La fonction d’un syst`eme, telle que l’application, est mod´elis´ee comme un ensemble de processus qui communiquent `

a travers les m´edias. Un comportement non-d´eterministe peut-ˆetre mod´elis´e et les contraintes peuvent re- streindre l’ensemble des ex´ecutions possibles. Les blocs d’architecture sont repr´esent´es par des mod`eles de performance o`u les ´ev´enements sont annot´es avec des coˆuts d’int´erˆet. Des annotations suppl´ementaires pour- raient inclure des informations arbitraires, comme une demande d’acc`es `a une ressource partag´ee, qui est soumise `a un contrˆole centralis´e par un gestionnaire de quantit´e. Une correspondance entre les mod`eles fonctionnels et l’architecture est d´etermin´ee par un troisi`eme r´eseau qui corr`ele les deux mod`eles par des ´ev´enements de synchronisation (en utilisant des contraintes) entre eux.

Artemis [114]. Universit´es de Amsterdam, Delft, Leiden, NL, et Philips Research. Artemis est fond´e sur une description en r´eseaux de processus de Kahn de l’application et int`egre les id´ees de SPADE [86], c’est `a dire que la co-simulation du syst`eme est effectu´ee en utilisant des traces d’instructions symboliques g´en´er´ees et interpr´et´ees lors de l’ex´ecution par les mod`eles de performance abstraits. Il ajoute des am´enagements afin

Figure 2.13: Repr´esentation graphique du flot Artemis [114].

d’explorer les architectures reconfigurables et pour le raffinement des mod`eles d’architecture. Dans [115], une couche suppl´ementaire de processeurs virtuels est introduite entre les applications et les architectures en vue

de r´esoudre les blocages possibles en raison de d´ecisions de mapping.

Rabbit (Plate-forme bas´ee sur QEMU) Laboratoire TIMA [139] (CNRS). Rabbit est une plate-forme bas´ee sur QEMU et SystemC permettant `a la fois d’ex´ecuter du code r´eel sur la partie processeur, mais aussi d’impl´ementer des p´eriph´eriques en SystemC. Cet environnement am´eliore l’´emulateur QEMU afin d’y ajouter la notion de temps. Il est alors possible d’annoter les diff´erents mod`eles de processeurs disponibles avec le nombre de cycle de chaque instructions. L’avantage de cette m´ethodologie est d’ˆetre capable d’ex´ecuter le vrai code qui s’ex´ecutera sur la plate-forme embarqu´ee. De plus, des mod`eles de consommation haut-niveau sont aussi impl´ementables. Diff´erents mod`eles de raffinement pour les acc`es m´emoire sont aussi possibles, ce qui permet d’effectuer des simulation plus ou moins rapides/pr´ecises. Cependant, le temps de simulation augmente fortement si le niveau de pr´ecision simul´e est tr`es important. En effet, le temps de simulation de 10 benchmarks peut aller de 15 minutes pour un niveau d’abstraction tr`es ´elev´e, jusqu’`a une journ´ee lorsque les niveaux de caches et l’interconnexion sont tr`es finement mod´elis´es [83].

L’exploration d’architectures automatique n’est pas disponible dans cet outil mais le nombre important de mod`eles de processeur permet d’explorer de nombreuses possibilit´es manuellement.

OpenPeople [132] Ce projet d´evelopp´e par plusieurs universit´es fran¸caises permet de d´ecrire des SoC dans le langage AADL. Cela donne la possibilit´e d’ajouter des contraintes et d’analyser les mod`eles. Cet outil a ´et´e d´evelopp´e afin de partager diff´erents mod`eles de consommation d’´energie dans une mˆeme plate-forme. Des mod`eles de processeurs, mais aussi de DSP ainsi que de FPGA sont disponibles. En plus de la plate-forme de mod´elisation, un banc de mesure de la consommation d’´energie `a distance a aussi ´et´e d´evelopp´e, ce qui permet la v´erification de ses mod`eles.

Figure 2.14: Illustration globale de la plate-forme Open-PEOPLE. [4]

La figure 2.14 montre le sch´ema global utilis´e dans le projet Open-PEOPLE. On peut y voir d’un cˆot´e la plate-forme mat´erielle permettant d’effectuer des mesures afin de cr´eer des mod`eles, et d’un autre cˆot´e la plate-forme logicielle permettant d’effectuer les mod´elisations.

Ce projet permet avec un unique langage (AADL) d’estimer la consommation d’´energie d’un syst`eme avec diff´erents mod`eles. Une des m´ethodologies d’estimation de la consommation d’´energie repose en deux

parties.

Dans un premier temps, des mod`eles de consommation de la plate-forme sont ´elabor´es. Ces mod`eles re- posent sur la m´ethodologie FLPA (Functional Level Power Analysis [97]) qui consiste `a identifier un jeux de blocs fonctionnels qui influent fortement sur la consommation d’´energie du composant cibl´e. Deux types de param`etres sont identifi´es dans [124], les param`etres algorithmiques qui d´ependent de l’algorithme ex´ecut´e (ex : taux de cache-miss et instructions par cycle) et les param`etres architecturaux qui d´ependent de la configuration du composant (ex : la fr´equence).

Une caract´erisation de la variation de consommation d’´energie lorsque les param`etres varient est alors ef- fectu´ee afin d’en d´eduire des lois. Ceci est fait `a l’aide de programmes ´el´ementaires en assembleur (que l’auteur appelle sc´enario) ou des vecteurs de test ´elabor´es pour stimuler chaque bloc s´epar´ement.

La deuxi`eme partie consiste `a d´ecrire l’architecture mat´erielle `a l’aide d’un simulateur (OVPSim). Ce simulateur est modifi´e et am´elior´e afin, lorsqu’il ex´ecute l’application, de compter les diff´erentes activit´es n´ecessaires `a l’estimation de consommation (taux de cache-miss, instructions par cycle...). Le simulateur est alors utilis´e ici comme un profiler permettant d’obtenir des informations dynamiques sur l’application. L’estimation de consommation est alors ensuite faite `a l’aide des lois d´eduites dans la premi`ere partie et de la simulation effectu´ee dans la deuxi`eme partie.

Figure 2.15: Une des m´ethodologies d’estimation de la consommation d’´energie dans le projet Open- PEOPLE. [124]

La figure 2.15 montre les deux diff´erentes ´etapes de cette approche, la mesure puis la simulation.

L’article [124] d´eduit des mesures un mod`ele de consommation pour le processeur ARM Cortex-A8 : P(mW ) = 0.79 · FP rocessor+ 18.65 · IP C + 0.26 · (y1+ y2) + 10.13

O`u :

– FP rocessorrepr´esente la fr´equence du processeur. – IP C repr´esente le nombre d’instructions par cycle. – y repr´esente le taux de cache-miss.

Cette approche est int´eressante du fait de sa pr´ecision (4% maximum) pour un niveau d’abstraction assez haut.

Ici encore, l’exploration d’architecture est manuelle pour le moment, mais plusieurs travaux visent `a automa- tiser le processus d’exploration.