Mod` ele d’ex´ ecution

el´ements forment des matrices de dimensions respectant un param`etre d’entr´ee ex-terne au programme.

La connexion de tous ces canaux avec les ports de communication des proces-seurs finalise l’instanciation du r´eseau d’interconnexion : la topologie du syst`eme est compl`etement d´etermin´ee.

IV.3.4 Mod`ele d’ex´ecution

Dans cette partie, nous pr´esentons le comportement de chaque processeur au sein de l’environnement de simulation. Comme pr´ecis´e pr´ec´edemment, SystemCTMimpose l’existence d’une horloge dans l’environnement. Nous pr´esentons ici deux mod`eles d’ex´ecution envisag´es pour r´epondre `a cet imp´eratif :

1. Un module horloge inutile pour un mod`ele enti`erement pilot´e par les donn´ees. 2. Un mod`ele cadenc´e par l’horloge, et fonctionnellement asynchrone.

IV.3.4.1 Mod`ele pilot´e par les donn´ees

Un tel r´eseau asynchrone est caract´eris´e par l’absence d’horloge. Comme la biblioth`eque SystemCTM est con¸cue pour le prototypage de syst`emes synchrones, la pr´esence d’une horloge globale est indispensable au fonctionnement de l’ordonnan-ceur. Nous avons donc int´egr´e cette horloge dans un module fonctionnel (module en haut `a gauche de la figure IV.13), sans interaction avec l’architecture mod´elis´ee. Ce module sert uniquement de base de temps pour le scheduler, et n’est jamais utilis´e pour cadencer les unit´es de traitement.

Le principal avantage de ce mod`ele est sa capacit´e `a reproduire fid`element le com-portement d’un circuit asynchrone. Il permet de simuler l’asynchronisme `a un haut ni-veau d’abstraction. La figure IV.13 pr´esente le mod`ele utilis´e pour l’instanciation d’un pixel et de ses canaux de communication. Les communications bloquantes ou non-bloquantes sont explicitement mod´elis´ees (signaux inDta/outDta, inAck/outAck ). Les ´

el´ements internes constituant le processeur (carr´es noirs) sont stimul´es par des si-gnaux internes (sisi-gnaux1 e ReceivedD, e Completed . . .) ind´ependants de l’horloge du simulateur : le syst`eme est enti`erement pilot´e par le flux des donn´ees (Data driven). Chacun de ces ´el´ements constitue un processus parall`ele pour le scheduler.

Le d´eveloppement et l’utilisation de ce mod`ele a mis en ´evidence la n´ecessite d’une quantit´e importante de ressources logicielles : plus la granularit´e est fine, plus le mod`ele est complexe (plus de 63 000 tˆaches parall`eles doivent ˆetre ´emul´ees pour une grille de 88 × 72 processeurs). La simulation d’un tel r´eseau n´ecessite plus de deux gigaoctets de m´emoire vive. Pour des r´eseaux de tailles inf´erieures, le point de convergence est atteint au bout de plusieurs heures de simulation, et ce, avec une machine SUN UltraSparc bi-processeurs. L’int´erˆet de la simulation `a un haut niveau

Chapitre IV : Mod´elisation pour la validation par simulation et l’exploration d’architectures Init_Send e_ReceivedAw inDtaW outAckW outDtaW inAckW Receiver Ack outDtaW inAckW Clk Start e_ReceivedAn e_ReceivedDn Data Ack Receiver Receiver busy? grey

outAckN ^{inDtaN inAckN outDtaN}

e_Completed nature e_Free e_ReceivedDw Ack Receiver grey grey Receiver Data busy? outAckE inDtaE inAckE outDtaE inDtaW outAckW busy? Receiver Data Ack Receiver Receiver Data busy? e_ReceivedDs e_ReceivedDe nature nature nature TestBench Processeur Computer

Fig. IV.13 – Synoptique du processeur 4-connexe (data driven).

d’abstraction est alors mis en d´efaut.

Ce mod`ele a cependant ´et´e utilis´e au cours d’une pr´e´etude de l’algorithme de Hill-Climbing r´eordonnanc´e. Les r´esultats d’un algorithme de recherche de minima (corollaire aux algorithmes IV.2 et IV.3 page 112) implant´e au niveau de granularit´e d’un processeur par pixel a montr´e la pertinence d’un tel mod`ele.

Afin de pouvoir simuler l’algorithme de segmentation complet sur des images de dimension QCIF (176 × 144 pixels) et d’explorer les architectures possibles, il est n´ecessaire de r´eduire la m´emoire utilis´ee par le simulateur, ainsi que les temps de simulation. Nous nous sommes donc orient´es vers un mod`ele de simulation plus simple, plus abstrait (i.e. moins prˆet du hardware), et moins gourmand.

IV.3.4.2 Mod`ele fonctionnellement asynchrone

Cette partie pr´esente la m´ethode adopt´ee pour r´eduire le nombre de processus parall`eles tout en conservant un mod`ele d’ex´ecution fonctionnellement asynchrone. Seule la granularit´e la plus fine est consid´er´ee ici, le mod`ele de simulation ´etant ´equivalent pour les granularit´es augment´ees.

Comme les traitements sont locaux, l’id´ee est d’attribuer un unique fil d’ex´ecution (scheduler thread ) `a chaque processeur. La complexit´e algorithmique est alors r´eduite d’un facteur dix environ.

La figure IV.14 pr´esente la synoptique du processeur ´el´ementaire : une machine `a ´etat fini compos´ee d’un module purement algorithmique et d’un module cadenc´e. Ce dernier fournit en entr´ee du module combinatoire les r´esultats des calculs obtenus `a

L’environnement de simulation – IV.3

Machine à état fini

Données de sortie Contrôle Données d’entrée Données transitoires Registre Reset Clock

Fig. IV.14 – Pr´esentation synoptique d’un processeur fonctionnellement asynchrone.

“l’´etape” pr´ec´edente.

L’espace temps du mod`ele. La notion “d’´etape” fait r´ef´erence ici `a une date : un front d’horloge ascendant. L’intervalle de temps s´eparant deux ´etapes successives repr´esente un quantum de temps indivisible entre deux ´etats diff´erents du r´eseau : c’est la r´esolution temporelle du mod`ele de simulation. Comme tous les processeurs sont immerg´es dans le mˆeme espace de temps (le temps est suppos´e incompressible), l’horloge les relie tous : elle est globale au syst`eme de simulation.

L’avantage de cette mod´elisation du comportement du processeur est qu’elle ne n´ecessite qu’un seul thread par processeur sensible uniquement `a l’horloge. Cependant, elle impose que tout calcul interm´ediaire s’effectue en une “´etape” (quantum de temps). Sans modification de ce mod`ele, il est impossible de mod´eliser des latences variables suivant la complexit´e des calculs.

Afin d’int´egrer des temps de traitement, la latence de chaque calcul ou com-munication est ´emul´ee par une mise en attente des fonctions combinatoire durant plusieurs cycles de l’horloge. Les estimations de ces latences sont issues des mesures de performances du processeur ASPRO [Viv01]. ´Etant de l’ordre de 7ns en moyenne, nous estimons que la latence d’une action est comprise entre 6 et 8ns. Afin d’´emuler l’ind´eterminisme des temps de calculs, la latence de chaque action est obtenue par tirage al´eatoire ´equiprobable. Une mod´elisation plus fid`ele de l’asynchronisme consisterait `a utiliser une loi de Rayleigh [Pla94, chap.4]. Cependant, l’estimation de la latence d’une action ´etant d´ej`a approximative, il ne nous a pas sembl´e utile d’alourdir le moteur de simulation en utilisant une telle loi. Dans le mˆeme ordre d’id´ees, afin de simplifier le processus d’´ecoulement du temps, la r´esolution est fix´ee

Chapitre IV : Mod´elisation pour la validation par simulation et l’exploration d’architectures

`

a une nanoseconde : la fr´equence de l’horloge est donc fix´ee `a 1 GigaHertz (p´eriode d’une nanoseconde).

Remarques:

• Il est important de noter que cette horloge est fictive et ne correspond `

a aucune caract´eristique technologique. Son rˆole est uniquement d’int´egrer le temps dans le mod`ele (rˆole de chronom`etre), et non pas d’´echantillonner les signaux entre blocs combinatoires d’un circuit (rˆole d’ordonnancement). • Les contraintes technologiques sont int´egr´ees dans l’estimation des chaˆınes

cri-tiques des op´erateurs, c’est-`a-dire la mise en attente des fonctions combinatoires durant un certain nombre de cycles de cette horloge. La simulation est fonctionnelle car cette mise en attente n’est pas fonction des donn´ees `a traiter, contrairement au fonctionnement mat´eriel.

L’implantation de l’algorithme de Hill-Climbing. Ce paragraphe d´ecrit la m´ethode utilis´ee pour implanter l’algorithme de segmentation dans le mod`ele pr´esent´e par la figure IV.14.

S Contrôle E N S O Actif N O E Mémoires tampon Masques

Fig. IV.15 – Processeur ´el´ementaire dot´e de ses ports d’entr´ee masquables et son unit´e de traitement effectuant l’algorithme de Hill-Climbing.

La figure IV.15 est une pr´esentation synoptique corollaire `a celle de la figure IV.14, o`u les interfaces de communication interprocesseurs sont plus d´etaill´ees (cas o`u la grille est 4-connexe). Le cœur du processeur<sup>1</sup> (cercle gris contenant la machine `a trois ´etats) effectue cycliquement et s´equentiellement une lecture, des calculs (une description pr´ecise du comportement est pr´esent´ee par les algorithmes IV.7 `a IV.10 page 119) et une ´ecriture vers ses voisins.

Afin de modifier dynamiquement le degr´e de connectivit´e des nœuds du r´eseau, chaque processeur g`ere une variable de quatre bits indiquant si tel ou tel voisin doit ˆetre ´ecout´e (inhibition des ports nord et est sur la figure IV.15). Dans la section III.3.1 page 39, nous avons d´esign´e cette variable par net<sub>G</sub>[v], o`u v correspond au processeur courant.

La d´etection de fin. Bien que le temps de calcul soit born´e (l’algorithme ne boucle pas ni ne cr´ee d’interblocages), il reste a priori inconnu. Il d´epend en effet des donn´ees et des chemins de convergence de l’algorithme (construction al´eatoire

L’environnement de simulation – IV.3

de la forˆet d’arborescence). Ces derniers ´etant inconnus et d´ependants de l’image, il est n´ecessaire de d´etecter le point de convergence puisqu’il ne peut ˆetre postul´e¹. La solution la plus simple et la plus efficace connue `a ce jour est de combiner, par un ou logique, l’ensemble des ´etats d’activit´e des processeurs [Dul96].

Un pixel est actif s’il re¸coit de nouvelles donn´ees et les consomme. Il passe `a l’´etat inactif, i.e. il s’endort, d`es qu’il a fini l’envoi de ses r´esultats vers ses voisins.

L’utilisation de communications non-bloquantes entraˆınent potentiellement de fausses d´etection de fin. Sans aucune hypoth`ese sur les latences de transport des donn´ees entre deux pixels voisins, il est n´ecessaire d’´etablir un ´etat d’activit´e sur les canaux de communication [Rob97]. Dans ce cas, le r´eseau est inactif si tous les processeurs sont inactifs et si tous les canaux de communication ne transportent pas de donn´ees.

Cette m´ethode accroˆıt la complexit´e de l’architecture pour la simple d´etection de fin. Afin de la minimiser, nous supposerons que les latences de communications sont born´ees, et qu’un filtre de glitch (filtre passe-bas sur le signal d’activit´e globale du r´eseau) est suffisant.

IV.3.5 Mod`ele de communication non-bloquante

Cette partie pr´esente les ´el´ements de la biblioth`eque SystemCTM utilis´es pour implanter des communications non-bloquantes. Seules ces communications sont d´etaill´ees ici puisqu’elles sont exclusivement utilis´ees par toutes les architectures ´

etudi´ees (§IV.2 page 80).

Si la m´emoire du canal est de taille unitaire, l’entit´e signal d´efinie dans SystemCTM

mod´elisant l’´etat logique d’un ou plusieurs fils est utilis´ee.

Si une m´emoire de taille sup´erieure est souhait´ee, alors des FIFO sont utilis´ees. L’´ecriture d’une donn´ee dans une FIFO ´etant bloquante par d´efaut (SystemCTM

bloque le processus ´emetteur jusqu’`a ce qu’une place dans le canal se soit lib´er´ee), chaque processeur ´el´ementaire sonde la pr´esence d’une donn´ee (resp. d’une place libre) lorsqu’il souhaite lire (resp. ´ecrire) une donn´ee.

La biblioth`eque SystemCTM n’autorise pas l’´ecriture simultan´ee d’une mˆeme va-leur sur plusieurs FIFO : un cycle d’horloge est impos´e pour chaque ´ecriture. ´Etant en contradiction avec le mod`ele de communication souhait´e, nous avons l´eg`erement modifi´e cette biblioth`eque afin que l’´ecriture simultan´ee d’une mˆeme donn´ee sur plu-sieurs canaux soit possible.

IV.3.6 Conclusion

Le caract`ere asynchrone du r´eseau ainsi que les communications non-bloquantes sont simul´es grˆace `a un environnement de haut niveau d’abstraction : SystemCTM.

Le mod`ele d’ex´ecution et de communication de chaque processeur est ´emul´e par une machine `a ´etat fonctionnellement asynchrone, cadenc´ee par l’horloge du scheduler dont les temps de latence sont choisis al´eatoirement. Cette alternative respecte les limitations de notre station de travail et nous permet de simuler le flux des donn´ees

1Une majoration du chemin critique de propagation (par une spirale par exemple) et des latences

Chapitre IV : Mod´elisation pour la validation par simulation et l’exploration d’architectures

dans un r´eseau de taille QCIF. L’environnement est alors suffisamment ´econome, en termes de ressources m´emoire (environ 1 Go) et temps de simulation (environ une heure pour une image QCIF), pour reproduire les principales caract´eristiques des architectures choisies (§IV.2).

IV.4 Validation des architectures

Les architectures d´esormais d´etermin´ees (§IV.1 et §IV.2) et l’environnement de simulation ´etabli (§IV.3), cette partie est consacr´ee `a la validation de ces archi-tectures par la simulation. Les mesures qualitatives des r´esultats de segmentation montrent la pertinence de ces architectures. Les mesures quantitatives de complexit´e des mod`eles seront ensuite pr´esent´ees dans la section IV.5.

Toutes les simulations pr´esent´ees dans le reste de cette partie sont r´ealis´ees sur trois images gradient de dimensions standards pour les terminaux visiophoniques et simplifi´ees1 pour des raisons de visibilit´e. Ainsi, la surface des bassins d’attraction est suffisamment grande pour observer la propagation des donn´ees dans le r´eseau.

(a) Image originale (b) Image gradient (c) Minima

Fig. IV.16 – Image de test : gradient simplifi´ee de Foreman SQCIF (88 × 72).

(a) Image originale (b) Image gradient (c) Minima

Fig. IV.17 – Image de test : gradient simplifi´ee de Foreman QCIF (176 × 144).

Les deux premi`eres sont les images Foreman aux formats SQCIF (88 × 72 pixels, figure IV.16)2 et QCIF (176 × 144 pixels, figure IV.17), et la troisi`eme est Susie au format QCIF (figure IV.18).

Les images gradient sont ici ´eclaircies afin de mieux visualiser les zones de transi-tions `a d´etecter.

Pour des raisons de reconnaissance des r´egions (SQCIF) et de visibilit´e (QCIF), les deux images Foreman n’ont pas subies le mˆeme niveau de simplification. Pour

1Utilisation de l’algorithme des cascades [Beu94] : premier niveau de hi´erarchie pour l’image

SQCIF et deuxi`eme niveau de hi´erarchie pour les images QCIF.

2Pour des raisons de visibilit´e, les images SQCIF sont l´eg`erement agrandies par rapport aux

Validation des architectures – IV.4

(a) Image originale (b) Image gradient (c) Minima

Fig. IV.18 – Image de test : gradient simplifi´ee de Susie QCIF (176 × 144).

l’image SQCIF, un seul niveau de hi´erarchie de l’algorithme des cascades est utilis´e, alors que pour l’image QCIF, deux niveaux de simplifications sont utilis´es. L’image gradient SQCIF (figures IV.16b-c) comporte un nombre plus important de minima par rapport `a l’image gradient QCIF (figures IV.17b-c). Un nombre plus important de r´egions pour l’image SQCIF est donc attendu.