Caract´erisation des modules logiciels

Les ressources mat´erielles utilis´ees par l’impl´ementation logicielle d’un module, excluant les ressources consomm´ees par le processeur lui-mˆeme, sont la m´emoire RAM n´ecessaire pour stocker les instructions et les donn´ees de ce module logiciel. Une contrainte de SPACE que les modules de l’application doivent respecter est que ces modules ne font pas d’allocation dynamique de m´emoire. De plus, on suppose que, `a l’instar de µC/OS-II, le RTOS est tel que la pile (stack ) de chaque tˆache logicielle est un tableau allou´e statiquement. Dans ce cas, il devient possible de d´eterminer statiquement la m´emoire requise par les modules logiciels. Ainsi, pour chaque processeur cible d’une architecture donn´ee, il suffit de compiler le code logiciel (incluant le RTOS, l’API logicielle et les modules assign´es au processeur) du processeur suite `a la synth`ese logicielle pr´esent´ee `a la section 3.2.5.1, puis d’analyser cet ex´ecutable `a l’aide de l’utilitaire size de la suite GNU (Barr et Massa, 2006). Cela indique la m´emoire RAM n´ecessaire au stockage et au fonctionnement du logiciel de ce processeur. Il est `a noter que cette quantit´e de m´emoire n’inclut pas une ´eventuelle m´emoire cache, qui serait plutˆot caract´eris´ee avec le processeur et le reste de la plate-forme.

Il est relativement long de synth´etiser et compiler le code logiciel pour un processeur cible : ce temps est de l’ordre de plusieurs secondes, voire d’une minute. Ce temps peut devenir prohibitif si, comme dans les algorithmes d’exploration architecturale du chapitre 8, il est n´ecessaire d’´evaluer des milliers d’impl´ementations. Il est possible de conserver dans une base de donn´ees la quantit´e de m´emoire requise par un ensemble donn´e de modules sur un processeur, afin de ne pas avoir `a compiler deux fois le mˆeme ex´ecutable avec le mˆeme ensemble de modules. Cependant, si il y a n modules qui peuvent ˆetre impl´ement´es en logiciel, alors il y a 2n<sub>− 1 ensembles de modules qui peuvent ˆetre assign´es `a un processeur</sub>

donn´e (excluant l’ensemble vide), ce qui repr´esente une croissance exponentielle. Dans le cadre d’une exploration architecturale, un tel nombre d’ex´ecutables `a compiler peut ˆetre prohibitif. Pour limiter le nombre d’ex´ecutables `a compiler, on d´efinit un mod`ele lin´eaire o`u la m´emoire M(p) requise pour le logiciel sur un processeur p est ´evalu´ee, pour une application donn´ee avec n modules pouvant ˆetre impl´ement´es en logiciel, par l’´equation suivante :

M(p) = β0+

n

∑

i=1

βisi(p) + e(p) (7.4)

Dans cette ´equation :

– Les variables si(p) sont des variables bool´eennes qui indiquent si le module i est impl´e-

ment´e en logiciel sur le processeur p ou non ;

– Le param`etre β0 repr´esente la m´emoire requise par le RTOS et l’API logicielle ;

– Le param`etre βi repr´esente la m´emoire requise par le module i ;

– Le terme e(p) est l’erreur entre le mod`ele lin´eaire et la v´eritable quantit´e de m´emoire n´ecessaire au code du processeur p.

Les valeurs des param`etres β0 et βi sont estim´ees par une r´egression lin´eaire multiple. On

obtient alors l’estim´e suivant pour la m´emoire n´ecessaire au code du processeur. ˆ M(p) = ˆβ0+ n ∑ i=1 ˆ βisi(p) (7.5)

Notre m´ethode de caract´erisation des modules logiciels automatise l’extraction d’un nombre suffisant d’´echantillons initiaux et la r´egression lin´eaire sur ceux-ci. Pour chaque module, un ´echantillon est g´en´er´e tel que le module est assign´e seul sur un processeur. Le code logiciel associ´e `a ce processeur est synth´etis´e, compil´e et analys´e avec size pour trouver sa taille M. Dans ce cas, les variables si valent toutes 0 sauf celle qui correspond au module assign´e. De

mˆeme, pour chaque paire de modules, un ´echantillon est g´en´er´e tel que ces deux seuls mo- dules sont assign´es `a un processeur et la taille M du code logiciel correspondant est mesur´e avec size. Les variables si sont alors toute `a 0 sauf les deux qui correspondent aux modules

assign´es. La m´ethode des moindres carr´es ordinaires (Weisberg, 2005) est ensuite appliqu´ee `a cet ensemble d’´echantillons pour trouver les valeurs estim´ees de ˆβ0 et ˆβi. Le nombre d’ex´ecu-

tables `a compiler est alors ´egal `a n(n + 1)/2, ce qui est bien moins que les 2n_{− 1 ex´ecutables}

qu’il serait autrement n´ecessaire de compiler. 7.3.3 Caract´erisation de la plate-forme

Lors de la synth`ese de la plate-forme, qui a ´et´e d´ecrite `a la section 5.3.2, les mod`eles transactionnels de bus, de processeurs et de p´eriph´eriques de la plate-forme virtuelle sont

remplac´es par les composants RTL ´equivalents de la plate-forme cible. Une caract´erisation initiale de la synth`ese de plate-forme permet d’´etablir, pour chaque composant de l’architec- ture `a haut niveau, quel est l’ensemble de composants RTL qui lui est associ´e. Il est ensuite n´ecessaire de caract´eriser les quantit´es de ressources mat´erielles de ces composants RTL afin de pouvoir estimer les besoins en ressources mat´erielles d’une architecture qui cible cette plate-forme. Ces quantit´es de ressources mat´erielles sont automatiquement caract´eris´ees par une synth`ese logique de chaque composant et par une analyse du rapport de synth`ese selon une m´ethode similaire `a celle pr´esent´ee `a la section 7.3.1.

Il est possible que les param`etres de certains composants RTL de la plate-forme, et donc leurs quantit´es de ressources mat´erielles, d´ependent de l’architecture choisie. Ces composants doivent donc ˆetre caract´eris´es pour diff´erentes valeurs de leurs param`etres. Le tableau 7.7 pr´esente les param`etres variables des composants RTL d’un FPGA Virtex de Xilinx cibl´e par SPACE.

Tableau 7.7 Param`etres des composants RTL d’un FPGA Virtex cibl´e par SPACE

Composant Param`etre Valeurs possibles

Adaptateur de bus Nombre de FIFO de r´eception 1, 2, . . . , n

Bus Nombre de maˆıtres 1, 2, . . . , n

Bus Nombre d’esclaves 1, 2, . . . , n

Bus Arbitrage avec priorit´es dynamiques 0, 1

Pont Nombre d’esclaves 1, 2, 3, 4

On observe que les valeurs de certains param`etres ne sont pas born´ees et pourraient ˆetre arbitrairement ´elev´ees. Cela signifie que la caract´erisation de ces composants pour l’ensemble des valeurs possibles de leurs param`etres demanderait un nombre arbitrairement ´elev´e de synth`eses logiques, ce qui est bien sˆur impossible. La solution retenue est donc de faire une caract´erisation initiale de ces composants seulement pour des valeurs de param`etres qui sont inf´erieures `a une borne maximale N donn´ee, par exemple N = 16. Les r´esultats extraits suite `a ces synth`eses logiques sont plac´es dans une base de donn´ees qui indique combien de ressources mat´erielles sont consomm´ees par chaque composant en fonction des valeurs de ses param`etres. Si il s’av`ere qu’on a besoin, lors de l’´evaluation d’une architecture, de connaˆıtre la quantit´e de ressources mat´erielles d’un composant pour des valeurs de param`etres qui n’ont pas ´et´e caract´eris´ees, alors une synth`ese logique sera automatiquement faite avec ces nouvelles valeurs et le r´esultat sera ajout´e `a la base de donn´ees.

Il est `a noter que, dans le cadre de l’exploration architecturale avec SPACE, certains composants de la plate-forme cible, tels les processeurs, sont utilis´es toujours avec exactement les mˆemes valeurs pour leurs param`etres. Ces composants sont donc caract´eris´es seulement

pour ces valeurs fixes. Si ces param`etres cessaient d’ˆetre fixes et devenaient variables, par exemple si l’exploration architecturale permettait d’ajouter une cache au processeur et de faire varier sa taille, alors il serait possible de caract´eriser ces composants pour les diff´erentes valeurs de ces param`etres.