Chapitre 3: La simulation pour l’estimation des performances et de la consommation
3.4. L’estimation de la consommation des systèmes sur puce
3.4.2. Les outils d’estimation de la consommation
Il existe un grand nombre de méthodes et outils, pour l’estimation de la consommation des SoCs, dans la littérature. Les niveaux d’abstraction auxquels ces outils opèrent, constituent une des façons de les différencier et les classifier. Ainsi, je présente dans la suite de cette section quelques outils connus pour chaque niveau d’abstraction, en allant du niveau transistors au niveau fonctionnel.
3.4.2.1. Niveau transistors
L’estimation de la consommation à ce niveau se base sur les courants électriques qui circulent dans les transistors, ce qui nécessite une description du SoC au niveau transistor. Parmi les outils opérant à ce niveau, nous trouvons SPICE [SPA], Lsim Power Analyst de Mentor Graphics [LSI04] et Power Mill de Synopsis [POW].
51
L’estimation à ce niveau a l’avantage de donner des résultats très proches des valeurs réelles mais elle a l’inconvénient d’un temps de simulation important. Cette lenteur constitue un obstacle pour l’estimation de la consommation d’une architecture à haut degré d’intégration.
3.4.2.2. Niveau portes logiques
A ce niveau, l’estimation de la consommation se base sur une bibliothèque de portes logiques permettant l’association d’un coût de consommation à chaque type de porte logique et l’utilisation de ces données pour déterminer la consommation du circuit. Parmi les outils utilisant cette technique, nous trouvons PowerGate de Synopsys [PoGa].
3.4.2.3. Niveau RTL
Ce niveau d’estimation se base sur la description de l’implémentation sous forme de registres et de bascules. Parmi les outils qui utilisent cette approche, nous trouvons Petrol de Philips [LlGo98].
L’estimation de la consommation aux trois niveaux présentés ci-dessus souffre d’une lenteur considérable, ce qui rend difficile l’exploration des différentes solutions architecturales. De plus, ces trois niveaux ne permettent pas d’étudier l’évolution de la consommation au cours de l’exécution de l’application du fait qu’ils se basent uniquement sur la partie matérielle.
3.4.2.4. Niveau architectural
Ce niveau d’estimation se base sur des niveaux d’abstraction plus élevés. Ce niveau estime la consommation correspondante à des évènements qui ne concernent pas la commutation dans un transistor ou le changement d’état d’une porte logique, mais qui sont liés aux activités des composants telles que l’exécution d’une instruction par un processeur ou l’accès mémoire.
L’analyse de la consommation par trace : La première approche est proposée par
l’outil AVALANCHE [HEN99]. Dans cette approche, l’application est exécutée en utilisant un simulateur de processeur décrit au niveau du jeu d’instruction (Instruction Set Simulator ISS). La trace de l’exécution de l’application sert à estimer la consommation du processeur. Pour la consommation de la hiérarchie mémoire, il y a aussi une trace des accès fournie par un traceur de requêtes. Cette trace est traitée par l’outil Dinero [LiHe98], pour en détecter les succès et les défauts de cache et les accès aux mémoires de données ou d’instructions. Les occurrences des activités du processeur et de la hiérarchie mémoire sont transmises à des modèles d’énergie, selon le type du composant, pour calculer la consommation totale. L’inconvénient de cette approche est qu’elle ne considère pas la consommation de l’interconnexion ni celle des interactions temporelles entre les composants telles que les délais dus aux conflits lors des accès simultanés à une mémoire.
L’analyse de la consommation au cycle près : Cette approche vient remédier à
l’imprécision de l’approche précédente en se basant sur une simulation au cycle près. Elle assure la synchronisation entre les différents composants du système décrits avec un langage de description comme le C et le SystemC. Un modèle de consommation pour chaque composant est intégré dans le simulateur pour permettre le calcul de la consommation à chaque cycle en se basant sur les occurrences des activités pertinentes des composants. Parmi les outils utilisant cette approche, on peut citer Wattch [BTM00] et SimplePower [YVK00]. L’inconvénient de cet outil est qu’il ne permet pas l’estimation de la consommation d’une architecture multiprocesseur (MPSoC) mais se base sur un seul processeur super-scalaire.
52 3.4.2.5. Niveau fonctionnel ou algorithmique
Ce niveau d’estimation étudie la consommation d’un programme. La première méthode pour ce type de consommation est la méthode de Tiwari et al. [TMW94]. Cette approche consiste à cumuler l’énergie consommée par chaque instruction pour trouver la consommation totale du programme. Cette méthode nécessite beaucoup d’analyses et de mesures et par conséquent un temps important pour développer le bon modèle de consommation pour un processeur cible.
Parmi les outils qui utilisent cette méthode, nous citons l’outil JouleTrack [SCJ00], développé par Sinha et al., qui permet d’estimer la consommation pour des processeurs simples tels que les RISC.
L’outil SoftExplorer [SLJ04], développé LabSticc, vise à étendre la méthodologie de Tiwari pour des processeurs plus complexes et à réduire le temps de développement des modèles de consommation. Cet outil utilise une méthode qui s’appelle FLPA (Functional Level Power Analysis) [LJS04]. Elle se base sur un nombre réduit de mesures permettant de déterminer des paramètres algorithmiques, agissant sur la consommation, tels que le taux du parallélisme et le taux d’occupation des unités de traitement. Les lois de la consommation sont extraites en exécutant des applications élémentaires sur le processeur. Ces lois s’écrivent en fonction des paramètres algorithmiques et des paramètres de la configuration tels que la fréquence et le placement des données en mémoire. Après avoir déterminé ces lois, elles peuvent être appliquées à chaque application pour déterminer sa consommation totale. Ainsi, une analyse du code est faite pour extraire les paramètres algorithmiques. Ces paramètres sont insérés par la suite dans les équations du modèle de consommation de l’application. L’avantage de cette méthode est sans doute son temps d’estimation de l’ordre de quelques secondes.