G´en´eration du code et synth`ese de l’extension mat´erielle

3.2.4.1 Mod`eles d’architecture de l’extension pour le NiosII

Deux mod`eles d’architecture sont actuellement support´es par notre flot. Ils sont illustr´es par la figure3.1. La figure3.1.a d´ecrit une architecture compos´ee d’un processeur extensible (e.g., NiosII) et d’un bloc reconfigurable contenant le mat´eriel n´ecessaire `a l’ex´ecution des occurrences de motifs s´electionn´ees dans le graphe d’une application. L’architecture 3.1.b illustre, quant `a elle, le cas o`u l’extension mat´erielle contient plusieurs blocs reconfigurables pouvant s’ex´ecuter en parall`ele. Ces blocs sont interconnect´es par un r´eseau de communication full-crossbar et contiennent potentiellement des m´emoires qui sont utilis´ees pour stocker les donn´ees externes (i.e., liens entrants ou sortants du graphe) sans solliciter le processeur pour acc´eder `a la m´emoire principale. D’autre part, les donn´ees transf´er´ees du processeur et celles qui sont produites sur l’extension (sans intervention du processeur) peuvent ˆetre m´emoris´ees dans une file de registres interne `a l’extension pour une utilisation ult´erieure sur l’un des blocs.

Si un bloc de l’extension supporte plusieurs instructions sp´ecialis´ees, le chemin de donn´ees qui met en œuvre l’ensemble de ces op´erations dispose alors de multiplexeurs qui seront (re)configur´es `a l’ex´ecution, en interpr´etant l’identifiant de l’instruction sp´ecialis´ee transmis par le processeur. De plus, les blocs reconfigurables peuvent ˆetre h´et´erog`enes. Chaque bloc supporte alors un ensemble d’op´erations complexes qui lui est propre. Cependant, il est important de noter que la multiplication des blocs ainsi que du nombre d’op´erations support´ees par chacun d’entre eux augmentera le nombre

3.2. Pr´esentation du flot de conception ASIP 55

1 void custom_butterfly(int a, int b, int c,int d, int *out1, int *out2){ 2 asm volatile("

3 custom 1, %0, %1, zero;

4 custom 2, %2, %3, %4;

5 custom 3, zero, zero, %5;"

6 :"r"(a) 7 :"r"(b) 8 :"r"(c) 9 :"r"(d) 10 :"=r"(*out1) 11 :"=r"(*out2) 12 ); 13 }

Figure 3.9 – Fonction C qui ex´ecute le motif de la figure 3.4 sur l’extension, trois instructions sp´ecialis´ees sont n´ecessaires : 1) envoi des deux premiers op´erandes 2) envoi des autres op´erandes, calcul et r´ecup´eration du r´esultat 3) r´ecup´eration du deuxi`eme r´esultat.

d’instructions sp´ecialis´ees `a supporter dans l’architecture. Dans le cas du NiosII, le nombre total d’instructions sp´ecialis´ees diff´erentes ne pourra exc´eder 256 (cf. paragraphe3.2.2.4, page51). 3.2.4.2 Compilation NiosII

`

A chaque motif peut correspondre une ou plusieurs occurrence(s) s´electionn´ee(s) dont les contextes d’ex´ecution (i.e., connexions entre les registres et les op´erateurs mat´eriels) peuvent varier d’une oc- currence `a l’autre. Il est donc possible que pour un mˆeme bloc reconfigurable, les configurations des multiplexeurs soient diff´erentes pour plusieurs des occurrences d’un mˆeme motif. Or, ce sont les instructions sp´ecialis´ees qui identifient les diff´erentes configurations. Puisque leur nombre est limit´e par les capacit´es du processeur cible, il est important de minimiser le nombre de configurations en optimisant l’allocation des registres pour chaque bloc. De plus, la surface occup´ee par l’extension mat´erielle sera d’autant plus faible que le nombre de configurations diff´erentes par bloc (et donc de multiplexeurs) sera r´eduit. Ce probl`eme d’optimisation n’entre pas dans le cadre de cette th`ese et pour plus de d´etails, le lecteur est invit´e `a consulter la th`ese de Kevin Martin [125] ou l’article [128]. Une fois que les diff´erentes configurations d’un mˆeme motif ont ´et´e identifi´ees, chacune de ses oc- currences s´electionn´ees lors de la couverture est remplac´ee, dans la repr´esentation interm´ediaire (e.g., DAG, HCDG), par un nouveau nœud symbolisant l’ensemble des instructions sp´ecialis´ees associ´ees. Une nouvelle version du code C qui exploite ces instructions (e.g., par des instructions assembleur en ligne) est ensuite reg´en´er´ee (tˆache 4 du flot, Figure 3.2). Cette version sera ensuite compil´ee par le compilateur natif du NiosII pour produire un binaire ex´ecutable sur l’architecture.

La Figure 3.9 montre le code C reg´en´er´e `a partir du motif de la Figure 3.4. La zone de code sp´ecifique est d´elimit´ee par la constructionasm volatilede GCC qui d´efinit une s´equence d’instruc-

tions assembleur ne pouvant ˆetre optimis´ees par le compilateur. Dans cette zone, chaque instruction sp´ecialis´ee est ´ecrite dans une syntaxe assembleur :

custom <id>, <r1>,<r2>,<r3> ;

dont les param`etres (%0,...,%5) sont des registres du processeur. Leur allocation est cependant laiss´ee

56

Chapitre 3. S´election et ordonnancement simultan´e d’instructions pour processeurs sp´ecialis´es

des symboles du code C (lignes 6-11). L’utilisation du registre d’une variable est sp´ecifi´ee par:"r"(a)

(lignes 6-9) et l’´ecriture par:"=r"(a)(lignes 10-11).

L’exemple de la figure3.9illustre la n´ecessit´e d’instructions suppl´ementaires pour la transmission et la r´eception des donn´ees entre le processeur et l’extension (cf. paragraphe 3.2.2.4, page 53) : une instruction suppl´ementaire (ligne 3) est n´ecessaire pour r´ecup´erer les deux premi`eres donn´ees du motif. L’instruction suivante (ligne 4) charge les deux op´erandes restants et retourne le premier r´esultat produit sur le mat´eriel d´edi´e. De mˆeme que pour les op´erandes d’entr´ee, une instruction suppl´ementaire (ligne 5) est requise pour rapatrier le dernier r´esultat.

Mis `a part le code sp´ecifique aux zones ex´ecut´ees sur l’extension mat´erielle, le reste du programme exploitant les instructions sp´ecialis´ees respecte la syntaxe haut niveau du C. Afin de limiter l’effort de d´eveloppement dans la mise en œuvre du reg´en´erateur de code, celui-ci exploite un des points forts de l’infrastructure GeCoS, `a savoir son extensibilit´e. Il est en effet possible d’´etendre la repr´esentation interm´ediaire de base utilis´ee par GeCoS, en y ajoutant de nouvelles constructions, ou en sp´ecialisant des constructions existantes. Les passes d’analyse et d’optimisation existantes peuvent alors ˆetre ´etendues pour supporter ces extensions (sans n´ecessiter de modification de leur code source) `a l’aide d’un syst`eme de points d’extension qui se charge de r´ealiser, `a l’ex´ecution, l’´edition de liens entre le cœur de l’infrastructure et les greffons qui lui sont associ´es. Le g´en´erateur du code sp´ecifique au NiosII utilise cette propri´et´e et se contente d’ajouter les fonctions n´ecessaires au traitement des instructions sp´ecifiques qui n’existent pas dans la repr´esentation interm´ediaire standard de GeCoS. 3.2.4.3 Synth`ese de l’extension

L’extension `a synth´etiser est compos´ee d’un ensemble de blocs de calcul correspondant aux motifs s´electionn´es. Un langage d´edi´e permet de d´ecrire simplement les blocs de l’extension et les diff´erents contextes de configurations support´es. Chaque contexte correspond `a une instruction sp´ecialis´ee indi- quant les correspondances entre les ports d’entr´ee/sortie des motifs et l’interface et/ou des registres de l’extension. Ce fichier de description de l’extension est g´en´er´e `a partir des informations obtenues `a la fin de l’´etape pr´ec´edente et est utilis´e pour g´en´erer du VHDL synth´etisable.

De mˆeme que pour la g´en´eration des motifs et l’identification des configurations de l’extension, la synth`ese de l’extension n’entre pas dans le cadre de cette th`ese et pour plus de d´etails, le lecteur est invit´e `a consulter la th`ese [125]. D’autre part, la g´en´eration automatis´ee de la description mat´erielle n’est pas, `a ce jour, enti`erement fonctionnelle et explique l’absence de r´esultats de synth`ese dans nos diff´erentes exp´erimentations.