Aper¸cu g´en´eral

Un aper¸cu g´en´eral de la m´ethodologie propos´ee est pr´esent´e `a la figure 3.1 alors que la figure 3.2 illustre les changements que subit une application donn´ee `a diff´erentes ´etapes de la m´ethodologie. Le point de d´epart est un mod`ele de calcul et une sp´ecification ex´ecutable parall`ele d’un syst`eme embarqu´e sous la forme d’un ensemble de modules SystemC (IEEE, 2005) communiquant ensemble et avec des p´eriph´eriques via des canaux de communications abstraits, tel qu’illustr´e `a la figure 3.2(a) (o`u le crossbar est fonctionnellement ´equivalent `a un ensemble de canaux FIFO). Ce syst`eme embarqu´e sera impl´ement´e sur une technologie cible, pour laquelle la plate-forme virtuelle SPACE (Filion et al., 2007; Bois et al., 2010) fournit un ensemble de mod`eles transactionnels de bus, de processeurs, de m´emoires et de p´eriph´eriques.

Pour impl´ementer la sp´ecification sur la plate-forme virtuelle, il est n´ecessaire de prendre des d´ecisions quant `a l’allocation des processeurs, bus et autres composants de la plate-forme et `a l’assignation des modules et des p´eriph´eriques de la sp´ecification sur ces composants al- lou´es. On d´esigne cette prise de d´ecision comme la synth`ese d’architecture et son r´esultat est l’architecture du syst`eme embarqu´e. Une telle architecture n’est donc pas directement ex´ecu- table, mais repr´esente un devis pour l’impl´ementation du syst`eme embarqu´e, tel qu’illustr´e `a la figure 3.2(b).

La synth`ese du syst`eme repr´esente la mise en oeuvre de ce devis afin d’obtenir, pour le syst`eme embarqu´e, une impl´ementation SystemC `a bas niveau qui est ex´ecutable et est ap- proximativement pr´ecise au cycle pr`es, tel qu’illustr´e `a la figure 3.2(c). `A partir du devis de l’architecture, la synth`ese du syst`eme alloue donc un ensemble de mod`eles transactionnels de composants de la plate-forme virtuelle puis assigne les modules et p´eriph´eriques de la sp´ecification `a ces composants. Plus pr´ecis´ement, si le devis indique qu’un module doit ˆetre

assign´e `a un processeur, alors la synth`ese du syst`eme assigne `a ce processeur l’impl´ementation logicielle de ce module ciblant ce type de processeur. De la mˆeme mani`ere, pour les modules qui doivent ˆetre assign´es directement sur un bus, la synth`ese du syst`eme y assigne l’impl´e- mentation mat´erielle RTL de ces modules pour la technologie cible. La synth`ese pr´ealable des modules permet de construire cette librairie d’impl´ementations logicielles et mat´erielles des modules qui sont utilis´ees par la synth`ese du syst`eme. Cette synth`ese du syst`eme inclut aussi un raffinement des canaux de communications entre les modules vers des protocoles et des m´ecanismes de communication concrets. Elle g´en`ere ´egalement, pour chaque processeur, un logiciel embarqu´e comprenant un RTOS et les modules logiciels assign´es au processeur. Le r´e- sultat de cette synth`ese est ainsi une impl´ementation en SystemC, qui est compos´ee de blocs RTL, de mod`eles transactionnels de bus et de p´eriph´eriques ainsi que de logiciels embarqu´es ex´ecut´es presqu’au cycle pr`es (cycle-approximate) par des simulateurs de jeu d’instructions (ISS).

Par la suite, la synth`ese de plate-forme remplace les mod`eles transactionnels des com- posants de la plate-forme virtuelle par les blocs RTL correspondant `a ces composants, tel qu’illustr´e `a la figure 3.2(d). L’impl´ementation finale obtenue est alors compl`etement au ni- veau RTL et, `a la suite d’une synth`ese logique dans un flot de conception RTL bien ´etabli, le syst`eme embarqu´e est r´ealis´e sur sa cible finale, tel qu’un FPGA ou un ASIC.

La partie du flot pr´esent´ee jusqu’`a maintenant est lin´eaire : la sp´ecification d’une appli- cation est progressivement raffin´ee et synth´etis´ee jusqu’`a ce qu’une impl´ementation RTL en soit obtenue. Cependant, un flot strictement lin´eaire ne r´epond pas aux questions suivantes : « Comment prendre les d´ecisions inh´erentes `a la synth`ese d’architecture ? » et « Comment v´erifier que les bonnes d´ecisions ont ´et´e prises ? » Pour ce faire, on introduit le profilage, la caract´erisation, l’estimation et l’exploration architecturale.

Une premi`ere r´eponse `a ces questions est d’effectuer une simulation avec profilage logiciel/ mat´eriel et une synth`ese logique de l’impl´ementation SystemC obtenue suite `a la synth`ese du syst`eme et d’ainsi recueillir des m´etriques sur la validit´e fonctionnelle, la performance et le coˆut mat´eriel de cette impl´ementation. Un processus d’exploration architecturale compare les m´etriques mesur´ees aux objectifs de performance et de coˆut de l’application et, si l’im- pl´ementation ´evalu´ee est satisfaisante, l’exploration architecturale peut se terminer et cette impl´ementation devient alors l’impl´ementation finale. Dans le cas contraire, l’exploration ar- chitecturale modifie les d´ecisions qui avaient ´et´e prises lors de la synth`ese d’architecture, g´en`ere une nouvelle impl´ementation via une synth`ese du syst`eme, puis l’´evalue et ainsi de suite. L’exploration architecturale automatise donc un processus d’essais et erreurs pour la synth`ese d’architecture et l’impl´ementation d’un syst`eme embarqu´e.

lent ´etant donn´e que le profilage et la synth`ese logique d’une impl´ementation sont des op´era- tions dont le temps se mesure en minutes, voire en heures, et que l’exploration architecturale peut avoir `a ´evaluer des milliers d’impl´ementations. Pour raccourcir la boucle d’exploration architecturale et l’acc´el´erer, on a recours `a l’estimation, qui permet d’estimer les m´etriques de validit´e fonctionnelle, de performance et de coˆut mat´eriel d’une architecture sans avoir `a effectuer un profilage et une synth`ese logique de chaque impl´ementation `a ´evaluer. Cette m´ethode d’estimation se base sur la simulation et la synth`ese logique totale ou partielle d’un nombre restreint d’impl´ementations initiales qui permettent de caract´eriser les param`etres de performance et de coˆut mat´eriel de l’application et de la plate-forme. Apr`es la carac- t´erisation initiale, la m´ethode d’estimation acc´el`ere grandement l’´evaluation des diff´erentes architectures de l’application par l’exploration architecturale.

La v´erification de l’application, de sa sp´ecification ex´ecutable ou de l’impl´ementation fi- nale ne fait pas partie des pr´esents travaux. On suppose ainsi que la sp´ecification ex´ecutable a d´ej`a fait l’objet d’une v´erification fonctionnelle, qui se trouve en amont de cette m´ethodo- logie, et qu’elle est correcte. Des m´ethodes existantes de v´erification au niveau RTL peuvent ´egalement ˆetre appliqu´ees sur l’impl´ementation finale en aval de cette m´ethodologie. On se sert n´eanmoins des propri´et´es de notre mod`ele de calcul pour v´erifier l’´equivalence fonction- nelle des ordonnancements r´ealis´es par la sp´ecification ex´ecutable et par l’impl´ementation de l’application. Ce degr´e d’´equivalence constitue une des m´etriques mesur´ees ou estim´ees dans la m´ethodologie.