Méthodologie d'estimation de la consommation de systèmes sur
4.3 Caractérisation des blocs IP matériels
Dans l'approche proposée, nous faisons l'hypothèse qu'un système peut être entière-ment représenté par un ensemble de modèles haut-niveau connectés entre eux. Chaque modèle haut-niveau fait référence à un ensemble de congurations (Ci, avec i allant de 1 à N) correspondant à une combinaison de paramètres (quantication des données, fréquence d'horloge etc.). Pour chaque conguration Ci du modèle de haut-niveau, la description RTL du composant IP matériel existe dans une librairie dédiée. Ces descriptions RTL sont généralement décrites en utilisant des langages de description matériel (HDL) tels que le VHDL ou le VERILOG. Elles peuvent aussi être directement générées à l'aide d'outil d'un fabricant de FPGA (par exemple, l'interface graphique Core Generator de Xilinx). Dans ce cas, le composant IP a généralement besoin d'un contrôleur associé pour eectuer sa conguration et son contrôle.
Comme indiqué sur la Figure 4.4, chaque bloc IP, qui correspond à une conguration spécique de son modèle haut-niveau, est entièrement caractérisé suivant les diérentes étapes constituant le ot de conception d'un FPGA. Son implémentation est eectuée en suivant les étapes de synthèse, mapping et placement-routage. On peut remarquer que ces étapes sont spéciques à un FPGA donné, conduisant à l'utilisation d'un nombre de ressources spéciques ainsi que des temps de propagation dénis.
Des options d'implémentation peuvent être choisies par les utilisateurs comme par exemple les choix d'optimisation lors de l'étape de synthèse (niveau de performances, surface utilisée, consommation), de l'étape de placement et de routage, etc. De plus, des contraintes peuvent être fournies aux outils de conception par l'intermédiaire d'un chier dédié. Toutes ces considérations peuvent avoir un impact important sur les performances (surface utilisée, vitesse du circuit) nales du système ainsi que sur sa consommation d'énergie [MGP11]. An de s'aranchir des choix de ces options et ainsi limiter l'impact des optimisations logicielles sur le circuit nal et sur chaque bloc IP, ces options ont, soit été réduites à une valeur standard, soit xées à leurs valeurs par défaut. De cette manière, à l'issue des phases d'implémentation, un circuit avec le minimum d'optimisations est obtenu, conduisant à une valeur non-optimisée de consommation. On peut alors considérer que, dès lors que les utilisateurs appliqueront des contraintes d'optimisation sur la consommation, les valeurs de consommation du circuit seront alors inférieures à celles obtenues en phase de caractérisation. A noter que durant la thèse, l'environnement de développement ISE v14.4 de Xilinx a été utilisé [Xil15].
Figure 4.4 Caractérisation de chaque bloc IP matériel
Après les étapes d'implémentation des blocs IP, un modèle de simulation obtenu après placement et routage et décrit en VHDL, est généré. Ce modèle fournit des informations précises concernant les retards et les temps de propagation dans la netlist du circuit -nal. Comme indiqué sur la Figure 4.4, le modèle de simulation de bas-niveau est ensuite simulé. Pour cela, l'outil Modelsim 10.1c de Mentor Graphics [Men15] a été utilisé comme simulateur. Un chier de testbench, décrit en VHDL, a aussi été généré an d'appliquer les signaux appropriés aux entrées du modèle bas niveau du composant IP à tester.
Durant cette simulation temporelle, le phénomène de glitches (voir section 2.3.2 du cha-pitre 2) peut être précisément évalué. De plus, l'activité interne du circuit est sauvegardée dans un chier d'activité (.vcd ou .saif).
Deux simulations temporelles sont eectuées an d'évaluer l'activité interne du circuit lorsque :
1. l'IP est active durant toute la durée de la simulation, 2. l'IP est inactive et qu'il n'y a pas d'activité.
A ce niveau de la phase de caractérisation, des outils d'analyse de la consommation comme XPower Analyzer [Xil12c] de Xilinx ou encore PowerPlay Analyzer [Alt14] d'Altera permettent, à partir des chiers d'activité obtenus durant les simulations et de chiers re-latifs à l'implémentation (c-à-d la netlist du circuit et de chier de contraintes), de fournir des estimations des puissances statique et dynamique du circuit.
La première simulation permet d'obtenir une estimation de la puissance dynamique moyenne lorsque le bloc IP est actif durant toute la simulation.
La seconde simulation permet de déterminer une valeur de puissance dynamique moyenne lorsque le bloc IP n'est pas actif, généralement lorsqu'une entrée de contrôle de type clock enable ou chip enable est égale à 0. De cette manière, des valeurs de consommation moyenne sont connues lorsque les composants IP sont dans ces deux états.
Remarques sur les simulations en phase de caractérisation :
Les points importants sont la durée de simulation et le choix des stimuli (ou patterns) d'entrée. En eet, l'objectif est d'éviter aux utilisateurs d'eectuer un grand nombre de simulations qui pourraient être très coûteuses en temps. Une étude menée dans le cadre de la thèse, dont une partie des résultats est indiqué dans le Tableau 4.2, a montrée que la durée de la simulation en phase de caractérisation dépend de l'architecture du composant IP.
Par exemple, si le composant possède des étages de pipeline, il est susant d'étudier l'activité de ce dernier uniquement lorsque le pipeline est plein (nous qualions cet état de régime permanent). Si le composant ne possède pas d'étages de pipeline, la longueur de simulation doit être susamment longue an d'obtenir une valeur représentative de la puissance dynamique moyenne.
Dans le tableau 4.2 est résumé les valeurs de consommations dynamiques moyennes obtenues pour le bloc IP IFFT (pour une quantication des données sur 10bits, une taille de transformée de 512pts et pour un FPGA Virtex-6 LX240T) en faisant varier la du-rée de simulation (exprimés en nombre de symboles OFDM générés) ainsi que le type de pattern appliqué (données binaires aléatoires ou données typiques telles que des symboles complexes modulés QPSK).
On peut constater que, pour des blocs IPs possédant un pipeline, les valeurs de consom-mation dynamique moyenne obtenues sont relativement constantes, indépendamment de la nature des stimuli d'entrée et de la durée de simulation. De plus, nous avons vérié et
Table 4.2 Tableau d'évaluation de la puissance dynamique moyenne consommée pour diérentes durées de simulation et de patterns appliqués
Bloc IP IFFT : 512pts, 10bits 50MHz, Virtex-6 LX240T
Durée d'évaluation : 1 symbole OFDM
Patterns 1 2 3 4 5
Puissance dynamique moyenne (mW) Typiques 58.74 59.36 59.2 59.04 58.59 Aléatoires 59.99 59.85 60.02 60.03 59.85 Durée d'évaluation : 10 symboles OFDM
Patterns 1 2 3 4 5
Puissance dynamique moyenne (mW) Typiques 58.74 59.36 59.2 59.04 58.95 Aléatoires 60.06 60.07 59.97 59.92 59.98 Durée d'évaluation : 90 symboles OFDM
Patterns 1 2 3 4 5
Puissance dynamique moyenne (mW) Typiques 58.88 59.02 59.06 59.04 59.01 Aléatoires 59.99 60.08 60.01 59.98 59.98
validé les hypothèses émises, pour d'autres congurations de ce bloc IP (tailles de trans-formée allant de 256 à 2048, ainsi que pour des valeurs de quantications diérentes allant de 10 à 18 bits). A noter que l'objectif n'est pas d'obtenir une précision extrêmement ne mais plutôt d'obtenir des valeurs qui reètent les valeurs typiques de consommation du bloc IP dans chaque état.
Pour les blocs IP qui ne possèdent pas de pipeline, les stimuli appliqués aux entrées doivent être les plus réalistes possibles par rapport à ceux utilisés dans le système -nal. Pour palier cela, durant les simulations, nous avons considéré des données binaires typiques, par exemple des symboles complexes QPSK au module suivant le modulateur QPSK, ou des données aléatoires ayant le même type d'activité que dans le système nal.
Si ces conditions ne sont pas réalisées, les estimations délivrées par des outils comme XPo-wer et PoXPo-werPlay peuvent varier d'environ +/- 20% [Alt15b].
A l'aide d'outils comme XPower et PowerPlay, il est possible d'évaluer chacune des composantes de la puissance dynamique. Ainsi, la puissance moyenne dynamique d'un système ou d'un bloc IP sur FPGA est répartie suivant plusieurs termes, comme indiqué par l'équation 4.1 :
PDynamiqueIP =PHorlogeIP+PLogiqueIP+PSignalIP+PE/SsIP+PBRAMIP+PDSPIP (4.1) avec PHorlogeIP la puissance dynamique moyenne consommée par l'arbre d'horloge
in-cluant les buers et les éléments de routage,
PLogiqueIP la puissance dynamique moyenne consommée par l'ensemble des éléments logiques (Congurable Logic Block (CLB) ou Logic Element (LE)) incluant les LUTs et les bascules,
PSignalIP la puissance dynamique moyenne consommée par les éléments de routage et les données,
PE/SsIP la puissance dynamique moyenne consommée par les broches d'entrées/sorties, PBRAMIP la puissance dynamique moyenne consommée par les mémoires,
PDSPIP la puissance dynamique moyenne consommée par les blocs multiplieurs, Di-gital Signal Processing (DSP).
Idéalement, la phase de caractérisation doit être eectuée pour chaque conguration d'un composant IP et pour un FPGA donné. Actuellement, la librairie contient de multiples analyses de dizaines de composants diérents. Dans le tableau 4.3, une liste non-exhaustive de résultats d'estimation de puissance dynamique obtenus pour diérents composants est présentée. Les résultats ont été obtenus pour une fréquence d'horloge de 50MHz, avec une quantication des données de 14 bits et pour une cible FPGA Virtex6-LX240T.
Un point important de la méthodologie a été l'automatisation de la phase de carac-térisation. Pour cela, des scripts TCL (Tool Command Language) ont été développés de manière à réduire l'eort de caractérisation. Les utilisateurs n'ont plus à entrer dans le ot de conception mais seulement à congurer ces scripts pour pouvoir caractériser leurs propres composants. Les résultats pourront aussi permettre de compléter la bibliothèque de composants déjà caractérisés.
Table 4.3 Exemples de puissances dynamiques moyennes pour diérents composants IP
Nom1 Conguration utilisée Puissance dynamique
moyenne (mW) IFFT Xilinx - IP Scaled [256, 512, 1024, 2048]Architecture pipelinée [59.45, 71.02, 79.8, 93.8]
FFT Xilinx - IP Unscaled [256, 512, 1024, 2048]Architecture pipelinée [67.98, 80.31, 86.89, 103.13]
Modulateur QAM - C [QPSK, 16QAM, 64QAM] [2.19, 2.44, 2.88]
Démodulateur QAM - C [QPSK, 16QAM, 64QAM] [1.9, 2.88, 2.3.58]
LTE Turbo EncoderXilinx - IP R=1/3 (bloc de 1024 bits) 8.89 LTE Mixed Mode TurboDecoder Xilinx - IP R=1/3 (bloc de 1024 bits) 179.27
Channel EstimatorEqualizer -C Zero-Forcing [73.64,20.12]
1IP ou VHDL 'Custom' (C)