pp. 903-937

903

Panorama des outils d'analyse et d'optimisation de la consommation dans les syst mes sur puce (SoC) Nathalie J U L I E N *

R6sum6

La consommation est actuellement une contrainte critique des applications de traitement du signal et de l'image ; l' apparition des Systbmes sur puce (Systems-on-Chip, SoC) ne fait qu'en complexifier l'gtude en augmentant l'hdt(rog(ndit(, la densitd et les performances du syst~me. Pour apprdhender ce probl~me et cibler efficacement les actions, nous examinerons d'abord les sources de cette consommation et sa r(partition dans les circuits et syst~mes ; puis nous proposerons un (tat de l' art non exhaustif des m(thodes d' estimation et d'optimisation de la consommation, des outils disponibles ainsi que des besoins et perspectives de la conception faible consommation pour les SoC. Mot cl6s: Syst~me sur puce, Consommation 6nergie, Puissance 61ectrique, Basse 6nergie, Gestion 6nergie, Syst~me int6gr6, Mat6riel, Logiciel, Optimisation, M6moire.

OVERVIEW OF POWER/ENERGY CONSUMPTION ANALYSIS AND OPTIMIZATION TOOLS IN SOCS Abstract

Power and energy consumption is currently a critical problem in digital signal and image processing applications; the emergence of Systems-on-Chip (SoCs) makes the power analysis difficult by increasing the system heterogeneity, density and performances. To take into account this problem and efficiently focus the actions, we will first examine the main sources of the power consumption and its distribution in circuits and systems; then we will propose a non exhaustive overview of estimation and optimization methods and available tools together with the needs and perspectives in low power SoC design. Key words: System on chip, Energy consumption, Electric power, Low energy, Energy management, Integrated system, Hardware, Software, Optimization, Memory.

* Laboratoire des Syst6mes Temps R6els (LESTER),Universit6de Bretagne Sud-Lorient, Centre de Recherche, rue de Saint Maud6 B.E 92116, 56321 Lorient Cedex, France ; [email protected] 1/35

ANN. T~Lf~COMMUN.,59, n° 7-8, 2004

904

N. JULIEN -- PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

Sommaire I. Introduction

II. Le problbme de la consommation III. Comment maftriser la consommation ? IV. Conception matdrielle

V. Conception logicielle

VI. Mdmoires VII. Circuits programmables et reconfigu-

rabies

VIII. Conclusion

Bibliographie (140 rdf )

I. I N T R O D U C T I O N

La consommation s'est dor6navant impos6e comme une nouvelle contrainte de conception des circuits VLSI, au mEme titre que la surface et la vitesse. Pour ~tre efficace, il est important d'en tenir compte au plus t6t et ~ chaque niveau du not de conception. Nous allons dans un premier temps examiner les 6volutions des applications du traitement du signal et de l'image (TDSI) et plus particuliOrement les pr6visions pour les SoC.

1.1. ]~volutions des applications TDSI Les syst6mes mobiles ou embarqu6s se sont fortement d6veloppEs dans les ann6es 90, et le march6 devrait continuer son 6volution. Ils sont caractEris6s par des besoins en calcul importants (de moins de 100 Mips pour un GSM h 3800 Mips pour UMTS)et une large bande passante (elle devrait 6voluer de 10 kbit/s ~ 10 Mbit/s). Dans ce march& l'utilisateur demande de plus en plus de fonctionnalitEs, de diversit6, d'adaptabilit6, de personnalisation (syst6mes <>) et de qualit6 [1]. De nouveaux syst6mes devraient prochainement ~tre embarqu6s dans un environnement quotidien comme des habits, le corps humain... [2] ; cela impliquera plus d'h&Erog6n6it6 car les syst6mes comporteront des capteurs/actionneurs, des MEMS, 6ventuellement des dispositifs de stockage de donn6es (optique ou disque dur). Enfin, le temps d'acc6s au march6 (time-to-market) vase r6duire de 1 an h 1 mois (instant silicon). Si on examine les 6volutions des circuits VLSJconstat6es sur les derni~res ann6es [3, 4] et leur projection dans les ann6es futures (roadmaps SIA [5], EDAA [6], ITEA [7], ITRS [8] et ESR [1]), dont les principales tendances sont r6sum6es clans le Tableau I, on aboutit aux constats suivants : le hombre de transistors sur une puce double tousles 12 h 24 mois (loi de Moore), la fr6quence des microprocesseurs F double h chaque nouvelle g6n6ration (c'est ~t dire tousles 2 ~ 3 ans) [3], la technologie diminue de 30% par g6n6ration ; de m~me, la tension d' alimentation Vdd d6cro]t de 30% par g6n6ration, jusqu'~ 0,4 V pour 2016 [8], la surface augmente de 25% par g6n6ration et la taille du logiciel double tousles afls.

ANY. TE~L,ECOMMUN., 59, n ° 7-8, 2 0 0 4

2/35

905

N. JULIEN -- PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

TABLEAUI. - l~volutions technologiques des circuits VLSI.

VLSlcircuit technological evolutions. Ann6e Technologie (nm) Horloge Iap(MHz) Surface (mm2) Vdd (V) Energie d'applications haute performance (W) Energie d'applications portables (W)

1999 180 1250 340 1.8

2002 130 2100 430 1.5

2005 100 3500 520 1.2

2008 70 6000 620 0.9

2011 50 10000 750 0.6

2014 35 16900 900 0.5

90 1.4

130 2

160 2.4

170 2.8

175 3.2

183 3.7

De plus, il faut ma~triser d'autres contraintes : le coot (au maximum quelques dollars par puce pour l'61ectronique de grande diffusion), la consommation ('power budget' constant donc il faudra plus de puissance de calcul par watt) et la surface (pour limiter les contraintes de cofit, manufacture et conception). La demande de flexibilit6 dans le circuit implique que le logiciel va devenir un 616ment pr6dominant ; il repr6sente h l'heure actuelle 70 % du coot de d6veloppement des syst~mes complexes et cette tendance va s'accentuer [9]. La m6moire aura, elle aussi, une part de plus en plus importante notamment avec de tr6s importants blocs de DRAM embarqu6s [ 10] et l'introduction de nouveaux types de m6moire au-del?t de 2007, comme des m6moires haute densit6 non volatiles (NVM) [8]. Afin de r6pondre ?~la dur6e de vie des produits et ?aleur temps de d6veloppement de plus en plus courts, ils seront conqus h partir d'une architecture standardis6e ou plate-forme (propri6taire ou multi-vendeurs). De plus, la flexibilit6 impose 6galement l'utilisation croissante de blocs de propri6t6 intellectuelle (Intellectual Properties, IP) ou composants virtuels (logiciels ou mat6riels) avec des efforts importants pour leur standardisation et leur interfaqage [ !]. Enfin, les circuits et syst~mes deviendront de plus en plus h6t6rog~nes, en faisant coexister des circuits CMOS classiques avec des circuits non-cMos, incluant notamment les interconnexions et la m6moire mais aussi des nouvelles technologies int6gr6es (MEMS, 61ectro-optique, 61ectro-chimique, 61ectro-biologique...) [8]. Or, actuellement la productivit6 cro]t seulement de 21% par an contre 58% pour la complexitE des circuits [4]. I1 faut donc accorder une attention particuli~re au dEveloppement des mEthodes de conception. Du fait de l'h6t6rogEnEit6 des cibles, il faudra des outils et des mEthodes de specification pluridisciplinaires, et spEcialement des outils de verification et de validation. I1 faudra 6galement accentuer l'automatisation des phases de conception de haut niveau. Les compilateurs devront optimiser diffErents crit~res : taille du code, d6bit, puissance, contraintes temps reel .... L'usage des compilateurs pour architectures VLIW, des compilateurs reciblables et des compilateurs pour architectures reconfigurables v a s e d6velopper. Les riots de conception HW/SW vont se confondre et l'exploration de l'espace de conception (Design Space Exploration) sera une phase sensible [11] ; pour la mener h bien, il faudra disposer de m6triqucs pour quantifier les decisions architecturales et plus prEcis~ment de modules fiables caract6risant les composants IP disponibles (en vitesse, surface et consommation...) [ 1].

3/35

ANN.TI~LI~COMMUN.,59, n° 7-8, 2004

906

N. JULIEN -- PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

1.2. P r 6 v i s i o n s p o u r les S o C

Les systEmes complets intEgrEs sur une mSme puce de silicium, ou System-On-Chip (SoC) peuvent contenir de la mEmoire (ROM, SRAM, DRAM), diffErents processeurs (microcontr61eurs, microprocesseurs, processeurs de traitement du signal) et leur logiciel embarquE, des circuits h application spEcifique (ASIC), de la logique reconfigurable (~GA), des IP (matEriels ou logiciels), des bus (NOC) mais 6galement des parties RF, analogiques et optoElectroniques. Ils se caract6risent donc par une forte complexit6 et l'importance de la rEutilisation de blocs IP (matEriel ou logiciel) pour des composants ou des fonctions [12]. A partir de 2007, on prEvoit que l'hEtErogEnEit6 des SoC va augmenter du fait de l'intEgration de capteurs et d'actionneurs en technologies h6tErogEnes [8]. La ma]trise de ta consommation est donc un problSme transversal dans la conception des SoC. Le Tableau II indique les reductions de consommation qui devront 8tre mises en oeuvre dans les futurs SoC [8]. Quand la cellule est en blanc, cela signifie que les solutions techniques sont connues et en cours d'optimisation ; si la cellule est en gris clair, les solutions techniques sont connues mais pas encore appliquEes, et si elle est en gris foncE, ces solutions sont encore inconnues. TABLEAUII. - PrEvisiondes reductionsde consornmationnEcessairesdans les SoC (source ITRS). Power consumption reductions required in future SoCs (source ITRS).

Ann6e R~ductionde Psmtique

t 2004 .

-

2007 ~

)

I

~

2010 /

.

.

2013 .

~

<

2016 :

~

REductionde Pdynamique

Comme, la conception des SoC sera domin6e par la rEutilisation d'IP, il faudra donc, pour concevoir le systEme et choisir le meilleur compromis entre 6nergie, performance et flexibilitE, disposer des caractEristiques completes de ces composants virtuels, y compris la consommation (statique et dynamique). Nous savons en effet, que les techniques d'optimisation au niveau systEme se rEvElent trEs efficaces mais qu'elles nEcessitent de disposer d'estimateurs fiables et rapides. Or la ma~trise de la consommation des systSmes nEcessite la ma~trise des phEnomSnes pour chaque 616ment en particulier ; cela rend le travail d'autant plus dElicat lorsque les systEmes sont fortement hEtErogEnes. I1 faut notamment 8tre capable, lors de la conception systEme, d'estimer les performances de diffErentes solutions architecturales afin d'effectuer rapidement le meilleur choix pour l'application. De plus, pour l'optimisation, il ne suffit pas d' assembler des composants ~ faible consommation, encore faut-il que les architectures elles-mSmes soient con~ues pour la faible consommation [13] ; il faudra notamment des architectures parallEles et 6galement optimiser le logiciel embarquE, et plus particuli~rement la gestion de la mEmoire. Nous verrons dans la section II les enjeux de la conception faible consommation puis en section III l'ensemble des moyens ~ disposition pour rEsoudre ce problbme. La section IV prEsentera plus spEcifiquement les m6thodes et les outils lies ~tla conception matErielle, alors que la section V s'int6ressera ~ la conception logicielle. La section VI traitera le cas particuANN. TI~LECOMMUN., 59, n° 7-8, 2004

4/35

N. JULIEN- PANORAMADESOUTILSD'ANALYSEET D'OPTIMATIONDELACONSOMMATION

907

lier des mEmoires, et la section VH prEsentera le probl~me pour les circuits reconfigurables avant de conclure sur les besoins.

II. LE PROBLEME DE LA CONSOMMATION Le terme de consommation englobe h la fois la notion de puissance et celle d'Energie dissipEe, deux grandeurs qui peuvent ~tre antagonistes. La consideration d'un crit~re plut6t que de l'autre dEpendra des contraintes de l'application : les limites technologiques des batteries impliqueront que les applications mobiles minimisent leur Energie alors que ce sont principalement les contraintes thermiques qui n6cessiteront de contr61er la puissance dissip6e. Les applications portables reprEsentent 32% du marchE des ordinateurs individuels [14] et la diffusion des syst6mes de type bloc-notes Electroniques (notebook), assistants Electroniques de poche (palm), tElEphones cellulaires, radiomessageurs (pagers)... se dEveloppe ; pour de tels syst6mes, le cofit, la taille, le poids et l'autonomie sont des arguments commerciaux importants. Toutes les projections sur l'Evolution des syst~mes s'accordent ~ signaler qu'il y aura de nombreuses difficultEs h ma~triser la puissance comme l'Energie [8].

II.1. Pourquoi s'int~resser h ia consommation ? La consommation devient une contrainte critique car on atteint actuellement les limites des circuits. En effet, les tendances pr6sent6es plus haut de l'augmentation de la complexit6, du niveau d'int6gration et de la fr6quence d'horloge contribuent h l'augmentation de puissance comme indiqu6 sur le Tableau I. On voit cependant que cette croissance s'infl6chit autour de 2005 ; c'est classiquement l'effet pr6vu de l'int6gration systEmatique des mEthodes de conception faible consommation qui permettront d'amEliorer d'un facteur 2 la consommation pour chaque gEn6ration [15]. Sans ce ph6nom~ne, les projections sont de 2000W pour les processeurs en 2010 ! La technologie des batteries n'Evolue pas aussi rapidement que celle des circuits VLSI (seulement quelques % d'amElioration par an). Cependant, l'Energie n'est pas le seul crit6re influant sur la durEe de vie de la batterie ; en effet, une utilisation intensive (en terme de courant moyen) peut diminuer la capacitE d'une batterie ion lithium de 22% par rapport h sa capacitE nominale alors qu'une utilisation raisonnEe peut la prolonger ~ 107% [16]. Les variations brusques d'activitE ne seront donc pas souhaitables. La temperature est fonction de la densit6 de puissance [17]. La puce peut tolErer une difference de temperature de 20 °C ; un bokier passif peut ainsi supporter au maximum 125150 W mais un boltier cEramique est 4 fois plus cher qu'un boitier plastique dont la limite est 2 watts [15]. Or, les puces en 0,6 gm ont d6jh dEpassE la temperature d'une assiette chaude soit 10 W/cm 2 [4] et l'augmentation de la temperature a des effets dEsastreux sur les circuits : une augmentation de IO°C divise la fiabilitE du circuit par deux et r6duit la durEe de vie du circuit car on augmente les dEfauts dans le silicium (phEnomSnes d'Electromigration, fatigue

5]35

ANN, T~LF~COMMUN.,59, n° 7-8, 2004

908

N. JULIEN - PANORAMA DES OUT1LS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

de lajonction .... ) [18]. En plus des pEnalitEs en poids et en volume, le refroidissement cofite 1 $ par puce par watt au-dessus de 40 W [19]. Enfin, les considerations sur l'environnement sont un sujet sensible depuis qu'une Etude parue dans le Financial Times a annonc6 qu'en 1998, 8% de l'Energie dissipde aux EtatsUnis 6tait due anx ordinateurs [14]. Afin de ma]triser le cofit des dEpenses d'Energie, plusieurs pays tels la Suisse, le Canada, ou l'Union europ6enne ont dEvelopp6 ou envisagent de dEvelopper un programme similaire au programme amEficain Energy Star de I'EPA. De plus, limiter la puissance dissipEe permet de limiter les radiations 61ectromagnEtiques et donc les perturbations des circuits environnants.

11.2. Qui consomme ? En premier lieu, on peut dEfinir les critEres utilisEs pour qualifier la consommation : en plus des param~tres de puissance (pour les phEnom~nes thermiques et de bruit) et d'Energie (pour les probl~mes de battefie), on utilisera comme mEtrique l'Energie par operation (ou l'inverse en Mips/W) pour comparer des processeurs et le cfit~re d'Energie-dElai quand des compromis entre vitesse et consommation seront nEcessaires [18]. Cependant, d'autres crit~res pourront ~tre pfis en compte selon la spEcificitE du probl~me 5 traiter. ConsidErons ici la consommation des circuits numEriques CMOS, h l'exception de certaines technologies de mEmoires. Elle comporte une composante statique Pstat et une composante dynamique Pdyn" La puissance statique exprimEe en (1) est la puissance due aux pertes (leakage) provenant de courants de fuite. Cette contribution a longtemps EtE considErEe comme nEgligeable, en dehors des mEmoires et des circuits avec peu d'activitE [20]. Or, les courants de fuite (leakage) sont de plus en plus importants dans les technologies submicroniques car ils augmentent lorsque la tension de seuil des transistors diminue : ils reprEsentent un tiers de la puissance globale pour une technologie de 0,09 [am et environ la moitiE pour une technologie de 0,06 [am. Parmi les diffErents phEnom~nes physiques comme la fuite de la jonction en inverse, c'est pfincipalement le courant sous seuil Isub lie ?~ l'imperfection du transistor comme interrupteur qui prEdomine, m~me si d'autres phEnombnes font leur apparition dans les technologies rEcentes : courrant tunnel (tunneling current), injection de porteuses chandes (hot carriers injection), forcement (punchthrough) .... Les Evolutions futures prEvoient que cette puissance statique sera mulfipliEe par 5 ~ chaque gEnEration [4]. Enfin, ce facteur est Evidemment important pour la consommation des circuits de faible activit6 comme les mEmoires. (1)

V~s - Vth Pstat = lsub X Vdd avec lsub o¢ loe S

La composante dynamique Pdy,, exprimEe en (2) comporte un terme reflEtant l'activitE de commutation Pcom et un terme dO au changement d'Etat correspondant ~ la puissance de court-circuit Pcc, lorsque les deux transistors NMOS et PMOS conduisent simultanEment ; ce dernier terme peut ~tre limitE 5 10% de la consommation globale par une technologie soignEe. C'est pourquoi, on trouve souvent exprimEe la consommation par la seule composante Pcom : elle depend de Vad la tension d'alimentation (de mani~re quadratique), de l'activitE du circuit ct, de la frEquence d'horloge F et de la capacitE Equivalente du circuit C L. ANN. TI~LI~COMMUN.,59, n ° 7-8, 2004

6/35

909

N. JULIEN -- PANORAMADES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

Pdyn = Pcc + Pcom #

(2)

TABLEAUIlL

-

Pcom= Or,X F×

CLX

V2dd

R6partition de la puissance pour des ordinateurs portables

Power consumption distribution in portable computers. Crit6re

CPU

Ecran

Disque dur

Vid6o

Alim

Hitachi

Pcrete

37%

20%

10%

3%

30%

Autre

Intel

Pcr~te

37%

10%

9%

12% (+m6moire)

10%

13%

Pmoyen

13%

30%

19%

15% (+m6moire)

10%

13%

Examinons maintenant la r6partition de cette consommation dans un systSme. Bien que peu de r6sultats soient disponibles, le Tableau III pr6sente diff6rentes mesures de la r6partition de la consommation sur ordinateur portable. Le premier exemple concerne un Hitachi VisionBook Pro (utilisant Word) et les r6sultats sont fournis par Gartner Group [16]. Le deuxiSme exemple, fourni par Intel, concerne un ordinateur portable avec un microprocesseur de fr6quence 600 MHz [9]. On voit qu'en terme de puissance maximum, c'est le processeur qui domine la consommation dans ces deux applications ; par contre, en puissance moyenne, c'est 6videmment l'6cran qui a la contribution la plus importante. Cependant, comme les diff6rentes contributions 6voluent fortement en fonction des applications, il conviendra d'&re vigilant dans la mise en oeuvre de m6thodes d'optimisation afin d'agir 1~ oh les r6ductions seront les plus efficaces [5].

Flexibilit~, Facilit~de m i s e ~ e

~

Performance,Co~t,Time-to-market[ Programmable

D6di6 Iv

pp I mmVMOp 50roW/MOp

DSP

ASIP

ASIC

0,1 mmVMOp

0,02mmVMOp

0,001 mm2/MOp

3mW/MOp

0,5mW/MOp

0,02mW/MOp

FIG. 1 - Caract6ristiques compar6es des circuits en technologie 0,5 pm.

Circuit characteristic comparison for 0.5 pm technology.

7/35

ANN. TI~L~'COMMUN.,59, n ° 7-8, 2004

910

N. JULIEN-- PANORAMADES OUTILSD'ANALYSEET D'OPTFMATIONDE LA CONSOMMATION

La figure 1 reprEsente l'Evolution des performances comparEes des microprocesseurs gEnEraux (~tp), des processeurs de traitement du signal (DSP), des circuits programmables spEcifiques h une application (ASIP) et des circuits intEgrEs spEcifiques ?~une application (ASIC) pour une technologie 0,5 pm. Plus un circuit est spEcialisE, moins il consomme, mais moins il est flexible. Les DSP sont donc prEfErables aux processeurs gEnEraux car leur efficacite en Mips/W est plus grande pour un coot moindre [21] ; ils reprEsentent un compromis intEressant entre la flexibilitE, les performances et la consommation pour les applications embarquEes. Cependant, on sait que ces performances ne sont pas encore suffisantes pour les besoins futurs [14] ; il faudra alors plutEt s'orienter vers des syst~mes multiprocesseurs. I1 peut Etre intEressant d'examiner plus prEcisEment la rEpartition de la consommation dans un processeur de traitement du signal (DSP) complexe pour des applications TDSI. La figure 2 propose deux profils moyens de rEpartition de la puissance obtenus pour le processeur Texas Instruments c6201, lorsque les donnEes sont respectivement en mEmoire interne et externe, avec un programme en mEmoire interne. On constate que la consommation due l'utilisation de la mEmoire externe est une part importante dans le deuxi~me cas. De faqon gEnErale, la consommation due ?~l'arbre d'horloge pour ce processeur correspond ~t 20 jusqu'~ 60% de la consommation globale. De plus, et contrairement h des processeurs ayant une architecture plus simple, l'effet de la correlation des donnEes n'a qu'un impact limitE 2% de la consommation globale. De m~me, pour ce processeur, la consommation liEe h une addition est identique ~ celle engendrEe par une multiplication. Cela est principalement dO la predominance de la consommation de l'Etage de prEchargement (Fetch) et l'importance du pipeline [22].

Donnees en m~moire interne UT+Data 3 0 %

~

~~hLHorloge

4o%

Donnees en m6moireexterne MemExt 28°,°

5% 30%

~ Fetch+Pro g 7%

Horloge 60%

FIG. 2 - REpartifionde la puissance pour le processeur TIC6201 Power consumption distribution for the TI C6201.

IlL COMMENT MAITRISER LA CONSOMMATION ?

Le probl~me de la consommation est complexe car de nombreux parambtres sont interdEpendants. Si on reprend l'expression de la puissance de commutation fournie en (2), Pcom = Ot X F X CLX V~d , on en dEduit que Faction la plus efficace pour rEduire ce terme est de ANN. TI~L1ECOMMUN.,59, n° 7-8, 2004

8•35

N. JULIEN - PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

diminuer la tension d'alimentation tionnel

x vad

911

Vdd. Or le temps de propagation du circuit est propor-

h (Vdd_ VT)20b VTest la tension de seuil des transistors. I1 est donc n6cessaire de

trouver un compromis entre la vitesse et la consommation comme l'illustre la figure 3 ; c'est l'op6rafion d'adaptation de la tension (voltage scaling), guid6e par le crit~re Energie-D61ai [23]. On peut 6videmment 6galement diminuer Vr mais l'effet est d'augmenter le courant de fuite et la puissance statique augmente ; de plus, avec de faibles tensions de seuil, la marge de bruit devient faible. On peut chercher ~t diminuer le chemin critique de la fonction logique pour que le d61ai ne soit pas p6nalisant mais il faudra pour cela augmenter la taille et la complexit6 du circuit (par pipeline ou parall61isme), ce qui va aussi entra~ner une surconsomma-

~,

E~

\

5.

0

~S

E nerg'y-Dela'~

~/T

...J~ J

/ 1

1.5 "/DD (V)

2

~.~

FIG. 3 - Illustration du voltage scaling.

Voltagescaling illustration.

tion. Un autre param6tre sur lequel agir est la capacit6 6quivalente CE Elle a deux composantes, une due aux circuits et l'autre due aux interconnexions. Diminuer le nombre et la taiUe des interconnexions sera donc positif, et ce d'autant plus que la proportion de ce terme s'amplifie avec les technologies sub-microniques. On peut 6galement r6duire la taille des transistors (transistor sizing mais alors le d61ai augmente [18]), ou celle des portes (gate sizing) [24], des bus [25] ou des m6moires [26]. Le demier terme sur lequel on puisse agir pour des applications temps r6el (oh la vitesse est une contrainte) est l'activit6 ~. Une des priorit6s sera de contr61er les glitchs : ce sont des commutations parasites, non pr6dites dans la description fonctionnelle, dont la contribution peut atteindre 40% de l'activit6 globale d'un circuit [27]. Une action efficace est d'6quilibrer les chemins de donn6es. Les mises en veille permettent 6galement de r6duire l'activit6 inutile. Pour presenter les diff6rentes actions d'optimisation de la consommation, il est classique de se r6f6rer aux niveaux de conception d'un circuit VLSItels que repr6sent6s sur la figure 4 [23]. Les bas niveaux, technologique et circuit, permettent une estimation pr6cise mais 9/35

ANN. TI~LI~COMMUN.,59, n° 7-8, 2004

912

N. JULIEN -- PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

longue et complexe ; il existe beaucoup de techniques d'optimisation ~tces niveaux mais leur impact reste limit6. Les estimations ~ haut niveau, algorithme et syst~me, bien que moins pr6cises, permettent un retour rapide d'information au concepteur pour qualifier les diff6rentes solutions par l'exploration de l'espace ATP(Area-Time-Power) ; les possibilit6s d'optimisations sont alors importantes [28].

T = temps T=s. mn

10-20x i,

d'estimation

II

i

i

ARC'rlITECTt~E I

T=h,j

i i

i i

CIRCUIT/LOGIOUE TECHNOLOGIE

II Impa t optimisation

[ [

20-50%

FIG. 4 - N i v e a u x d e c o n c e p t i o n d ' u n c i r c u i t vlsi

VLS! design levels.

III.1. Niveau technologique On a d6j~ parl6 du transistor sizing [18]. Des outils ont 6t6 d6velopp6s afin de d6terminer les compromis d61ai-consommation [29]. On peut 6galement agir sur VT avec par exemple des seuils faibles quand le circuit est actif pour &re plus rapide, et des seuils 61ev6s sinon pour ma~triser tes pertes [30]. La technologie sol semble prometteuse car il n'y a pas de courant de fuite de jonction et les capacit6s parasites sont 2 h 3 fois plus faibles que pour la technologie 'bulk', mais la difficult6 de conception persiste puisque les biblioth~ques ne sont pas disponibles [31]. On a vu qu'il est important de contr61er Vdd ; afin de limiter le nombre de tensions diff6rentes car cela aussi a un cofit, la plupart des circuits proposent une alimentation de ceeur de circuit faible et une alimentation des E/S plus 61ev6e pour augmenter la vitesse. Une des plus importantes pr6occupations h ce niveau sera de maitriser le courant de fuite dfi aux faibles valeurs de V~ et Vda [4, 8].

ANN. TI~LI~COMMUN.,59, n ° 7-8, 2004

10/35

913

N. JULIEN - PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

III.2. Niveau circuit/logique On trouve le dimensionnement des portes (gate sizing) [24], et de nombreux types de logique : logique adiabatique [32], logique h pr6chargement, logique Domino (chalne d '&ages pr6chargds), pass-transistor [33], CPL (Complementary Pass-Transistor), logique ~t faible excursion .... Les actions sur les horloges sont particuli~rement efficaces puisque l'arbre d'horloge repr6sente typiquement 30% de la puissance cr&e d'un processeur. La technique la plus r6pandue est le clock gating qui consiste h 6teindre les branches inacfives de l'arbre d'horloge [18]. On peut 6galement utiliser les deux fronts de l'horloge pour la synchronisation (half frequency) ou encore limiter l'excursion d'horloge h Vad/2 (halfswing clock) [34]. Bien que tr6s prometteuse pour les SoC [13], le manque d'outils de conception et de test fait que la logique asynchrone reste encore complexe 7t mettre en oeuvre et limite son usage ; pour l'instant, on utilise plut6t des syst~mes globalement asynchrones et localement synchrones [4]. On trouve 6galement diverses optimisations logiques : precomputation [35], common case computation [36], extractions logiques [37] ....

III.3. Niveau architectural On peut tout d'abord agir sur le format de codage des donn6es. En effet, les circuits sont dimensionn6s pour le pire cas (en d61ai et nombre de bits). Dans les cas d'applications temps r6el 'mou' (non-strict), on peut envisager d'ajuster le format des donn6es pour r6pondre ?aun crit~re de qualit6 ce qui a pour effet direct de diminuer ~tla fois la surface et la consommation [38]. Les autres options possibles sont essenfiellement le pipeline et le parall61isme dont les effets sont illustr6s par le Tableau IV, pour une fonction logique simple sup(A+B, C) ; elles permettent en effet, en diminuant le chemin critique de la fonction, de diminuer Vdd sans ~tre p6nalis6 par le d~lai induit [39]. Mais un compromis raisonnable doit &re trouv6 avec l'augmentation en surface. Enfin, ~t ce niveau, on peut appliquer des techniques de codage de bus [40].

TABLEAU IV. - Impact du pipeline et du parall61isme [18].

Parallelism and pipeline architecture impact [18]. Datapath Simple

Surface

Puissance

5

1

1

Pipeline

2,9

1,3

0,37

Parall~le

2,9

3,4

0,34

2

3,7

0,18

Pipeline/parall~le

11/35

Vdd (V)

ANN. "I'EI.ECOMMUN.,59, n ° 7-8, 2004

914

N. JULIEN - PANORAMA DES OUT1LS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

III.4. Niveau aigorithmique On peut dans un premier temps chercher h diminuer l'activitE de l'algorithme, en diminuant sa taille ou son nombre d'opErations (par Elimination des sous-expressions communes, par Elimination du code mort, par propagation des constantes, en remplacant une operation par une plus simple...) [41]. Lh encore, si on peut augmenter la vitesse de traitement, on pourra diminuer Vaa~ et donc rEduire la consommation. On trouve ainsi le pipeline fonctionnel, la mise en ligne des fonctions, les transformations algEbriques, les transformations de boucles .... [42]. Le compilateur peut Eventuellement remplacer une instruction coOteuse par une instruction Equivalente nEcessitant moins de puissance [43]. Enfin, des algorithmes rEguliers (avec une forte localitE spatiale) permettent de diminuer le coot d'implantation en gEnErant moins de contr61e et d'interconnexions [18].

III.5. Niveau syst~me ce niveau, ce qui pr6domine, c'est le contr61e de l'activit6 g6r6 par l'os. Or, il n'est pas toujours n6cessaire que le processeur fonctionne le plus vite possible ; on peut donc d6cider de rEgler la frEquence F et Vdd en fonction de l'activitE. Par exemple, le microprocesseur Intel Strong ARM Xscale consomme 450 mW ?t 600 MHz et 40 mW h 150 MHz [44]. L'os peut ainsi appliquer le voltage scaling pour diminuer la consommation quand le processeur est inactif. De plus, la plupart des circuits rEcents disposent de diffErents modes de veille correspondant h diffErentes fonctionnalitEs disponibles ou non (pEriphEriques, mEmoire...). Quand le circuit est sous-utilisE, on le maintient dans une fonctionnalitE de 'bas niveau' et on peut Eventuellement Eteindre certaines parties (par gated clock). Combinant ces deux techniques, on trouve le Power Management : c'est l'optimisation algorithmique de la consommation par rEglage de F et Vdd et mise en veille. Pour un circuit donnE, on connait les diffErents Etats de veille ou d'activitE, leur puissance associEe et les temps de rEveil ou de passage entre ces Etats ; un exemple en est donne en figure 5 pour le StrongArm SA1100 [9]. En fonction de l'Evolution de l'application, le syst~me decide de la mise en veille ou pas (energy aware os) [45]. II faut Evidemment minimiser l'impact de l ' o s lui-m~me sur les caractCristiques du circuit. ACPI (Advanced Communication and Power Interface) est une specification industrielle ouverte (commune h Intel, Microsoft et Toshiba) qui dEfinit, depuis 1997, une interface matErielle multi-plateforme pour standardiser l'intEgration du Power Management dans diffErents syst6mes h base de PC (notebook, desktop et serveur) ; il est intEgr6 notamment dans le PowerPc750 [46]. On voit qu'il existe une vaste palette de techniques d'optimisation de la consommation ; h l'heure actuelle, la criticit6 de ce probl~me fait qu'~t chaque niveau de conception, il est imp6ratif de mettre en oeuvre les techniques ad6quates.

ANN.T~L~COMMUN.,59, n° 7-8, 2004

12/35

N. JUL1EN -- PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

915

400 m W

160 m s ~

50 mW

I

90 ~s

o

160 ~ W

Fr~. 5 -l~tats de puissance pour le StrongArm SA1100.

Power states for the StrongArm SAl lO0.

IV. C O N C E P T I O N M A T I ~ R I E L L E

La plupart des travaux dans ce domaine se sont focalisEs sur l'optimisation en vitesse et en surface. Comme nous sommes actuellement arrives hun seuil critique de consommation des circuits, il faut impErativement intEgrer cette contrainte dans le riot de conception. Cependant, nous l'avons vu, il y a toujours nEcessit6 de rEaliser un compromis entre la contrainte de temps, qui indique la vitesse de l'application, la surface et la consommation (exploration de l'espace ATPpour Area-Time-Power). I1 est clair que simplement diminuer la tension d'alimentation, bien qu'Etant une technique efficace, n'est pas une rEponse suf-fisante. Nous allons voir dans ce paragraphe quels sont les diffErents outils pour l'optimisation de la consommation lors de la conception matErielle. Cependant, afin de valider les diffErentes techniques d'optimisation, il est nEcessaire de se rEfErencer ~t des outils precis d'estimation correspondant aux diffErents niveaux de conception du circuit. Les outils commerciaux se sont principalement intEressEs aux niveaux logiques et technologiques, qui sont en fait largement explores. De l'autre c6tE, les niveaux syst~me et algorithmique sont trSs peu reprEsentEs dans la littErature.

IV.1. N i v e a u t e c h n o l o g i q u e

Les outils de CAO qui int~grent l'estimation de puissance au niveau transistor sont nombreux : Voltage Storm de Simplex [47], PowerMill et RailMill de Synopsys [48], Star Power de Avant! [49], Lsim Power Analyst de Mentor Graphics [50], Dolphin de Monterey Design Systems [51]... A c e niveau, les sources de consommation sont clairement identifiEes donc l'estimation est tr~s precise mais nEcessite un temps de calcul tr~s consequent pour 6valuer des systbmes importants [52]. Si Spice demeure la rEfErence h bas niveau, la tendance est de 13/35

ANN. TI~LI~COMMUN.,59, n° 7-8, 2004

916

N. JULIEN-- PANORAMADESOUTILSD'ANALYSEET D'OPTIMATIONDE LACONSOMMATION

dEvelopper des estimateurs aussi precis mais plus rapides [53, 54]. Pour l'optimisation, les principales actions sont la diminution de la tension de seuil Vr (pour permettre de diminuer la tension d'alimentation) et le dimensionnement des transistors comme dans AMPS de Synopsys [48].

IV.2. Niveau logique Pour mener une estimation 5 ce niveau, on doit Evaluer les transitions des portes pour chaque fonction logique. I1 y a classiquement deux approches possibles pour dEvelopper la biblioth~que de modEles de consommation des composants : l'analyse des probabilitEs de transition ou la mesure statistique des transitions observEes sur un jeu de test. La precision de l'estimation repose respectivement sur le choix du module de probabilitd ou le choix des vecteurs de test [55-58]. I1 est donc possible d'Elaborer sa propre biblioth~que via un outil du commerce (Power Arc de Synopsys a un mode probabiliste [48]) ou d'utiliser des librairies industrielles (CooLib de Xemics propose des circuits Standard Cells tr~s faible consommation) [59]. Le choix de l'outil ~ ce niveau est trEs large puisque chaque outil de synth~se logique inclut maintenant l'analyse de puissance : QuickPower de Mentor Graphics [50], WattWatcher/PowerTheater de Sequence [60], DesignPower et Power Gate de Synopsys [48], POEt de Viewlogic... Power Compiler de Synopsys est actuellement le seul outil de synth~se logique qui optimise automatiquement la consommation ; il utilise l'exploration ATP, le dimensionnement des cellules et des buffers et des transformations logiques [48]. On trouve 6galement des outils combines avec un simulateur Verilog tels que PowerSim de System Science et Power-tool de Veritool ainsi que quelques outils universitaires tels que PowerCalc et Gate Power [61, 62].

IV.3. Niveau architectural ce niveau, un outil de CAO doit assurer un compromis raisonnable entre le temps cPu et la precision afin de pouvoir informer rapidement l'utilisateur des caractEristiques de consommation [18, 42]. Or, il est connu que la statistique des signaux influence la dissipation des opErateurs arithmEtiques. Quand la correlation entre variables augmente, la puissance induite diminue. La cEl~bre technique dEveloppEe h Berkeley, Dual Bit Type (Dnr), intEgrEe dans l'outil universitaire I-Iyper_LP, modElise cette activitd des entrees [63]. Mais la determination precise des caractdristiques des signaux est fortement dEpendante de l'application. PowerCheck utilise une version amEliorEe de la modElisation DBT [64]. Afin de donner une estimation rapide pour l'ensemble des applications TDS~, GAUT LP introduit un modEle d'opErateur simplifid qui peut ~tre utilisd lorsque les statistiques des signaux ne sont pas connues : pour le premier module, les deux entrees de l'opErateur changent entre deux operations consEcutives et sont moddlisEes par du bruit blanc ; d a n s le deuxiEme cas, seulement une des entrees de l'opErateur change entre deux op6rations consEcutives, l'autre 6tant stable. La biblioth~que de ressources obtenue ANN. TI~LI~COMMUN,,59, n° 7-8, 2004

[4/35

N. JULIEN -- PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

917

montre entre les deux modules une difference de 25% pour les additionneurs et de 50% pour les multiplieurs [381. Plusieurs outils commerciaux d'analyse utilisent des modElisations par macro-modUles logiques comme notamment dans Watt Watcher~Power Theater, Peak Watcher de Sequence [60], Design Power de Synopsys [48] et Orinoco d'Offis [65]. Mais les outils d'optimisation sont peu nombreux et utilisent principalement la technique de 'gated clock' comme dans Apollo H d'Avant! [49] et Power Compiler de Synopsys [48]. Enfin, on trouve quelques outils de recherche bases sur diffErentes techniques architecturales telles que l'exploration de l'espace ATP,le parallElisme et le pipeline comme Hyper_LP et Gaut_LP [64, 24, 66].

IV.4. Niveau algorithmique L'optimisation au niveau comportemental a un impact tr~s fort sur la consommation finale du circuit. Cependant, l'estimation precise est delicate ; en fait, l'objectif de l'estimation ~ ce niveau est plut6t de fournir des ordres de grandeur fiables, permettant de comparer les performances de plusieurs algorithmes pour une m~me fonction, par exemple du filtrage [67] et le retour d'information au concepteur doit ~tre rapide [68]. Pour l'analyse, on trouve principalement deux approches : d'une part, l'utilisation de m&riques caractErisant l'algorithme seul [69] (parfois difficiles 5 determiner) comme la localitE spatiale [18] ou le nombre d'opErations [70] ou, d'autre part, la prise en compte d'un modrle architectural pour l'estimation [71, 72]. Les principales techniques d'optimisation consistent ~ minimiser le chemin critique avec le retiming ou les transformations algEbriques [73, 74], rEduire le nombre d'opErations ou substituer des opErateurs [75], ou bien diminuer le nombre d'accrs mEmoire, par exemple par transformation de boucle [76]. I1 y a depuis peu un outil commercial, Orinoco d'Oftis et plusieurs travaux sont bases sur des outils universitaires comme ceux dEveloppfs ~ Berkeley Hyper_Le, Explore et PowerPlay, ainsi que Gaut_Lp [77, 66].

IV.5. Niveau syst~me I1 y a tr6s peu de travaux ~t ce niveau. Nous pouvons mentionner [78] dont l'approche minimise la dissipation d'un systrme complet (un cceur de microprocesseur, un ASIC, un cache et de la mEmoire) grfice ~ du partitionnement hardware/software. Des reductions significatives de la consommation sont obtenues avec un faible surcofit materiel. On peut 6galement citer les travaux sur le <~ [79] mais il n'y a pas ?al'heure actuelle d'outil disponible h ce niveau. Bien que la minimisation de la consommation soit plus efficace aux niveaux architectural et comportemental, il y a actuellement un manque d'outils de haut niveau ~ la fois pour Foptimisation et l'estimation. Le Tableau V, ota les outils universitaires sont signalEs en italique, prEsente une synthrse des outils d'estimation et d'optimisation existants pour les diffErents niveaux.

15/35

ANN.TELI~COMMUN.59, , n° 7-8, 2004

918

N. JULIEN -- PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION T A B L E A U V. - O u t i l s d ' e s t i m a t i o n

et

d'optimisation

p o u r c i r c u i t s VLSI.

VLSlcircuit estimation and optimisation tools.

Niveau Nom de l'outil Technologique SPICE Dolphin Lsim Power Analyst Voltage Storm PowerMill/RailMill AMPS Star Power POPS

Logique

Architecture

Algorithme

Power Compiler Design Power WattWatcher Gate POET PowerSim Power-tool PowerCalc Gate Power Apollo II Design Power Power Compiler WattWatcher Architect Top-Down Design Planner Orinoco

Constructeur Berkeley Monterey Mentor Graphics Simplex Synopsys Synopsys Avant! LIRMM

Synopsys Synopsys Sequence ViewLogic Systems Science Veritools Zurich ENST Paris Avantl Synopsys Synopsys Sequence HLDS Cadence Offis

Optimisations transistor sizing Transistor~gate sizing diverses clock gating clock gating diverses exploration ATP

Gaut_LP

LESTER

diverses

PowerCheck Hyper_Le Orinoco Hyper_Lp/PowerPlay

LASTI

diverses exploration ATP

Gaut._LP

LESTER

Berkeley Offis Berkeley

exploration ATP exploration ATP

V. C O N C E P T I O N L O G I C I E L L E

A l'heure actuelle, le logiciel repr6sente au moins 70% du cofit du d6veloppement des syst~mes complexes. Comme la taille du code des applications TDSIdouble tous les deux ans, on conqoit qu'il soit indispensable de disposer, au plus t6t dans la conception, de m6triques fiables caract6risant les algorithmes [80]. De plus, il est n6cessaire de s'int6resser sp6cifiquement h l'estimation de puissance car, en fait, deux codes de m~me fonctionnalit6, peuvent avoir les m~mes performances (en temps d'ex6cution) mais des consommations diff6rentes ANN. TELI~.COMMUN.59, , n ° 7-8, 2 0 0 4

16/35

N. JULIEN - PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

919

[81]. Si la contrainte de l'application porte plus particuli~rement sur l'6nergie, il est efficace d'am61iorer la performance en temps d'ex6cution, par exemple en augmentant le paraU61isme mais alors la puissance dissip6e augmente ; si la contrainte porte plut6t sur cette derni6re caract6ristique, alors l'am61ioration des performances devra tenir compte de cette limitation. I1 y a deux composantes dans la consommation dynamique d'un logiciel : la partie inh6rente ~ l'algorithme et la surconsommation d'implantation (overhead) [18]. La premi6re partie se caract6rise par le nombre d'op6rations et le nombre d'acc~s m6moire dans l'algorithme. La deuxi~me composante tient compte de l'architecture sur laquelle le logiciel doit ~tre implant6. Elle est li6e ~ un certain nombre de propri6t6s de l'algorithme telles que la localit6, la r6gularit6, la concurrence.., qui conditionne le contr61e, les interconnections et les registres mais 6galement les possibilit6s de parall61isme [82]. Bien que d'une importance 6quivalente voire sup6rieure h la premiere composante, cette derni6re contribution est souvent n6glig6e par les concepteurs d'algorithmes. Mais, pour des estimations r6alistes, elle doit imp6rativement &re prise en compte.

V.1. M~thodes d'estimation existantes La figure 6 classe les diff6rentes m6thodes existantes par rapport aux niveaux d'abstraction des modules du processeur et du logiciel ; en particulier, le nom de la m6thode est donn6 en r6f6rence au type de module de logiciel. Les m6thodes d'estimation de la consommation de niveau cycle demandent un temps de calcul important, et d'autre part, reposent sur un module tr~s d6taill6 de description de l'architecture, soit au niveau transistor (AccuPower), soit au niveau micro-architecture (Wattchet SimplePower). Si ce module est indisponible, par exemple pour des processeurs du commerce, on utilise une m6thode au niveau instruction qui consiste h mesurer le courant pour chaque instruction et chaque couple d'instructions successives. Bien que certaines 6tudes r6centes aient compl6t6 (et complexifi6) le module fonctionnel initial du processeur, une telle approche limite l'estimation de consommation au niveau assembleur. L'approche param6trique (outil SoftExplorer) est bas6e sur un module architectural 'gros grain' du processeur. I1 s'agit actuellement de la seule m6thode permettant l'estimation d'un langage source C mais elle ne permet pas de r6aliser des optimisations 'grain fin', par exemple en remplaqant une instruction consommatrice par une autre fonctionnellement 6quivalente mais plus efficace en terme de consommation. De fa~on marginale, on trouve une approche simpliste au niveau syst~me (outil JouleTrack)qui ne mod61ise pas le programme et dont le mod61e de processeur est compos6 uniquement de param~tres de configuration. Cependant, toutes ces approches ont une lacune en commun : la mod61isation du contr61e n'est pas r6alis6e. V.I.1. M ~ t h o d e s

de niveau cycle

Dans cette cat6gorie sont regroup6es plusieurs mEthodes qui ont en commun de n6cessiter une connaissance fine de l'architecture du processeur. BasEes sur SimpleScalar, elles permettent de faire de l'estimation cycle par cycle. SimpleScaIarutilise un module g6n6rique de processeur param6tr6 pour s'approcher au plus pr6s de la cible souhait6e. Le code binaire, appliqu6 h ce processeur gEnErique, permet de d6finir les taux d'activit6. Pour toutes ces 17/35

ANN. TI~L]~COMMUN.,59, n ° 7-8, 2004

920

N. JULIEN - PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

APPLICATION

I

Q

Niveau logiciel

Modkle logiciel

]

Syst&ne

SpEcification

._Para.m~t.ri~.t_{e._.t Langage ""-..,,

source (C)

l_.n.struct.ion.....

._.[ Langage machine (assembleur)

O

Cycle

Langage binaire

e-.

PROCESSEUR

Modble du processeur

]

FIG.6 - Classificationdes mEthodesd'estimationlogicielle

Softwareestimationtechniqueclassification.

approches, les simulations sont longues et complexes avec des temps de calcul consEquents (quelques heures h quelques jours) et les exemples d'application sont souvent pour des architectures simples (voire simplifiEes). De plus, la precision de SimpleScalar est tr~s controversee, notamment pour l'estimation du chemin des donn6es (datapath) dont l'erreur dEpasse souvent 10%. Par contre, on obtient finalement un profiling h grain fin du code qui permet d'intervenir sur le compilateur pour effectuer des optimisations. SimplePower utilise l'Iss (Instruction Set Simulator), complEtE par des param~tres technologiques et architecturaux, pour determiner avec precision chaque transition et son coot EnergEtique [83] ; eAC (Energy Aware Compiler) est sa version accE1ErEe mais les problEmes de precision demeurent [84]. Wattch modElise des blocs fonctionnels comme des modules interconnectEs et utilise SimpleScalar pour la determination des capacitEs de commutation Equivalentes [85]. On retrouve une approche similaire dans Powerlmpact [86]. Enfin, AccuPower utilise des donnEes complEmentaires de niveau transistor issues de SINCE,ce qui amEliore la precision mais augmente encore le temps de calcul nEcessaire ~ l'estimation [87].

ANN.TI~LI~COMMUN.59, , n° 7-8, 2004

18/35

N. JULIEN -- PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

921

V.1.2. M~thodes de niveau instruction

Introduite par Vivek Tiwari ~ l'Universit6 de Princeton en 1994, l'analyse de la consommation au niveau instruction 0LPA Instruction Level Power Analysis) 6tait la premi6re m6thode ne n6cessitant pas de connaissances internes de la cible et demeure h l'heure actuelle la r6f6rence pour ce type d'applications [88]. Elle repose sur un ensemble de mesures du courant pour chaque instruction Instr i individuellement ~ l'aide de programmes en boucles. Mais il faut 6galement tenir compte de la surconsommation inter-instructions (overhead) lorsque l'on passe d'une instruction Instr i ~ une instruction diff6rente Instri+ 1. Outre une pr6cision de l'ordre de 3%, un avantage important est d'obtenir une trace en 6nergie du programme qui permet d'int6grer dans le compilateur des optimisations de consommation par substitution d'instructions cofiteuses par des instructions moins cofiteuses. Par contre, cette m6thode comporte deux d6fauts majeurs. Tout d'abord, le nombre de mesures n6cessaires pour 6tablir le mod61e du processeur devient rapidement prohibitif d~s que l'on consid6re des architectures un peu plus complexes puisqu'il faut mesurer non seulement toutes les instructions du jeu d'instructions mais 6galement toutes les combinaisons possibles d'instructions successives (1176 mesures sont n6cessaires pour un DSP 56K [89] et au minimum 718 pour le C6x). I1 est possible d'6tablir des groupes d'instructions caract6ris6es globalement par leur courant moyen [43] - mais l'61aboration des groupes reste complexe- ou de ne d6finir qu'un seul overhead par instruction par rapport au NOP [89], ce qui affecte la pr6cision. Cette limite rend donc I'ILPA inapplicable aux processeurs DSP. De plus, le module instruction du processeur est largement incomplet puisqu'il ne tient pas compte du parall61isme, des probl6mes de m6moire tels que les d6fauts de cache, du pipeline, et de l'adressage des donn6es. Certaines 6tudes compl&ent donc I'mPA soit par une approche fonctionneUe au niveau instruction [90, 91, 92] (mais peu de travaux concernent les processeurs v u w [93]), soit par des mod61es de m6moire [94]. Ces approches aboutissent h des pr6cisions int6ressantes (de l'ordre de 3%) mais au prix de mod61es complexes qui deviennent difficilement applicables dans des cas r6alistes. De plus, les ruptures de pipeline ne sont pas encore correctement moddlis6es (erreur de 13% sur une architecture VLIW simplifi6e [90]). V.1.3. M~thode param~trique

En fait, dans les applications actuelles et sur les processeurs de derni~re g6n6ration, le parall61isme, la m6moire (via les d6fauts de cache) et le pipeline (via ses ruptures) sont des ph6nom6nes dominants pour la consommation et doivent absolument ~tre int6gr6s dans l'estimation. La m&hode param6trique est bas6e sur une analyse fonctionnelle de l'architecture du processeur, ind6pendante du compilateur, et permet d'intdgrer t o u s l e s ph6nom6nes majeurs concernant la consommation. L'erreur maximale obtenue, par rapport aux mesures est de 4% pour le niveau assembleur et 8% a partir du code source C. Cette approche fonctionnelle convient bien h l'estimation pour des cibles complexes comme des DSP VLIW (TI C62, C67) mais 6galement pour des architectures plus simples (TI C55, ARM7). Par contre, la classe d'applications est limit6e aux applications de traitement du signal et de l'image. L'estimation directement au niveau c permet d'analyser le code pour plusieurs processeurs, et donc de choisir efficacement la meilleure cible pour l'application vis6e. De plus, le retour rapide d'information (quelques secondes) permet ~ l'utilisateur de quantifier rapidement les optimisations de code. Par contre, par rapport ~ des m6thodes de plus bas niveau, il n'y a pas

19/35

ANN.TI~LECOMMUN.,59, n° 7-8, 2004

922

N. JULIEN-- PANORAMADES OUTILSD'ANALYSEET D'OPTIMATIONDE LACONSOMMATION

de profiling au niveau instruction mais un profiling 'gros grain' pour chaque boucle ou fonction du code. L'outil SoftExplorer, utilisant cette approche, est disponible en ligne [22].

V.I.4. M~thode de niveau syst~me L'hypoth~se de d6part est que, dans les processeurs r6cents, les fluctuations dues aux seules instructions sont tr~s faibles et noy6es dans les surcofits communs (cache, chargement...) ; sur les StrongARM SA-1 100 et Hitachi sn-4 les mesures de variations de courant sur toutes les instructions montrent un 6cart de 38% qui, sur l'ensemble de diff6rents programmes, se r6percute par moins de 8% d'6cart. Une approche au niveau instruction serait donc inutile [95]. JouleTrack est un outil en ligne bas6 sur un module tr~s simple du processeur : routes les instructions sont consid6r6es comme ayant la m~me consommation moyenne, d6pendant uniquement de la fr6quence de fonctionnement et de la tension d'alimentation. Une telle approche radicale donne des r6sultats corrects pour les microprocesseurs avec une erreur maximum de 7%, mais est tr6s insuffisante pour les DSP puisque, dans ce cas, un module du 2 e ordre reprenant une approche ILPA a 6t6 d6velopp6 pour maintenir une pr6cision raisonnable.

V.2. Techniques d'optimisation Les diff6rentes techniques d'optimisation logicielle de la consommation sont souvent bas6es sur les techniques d'optimisation en performance. Par contre, il est souvent tr6s d61icat de pr6voir l'impact d'une optimisation de code sur les caract6ristiques finales du syst6me ; en effet, des d6gradations locales peuvent servir efficacement des optimisations post6rieures. L'ordre d'application de ces techniques d'optimisation est donc peu trivial d6terminer [96]. De plus, les effets de ces modifications de code sont difficilement pr6visibles et peuvent avoir un impact diff6rent sur la puissance et l'6nergie [80, 81]. On peut cependant d6gager quelques r6gles g6n6rales. I1 est int6ressant de privil6gier les algorithmes r6guliers afin de diminuer le coot d'impl6mentation. On peut diminuer l'activit6 de l'algorithme en diminuant la taille du code (par 61imination des sous-expressions communes et compression de code [97]), en diminuant le nombre d'op6rations et les acc6s m6moire ou en diminuant le cofit des op6rations (par transformations alg6briques, r6duction des transferts de type Load/Store, et la s61ection des instructions les moins consommatrices). On peut 6galement augmenter la vitesse de traitement de la tache afin de pouvoir alors diminuer la tension d'alimentation, par exemple grace au pipeline fonctionnel, h la mise en ligne des fonctions, aux transformations de boucles... Enfin, on peut am61iorer la gestion des donn6es (Data reuse, am61ioration de l'utilisation des registres), r6duire la commutation des lignes d'adresse, et exploiter la localit6 des donn6es (localit6s spatiales et temporelles) grace aux transformations de boucle afin de s'adapter ~ l'architecture du processeur : 6change/inversion de boucle, d6roulage de boucle, loop tiling, fusion ou fission de boucles, extraction des invariants de boucles ..... En illustration de ce probl~me, nous allons examiner quelques exemples des variations de consommation d'une application selon le choix du processeur cible, les options de compilation et le code. ANN.T~L~COMMUN.,59, n° 7-8, 2004

20/35

923

N. JUL1EN -- PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

V.2.1. Choix du processeur cible

Le Tableau VI pr6sente les r6sultats de mesures de consommation pour trois processeurs difffrents pour des applications repr&entatives du domaine TOSI : une transform6e en ondelettes (DWT) ~t trois niveaux de r6solution avec une image de taille 512"512, un vocoder Enhanced Full Rate pour GSM (E~), et un d6codeur MVEG. Trois cibles sont propos6es : le an TMS320C6201 (DSV VLrW ~t virgule fixe), le TMS320C6701 (DSP VLrW 7t virgule flottante) et le a'I TMS320VC5510, un processeur low-power ~ virgule fixe. Bien stir, la puissance e du c55 est moins importante puisqu'il s'agit d'un processeur sp6cifique pour la faible consommation. En particulier, il a une tension d'alimentation de co~ur de 1,7 v au lieu de 2,5 v pour le c62 et 1,8 v pour le c67. C o m m e le degr6 de parall6lisme et la fr6quence d'horloge sont similaires pour les c62 et le c67, le temps d'ex6cution Texe est donc identique pour ces deux processeurs. Cependant, les puissances consomm6es sont diff6rentes car ils n'utilisent ni la m~me technologie (0,25 pin pour le c62 et 0,18 pm pour le c67) ni la m~me tension d'alimentation. Du fait de l'important parall61isme des c62 et c67 (jusqu'~ 8 instructions en parall61e), le temps d'ex6cution pour ces processeurs est g6n6ralement meilleur que celui pour le c55 sauf pour l'application EFR pour laquelle ce parall61isme est inutile puisque le taux de rupture de pipeline est de 80%, ce qui implique une forte p6nalit6, ~ la fois en temps et en 6nergie ; c'est le c55 qui est alors le processeur le plus adapt6 ~ cette application. Enfin, pour le d6codeur MPEG, c'est le C67 qui est le plus efficace en 6nergie, grace h son important parall61isme (qui fournit un temps d'ex6cution 100 fois plus faible que pour le c55) combin6 ?tune puissance maltris6e (3,5 fois plus grande que le C55). On voit ici que, si le r6sultat en puissance est pr6visible, les conclusions en terme d'6nergie d6pendent fortement des contraintes de l'application. II est donc n6cessaire de disposer d'une estimation de haut niveau fiable qui permette au concepteur non seulement de choisir le processeur le plus adapt6 h son application et mais 6galement de r6gler sa fr6quence de fonctionnement en fonction de ses contraintes.

TABLEAU VI. - R6sultats de mesures sur diff6rents processeurs. Measurement resultsfor various processors. Application

Algo DWT

EFR

MPEG

21/35

Cible C62 C67 C55 C62 C67 C55 C62 C67 C55

Mesures

F (MHz) 200 200 160 200 200 160 200 200 160

P (W) 3.83 0.9 0.39 2.62 0.95

Texe (~s)

0.43

3140

5.59 1.45

40.37

0.4

4090

2320 2320

4615 4050 4050

40.37

E (pJ) 8880 2090 1780

10630 3850 1370 230 38 1640

AnN. TI~LI~COMMLrN.,59, n° 7-8, 2004

924

N. JULIEN - PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

V.2.2. Influence des options de compilation

Habituellement, deux possibilit6s sont offertes : l'optimisation en code ou l'optimisation en performance. Ensuite, parmi les diff6rents niveaux d'optimisation propos6s, l'utilisateur choisit en g6n6ral le niveau le plus 61eve pour l'une de ces deux options. Le Tableau VII pr6sente des mesures pour les trois applications pr6c6dentes cibl6es sur le c6201. La fr6quence d'horloge est de F = 200 MHz, le programme et les donn6es sont plac6s en m6moire interne sauf pour les donn6es de la DWT qui sont en m6moire externe. Nous fournissons les mesures de temps d'ex6cution Texe, de puissance P e t d'6nergie E obtenues pour trois cas de figures lors de la compilation. Tout d'abord sans option de compilation, le code reste purement s6quentiel. Pour l'optimisation en performance, le maximum de parall61isme est obtenu, en utilisant le d6roulage de boucle et le pipeline logiciel ; 6videmment la puissance du processeur augmente puisque ses ressources sont mieux utilis6es mais l'6nergie est beaucoup plus faible. Enfin l'optimisation en code oh aucun d6roulage de boucle n ' a lieu mais oil on trouve encore du parall61isme au sein des boucles ; la puissance est plus faible et l'6nergie plus importante que pour l'optimisation en performance.

TABLEAU VII. - Influence des options de compilation.

Compiling option impact. MESURES Vs OPTIONS DE COMPILATION PERFORMANCE SANS OPTION Texe(ms) P ( W ) E(mJ) Texe(ms) P(W) 577.8 2.55 DWT 992.4 2.26 2243 4.05 2.64 EFR 17.83 2.17 38.7 0.04 5.83 MPEG 0.58 2.71 1.57

E(mJ) 1473 10.7 0.23

Texe(mS) 679.9 7.77 0.178

CODE P(W) 2.26

2.44 3.02

E(mJ) 1537 19.0 0.54

V.2.3. Impact de l'optimisation de code

Afin d'illustrer l'importance des modifications algorithmiques sur les performances finales d'une application, nous pr6sentons ici un exemple sur la transform6e en ondelettes (Discrete Wavelet Transform, DWr) avec trois niveaux de r6solution sur une image de taille variable (de 64*64 jusqu'~ 512"512). Le code source C a 6t6 compil6 avec optimisation en performance pour le c6201 h F = 200 MHz, lorsque le programme est en m6moire interne et les donn6es en m6moire externe. La premi6re version de l'algorithme (Algol) effectue, de faqon classique, un r6arrangement de l'image ~t la fin de chaque traitement pour le niveau de r6solution consid6r6. Or, une partie tr6s importante du temps d'ex6cution de 1' application est alors occup6e par ce r6arrangement, jusqu'~ 85% dans le cas de l'image de taille 512"512. Nous avons doric 16g6rement modifi6 les pas des boucles de cet algorithme afin d'6viter cette phase de r6arrangement (Algo2). La cons6quence directe est doric de limiter le nombre d'acc~s en m~moire externe et donc d'agir fortement sur les performances. Cela se traduit par des r6ductions de la puissance jusqu'g 44% et de l'6nergie jusqu'h 94% pour l'image de taille ANN.TI~Lr~COMMUN.,59, n° 7-8, 2004

22/35

925

N. JULIEN - PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

TEMPS EXECUTION

PUISSANCE C O N S O M M E E

IJU

o Z

!-

0,,

64*64

128"128

256*256

512"512

64*64

128"128

TAILLEIMAGE

256*256

512"512

TAILLE IMAGE

ENERGIE CONSOMMEE

A

2520 i

--. 15 ~ O

a: u.I 10, z 5IJ.I 0-

• ALGO-1 [ ] ALGO-2 64*64

128"128 256*256 512"512 TAILLE IMAGE

FIG.7 - Impact de la modificationalgorithmiquepour la transform6een ondelettes. Algorithmic optimization impact for a DWZ.

512*512 repr6sent6es sur la figure 7. L'impact d'une telle modification prouve la nfcessit6 de disposer d'outils d'estimation de haut niveau rapides et fiables.

VI. L E S MI~MOIRES

Dans les applications au traitement du signal et de l'image (TDSI), la m6moire devient le point critique du syst~me ; elle limite les performances et sa consommation repr6sente 20 h 80% de la consommation globale [76]. Plusieurs travaux r6cents se pr6occupent de diminuer aussi bien la consommation statique [98] que dynamique [99] des m6moires. Mais pour se faire, il faut agir par des techniques d'optimisation qui concernent aussi bien le riot de conception logiciel que materiel.

23/35

ANN. TELI~COMMUN.,59, n° 7-8, 2004

926

N. JIJLIEN-- PANORAMADES OUTILSD'ANALYSEET D'OPTIMATIONDE LA CONSOMMATION

VI.1. Caract6risation

TABLEAU VIII. - Puissance normalis6e pour diff6rents types de m6moires.

Normalized power consumptionfor various memories. Types

Marque

Taille (Mbits)

FMAX (MHz)

P

Pnormalis6e

SRAM

Mitsubishi

2,25

350

1,2 W

1524

SDRAM

Intel

18

1060

10,3 W

540

IBM

1

470

1,9 W

505

NTT

1

200

35 mW

175 2333

Hitachi

0,88

1800

4,2 W

Fujitsu

0,288

700

280 mW

1389

Hynix

256

133

0,7 W

20,6

Micron

256

133

1W

29,4

Elpida

256

133

1W

29,7

Un premier probl6me est la caract6risation des m6moires afin de s61ectionner la plus performante lots de la conception syst6me ; en effet, les indications des constructeurs sont la plupart du temps insuffisantes. Les informations sur la puissance statique ne sont souvent pas foumies, alors que cette consommation peut ~tre importante pour les SRAM rapides en technologie submicronique, et il est extr~mement difficile d'obtenir des donn6es comparables pour diff6rents produits. Cependant, pour d6partager plusieurs types de m6moire diff6rents, on peut W qui 6ventuellement se r6f6rer ~ une puissance normalis6e Pnormalis6eexprim6e en MHzpXMbits

I

~ 4

Meawry

!

FIG. 8 - Comparaison du MTC de diff6rents types de m6moires (source Mosys).

MTCfactor comparisonfor various memories (source Mosys). ANN. TI~LI~A2OMMUN.,59, n° 7-8, 2004

24/35

N. JULIEN -- PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

927

donne un crit~re de consommation dynamique en fonction de la taille de mEmorisation et de la frEquence maximale de fonctionnement. Le Tableau VIII fournit les valeurs obtenues pour diffErents types de mEmoires courantes. Cependant, Mosys propose un crit~re plus gEnEral, le Memory Technology Coefficient MTC dEfini comme indiquE en (3) ; il caractErise la vitesse, la densitE et la consommation de la mEmoire [100]. Ce crit~re est applique pour comparer l'Evolution des principaux types de mEmoire en figure 8 ; il avantage la DRAM par rapport h la SRAM habituelle car, bien que moins rapide, elle est plus dense et elle consomme moins. Mosys propose cependant une classe de SRAMplus dense (1T-SRAM)qui surpasse alors la DRAM. Cependant, pour une comparaison plus pertinente, il faudrait Egalement tenir compte de la puissance statique.

MTC -

(3)

Fmax (MHz) X Densit~ (Mbits/mm 2) Pnormalis~e

Un autre probl~me pour la consommation des mEmoires est le coot des acc~s. Pour un processeur ARM, le coot d'un acc~s externe (off-chip) par rapport ~ un acc~s intEgrE (on-chip) est 3 fois plus important en puissance et 7 fois en Energie [19]. Des mesures sur le TIC6201 donnent des rEsultats similaires ; pour une application de transformEe en ondelettes, l'Energie totale nEcessaire ~tl'application lorsque les donnEes sont en mEmoire externe est 3,6 fois plus importante que lorsque les donnEes sont en mEmoire interne [22]. La caractErisation de la mEmoire reste donc un probl~me difficile et cependant incontournable ; ~ tousles niveaux de conception, elle conditionne les performances du circuit. Pour prendre des decisions ~ haut niveau, par exemple choisir la hiErarchie de la mEmoire ou son architecture, il faut se rEfErer ~ une librairie mEmoire, caractErisant les capacitEs en terme de stockage, la surface, les temps d'acc~s et les coots EnergEtiques en lecture et en Ecriture, aussi bien pour des mEmoires externes que pour des mEmoires internes. Or, ces param~tres sont tr~s dElicats ~ chiffrer de fa~on fiable avec les outils actuels.

VI.2. ModUles De faqon non exhaustive, la consommation d'une mEmoire depend : • de param~tres technologiques (type de la mEmoire, technologie de fabrication, tension d' alimentation...), • de param~tres architecturaux lies au format (taille, largeur de mot), h la structure (nombres de bancs, nombre de ports, nombre et organisation des niveaux de hiErarchie...), et au contr61e (cache ou mEmoire bloc-notes, associativitE...) • de parambtres algorithmiques indiquant son activitE (nombre d'acc~s, mode d'acc~s, taux de dEfaut de cache, commutations des adresses ou des donnEes...) et fortement lie au placement des donnEes [101]. Pour l'estimation de la consommation des mEmoires intEgrEes ~ la puce, on trouve deux classes de modEles : des modEles analytiques et des modEles empiriques. L'ensemble des modEles analytiques reprend le module d'Evaluation des capacitEs intemes dEvelopp6 darts Cacti, un outil d'estimation d'un cache ~ base de SRAMcaractErisE par sa taille, la taille des 25/35

ANN.T~LI~COMMUN.59, , n° 7-8, 2004

928

N. JULIEN -- PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

blocs et son associativitE [102]. I1 consid~re la mEmoire comme un ensemble de diffErents modules dont les caract&istiques sont dEfinies indEpendamment ; la consommation globale correspond a la somme des consommations des diffErents modules. Cependant, cet outil parait peu adapt6 anx problEmes rEcents : il ne traite pas l'estimation des DRAM(qui sont de plus en plus utilisEes en mEmoires sur la puce) et ses caractEristiques ont EtE dEfinies pour une technologie de 0,8 pm. On trouve en [ 101 ] l'estimation de la consommation d'un cache base sur les rEsultats de Cacti ; mais le modEle est complexe et l'erreur atteint 30% car il ne modElise pas correctement l'activit6 de la mEmoire. Dans [103] est propose un modEle simple et rapide qui a EtE amEliorE par [104] pour tenir compte des dEfauts de cache. Par contre, ces derni~res estimations ne tiennent pas compte de l'Ecriture en mEmoire, de la logique de dEcodage et, pour les caches associatifs, des comparateurs &Etiquettes et d'adresses. De plus, le taux d'activitE des donnEes est fixE arbitrairement ~ 0,25 pour toutes les applications. Les modules empiriques utilisent une approche 'boite noire' : de nombreuses simulations sont menEes en faisant varier les diffErents param~tres de la mEmoire afin de determiner des lois gEnErales d'Evolution de la consommation en fonction de ces param&res. [105] utilise des simulations de mEmoires SRAMasynchrones modElisEes avec SPICEet dont les caractEristiques (Energie et temps) sont obtenues par Star-Sim de Avant!. Les lois de consommation, obtenues par regression linEaire, fournissent une erreur infErieure h 8%. [106] applique cette mEthode ~t une approche non linEaire sur des mEmoires SRAMet ROM. Les rEsultats, plus prEcis qu'avec un module linEaire, fournissent cependant une erreur maximale de 23,5%. Pour l'estimation des mEmoires extemes, le seul outil disponible ~t l'heure actuelle est fourni par le constructeur Micron pour calculer la consommation de ses SDRAM [107]. Dans la plupart des cas, les informations foumies par les constructeurs sont plut6t succinctes, ce qui rend difficiles les comparaisons.

VI.3. Optimisations Les performances des systEmes sont fortement conditionnEes par celles de la mEmoire, liEes non seulement ~ son architecture (hiErarchie, cache, bancs...) mais Egalement aux donnEes qui y sont placEes et leurs transferts. La hiErarchie mEmoire, en permettant de placer les donnEes les plus souvent utilisEes dans des mEmoires plus petites, d'acc6s plus rapide, amEliore les performances du systbme, mais pas forcEment sa consommation. Cette hiErarchie peut ~tre basEe sur plusieurs niveaux, plusieurs types de mEmoires : SRAM, DRAM (externe ou intEgrEe), et plusieurs modes de contr61e : cache ou mEmoire bloc-notes [10]. VI.3.1. M~thodes mat~rielles

Dans l'ensemble des mEthodes dEveloppEes ~t l'heure actuelle dans la littErature, une premiere approche s'intEresse ~t la conception d'architecture mEmoire pour des applications dEterministes (les acc~s en mEmoire sont connus). I1 faut donc dEfinir l'architecture et ses paramEtres afin de rEduire aussi bien la taille de la mEmoire que son activitE. On trouve des mEthodes d'exploration de l'architecture basEes sur des estimations syst~me sans module ANN. TF~.LECOMMUN., 59, n ° 7-8, 2004

26/35

N. JULIEN -- PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

929

m6moire [10], ou int6grant un mod61e simple [104]. I1 est important de d6terminer avec pr6cision la taille globale de m6moire n6cessaire h l'application [108, 109] : on peut diminuer la m6moire de programme grace ~t des techniques de compression de code [110] ; il est aussi int6ressant de d6terminer le nombre de bancs [111] en fonction des acc~s, car le partitionnement des m6moires peut r6duire leur consommation et facilite les mises en veille s61ectives [26]. De nombreuses 6tudes portent sur les m6moires caches : mod61e [101], architecture [112], mise en veille [113], dimensionnement [114] ; or, la flexibilit6 de ces m6moires est peu int6ressante dans les applications embarqu6es, et trop consommatrice [115]. Les travaux r6cents s'orientent plut6t sur l'utilisation de m6moires d6dides (Application Specific Memory ou scratchpad) dans lesquelles sont placdes directement les donnEes utiles ~ l'application ; l'6nergie par acc~s est alors 2,5 ~ 4 fois plus petite que pour un cache de taille 6quivalente [116]. Le probl6me est alors de d6terminer les donn6es ~ y placer et sur quel intervalle de temps. Cependant, tous ces travaux considarent une organisation de la hi6rarchie m6moire donn6e en nombre de niveaux de hidrarchie, types de m6moire et de contr61e ; aucune 6tude, l'heure actuelle, ne permet de d6terminer ces caract6ristiques afin de garantir la meilleure organisation m6moire en fonction de l'application. On trouve plusieurs propositions architecturales, h base de cache [ 117], voire d'un cache de d6codage d'instructions [118], ou le 'data forwarding' qui consiste h utiliser les chemins de donn6es directs pour le stockage des variables de faible dur6e de vie [ 119]. Pour diminuer les commutations lors des transferts, on peut 6galement agir sur les bus grace ~t des techniques de codage telles que le code de Gray qui ne demande pas de surco0t mat6riel, le code inversion de bus [120] int6ressant pour des donn6es larges, le code 'z6ro transition' pour les adresses [121] ou des techniques ?a base de dictionnaire [122]. Quelques techniques interviennent apr6s la synthbse architecturale pour optimiser la g6n6ration d'adresses et donc la transition sur les bus d'adresses [123, 124]. VI.3.2. M6thodes logicielles Une autre classe d'optimisations concerne, pour une architecture fix6e, des transformations de code afin surtout de rfduire le coot dO aux acc~s m6moire. Bien qu'elles permettent d'optimiser ~tla lois les performances et l'6nergie, on trouve peu de transformations ind6pendantes de l'architecture [125] : des transformations de graphes pour tenir compte des modes d'acc6s de la m6moire [10], l'assignation unique, la mise en ligne des fonctions, l'extraction des invariants de boucles... Quant aux transformations d6pendantes de l'architecture, si la reduction des instructions de chargement et stockage am61iore fi la fois les performances et l'6nergie, d'autres techniques ndcessitent des compromis [81] comme le r6-ordonnancement pour augmenter la r6utilisation des donn6es [126] et le pipeline de registres. C'est pourquoi de nombreux travaux portent sur les transformations de boucles (inversion, d6roulage, loop tiling, fusion/fission) et leurs interactions avec l'architecture car il est tr6s difficile d'en pr6voir l'impact sur les performances finales [127, 128, 129]. Cette difficult6 est h l'heure actuelle un frein au d6veloppement d'outils, notamment de compilateurs pour l'optimisation m6moire [130]. Quand l'architecture est fix6e, un autre probl~me est la distribution et le placement des donn6es afin d'utiliser au mieux l'espace m6moire. La plupart des techniques de placement pour les m6moires d6di6es qui prennent en compte le crit~re de consommation sont des m&hodes statiques : [131 ] propose simplement de choisir les addresses les plus fr6quemment acc6d6es, [116] utilise une m6moire bloc-notes pour les donn6es et une pour les instructions ; seul [132] pr6sente une m6thode de placement dynamiqne. On trouve 6galement diff6rentes techniques de gestion de cache [133], y compris pour les caches d'instruction [134]. 27/35

ANN.TI~LI~COMMUN.,59, n° 7-8, 2004

930

N. JULIEN-- PANORAMADESOUTILSD'ANALYSEETD'OPTIMATIONDELACONSOMMATION

VI.3.3. Optimisation conjointe

La troisi~me approche, la plus complexe, est celle qui donne les meilleurs r6sultats puisqu'elle permet l'optimisation conjointe de l'architecture m6moire et du code de l'application. On connalt surtout la m6thode DTSE ( D a t a T r a n s f e r t a n d S t o r a g e E x p l o r a t i o n ) d6velopp6e h I'IMEC [76] ; cependant le temps n6cessaire ~ l'obtention d'une solution optimale est relativement important (plusieurs mois) car, bien qu'il existe l'outil A t o m i u m , de nombreuses 6tapes ne sont pas automatis6es et requi~rent l'expertise d'un concepteur avis6, notamment pour appliquer les transformations de code [77]. Une autre approche est bas6e sur une granularit6 plus forte puisqu'elle consid6re les structures de donn6es dans leur ensemble [135] ; de plus, la modification de l'ordonnancement permet de tenir compte des contraintes d'acc~s aux m6moires lors de la synth~se architecturale.

VII. CIRCUITS PROGRAMMABLES

ET RECONFIGURABLES

La n6cessit6 de flexibilit6 des SoC implique l'utilisation de circuits logiques programmables, voire d'architectures reconfigurables ; cependant, ici encore, l'un des probl~mes majeurs sera la ma~trise de la consommation. En effet, les circuits logiques programmables (et reprogrammables) se caract6risent pour l'instant par une consommation statique importante ; cependant les constructeurs int~grent actueUement cette contrainte et am61iorent leurs produits en cons6quence ; le d6veloppement de FP6A embarqu6s faible consommation permettra leur int6gration dans les syst6mes [136].

TABLEAUIX. - Caract6ristiquesATPdes circuits Xilinx pour un multiplieur 16 bits. ATP characteristics for a 16-bit multiplier on a Xilinx circuit. Famille

Circuit

Pstatique mW

Spartan

2-5

[2, 69-6,57]

11, 748

128

10.079

128

0,81

9, 922

128

0,81

8,888

128

1,65

12,894

128

5

1,65

11,353

128

6

1,65

10,165

128

[360-540]

2E-7

Virtex2

Surface(# LC)

1,15

2E-6

VirtexE

Vitesse(ns)

1,15

2-6

Virtex

Pdynamique mW/MHz

4

[20,19-25.57]

0,86

9,922

128

7

O,86

8, 888

128

8

0,86

7,302

128

6

4

[360-900]

13,09

7,979

135

5

[112,5-450]

13,09

6,95

135

6

13,09

6,95

135

ANN. TF,LI~COMMLrN.,59, n° 7-8, 2004

28/35

N. JULIEN -- PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

931

Peu de travaux ont port6 sur la modElisation en consommation des circuits configurables et reconfigurables. De surcroit, vu la rapiditE d'Evolution de ces circuits, les caractErisations rEalis6es sont rapidement obsolbtes. Le Tableau IX pr6sente les diffErentes caractEristiques obtenues en surface (en nombre de cellules logiques El6mentaires ou LC), vitesse et consommation (statique et dynamique) pour un multiplieur 16 bits. Les estimations ont 6tE fournies par le logiciel lSE qui inclus Xpower, l'outil constructeur d'estimation de consommation post placement/routage [137]. Les valeurs de consommation statique dependent de la taille de la matrice programmable et donc de la taille du circuit ; nous fournissons ici les valeurs extremes pour les circuits concernEs. I1 est int6ressant de noter que les versions 'amEliorEes' des circuits (E : Enhanced), se caract6risent par une augmentation de vitesse et une reduction de la puissance dynamique mais au d6triment d'une puissance statique plus grande. Pour des technologies VSM (en dessous de 65 nm, dont l'apparition est prEvue h partir de 2007), seul le parall61isme maximal ~ la fois pour l'algorithme et l'architecture pourront permettre de r6pondre aux contraintes de vitesse et de consommation des syst6mes haute performance [8]. Pour les applications d6pendantes de plusieurs variables et standards, la logique reconfigurable sera indispensable. Pleiades est l'architecture reconfigurable developpEe h Berkeley pour des applications radio-logicielles [136] ; elle permet d'obtenir 10 ~t 50 MOPS/roW contre 3 MOPS/roW pour des DSP ou ASIP. Cependant, sa consommation est dominee par l'Energie de configuration par rapport ~ l'6nergie d'ex6cution. L'Evaluation du coot 6nerg6tique d'une reconfiguration est donc un param6tre important dans l'6valuation des diff6rentes architectures reconfigurables, qui pourrait pond6rer le crit~re de rEmanence li6 ~ la dynamique de reconfiguration [138] ; les optimisations architecturales devront aussi &re Evalu6es par rapport ~t leur impact sur la consommation globale du syst6me, et intEgrer les techniques de conception faible consommation (voltage scaling, mises en veille...). I1 y aura donc un enjeu important ~ dEgager les spEcificitEs des circuits programmables et reconfigurables tant pour l'estimation que pour l'optimisation de consommation par rapport aux mEthodes et techniques existantes.

VIII. C O N C L U S I O N

Nous avons montr6 la nEcessit6 de prendre en compte le crit6re de consommation au plus t6t dans la conception des SoC. I1 y a donc, ~t l'heure actuelle, un fort besoin de mEthodes et d'outils pour l'estimation et l'optimisation de la consommation aux diffErents niveaux de conception matErielle et logicielle. Nous avons 6galement vu que la mEmoire, aussi bien par son architecture que par les donnEes qui doivent y ~tre placEes, est un ElEment important qui conditionne les performances du syst~me ; il faut donc Egalement intEgrer cette contrainte tout au long du riot de conception. Les techniques d'optimisation au niveau syst~me se rEv~lent tr~s efficaces mais elles nEcessitent de disposer d'estimateurs fiables et rapides. Or la ma~trise de la consommation des syst6mes nEcessite la maitrise des phEnom~nes pour chaque E16ment en particulier ; cela rend le travail d'autant plus dElicat lorsque les syst~mes sont fortement hEtErog~nes, comme dans les SoC. I1 faut notamment ~tre capable, lors de la conception syst~me, d'estimer les performances de diff~rentes solutions architecturales afin d'effectuer rapidement le meilleur choix pour l'application. Pour cela, il faut ~tre capable, non seulement de mod61iser chaque composant du syst~me (processeur, DSP, ASIC, FPGA, 29/35

ANN. TI~LI~COMMUN.,59, n° 7-8, 2004

932

N. JULIEN - PANORAMA DES OUTILS D'ANALYSE ET D'OPT1MATION DE LA CONSOMMATION

mEmoires .... ) mais 6galement de mod61iser les interactions de ces diff6rents composants pour la classe d'applications vis6e. En effet, il ne suffit pas d'assembler des composants faible consommation, encore faut-il que les architectures elles-m~mes soient conques pour la faible consommation [13] ; il faudra notamment d6velopper des architectures fortement parall~les et 6galement optimiser le logiciel embarqu6, et plus particuli~rement la gestion de la m6moire. L'ensemble des techniques pr6sent6es au cours du document pourront donc &re appliqu6es avec profit pour la conception des SoC. Certains probl~mes, loin d'etre n6gligeables, n'ont cependant pas 6t6 trait6s dans cet article car peu de travaux les prennent en compte actuellement. Les interconnexions et plus particuli& rement les r6seaux surplus (NoC), devront ~tre caract6ris6s et optimis6s en consommation car leur importance va augmenter au fur et~ mesure de l'6volution de la technologie. Plusieurs r6alisations de prototypes en logique asynchrone ont donn6 des r6sultats encourageants mais l'absence d'outils freine encore le d6veloppement industriel de ce type de conception. Les composants virtuels (IP) sont en train d'6merger mais pour l'instant, les caract6ristiques en consommation fournies sont tr~s incompl&es : il est envisageable de d6velopper des mod61es de composants param6trables permettant de caract6riser les comportements en consommation de ces IP. La gestion de la consommation par le syst6me d'exploitation (os) se d6veloppe mais jusqu'~t pr&ent, l'impact du syst6me d'exploitation lui-m~me sur la consommation a 6t6 tr6s peu 6tudi6 ; on trouve cependant qu'il peut engendrer, suivant les applications, de 6 ~t 50 % de surconsommation et cette contribution augmente avec la fr6quence et la tension du systbme [ 139]. Enfin, les circuits mixtes rencontrent 6galement le probl&rle de la consommation ; actuellement, seules quelques 6tudes ont caract&is6 la consommation des convertisseurs analogique/num6rique en fonction du format des donn6es [140]. Manuscrit requ le 2 octobre 2003 Acceptg le 30janvier 2004

BIBLIOGRAPHIE

[1] ESR Core-Zearfl, ~Embedded Systems Roadmap~>, 22 Feb. 2002.

[2] DE MAN (H.), ~>,presentation in DATE,Paris, March 4-8, 2002. [3] CAI (G.), LIM (C.H.), ,Architectural Level Power/Performance Optimization and Dynamic Power Estimation>>, in ACM,OEEEConf. MICRO-32CoolChip Tutorial, Nov. 15, 1999. [4] DE (V.), BORKAR (S.), <~Low Power and High Performance Design Challenges in Future Technologies>>, in Proc. GtSVLSI,2000. [5] IRWIN(M.J.), NARAYANAN(V.), ,Low Power Design: From Soup to Nuts>>, in ISCATutorial Low Power Design, 2000. [6] EDAA, <>, Jan. 21, 1998, http://www.edaa.com. [7] ITEA, ,Technology Roadmap on Software Intensive Systems>>, ITEA Office Association, Eindhoven, March 2001, http://www.itea-office.org. [8] ITRS, ~4nternational Technology Roadmap for Semiconductors>>, Edition 2001, http://public.itrs.net. [9] BENINI (L.), MARWEDEL(P.), <~Low-Power/Low-Energy Embedded Software,, in Tutorial DarE, Paris, March 4-8, 2002. [10] PANDA(P. R.), Du'rr (N.), NICOLAU (A.), Memory Issues in Embedded Systems-On-Chip: Optimizations and Exploration, Kluwer Academic Publishers, ISBN: 0-7923-8362-1, 1999. I1 l] JERRAYA (A.-A.), Conception de haut niveau des systkmes monopuces, Lavoisier, Paris, Hermes Science Publications, coll. ECEM, 2002, ISBN : 2-7462-0433-9. ANN. Tt~LI~COMMUN.,59, n ° 7-8, 2004

30/35

N. JULIEN - PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

933

[12] ROBERT(M.), TORRES (L.), SASSATLLI(G.), CAMBON(G.), <>, in Proc. 13th European Simulation Symposium, Simulation in Industry., Marseille, France, October 18-20, 2001, pp. 17-19. [13] PIQUET (C.), RENAUDIN (M.), OMNES (J-E), <¢Special Session on Low-Power Systems on Chips (SoCs)>>, in Proc. DATE,March 13-16 2001, Munich, pp488-494. [14] MUDGE (T.), <> in Computer, 34 n°4, April 2001, pp. 5257. [ 15] SINGH (D.) TtWARt (V.), <>, in ACM/tEEE Cot~ MICRO-J2 CoolChip Tutorial, Nov. 15, 1999. [16] POPPEN (F.), <~, http://www.lowpower.de/charter/designguide.php. [17] WILCOX (K.), MANr~ (S.), <, in ACM/mEE Conf. M1CRO-32 CoolChip Tutorial, Nov. 15, 1999. [ 18] RABAEV(J. M.), PEDRAM(M.), Low Power Design Methodologies, Kluwer Academic Publishers, ISBN: 0-79239630-8, 1996. [19] NEBEL (W.), SCHM1DT(E.), <~Low Power Design Training>~, in Tutorial Dare, Paris, March 4-8, 2002. [20] BEELOUAR(A.), ELMASRY (M. I.), Low-Power Digital vLst Design, Circuits and Systems, Kluwer Academic Publishers, ISBN: 0-7923-9587-5, 1995. [21] BICKERSTA~ (M.), NICOL (C.), ACKLAND (B.), < eOAC96, pp. 214-218. [25] CONO (J.), KOH (C. K.), < 1995 DAC, pp 612-617. [28] RAGUNATHAN(A.), JHA (N.K.), DEY (S.), High-level Power Analysis and Optimization, Kluwer Academic Publishers, ISBN: 0-7923-8073-8, 1998. [29] AZEMARD(N.), AUVERGNE(D.), ~, in Proc. Dare, Paris, March 4-8, 2002. pp. 163-167. [31] CRISTOLOVEANU(C.), Lt (S.S./, Electrical Characterization of Silicon On Insulator Materials and Devices, Kluwer Academic Publishers, ISBN 0-7923-9548-4, Boston, 1995. [32] DICKINSON(A.G.), DENKER (J.), ~ mEE Journal of Solid State Circuits, 30 n°3 March 95 pp. 311-315. [33] OHKUBO(N.), SUZUKY(M.), SHINTO (T.), YAMANAKA(T.), SHIMIZU(A.), SASAK[(K.), NAKAGOME(Y.L <> IEEE Journ. of Solid State Circuits, 30 n°3 March 95 pp. 251-256. [34] KOJIMA(H.), TANAKA(S.), SASAKI(K.), <> IeEE of Journal of Solid State, 30 n°4 April 95 pp. 432-435. [35] ALIDISSA(M.), MONTEIRO(J.), DEVADAS(S.), GHOSH (A.), PAPAEFrHYMIOU(M.), <> IEEE Trans. on VLS!Systems, 2 n°4 December 94 pp. 426-435. [36] LAKSHMINARAYAN(G.), RAGHUNATHAN (A-L KHOURI (K. S.), JHA (N. K.), DEY (S.), <,Common-Case Computation: A High-Level Technique for Power and Performance Optimization,>> DAC, New Orleans, USA, 1999. [37] IMAN (S.), PEDRAM (M.), <> DAC, 1995, pp. 248-252. [38] JULIEN(N.), GAILHARD(S.), MARTIN(E.), <>,Journal of VtSl Signal Processing 35 n°2, August 2003, pp. 195-211. [39] RABAEY(J. M.), <
31/35

ANN. TI~LI~COMMUN.,59, n ° 7-8, 2004

934

N, JULIEN - PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMATION DE LA CONSOMMATION

[41] MACII (E.), PEDRAM (M.), SOMENZI(E), <~High-Level Power Modeling, Estimation, and Optimization,>~ lEEE Trans. Computer-Aided Design of lntegrated Circuits and Systems, 17, n°l l, Nov. 1998, pp. 1061-1079. [42] SINGH (D.), RABAEY (J.M.), PEDRAM ( i . ) , CATTHOOR (E), RAJGOPAL (S.), SEHGAL (N.), MOZDZEN (T.J.), ~Power conscious CAD tools and methodologies : a perspective,~> in Proc. OflEEE, 83 n°4 April 95 pp. 570-594. [43] TIWAR1(V.), MALIK (S.), WOLFE (A.), LEE (M. T.-C.), <4nstruction Level Power Analysis and Optimization of Software,s, in Int. Journal orris1 Signal Processing, 1-18, (1996). [44] INTELXscale, http://www.intel.com/design/intelxscale/index.htm. [45] BENIN1 (L.), DE MICHELI (G.), <> Proc. of DAC'97, Anaheim 1997. [53] ROUATBI(E), HAROUN (B.), AL-KHAULI (A.J.), <~ IEEE CAD 1992, pp204-209. [54] NASAVI-LIsHI (A.), RUMIN (N.), <, lEEE Trans. on VtSl Systems, 4 n°4 December 94 pp. 446-454. [56] BURCH(R.), NAJM (E), YANG (P.), TRICK (T.), < ~EEE CAD 92, pp. 90-97. [571 GHOSH (A.), DEVADAS(S.), KEt.rr-ZER(K.), WHn'E (J.), <~ tEEE DAC 92, pp. 253-259. [58] GUPTA(S.), NAJM (E N.), <~ DAC 97, Anaheim USA. [59] XEMICSweb site, www.xemics.ch. [60] SEQUENCEweb site, http://www.sequencedesign.com. [61] ZIMMERMANN(R.), POWERCALC,Power Calculator for Compass, Integrated Systems Laboratory, Swiss Federal Institut of Technology, Zurich, 1996. [62] BOUZlD1 (M.), ~, Doctorat de I'Universitd de Rennes 1, 15 octobre 2001. [65] ORINOCOweb site, http://www.o-s-c.deldeutsch/lp.htm. [66] GAILHARD(S.), JULIEN(N.), DIGUET(J.-PH.), MARTIN(E.), ~How to Transform an Architectural Synthesis Tool for Low Power VLSI Designs~, 8-th IEEE GLS-VLSt 98, Louisiana, Feb. 1998. [67] GRANDPIERRE (T.), LAVARENNE(C.), SOREL (Y.), ~ lEEE Proc. of 35 th. Design Automation Conference DAC98 , San Francisco USA. [69] GUERRA(L.), POTKONJAK(M.), RABAEY (J.), <~System-level design guidance using algorithm properties,~ IEEE VLSl Signal Processing, VII pp. 73-82. [70] GAILrtARD(S.), JULIEN (N.), MARTIN (E.), ~ EUROSIPCO98, Greece Sept. 98. [71] CHANDRAKASAN(A.P.), POTKONJAK(M.), MEHRA (R.), RABAEY (J.), BRODERSEN (R.W.), ~Optimizing power using transformations,>~ leEE Trans. on VLSI Systems, Vol. 14 n°l January 95 pp. 12-29. [72] LISKY (D.), RABAEY (J.), ~Early Power Exploration - A World Wide Web Application,s, Proc. of the 1996 Design Automation Conference, pp. 27-32. [73] MARTIN (E.), PHILIPPE (J.L.), < in Proc. DAC 93, pp. 573-577.

ANN. TI~LI~COMMUN.,59, n ° 7-8, 2004

32/35

N. JULIEN -- PANORAMA DES OUTILS D'ANALYSE ET D~OPTIMATION DE LA CONSOMMATION

935

[75] POTKON.IAK(M.), SRIVASTA(M.B.), CHANDRAKASAN(A.P.), ((Multiple constant multiplications : efficient and versatile framework and algorithm for exploiting common sub expression elimination, >, rEEETrans on CAD, 15 n°2 Feb. 95 pp. 151-165. [76] CATrHOOR (F.), WUYTACK (S.), DE GI~EF (E.), BALASA (F.), NACHTERGAELE(L.), VANDECAPELLE (A.), Custom Memory Management Methodology, Kluwer Academic Publishers, Boston, 1998, ISBN: 0-79238288-9. [77] LANDMAN(P.E.), MEHRA (R.), RABAEY (J.), ((An integrated CAD environment for low power Design,)> IEEE Design and Test of Computers, 13 n°2 pp. 72-82 June 96. [78] LI (Y.), HENKEL (J.), ((A Framework for Estimating and Minimizing Energy Dissipation of Embedded rrw/sw Systems,>> IEEEProc. of 35 th. Design Automation Conference DAC98, San Francisco, USA. [79] CrrONG (E.Y.), BENINI (L.), BOGLIOLO (A.), DE MICHELI (G.D.), ((Dynamic power management for non-stationary service requests,>> Design Automation and Test in Europe, 1999. [80] RoY (K.), JOHNSON (M. C.), ,> in Naro Advanced Study Institute on Low Power Design in Deep Submicron Electronics, Aug. 1996, NATOASt Series, chap. 6.3. [81] VhLLU~ (M.), JOHN (L.), (( Is Compiling for Performance = Compiling for Power %, Workshop on Interaction between Compilers and Computer Architectures INTEgACT-5,January 2001. [82] RABA~Y(J.), Gt~ggh (L.), MErmA (R.), ((Design Guidance in the Power Dimension>>, Proc. of the ICASSP,1995. [83] YE (W.), VIJAYKPdSHNAN(N.), KANDEMrR(M.), IRWIN(M.J.), "The Design and Use of SimplePower: A Cycle Accurate Energy Estimation Tool>>, in Proc. Design Automation Conf., June 2000, pp. 340-345. [84] KADAYIF(I.), KANDEMrg (M.), VIJAYKR.lSHNAN(N.), IRWIN(M.J.), SIVASUBRAMAN~AM(A.), ((EAC:A Compiler Framework for High-Level Energy Estimation and Optimization>>, in Proc. DATe'02, March 4-8 2002, pp. 436-442. [85] BROOKS(D.), TIWARI(V.), MARTONOSI(M.), ((Wattch: A Framework for Architectural-Level Power Analysis and Optimizations,>> in Proc. Int. Symp. on Computer Architecture, June 2000, pp. 83-94. [86] LIAO(W.), HE (L.), (, Power Modeling and Reduction of VLIWProcessors),, in Proc. Workshop on Compilers and Operating Systems for Low Power COLP,2001, pp. 8-1/8-7. [87] PONOMA~V (D.), KUCUK (G.), GHOSE (K.), ((AccuPower: An Accurate Power Estimation Tool for Superscalar Microprocessors>>, in Proc. DAT~'02, March 4-8 2002, pp. 124-129. [88] TIWAed(V.), MALIK (S.), WOLFE (A.), ((Power analysis of embedded software: a first step towards software power minimization,>> 1EEETrans. vLsl Systems, 2 n°4, Dec. 1994, pp. 437-445. [89] KLASS (B.), THOMAS (D.E.), SCHMIT (H.), NAGLE (D.E), ((Modeling Inter-Instruction Energy Effects in a Digital Signal Processor>> Power Driven Microarchitecture Workshop 1SCA, 1998. [90] BRANDOLESE(C.), FORNAClARI (W.), SAHCE (E), SClUTO (D.), "An Instruction-Level Functionality-Based Energy Estimation Model for 32-bits Microprocessors," in Proc. Design Automation Conf., June 2000, pp. 346-351. [91] Qu (G.), KAWABE(N.), USAMI (K.), POTKONJAK(M.), ((Function-Level Power Estimation Methodology for Microprocessors,>> in Proc. Design Automation Conf, June 2000, pp. 810-813. [92] BELLEUDY (C.), GUITTON-OUHAMOU (P.), AUGUIN (M.), ((Power Consumption Model for the DSP OAK Processor>>, in Proc. vI~l-soc, Montpellier, December 3-5, 2001, pp. 73-78. [93] BONA (A.), S~MI (M.), Scitrro (D.), SILVANO(C.), ZACCARIA(V.), ZAFALON(R.), <(Energy Estimation and Optimization of Embedded VLrWProcessors based on Instruction Scheduling>,, in Proc. DAC'02, June 10-14, 2002, New Orleans, USA, pp. 886-891. [94[ STErNK~(S.), KNAUER (M.), WEHMEYER (L.), MARWEDEL (P.), ((An Accurate and Fine Grain InstructionLevel Energy Model Supporting Software Optimizations)> in Proc. PArMOS(2001). [95] SIN'aA (A.), CH~AKASAN (A. P.), ((JouleTrack - A Web Based Toot for Software Energy Profiling>>, in Proc. DAC, June 2001, p. 220. [96] B~ASA (E), CATr~IOOR(E), DE MAN (H.), ((Practical solutions for counting scalars and dependences in ATOMIUM>>,tEEe Trans. On Computer Aided Design, 16, pp. 133-145, February 1997. [97] BEN~ql (L.), MAClI (A.), MACII (E.), ((Static Footprint Control in Code Compression for Low-Energy Embedded Systems>>, in Proc. Int. Workshop on PArMOS,2001. [98] BEN AMMAR (L.), AMARA (A.), ((R6duction des courants de fuite dans les ROMS en utilisant la pr6charge s61ective~>, in Proc. 3~mes Journdes Francophones d'Etudes Faible Tension - Faible Consommation, Paris, France, 30 mai-ler juin, 2001, pp. 13-18. [99] PAPAIX(C.), DAGA (J. M.), CASETrA (M.), AUVERGNE(D.), ((Optimisation en puissance de l'6criture des m6moires EEI'ROMembarqu6es)), in Proc. 3~mes Journdes Francophones d'Etudes Faible Tension - Faible Consommation, Paris, France, 30 mai - ler juin, 2001, pp. 23-25. [100] MOSYSweb site, http://www.mosys.com. [101] KAMBLE(M.), GHOSE (K.), ((Analytical energy dissipation models for low power caches,)> In Proceedings of International Symposium. on LOw Power Electronic and Design, pp. 143-148, August 1997. 33/35

ANN. TI~L~,COMMUN.,59, n ° 7-8, 2004

936

N. JULIEN -- PANORAMA DES OUTILS D'ANALYSE ET D'OPTIMAT1ON DE LA CONSOMMATION

[102] SHIVAKUMAR(E), JOUPPI (N. E), <> Technical Report, Compaq, Western Research Laboratory, august 2001. [I03] Su (C.), DESFAIN(A.), <>, in Proc. 36th t~F~EDesign Automation Conference, june 1999, pp. 140-145. [105] COUMERI(S.), THOMAS (D.), <> In Proceedings of bzternational Symposium on Low Power Electronic and Design, pp. 179-184 August 1998. [106] SCHMIDT(E.), JOCHENS(G.), KRUSE(L.), THEEUWEN(El, NEBEL (W.), <>, in Proc. DATE, 2001, p. 808. [107] MICRON,<>, Technical Note, TN-46-03, Micron, 2001. [108] GRUN /E), BALASA (E), Duwr (N.), <>, in Proc. 6th International Workshop on Hardware~Software Co-Design CODES,March 1998. [ 109] ZHAO(Y.), MALIK (S.), <,, mEE Trans. VLSt Systems, 8, N ° 5, October 2000. [110] LEg:ATSAS(H.), HEN~L (J.), WOLF (W.), <>, in Proc. OAC, 2000, p. 294. [111] BENINI (L.), MACCHIARULO(L.), MACII (A.), MACII (E.), PONCINO (M.), <>, in Proc. OAC, 2001, p. 784. [112] MALIK (A.), MOVER lB.), CERMAK (D.), <>, in Proc. ISLPED, 2000, pp. 241-243. [113] ZHOU (H.), TOBUREN (M.C.), ROTENBERG(E.). CONTE (T. M.), <>, in Proc. Int. Cot~ On Parallel Architectures and Compilation Techniques, 8-12 September 2001, Barcelona, Spain, pp. 61-70. [114] FORNAC~ARI(W.), SCIUTO (D.), SILVANO(C.), ZACCARIA(g.), <>, in Proc. CODES, 2001, p. 260. [115] BENrNI(L.), MACn (A.), MACII (E.), PONCINO (M.), ,>, in Proc. 37th rEEe Design Automation Conference, June 2000. pp. 300-304. [116] STEINKE (S.), WEHMEYER (L.), LEE (B-S.), MARWEDEL (P.), <>, in Proc. DATE, March 4-8, 2002, Paris, pp. 409-415. [117] TANG (W.), GtJr"rA (R.), NICOLAU (A.), <>, in Proc. DATE, March 4-8, 2002, pp. 443-448. [118] KIN (J.), GUFTA (M.), MANGIONE-SM)TH(W.), <>, in Proc. International Symposium on Microarchitecture, December 1997, pp. 184-193. [119] SAMI (M.), SCltrro (D.), SJLVANO(C.), ZACCARIA(V.), <>, in Proc. DARE,2001, pp. 252-257. [120] STAN(M.R.), BURLESON(W.P.), <,Bus-invert coding for low-power fro>>,IEEE Trans. ws~ Syst., 3, pp. 49-58, Mar. 1995. [121] BENINI (L.), DE M~CHEL! (G.), MACII (E.), PONCINO (M.), QUER (S.), <>, IEeE Trans. VLSl S_vstems, 6 N°4, December 1998. [122] Lv (T.), HENKEL (J.), LEKATSAS(H.), WOLF (W.), <>, in Proc. DATE, March 4-8. 2002, pp. 1059-1064. [123] CHILLET(D.), SENTIEYS (O.), CORAZZA (M.), <>, in Proc. GLS-VLSt, Ann Arbor, Feb. 1999. [124] KHARE (A.), PANDA(P.), DUTT (N.), NICOLAU(A.), <>,in Proc. SASIMI98 [125] CHAKRAPANI(L.N.), KORKMAZ(P.), MOONEY hi (V.J.), PALEM(K.V.), PUTrASWAMY(K.), WONG (W.E), <>, in Proc. CASES, 2001. [126] KANDEMIR(M.), <>, in Proc. DATE, March 4-8, 2002, Paris, pp. 984-990. [127] KrM (H.S.), IRWIN (M.J.), VUJAYKRISHNAN(N.), KANDEMIR(M.), <>, in Proc. Workshop on Signal Processing System. October 2000. [128] CHATZIGEORG1OU(A.), KOUGIA(S.), NIKOLAID1S(S.), <>, in Proc. Int. Workshop on PArMOS, 2001. [129] YANG (H.), GAD (G. R.), MARQUEZ (A.). CAI (G.). Hu (Z.), <>, in Proc. Workshop on cole, 2001, pp. 12-I/12-8. [130] GRUN (P.), DuTr (N.), NICOLAU (A.), <>, in Proc. 37th Design Automation Conference (DA¢), pp. 316-321, June 2000. ANN. TI~L/~COMMUN.,59, n ° 7-8, 2004

34/35

N. JULIEN - PANORAMADES OUTILS D'ANALYSEET D'OPTIMATION DE LA CONSOMMATtON

937

[131] BENINI(L.), MACI! (A.), MACII (E.), PONCINO(M.), ~Synthesis of Application-Specific Memories for Power Optimization in Embedded Systems~>, in Proc. 37th 1EEEDesign Automation Conference, June 2000, pp. 300-304. [132] PIGNOLO(S.), MAgTIN (E.), JULIEN(N.), SENN (E.), SAGET(B.), ~Optimisation de la consommation d'6nergie des applications de Traitement du Signal et de l'image embarqu6es sur DSP~, in Proc. 3dines Journ¢es francophones Faible Tension Faible Consommation, Paris, Juin 2001. [133] IRIS BAHAR (R.), ALBERA (G.), MANNE (S.), ~Power and Performance Tradeoffs using Various Caching Strategies~, In Proc. Int. Symposium on Computer Architecture ISCA, 1998. [134] LWEPaS(N.), ZERVAS(N.D.), SOUDRIS(D.), GOUTIS (C.E.),~A Code Transformation-Based Methodology for Improving I-Cache Performance of DSP Applications>~, in Proc. DATE,March 4-8, 2002, Paris, pp. 977-983. [135] CoggE (G.), JVLIEN(N.), SENN (E.), MARTIN(E.), ~Ordonnancement sous contrainte de m6morisation: une optimisation efficace des ressources lots de la synth6se d'architecture)r, in Proc. 4ejournges d'~tudes Faible Tension Faible Consommation, 15- 16 mai 2003, pp. 147 - 152. [136] RABAEY(J. M.), ~Managing Power-Dissipation in the Generation-after-Next Wireless Systems~, vrFc'99. [137] XtLtNXweb site, http://www.xilinx.com. [138] DEMIGNY(D.), BOUDOUAN1(N.), ABEL (N.), KESSAL(L.), ~La r6manence des architectures reconfigurables : un crit6re significatif de classification des architectures ~, in Proc. Joum6es Francophones Ad6quation Algorithme Architecture, 16-18 D6cembre 2002, pp. 49-52. [139] ACQUAVIVA(A.), BENINI (L.), RICCO (B.), ~(Energy characterization of embedded real-time operating systems~, Workshop on Compilers and Operating Systems for Low Power, 2001. [140] LOUMEAU(P.), NAVINER(J.E), PETIT (H.), NAVINER(L.), DESGREYS(P.), (~Analog to digital conversion : technical aspects>~,Annales des Tglgcommunications, 57, n°5-6, 2002, pp. 338-385.

35/35

ANN. "I'~LI~COMMUN.,59, n ° 7-8, 2004