Caract´erisation de la plate-forme

La caract´erisation de la plate-forme consiste en la caract´erisation des ´el´ements de la plate-forme qui sont g´en´eriques et ne sont pas sp´ecifiques `a une application particuli`ere. Ces ´el´ements comprennent notamment des composants mat´eriels tels que des p´eriph´eriques, des adaptateurs de bus, des bus, des processeurs ainsi que des composants logiciels tels qu’un RTOS et une API logicielle. Comme les composants mat´eriels d’une plate-forme sont g´en´eralement stables et que leurs caract´eristiques de performance sont souvent standardi- s´ees, on r´ealise une caract´erisation manuelle de la performance de ces composants mat´eriels.

´

Etant donn´e que les composants logiciels sont plus mall´eables et que leurs caract´eristiques de performance peuvent facilement changer d’une version `a l’autre, on pr´esente une m´ethode automatis´ee de caract´erisation de la performance des composants logiciels.

La caract´erisation de la plate-forme permet notamment d’estimer le temps pris par les communications, les changements de contexte et le traitement des interruptions pour une architecture donn´ee ciblant cette plate-forme. Un param`etre important pour la caract´erisation des composants mat´eriels est leur largeur en octets : ce param`etre d´esigne le nombre maximal d’octets que le composant mat´eriel est capable de recevoir ou envoyer en un seul transfert sur le bus. Si un module effectue une communication de n octets avec un composant mat´eriel de largeur l tel que n > l, alors cette communication doit ˆetre scind´ee par l’adaptateur de bus en plusieurs transferts de taille inf´erieure ou ´egale `a l, soit en ⌈n/l⌉ transferts.

Les m´ethodes pr´esent´ees dans cette section pourraient s’appliquer `a diff´erentes plates- formes utilisant diff´erentes types de bus, de processeurs et de RTOS. Ces m´ethodes sont pr´esent´ees ici en utilisant la plate-forme virtuelle SPACE, qui cible un FPGA Xilinx muni de bus OPB CoreConnect IBM Corp. (1999), de processeurs MicroBlaze (Xilinx Inc., 2005) et d’un RTOS µC/OS II (Labrosse, 2002).

7.2.3.1 Caract´erisation des p´eriph´eriques

Les principaux param`etres de performance d’un p´eriph´erique sont sa largeur l en octets et le temps t qu’il prend pour traiter chaque requˆete. On suppose que le p´eriph´erique prend un temps t identique pour traiter deux requˆetes diff´erentes qui sont chacune de taille inf´erieure ou ´egale `a l. Le temps que le p´eriph´erique prend pour traiter une requˆete de n octets est donn´e par ⌈n/l⌉t. Ce temps caract´erise l’arc de s´equence correspondant au traitement d’une requˆete par le p´eriph´erique dans le CPG de l’application. Il n’inclut pas les d´elais caus´es par le transfert de la requˆete ou de la r´eponse sur le bus : ceux-ci sont plutˆot pris en compte dans la caract´erisation du bus. Le tableau 7.4 pr´esente les valeurs de ces param`etres de performance pour diff´erents p´eriph´eriques qui peuvent se brancher sur un bus OPB dans un

FPGA Xilinx. Les valeurs de t sont donn´ees en cycles d’horloge pour que cette caract´erisation puisse s’appliquer `a diff´erentes fr´equences d’horloge.

Tableau 7.4 Param`etres de performance pour diff´erents p´eriph´eriques avec interface OPB

Nom l t

BRAM (sur puce) 4 octets 1 cycle SDRAM (externe) 4 octets 14 cycles

UART 1 octets 1 cycle

7.2.3.2 Caract´erisation des adaptateurs de bus

Les adaptateurs de bus fournis par SPACE connectent chaque module impl´ement´e en mat´eriel `a un bus et leur permettent de communiquer via leur bus respectif. Il est `a noter que les autres composants mat´eriels (tels les p´eriph´eriques et les processeurs) n’ont pas besoin de ces adaptateurs de bus, car leur protocole de communication est d´ej`a adapt´e au bus. Dans la plate-forme virtuelle SPACE, la largeur des adaptateurs de bus est pr´esentement fix´ee `a 4 octets. Ainsi, toute requˆete ou r´eponse envoy´ee ou re¸cue du bus par un module est scind´ee en transferts de 4 octets lors de la communication avec l’adaptateur de bus. Pour tous ces transferts `a l’exception des acquittements, il y a un d´elai d’un cycle pour initier la s´erie de transferts et l’adaptateur prend ensuite exactement un cycle pour recevoir 4 octets du module ou pour lui transmettre 4 octets. Il y a donc un d´elai de 1 + ⌈n/4⌉ pour une communication de n octets.

Cette valeur ne tient pas compte des d´elais de communications entre l’adaptateur et le bus : ceux-ci sont plutˆot pris en compte lors de la caract´erisation du bus. Dans le cas d’une ´ecriture bloquante, le module transmetteur doit ´egalement attendre que le module r´ecepteur ait retourn´e son acquittement. L’adaptateur de bus du module r´ecepteur se charge de r´epondre avec un acquittement d`es que le module r´ecepteur a lu cette communication. Ce d´elai de r´eception de l’acquittement est ind´etermin´e tant que les op´erations de ces modules n’ont pas ´et´e ordonnanc´ees : c’est donc l’estimateur d’ordonnancement qui permet d’obtenir ce d´elai.

7.2.3.3 Caract´erisation des bus et des ponts

Un bus est un canal de communication qui peut ˆetre partag´e par plusieurs maˆıtres pour communiquer avec un ou plusieurs esclaves. Si plusieurs maˆıtres attendent d’obtenir le bus et que celui-ci se lib`ere, un arbitre choisit quel maˆıtre obtient le bus. Une caract´eristique d’un

bus est donc sa politique d’arbitrage. Un autre param`etre de performance est le d´elai ta que

prend le bus pour effectuer chaque arbitrage. Comme pour les autres composants mat´eriels, la largeur lb en octets d’un bus constitue un param`etre de performance important. Finalement,

le dernier param`etre de performance est le d´elai tcpour un transfert de lb octets ou moins sur

le bus lorsque le maˆıtre d´etient le bus. Si on suppose que le maˆıtre ne lib`ere pas le bus tant qu’il n’a pas fini de transf´erer le paquet au complet, alors le temps n´ecessaire au transfert d’un paquet de n octets vers un destinataire de largeur ld se trouvant sur le mˆeme bus est

donn´e par :

ta+ ⌈n/min(lb, ld)⌉tc (7.2)

Ce temps donne le d´elai `a partir du moment o`u s’effectue l’arbitrage qui donne le contrˆole du bus `a ce maˆıtre pour ce transfert. Le d´elai entre le moment o`u le maˆıtre demande l’acc`es au bus et le moment o`u cet arbitrage s’effectue ne sera connu que lorsque les op´erations du syst`eme seront ordonnanc´ees, ´etant donn´e qu’il d´epend du moment o`u les autres maˆıtres demandent l’acc`es au bus.

Dans le cas o`u le destinataire se trouve sur un bus diff´erent, il y a un d´elai d’arbitrage et de transfert sur chacun des deux bus en plus d’un d´elai de transfert sur le pont qui relie les deux bus. Le d´elai sur chaque bus est donn´e par l’´equation 7.2. Le d´elai associ´e `a chaque transfert sur le pont (de taille inf´erieure ou ´egale `a min(lb, ld)) est ´egal `a tp. On trouve donc

que le temps pour transf´erer un paquet de n octets d’un transmetteur sur un bus vers un r´ecepteur sur un autre bus est donn´e par :

2ta+ ⌈n/min(lb, ld)⌉(2tc+ tp) (7.3)

Ce temps exclut, encore une fois, le temps pendant lequel un des deux bus est occup´e par une autre communication.

Le bus OPB supporte deux politiques d’arbitrage : la premi`ere utilise des priorit´es sta- tiques assign´ees `a chaque maˆıtre et la seconde est un algorithme LRU qui donne le bus au maˆıtre qui a le moins r´ecemment obtenu le bus. Ces deux politiques sont mod´elis´ees dans la plate-forme SPACE et dans la caract´erisation du bus OPB. Pour les param`etres de perfor- mance du bus OPB et du pont OPB-OPB tels que mod´elis´es dans SPACE, on obtient les valeurs pr´esent´ees au tableau 7.5.

7.2.3.4 Caract´erisation du RTOS et de l’API logicielle

Le dernier ´el´ement de la plate-forme `a caract´eriser est le temps requis pour les op´erations du RTOS et de l’API logicielle. Cela inclut la gestion des communications logicielles, que

Tableau 7.5 Param`etres de performance du bus OPB et du pont OPB-OPB Param`etre Description Valeur

lb Largeur du bus 4 octets

ta D´elai d’arbitrage 3 cycles

tc D´elai de transfert 5 cycles

tp D´elai du pont 4 cycles

celles-ci se fassent `a l’int´erieur d’un mˆeme processeur, avec d’autres processeurs, avec des modules mat´eriels ou avec des p´eriph´eriques. Cela comprend ´egalement les changements de contexte et les traitements des interruptions du processeur. Les param`etres de performance du RTOS et de l’API logicielle sont pr´esent´es au tableau 7.6 et sont d´ecrits plus en d´etails `a l’annexe B.

´

Etant donn´e que le code logiciel associ´e au RTOS ou `a l’API logicielle peut subir des mises `a jour et que leur performance peut en ˆetre modifi´ee, une m´ethode automatis´ee est pr´esent´ee pour caract´eriser automatiquement leurs param`etres de performance. Cette m´ethode utilise une application synth´etique, dont la sp´ecification ex´ecutable est d´efinie avec SPACE, pour exercer les diff´erents cas d’utilisation des fonctions de communications de SPACE : lectures et ´ecritures bloquantes ou non-bloquantes vers des modules ou des p´eriph´eriques avec diff´e- rentes tailles de paquet. Selon l’architecture qui l’impl´emente, l’application synth´etique exerce aussi (indirectement) les fonctions de changement de contexte et les ISR du RTOS. Cette application synth´etique est simul´ee et profil´ee avec diff´erentes architectures, qui repr´esentent diff´erents partitionnements logiciel/mat´eriel sur un ou deux processeurs. Cette m´ethode exa- mine ensuite l’ensemble des enregistrements g´en´er´ees par le profilage de ces simulations et en extrait les param`etres de performance pr´esent´es au tableau 7.6. Les d´etails de cette m´ethode sont pr´esent´es `a l’annexe B.

On constate que les d´elais associ´es aux communications effectu´ees par les modules logiciels sont ´elev´es. On propose `a la section 10.2.5 des pistes de solution pour diminuer ces d´elais, mais l’optimisation du RTOS ou de l’API logicielle de SPACE d´eborde du cadre de cette th`ese. En l’absence de telles optimisations et pour ´eviter que les temps d’ex´ecution du RTOS et de l’API logicielle deviennent le facteur dominant de l’exploration architecturale r´ealis´ee au chapitre 8, on d´efinit un facteur d’acc´el´eration a du RTOS et de l’API logicielle. Ainsi, si on effectue une estimation de performance avec un facteur d’acc´el´eration de a, alors les valeurs des param`etres de performance du RTOS et de l’API logicielle seront divis´ees par a par rapport aux valeurs pr´esent´ees dans le tableau 7.6. L’ajout d’un tel facteur d’acc´el´eration se fait sans perte de g´en´eralit´e puisqu’il demeure possible d’utiliser directement les valeurs

Tableau 7.6 Param`etres de performance du RTOS µCOS II et de l’API logicielle

Nom Description Valeur

tctx D´elai de changement de contexte 489 cycles

tisr0 D´elai de base de l’ISR de r´eception d’un message 2600 cycles

tisr+ D´elai additionnel de cette ISR pour chaque 4 octets 798 cycles

tisrunblk D´elai additionnel si l’ISR d´ebloque la tˆache destinataire 1023 cycles

tisrack D´elai de l’ISR de r´eception d’un acquittement 1885 cycles

tper0 D´elai de base d’une communication avec un p´eriph´erique 272 cycles

tper+ D´elai additionnel pour chaque 4 octets 83 cycles

thw0 D´elai de base d’une ´ecriture `a un module externe 618 cycles

thw+ D´elai additionnel de l’´ecriture pour chaque 4 octets 83 cycles

thwblk D´elai additionnel si cette ´ecriture est bloquante 494 cycles

thwackblk D´elai additionnel si cette ´ecriture bloque 930 cycles

tsw0 D´elai de base d’´ecriture `a un module du mˆeme processeur 2035 cycles

tsw+ D´elai additionnel de cette ´ecriture pour chaque 4 octets 679 cycles

tswunblk D´elai additionnel si elle d´ebloque le module destinataire 938 cycles

tswblk D´elai additionnel si l’´ecriture est bloquante 342 cycles

tswackblk D´elai additionnel si l’´ecriture bloque 466 cycles

trd0 D´elai de base d’une lecture d’un message 1487 cycles

trd+ D´elai additionnel pour chaque 4 octets 684 cycles

trdblk D´elai additionnel d’une lecture qui bloque 699 cycles

trdempty D´elai d’une lecture non-bloquante sur un canal vide 473 cycles

thwack D´elai d’un acquittement `a un module externe 276 cycles

tswack D´elai d’un acquittement `a un module du mˆeme processeur 677 cycles

du tableau 7.6 en sp´ecifiant a = 1.