Le cœur de l’approche repose sur un flot de projection pour lequel il faut définir un objec- tif. Cet objectif doit permettre de prendre en compte le fait que des fautes permanentes sont susceptibles d’apparaître dans l’architecture. Sur un CGRA – qui possède un grand nombre de ressources de calculs – il est intuitif de penser que pour minimiser la probabilité d’apparition d’erreurs, il faut minimiser le nombre de ressources utilisées, i.e. la surface utilisée. Ainsi, si le flot permet de générer des mappings qui utilisent le plus petit nombre de ressources tout en respectant les contraintes de l’utilisateur, alors ces configurations devraient permettre de faire durer le plus longtemps possible le composant. Cependant, ce n’est pas suffisant. Considérons le CGRA 4 × 4 torique de la figure 2.4a. Supposons que les tuiles 1, 2, 4, 9, 10 et 16 sont défectueuses et que le mapping utilisant le moins de tuiles est en forme de croix comme celui de la figure 2.4b en vert. Si la tuile 8 devient défectueuse comme dans la figure 2.4c, alors il n’est plus possible d’utiliser ce mapping sur l’architecture alors qu’elle possède encore plus de la moitié de ses ressources. Pour pouvoir continuer à fonctionner, il faudrait avoir par exemple une configuration « en ligne » comme celle de la figure 2.4d.
On peut donc conclure qu’avoir uniquement le mapping ou un ensemble de mappings de taille minimale n’est pas suffisant pour répondre à notre problématique. Il faut avoir à disposition d’autres mappings. La littérature ne fournit pas de méthode permettant de déterminer en temps restreint une configuration ou mapping sur un CGRA. Il faut donc obtenir avant l’exécution du code applicatif sur l’architecture un grand nombre de configurations différentes pour ce dernier. Pour cela, il faut projeter le code sur l’architecture de sorte qu’il « l’utilise » de différentes façons.
WƌŽŐƌĂŵŵĂďŝůŝƚĠ dŽůĠƌĂŶĐĞĂƵdžĨĂƵƚĞƐ dLJƉĞĚ͛ĂƌĐŚŝƚĞĐƚƵƌĞ͗ 'Z DŽĚğůĞĚ͛ĂƉƉůŝĐĂƚŝŽŶ͗ &' ƌĐŚŝƚĞĐƚƵƌĞ'Z ƉĂƌƚŝĞůůĞŵĞŶƚƚŽůĠƌĂŶƚĞ &ůŽƚĚ͛ŝŵƉůĠŵĞŶƚĂƚŝŽŶ ^LJƐƚğŵĞƚŽůĠƌĂŶƚ KƉĠƌĂƚŝŽŶƐ KƉĠƌĂƚĞƵƌƐ
Figure 2.3 – Illustration du cheminement logique de la proposition générale finalisée.
(a) Architecture initiale. (b) Architecture en cours de fonctionnement
après 6 fautes.
(c) Architecture après une faute sur la tuile 8. (d) Fonctionnement après changement pour un
mapping linéaire utilisant 6 tuiles.
1 2 3 4
5 7 8
9 10 11 12
13 14 15 16
6
(a) Architecture d’origine.
2 3 5 7 8 9 10 12 16 15 14 (b) 1er exemple. 4 11 15 13 12 10 9 7 5 3 2 (c) 2eme` exemple. 7 8 9 10 11 12 13 14 15 16 6 (d) 3`eme exemple.
Figure 2.5 – Trois exemples d’apparition de cinq fautes permanentes dans un CGRA 4 × 4 possédant un mesh-2D. Les tuiles fautives ne sont pas représentées pour plus de lisibilité.
2.4.1 Notion de réseaux
Une « utilisation » correspond à l’ensemble des ressources qui sont utilisées par le code au cours de son exécution (i.e. une projection géométrique selon l’axe temporel du mapping sur l’architecture). Il ne s’agit pas simplement de la localisation des ressources dans l’architecture, mais aussi de la façon dont elles sont reliées. Dans le cas d’un CGRA, un réseau est constitué par un ensemble de tuiles (ressources) reliées par une sous-partie de l’interconnexion. Cette association « tuiles + interconnexion » est appelée un « réseau ».
2.4.1.1 Exemples
Considérons un CGRA 4 × 4 possédant une interconnexion de type mesh-2D simple illustré en figure 2.5a. Les figures 2.5b, 2.5c et 2.5d présentent trois possibilités de dégradation de l’architecture par cinq fautes permanentes. Dans le premier cas (figure 2.5b), le réseau restant est équivalent à un réseau linéaire avec chaque tuile pouvant communiquer avec deux voisins à l’exception des deux extrémités qui ne peuvent communiquer qu’avec un seul voisin. Dans le deuxième cas, le réseau restant est assez hétérogène avec six tuiles pouvant communiquer avec un seul voisin, deux avec deux, deux avec trois et une avec quatre. Dans le troisième cas le réseau résultant reste très connecté. Une application qui a été compilée pour un de ces réseaux précis ne pourra pas s’exécuter simplement sur un autre de par les différences de capacité de communication. Il faut donc arriver à générer un ensemble de mappings pouvant s’exécuter sur ces sous-réseaux.
possibilités de réseaux de différentes architectures.
Taille du CGRA Durée totale
Hypothèse d’une minute Hypothèse d’une seconde
2 × 2 16 minutes 16 secondes
3 × 3 8,5 heures 8,5 minutes
4 × 4 45,5 jours 18,2 heures
5 × 5 63.8 ans 1 an
8 × 8 35 000 milliards d’années 584 milliards d’années
2.4.1.2 Approche mathématique
Comme cela a été illustré par l’exemple précédent, à partir d’une architecture CGRA possé- dant un réseau d’interconnexion simple, il est possible d’obtenir, après l’apparition de quelques fautes permanentes, des réseaux complètement différents dans leur capacité à exécuter un code. En fait, chaque tuile possède deux possibilités d’état : non fautive ou fautive. De ce fait, pour un CGRA possédant nbT uiles tuiles, il y a 2nbT uiles possibilités de réseaux sur lesquels il faudrait avoir un mapping. L’ordre de grandeur de la durée de l’obtention d’un mapping pour les mé- thodes de l’état de l’art est d’environ une minute. Le tableau 2.1 donne pour quelques tailles de CGRA le temps de compilation total pour obtenir un mapping par réseau en supposant que le temps de compilation vaut soit une minute, soit une seconde par projection. Au vu des valeurs pour un CGRA 4 × 4, dans les deux cas, il n’est pas envisageable d’utiliser l’énumération de tous les réseaux qui pourraient être obtenus en cas de fautes et de projeter l’application sur chacun d’entre eux.
De manière à diminuer ce temps, il est possible de remarquer que cette énumération est très redondante. En effet, par exemple dans la figure 2.5b, si la tuile numéro 7 était fautive à la place de la tuile numéro 4, le résultat de la compilation serait identique en termes d’exécution. De même, le résultat de la compilation ne change pas d’un réseau à l’autre si il existe des symétries, des rotations ou des translations permettant le passage de l’un à l’autre. Prendre en compte ces éléments de géométrie permet de réduire le nombre de réseaux pour lesquels il faudrait réaliser les projections et ensuite regénérer les configurations manquantes.
Dans le cas d’un réseau de type mesh-2D, la détermination des réseaux pour lesquels il est intéressant d’effectuer la projection est quasi-équivalente à celle de déterminer les Polyominos à Forme Libre (PFLs). Les PFLs ont été nommés ainsi par Solomon Golomb [Golomb, 1996] qui cherchait à trouver et dénombrer des pavages de l’espace à base de carrés. Les Polyominos à Forme Fixée (PFFs) correspondent aux pavages strictement différents de l’espace par transla- tions et rotations alors que les PFLs correspondent aux pavages qui sont différents par symétries, rotations et translations. La figure 2.6 illustre les différents PFFs possibles avec 4 éléments1. Dans une optique d’obtention de mappings différents, il n’y a que trois réseaux véritablement différents : le carré, celui en forme de T et la ligne, en bleu sur la figure. Les autres pavages sont semblables à la ligne. Il y a donc sept PFFs à quatre éléments, mais seulement trois PFLs.
2.4.1.3 Obtention des réseaux différents
Le problème de l’obtention des PFFs et des PFLs est très complexe. La génération en se basant sur les solutions précédentes n’est pas aisée non plus pour ne pas oublier des réseaux « inédits ». Il existe néanmoins quelques algorithmes dans la littérature qui ont permis en 8 mois de calcul d’obtenir les PFLs possédant jusqu’à 28 éléments (il y en a 153 511 100 594 603) et les PFFs jusqu’à 56 éléments [Oliveira e Silva, 2007]. Le tableau 2.2 donne quelques uns des
Figure 2.6 – PFFs possédant quatre éléments. Les PFLs sont bleus.
Tableau 2.2 – Illustration du nombre de Polyominos à Forme Fixée (PFFs) et à Forme Libre (PFLs) [Jensen and Guttmann, 2000, Guttmann, 2009].
Nombre d’éléments Nombre de PFFs Nombre de PFLs
2 2 1 3 6 2 4 19 5 5 63 12 6 216 35 7 760 108 8 2 725 369 9 9 910 1 285 16 104 592 937 13 079 255 25 20 457 802 016 011 2 557 227 044 764 56 69 150 714 562 532 896 936 574 425 480 218 ?
nombres de polyominos pour différents nombre d’éléments et illustre que même en tenant compte des propriétés mathématiques des réseaux, au delà de quelques éléments ce nombre devient non raisonnable. Par exemple pour des réseaux à 16 éléments, les 13 079 255 possibilités entraîneraient un temps de compilation de plusieurs années en considérant un temps unitaire d’une seconde. Une méthode se basant sur une génération exhaustive de réseaux ne passe donc pas à l’échelle.
2.4.2 Implications sur le flot
Obtenir des « utilisations » différentes pour un code, et donc pouvoir s’adapter à un ensemble de fautes permanentes, peut se faire de deux façons. La première consiste à énumérer les différents réseaux possibles et pour chacun d’eux lancer un processus de projection qui serait donc sous contrainte de réseau. Mais comme montré au paragraphe précédent, ce n’est pas une solution réaliste. La seconde façon de faire consiste à non pas être sous contrainte de réseau, mais sous objectif de réseau. Dans cette approche, le processus de projection doit essayer d’obtenir le plus de réseaux différents possibles, sans avoir connaissance a priori de ceux-ci. Pour la mettre en œuvre, il est possible de définir une heuristique ou une meta-heuristique. Cette méthode doit alors réaliser la projection de l’application sur le CGRA de manière à obtenir le plus d’utilisations différentes à la fin. C’est ce type d’approche que nous nous proposons d’explorer dans ce manuscrit.
2.4.3 Implications sur l’interconnexion
Le choix du réseau d’interconnexion n’est pas sans conséquence sur la méthode permettant d’obtenir des utilisations différentes et sur le nombre de réseaux de tuiles qui peuvent être
des tuiles était un mesh-2D simple. Soient quatre CGRAs A, B, C et D possédant 16 tuiles organisées en 4 × 4 différant uniquement par leur réseau d’interconnexion :
— le CGRA A possède un réseau d’interconnexion de type mesh-2D simple (figure 2.7a) ; — le CGRA B possède un réseau d’interconnexion de type mesh-2D torique (figure 2.7b) ; — le CGRA C possède un réseau d’interconnexion de type mesh-plus (figure 2.7c) ; — le CGRA D possède un réseau d’interconnexion de type mesh-X (figure 2.7d).
Lorsque l’on considère des fautes permanentes sur certaines tuiles, le réseau formé peut considérablement changer. La figure 2.8 donne l’architecture résultante après l’apparition de huit fautes permanentes (en enlevant les tuiles défectueuses) :
— dans le cas du mesh-2D simple (figure 2.8a), trois tuiles se retrouvent isolées et ne pourront être utilisées que si l’application possède des parties indépendantes et peu gourmandes en ressources. Le plus grand réseau possède alors uniquement cinq tuiles ;
— dans le cas du mesh-2D torique (figure 2.8b), une des tuiles qui était précédemment isolée reste reliée, ce qui porte à six tuiles le plus grand réseau. Le coût à payer est l’ajout des liens entre les tuiles de côté qui va augmenter le temps de propagation et limiter la fréquence de fonctionnement en fonction de la dimension du CGRA ;
— dans les cas des mesh-plus et mesh-X (respectivement en figures 2.8c et 2.8d), l’ensemble des tuiles reste relié dans cet exemple en formant un seul réseau. Mais ceci au coût d’une interconnexion à huit voisins au lieu de quatre.
Une tuile isolée étant moins à même d’exploiter le parallélisme d’une application qu’une tuile reliée à d’autres, il est préférable, dans l’architecture, de disposer d’un maximum de tuiles reliées. Cependant, il faut prendre en compte les coûts en surface et temps de propagation de tels réseaux.