Universit´e Libre de Bruxelles Facult´e de Sciences appliqu´ees Service des Syst`emes Logiques et Num´eriques

Impl´ementation des filtres non-lin´eaires de rang sur des architectures universelles et reconfigurables Dragomir Milojevic

Promoteur : Prof. Philippe Van Ham

Travail pr´esent´e en vue de l’obtention du titre de Docteur en Sciences Appliqu´ees Ann´ee Acad´emique 2003-2004

Remerciements

Je tiens a` remercier plus particuli`erement le Prof. Philippe Van Ham pour ses conseils, pour son soutien et surtout pour ce goutˆ du savoir qu’il a r´eussi a` me faire partager.

Un grand merci ´egalement au Prof. Nadine Warz´ee, pour son soutien, son efficacit´e et pour sa grande disponibilit´e.

Je remercie ´egalement : Le Prof. Marc Acheroy et les membres du SIC de l’Ecole´ Royale Militaire avec lesquels j’ai eu l’opportunit´e de faire de la recherche appliqu´ee dans un but huma- nitaire et de r´ealiser des exp´eriences pas comme les autres.

Le Prof. Eduardo Sanchez pour son accueil au sein du Laboratoire des Syst`emes Logiques de l’EPFL et pour ce s´ejour inoubliable a` Lausanne.

Les Prof. Pierre Mathys, Prof. Marcel Dotrimont, Prof. Patrick Merken pour avoir accepter de faire partie de mon jury.

Un tout grand merci a` Fr´ed´eric Robert qui a pu trouver un moment pour me lire et pour m’encourager.

Je tiens a` remercier aussi tous les membres de l’´equipe du laboratoire des Syst`emes Logiques et Num´eriques avec qui j’ai partag´e beaucoup plus que le quotidien : prof. Jean Florine, Christophe De Hauwer (¸ca va ˆetre vite fait), Olivier Debeir (on va mettre encore une couje), Serge Joris (ma biche), Don Patrick Bischop (vive la Westmalle), Xavier Baele (le th´e vert au jasmin est dans mon tiroir), Claude Verbeek (Led Zep a` 7h du matin annoncent une belle journ´ee), Constant Hubert (il n’y a qu’un ampli a` lampes qui sonne bien), Denis Haumont, Laurent Mundeleer, C´edric Laugerotte, Thierry Leloup et tous les autres ... Merci a` Bill, Ella, Sarah, Billie, Isao, Eva, Patricia, et les autres de m’avoir accompagn´e a` tout moment.

Enfin je tiens a` remercier ma Julie, pour son amour, pour sa patience et pour la volont´e qu’elle a eue de corriger mon mauvais fran¸cais entre les bains de Dora et Sasha et ses dossiers des r´efugi´es Rwandais.

Table des mati`eres

R´esum´e 1

Abstract 1

1 Introduction 5 1.1 Pr´esentation g´en´erale ...... 5 1.2 Contenu et contributions ...... 8 1.2.1 Contenu ...... 8 1.2.2 Contributions ...... 9 1.3 Traitement ...... 10 1.3.1 Images et transformations ...... 10 1.3.1.1 Notations ...... 10 1.3.1.2 Transformations ponctuelles ...... 12 1.3.1.3 Transformations spatiales ...... 12 1.3.2 Filtres non-lin´eaires ...... 13 1.3.2.1 Classification ...... 13 1.3.2.2 Filtres non-lin´eaires de Classe I ...... 14 1.3.2.3 Filtres non-lin´eaires de Classe II ...... 18 1.3.2.4 Exemples d’application des filtres non-lin´eaires ...... 20 1.4 Machine ...... 23 1.4.1 Historique ...... 23 1.4.2 Classification des architectures ...... 27 1.4.2.1 Taxinomies des architectures universelles ...... 27 1.4.2.2 Taxinomies des architectures d´edicac´ees ...... 31 1.4.2.3 Taxinomies des architectures selon la configurabilit´e . . . . . 32 1.5 Performance ...... 33 1.5.1 Performance du mat´eriel ...... 33 1.5.1.1 Param`etres classiques ...... 34 1.5.1.2 Param`etre commun ...... 35 1.5.2 Performance d’une application ...... 37 1.5.2.1 Temps d’ex´ecution ...... 37 1.5.2.2 Acc´el´eration ...... 37 1.5.2.3 Mesure sp´ecifique pour le traitement d’images ...... 38

i Table des mati`eres

2 Architecture universelle 39 2.1 Parall´elisme des architectures universelles ...... 40 2.1.1 Parall´elisme intra-processeur ...... 40 2.1.1.1 Parall´elisme des instructions ...... 40 2.1.1.2 Probl`emes li´es a` l’exploitation du parall´elisme des instructions 45 2.1.1.3 Parall´elisme des donn´ees ...... 48 2.1.2 Parall´elisme inter-processeur ...... 49 2.1.2.1 Parall´elisme des syst`emes a` m´emoire partag´ee ...... 49 2.1.2.2 Parall´elisme des syst`emes a` m´emoire repartie ...... 52 2.1.3 Processeurs actuels ...... 52 2.1.4 Architectures universelles cibl´ees ...... 53 2.1.4.1 Architecture standard ...... 53 2.1.4.2 Extensions ...... 55 2.1.4.3 Diff´erences entre Pentium 2 et Pentium 4 ...... 57 2.1.4.4 Performance de la m´emoire ...... 57 2.1.5 Exploitation des diff´erents niveaux de parall´elisme ...... 58 2.1.5.1 Acc`es au parall´elisme intra-processeur ...... 58 2.1.5.2 Acc`es au parall´elisme inter-processeur ...... 60 2.2 Exploitation de l’architecture standard ...... 62 2.2.1 Impl´ementation de filtre de rang g´en´eralis´e ...... 63 2.2.1.1 Tri a` bulle (Bubble sort) ...... 63 2.2.1.2 Tri par s´election (Selection sort) ...... 63 2.2.1.3 Tri par insertion (Insertion sort) ...... 64 2.2.1.4 Tri rapide (Quicksort) ...... 64 2.2.1.5 Tri par fusion (Merge sort) ...... 66 2.2.1.6 Tri par tas (Heap Sort) ...... 67 2.2.1.7 Tri par classement (Bucket sort) ...... 67 2.2.2 Impl´ementation des filtres sp´ecifiques ...... 70 2.2.3 Conclusion ...... 70 2.3 Exploitation de parall´elisme intra-processeur ...... 73 2.3.1 Librairie de traitement des images ...... 74 2.3.2 Programmation des extensions : filtres sp´ecifiques Min/Max ...... 74 2.3.2.1 Description g´en´erale de l’algorithme ...... 74 2.3.2.2 Parcours horizontal ...... 80 2.3.2.3 Parcours vertical ...... 82 2.3.2.4 Analyse a` l’aide de VTune ...... 83 2.3.3 Programmation des extensions : filtre M´edian ...... 85 2.3.4 Programmation des extensions : filtre d’un rang quelconque ...... 86 2.3.5 Filtres d´eriv´es et/ou la chaˆıne de traitement ...... 86 2.3.6 Filtre de rang g´en´eralis´e ...... 86 2.4 Exploitation du parall´elisme inter-processeur ...... 88 2.4.1 Ex´ecution sur deux processeurs ...... 88 2.5 Conclusion ...... 90 ii Table des mati`eres

3 Architectures d´edicac´ees 91 3.1 Circuits FPGAs ...... 92 3.1.1 Architecture ...... 92 3.1.1.1 Description g´en´erale ...... 92 3.1.1.2 Ressources typiques des FPGAs actuels ...... 93 3.1.2 Impl´ementation des circuits logiques dans les FPGA ...... 95 3.1.2.1 Processus d’impl´ementation ...... 95 3.1.2.2 Perspectives de la description des circuits ...... 97 3.1.2.3 Efficacit´e des outils actuels d’impl´ementation ...... 98 3.1.3 Applications des FPGAs ...... 100 3.2 Parall´elisation du calcul des filtres non-lin´eaires ...... 101 3.2.1 Classification des algorithmes et des architectures existants ...... 101 3.2.2 Architectures matricielles ...... 104 3.2.2.1 Mode bit-s´erie ...... 104 3.2.2.2 Mode bit-parall`ele ...... 105 3.2.3 R´eseaux de tri ...... 106 3.2.4 Architectures bit-s´erie ...... 109 3.2.4.1 Algorithme pour le filtre de rang ...... 109 3.2.4.2 Cas particulier de filtre m´edian ...... 111 3.2.4.3 G´en´eralisation de l’algorithme pour les filtres Min/Max . . . 114 3.2.4.4 G´en´eralisation pour les autres filtres non-lin´eaires ...... 115 3.2.5 Architectures d´edi´ees aux filtres de piles ...... 116 3.3 Conclusion ...... 118 3.3.1 Performance des syst`emes d´edicac´es existants ...... 118 3.3.2 Remarques ...... 119 3.3.2.1 Remarques g´en´erales ...... 119 3.3.2.2 Remarques sp´ecifiques a` l’architecture ...... 120 3.3.3 Objectifs ...... 122

4 Architecture reconfigurable 123 4.1 Description globale du syst`eme d´edicac´e reconfigurable ...... 126 4.1.1 Introduction ...... 126 4.1.2 Parties constitutives ...... 127 4.1.2.1 Partie traitement ...... 128 4.1.2.2 M´emoire globale ...... 129 4.1.2.3 Unit´e de contrˆole ...... 131 4.1.3 Hypoth`eses de travail ...... 132 4.2 M´emoire locale des unit´es de traitement ...... 133 4.2.1 Description de la m´emoire locale source ...... 133 4.2.2 Description de la m´emoire locale destination ...... 138 4.2.3 Validation de la description ...... 139 4.2.4 Impl´ementation ...... 141 4.2.5 Discussion ...... 143 4.3 Unit´es de traitement ...... 144 4.3.1 Algorithmes ...... 144 4.3.1.1 Algorithme Max ...... 144 4.3.1.2 Algorithme Min ...... 146

iii Table des mati`eres

4.3.1.3 Algorithme pour le filtre g´en´eralis´e ...... 146 4.3.2 Description de l’unit´e de traitement pour les filtres Max/Min . . . . . 149 4.3.3 Description de l’unit´e de traitement pour le filtre de rang g´en´eralis´e . 153 4.3.3.1 Algorithme d’´elimination successives des maxima/minima lo- caux ...... 153 4.3.3.2 Algorithme de Danielsson ...... 154 4.3.4 Validation de la description ...... 156 4.3.5 Impl´ementation ...... 159 4.3.5.1 Unit´e de traitement bas´ee sur l’algorithme Min/Max . . . . . 161 4.3.5.2 Unit´e de traitement bas´ee sur l’algorithme de Danielsson . . 161 4.3.5.3 Discussion ...... 162 4.4 Syst`eme reconfigurable complet ...... 163 4.4.1 Description du syst`eme complet ...... 163 4.4.2 Impl´ementation d’un module de traitement ...... 164 4.4.3 Etablissen´ t d’une correspondance entre ressources n´ecessaires et res- sources disponibles ...... 169 4.4.4 Impl´ementation du syst`eme complet ...... 170 4.4.5 D´ebit des pixels trait´es ...... 171 4.5 Conclusion ...... 172

5 Discussion et conclusion 173 5.1 Probl`eme, motivation et int´erˆet ...... 173 5.2 Impl´ementation sur l’architecture universelle ...... 174 5.3 Impl´ementation sur des architectures d´edicac´ees reconfigurables ...... 175 5.4 Am´eliorations possibles ...... 177 5.5 Conclusion finale ...... 178

A Architecture universelle 181 A.1 Pr´esentation g´en´erale de l’application ...... 181 A.2 Mesure de temps d’ex´ecution d’une proc´edure ...... 183 A.2.1 Diff´erentes m´ethodes de mesure de temps ...... 183 A.2.2 Analyse des mesures pour les proc´edures types ...... 183 A.3 Fonctionnement en mode multithread ...... 187 A.3.1 M´ecanisme ...... 187 A.3.2 Influence de la priorit´e des threads sur le temps d’ex´ecution ...... 187 A.4 Mesure de performance de la m´emoire ...... 188 A.5 Code auto-modifiable pour le calcul d’adresses ...... 188

B Circuits FPGAs Xilinx 191 B.1 Architecture des FPGAs Virtex ...... 192 B.1.1 Cellule logique ´el´ementaire ...... 192 B.1.2 Modes de fonctionnement d’un CLB ...... 193 B.1.3 Bloc de m´emoire RAM ...... 194 B.1.4 Multiplicateur ...... 194 B.1.5 Digital Clock Manager - DCM ...... 195 B.1.6 Blocs d’entr´ee/sortie ...... 195 B.1.7 R´eseau d’interconnexions ...... 195 iv Table des mati`eres

B.1.8 Architecture ...... 196 B.2 Circuits FPGAs de la famille Virtex II ...... 196 B.3 Performance des FPGAs ...... 196

C Architecture reconfigurable 199 C.1 Impl´ementation des circuits propos´ees ...... 199 C.2 Validation des unit´es de traitement pour des voisinages de 5 5 et 7 7 pixels 203 × × C.3 Validation des modules de traitement apr`es placement et routage ...... 207

Glossaire 211

Bibliographie 213

v Table des mati`eres

vi R´esum´e

Les filtres non-lin´eaires de rang sont souvent utilis´es dans le but de rehausser la qualit´e d’une image num´erique. Leur application permet de faciliter l’interpr´etation visuelle et la compr´ehension du contenu des images que ce soit pour un op´erateur humain ou pour un traitement automatique ult´erieur. Dans le pipeline d’une chaˆıne habituelle de traitement des images, ces filtres sont appliqu´es g´en´eralement dans la phase de pr´e traitement, juste apr`es l’acquisition et avant le traitement et l’analyse d’image proprement dit.

Les filtres de rang sont consid´er´es comme un important goulot d’´etranglement dans la chaˆıne de traitement, a` cause du tri des pixels dans chaque voisinage, a` effectuer pour tout pixel de l’image. Les temps de calcul augmentent de fa¸con significative avec la taille de l’image a` traiter, la taille du voisinage consid´er´e et lorsque le rang approche la m´ediane.

Cette th`ese propose deux solutions a` l’acc´el´eration du temps de traitement des filtres de rang.

La premi`ere solution vise l’exploitation des diff´erents niveaux de parall´elisme des ordina- teurs personnels d’aujourd’hui, notamment le parall´elisme de donn´ees et le parall´elisme inter- processeurs. Une telle approche pr´esente un facteur d’acc´el´eration de l’ordre de 10 par rapport a` une approche classique qui fait abstraction du mat´eriel grˆace aux compilateurs des langages ´evolu´es. Si le d´ebit r´esultant des pixels trait´es, de l’ordre d’une dizaine de millions de pixels par seconde, permet de travailler en temps r´eel avec des applications vid´eo, peu de temps reste pour d’autres traitements dans la chaˆıne.

La deuxi`eme solution propos´ee est bas´ee sur le concept de calcul reconfigurable et r´ealis´ee a` l’aide des circuits FPGA (Field Programmable Gate Array). Le syst`eme d´ecrit combine les algorithmes de type bit-s´erie et la haute densit´e des circuits FPGA actuels. Il en r´esulte un syst`eme de traitement hautement parall`ele, impliquant des centaines d’unit´es de traitement par circuit FPGA et permet d’arriver a` un facteur d’acc´el´eration suppl´ementaire de l’ordre de 10 par rapport a` la premi`ere solution pr´esent´ee. Un tel syst`eme, ins´er´e entre une source d’image num´erique et un syst`eme hˆote, effectue le calcul des filtres de rang avec un d´ebit de l’ordre de centaine de millions de pixels par seconde.

Mots-clefs Traitement des images, filtres non-lin´eaires, filtres de rangs, calcul parall`ele, calcul reconfigu- rable, algorithmes bit-s´erie, circuits FPGA.

1 2 Abstract

Ranking filters are non-linear filters frequently used in digital image processing for image restoration and enhancement. Their application makes the visual interpretation and the com- prehension of the content of the image easier, that is for a visual inspection of human operator or a later automatic treatment. In the pipeline of the image processing chain, these filters are generally applied at the stage of pre-processing, just after the acquisition and before the actual image processing or analysis tasks take place.

Ranking filters represent a serious bottleneck in the image processing chain because we need to sort pixels in each neighborhood, the operation has to be repeated for every pixel of the image to be processed. The computing time increases to a significant degree with the size of the image to be treated, the size of the neighborhood considered and when the rank approaches the median.

This thesis proposes two solutions for the problem of ranking filter computing time accelera- tion.

The first solution aims the exploitation of the various levels of parallelism of personal compu- ters today and in particular the data parallelism and the parallelism between processors. Such an approach shows a factor of acceleration of about 10, compared to a traditional approach, which disregards the underlying hardware thanks to the compilers of the advanced computer languages. If the resulting data throughput makes it possible to work in real time with video applications, for the rates of about 10 million of pixels per second, little time remains for other treatments in the processing chain.

The second solution is based on a concept of reconfigurable computing and FPGA (Fied Programmable Gate Array) circuits. The described system combines the power of bit-serial algorithms and the high density of today’s FPGA circuits. The resulting system is highly parallel, implying hundreds of processing elements per FPGA and exhibits a supplementary factor of acceleration of 10 compared to the first solution proposed. Such a system, that can be easily inserted between the source of the digital image and a host system, carries out the computation of ranking filters at the rates of about hundred millions of pixels per second.

Keywords Image processing, non-linear filtering, ranking filters, parallel computation, reconfigurable computing, bit-serial algorithms, FPGA circuits.

3 4 Chapitre 1

Introduction

1.1 Pr´esentation g´en´erale

La discipline de traitement des images num´eriques est souvent repr´esent´ee comme une chaˆıne compos´ee de trois maillons : l’acquisition de l’image, le traitement et/ou l’analyse suivis de l’exploitation des donn´ees obtenues. L’image, au d´epart repr´esent´ee par un signal analogique, est transform´ee dans le domaine discret lors de l’acquisition. Le passage du monde analogique vers le monde num´erique est souvent accompagn´e par une d´egradation de l’infor- mation, dueˆ principalement aux imperfections du processus d’acquisition, de conversion et de transmission. Lors du traitement, l’aspect visuel de l’image num´erique acquise peut ˆetre am´elior´e en effectuant diverses op´erations de filtrage. Dans la phase d’analyse, une ou plusieurs caract´eristiques significatives sont extraites de l’information num´erique d’une seule ou d’une s´erie d’images. Les param`etres ainsi obtenus sont ensuite utilis´es par un op´erateur humain ou par un syst`eme dot´e d’une intelligence artificielle afin de mieux saisir l’information visuelle, de prendre une d´ecision particuli`ere, ou encore d’automatiser enti`erement une activit´e.

Actuellement, le processus d’acquisition des images num´eriques peut se faire avec une tr`es grande pr´ecision1 et vitesse2 ce qui a pour cons´equence un d´ebit de donn´ees qui peut facilement atteindre plusieurs dizaines de m´egaoctets par seconde, auquel le syst`eme de traitement et d’analyse3 doit pouvoir faire face. Si a` une aussi grande quantit´e de donn´ees on ajoute la complexit´e sans cesse croissante des traitements, le syst`eme qui automatise le processus de traitement doit pouvoir pr´esenter une importante puissance de calcul.

Pour atteindre une telle puissance de traitement trois solutions s’imposent d’avantage : 1. augmenter la vitesse des syst`emes de traitement existants,

1En 2004, les circuits CCD courants sont dot´es d’une r´esolution de l’ordre de plusieurs megapixels, chaque pixel ´etant quantifi´e sur 8 a` 12 bits, par composante couleur acquise. Une seule image est donc repr´esent´ee par une quantit´e d’information de l’ordre de quelques m´egaoctets. 2Pour les cam´eras num´eriques rapides, la fr´equence d’acquisition peut atteindre plusieurs centaines d’images par seconde. 3La phase de traitement devra de toute fa¸con faire face a` toute la quantit´e de donn´ees acquises. Dans la phase d’analyse on peut imaginer travailler sur une quantit´e d’information plus r´eduite : passage a` la repr´esentation par objets, r´egions d’int´erˆet, codage des contours etc.

5 Chapitre 1. Introduction

2. distribuer le calcul entre plusieurs syst`emes de traitement existants : la parall´elisation, 3. ou cr´eer des syst`emes d´edicac´es, ´eventuellement parall`eles.

Nous d´evelopperons chacune de ces solutions dans les trois paragraphes suivantes.

L’augmentation de la vitesse des syst`emes informatiques suit la pr´ediction de Gordon Moore annonc´ee d´ej`a en 1965 [Moo65]. Cette pr´ediction, plus connue sous le nom de la loi de Moore, stipule que la vitesse de fonctionnement des processeurs double tous les 18 mois, chiffre qui se voit v´erifi´e depuis4. Cependant la raison nous sugg`ere que le respect de cette loi ne pourra pas continuer ind´efiniment car une limite, impos´ee par des lois physiques, doit exister. En 2000, les pr´evisions sur le d´eveloppement de la technologie fixent cette limite dans deux d´ecennies [BW00].

Des facteurs d’acc´el´eration beaucoup plus importants peuvent ˆetre obtenus en distribuant le calcul entre plusieurs syst`emes de traitement. Le parall´elisme et le traitement d’images ont une longue histoire dont les d´ebuts remontent aux ann´ees ’80 [Duf83]. Depuis, d’impor- tantes avanc´ees technologiques dans la fabrication des composantes ´electroniques ont permis la r´ealisation de syst`emes d’un parall´elisme de plus en plus important, pour un prix de plus en plus faible.

La naissance de la nouvelle g´en´eration des circuits logiques programmables - les FPGA5 en 1986 [CDF+86], introduit un important changement du paradigme de calcul automatis´e, celui du calcul reconfigurable. Grˆace a` ces circuits il est possible de concevoir les syst`emes de trai- tement ou` le mat´eriel “s’adapte” a` un probl`eme particulier de calcul, d’ou leur appellation. Le haut degr´e d’int´egration des FPGAs implique la possibilit´e de parall´elisation du traitement au sein d’un mˆeme circuit, dont le degr´e d´ependra, bien entendu, de la complexit´e du traite- ment souhait´e. Enfin le prix des FPGA n’est pas prohibitif, il s’agit de circuits commerciaux, destin´es a` l’industrie ´electronique de faible volume de production ou l’usage des ASIC 6 ne serait pas rentable.

Les deux derni`eres solutions au probl`eme du traitement des images num´eriques m´eritent donc d’ˆetre ´etudi´ees de plus pr`es et repr´esentent le principal fil conducteur de cette th`ese.

Cette br`eve pr´esentation g´en´erale a permis de mettre en ´evidence trois pˆoles : le traitement, la machine et la performance qui dictent la structure de ce chapitre d’introduction, qui comporte quatre autres sections :

Section 2 - Propose une br`eve description du contenu de cette th`ese ainsi que sa contribution dans le domaine de l’acc´el´eration du temps de calcul d’un type de traitement particulier.

Section 3 - Donne une introduction au probl`eme particulier du traitement des images num´eriques qui nous int´eresse : les filtres non-lin´eaires. Par leur nature, ces traitements s’av`erent particuli`erement inadapt´es aux architectures classiques et repr´esentent souvent le goulot d’´etranglement dans la chaˆıne de traitement.

4Dans le texte original Moore parle de 12 mois, chiffre qui a ´et´e correct durant les quelques premi`eres ann´ees qui ont suivi la publication de l’article. Ensuite, la course a quelque peu ralenti et le chiffre a ´et´e corrig´e a` 18 mois. 5Field Programmable Gate Array. 6Application Specific Integrated Circuit.

6 1.1. Pr´esentation g´en´erale

Section 4 - Propose un parcours des diff´erentes architectures informatiques. Plusieurs taxi- nomies pr´esent´ees permettrons de se familiariser avec les notions g´en´erales li´ees au calcul parall`ele et n´ecessaires pour le d´eveloppement de la suite.

Section 5 - Nous nous int´eressons a` la performance de calcul et cette section a pour but de montrer comment elle peut ˆetre mesur´ee. A la mˆeme occasion, une comparaison de la puissance brute de calcul des processeurs et des FPGAs permettra de justifier l’emploi de ces derniers au probl`eme pos´e.

7 Chapitre 1. Introduction

1.2 Contenu et contributions

1.2.1 Contenu

Cette th`ese traite du probl`eme de l’acc´el´eration du temps de calcul d’une classe particuli`ere des filtres non-lin´eaires a` l’aide des architectures universelles et des architectures d´edicac´ees reconfigurables, massivement parall`eles.

De tous les filtres non-lin´eaires utilis´es dans le traitement des images num´eriques nous allons nous limiter uniquement aux filtres de rang, car ces filtres repr´esentent la brique de base pour la construction de la plupart des filtres non-lin´eaires. Ce choix est encore justifi´e par le fait qu’il s’agit de filtres efficaces, mais lents, surtout lorsqu’il s’agit de les calculer a` l’aides des architectures traditionnelles de type SISD.

Les impl´ementations propos´ees mettent en opposition deux approches distinctes des architec- tures informatiques : 1. Approche des unit´es de traitement tr`es rapides mais d’un parall´elisme faible. 2. Approche d’un parall´elisme d’unit´es de traitement beaucoup plus massif, mais de vitesse de fonctionnement plus faible. Rien ne nous permet de dire a priori laquelle des deux approches est la plus avantageuse. La r´eponse est fortement li´ee a` un tout indissociable : le probl`eme - l’algorithme - le programme - le mat´eriel. Ce dernier maillon est fortement li´e a` un moment pr´ecis des technologies d´eploy´ees pour sa fabrication et aura une influence directe sur la performance du traitement.

Mis a` part ce Chapitre d’introduction, cette th`ese en propose quatre autres : Chapitre 2 - Architecture universelle Ici nous allons traiter de l’impl´ementation des filtres de rangs sur des ordinateurs person- nels en tant qu’exemple type d’une architecture universelle, dot´ee d’un faible nombre d’unit´es de traitement fonctionnant a` grande vitesse. Nous allons montrer les limita- tions de tels syst`emes surtout lorsqu’il s’agit de calculer les filtres consid´er´es pour des voisinages de grande taille. Chapitre 3 - Architectures d´edicac´ees Dans ce Chapitre on trouvera la description d’un ensemble d’algorithmes et de syst`emes d´edicac´es existants permettant de calculer les filtres de rangs. Ce parcours nous aidera a` mettre en ´evidence les d´esavantages des syst`emes propos´es jusqu’`a pr´esent et justifier la n´ecessit´e d’une approche alternative. Chapitre 4 - Architecture reconfigurable Ce Chapitre contient la description d’un syst`eme reconfigurable de traitement original, caract´eris´e par un grand nombre d’unit´es de traitement d’une vitesse faible de fonction- nement. N´eanmoins nous allons montrer qu’un tel syst`eme permet d’arriver a` un d´ebit de traitement beaucoup plus important que celui d’une architecture universelle et des architectures d´edicac´ees existantes. Chapitre 5 - Discussion et conclusion Enfin dans ce dernier Chapitre nous allons comparer les diff´erents r´esultats obtenus, ce qui nous permettra de conclure.

8 1.2. Contenu et contributions

1.2.2 Contributions

Architecture universelle L’op´eration de tri constitue la tˆache la plus r´ecurrente dans le monde de l’informatique. De ce fait un grand nombre d’algorithmes de tri a ´et´e propos´e, surtout pour des architectures universelles de type SISD. Malheureusement ces algorithmes ne sont pas vraiment adapt´es au parall´elisme de type SIMD et MIMD (ici on fait r´ef´erence aux stations multi-processeurs a` m´emoire partag´ee) int´egr´es dans la plupart d’architectures universelles d’aujourd’hui.

1. La contribution principale de cette th`ese dans l’´etude des architectures uni- verselles se situe dans la conception d’algorithmes et de programmes ori- ginaux, permettant une exploitation optimale des diff´erents niveaux de pa- rall´elisme pour le calcul des filtres de rang. La d´emarche, celle d’une ´etude du mat´eriel sous-jacent, de la conception d’algorithmes et de leur codage en fonction du mat´eriel, d´emontre que pour ces applications particuli`eres il est possible d’obtenir d’importants facteurs d’acc´el´eration par rapport a` une d´emarche classique ou` la seule ´etude algorithmique fait abstraction compl`ete du mat´eriel.

Architecture reconfigurable Les diff´erentes impl´ementations des filtres de rang dans les architectures d´edicac´ees propos´ees jusqu’`a pr´esent ne concernent que des voisinages de petite taille et des valeurs de rang pour les- quelles les algorithmes peuvent ˆetre consid´erablement simplifi´es. De plus, les impl´ementations existantes n’envisagent pas la parall´elisation du traitement, actuellement possible a` une grande ´echelle grˆace au haut degr´e d’int´egration des circuits int´egr´es.

2. Le principal apport de cette th`ese dans l’acc´el´eration du calcul des filtres de rang a` l’aide des architectures reconfigurables est li´e au d´eveloppement d’un syst`eme de traitement original, ayant les caract´eristiques suivantes :

(a) Le syst`eme de traitement permet de travailler avec des voisinages dont la taille et la forme sont param´etrables. C’est un point important car on souhaite pouvoir adapter au mieux le type de filtre a` l’application donn´ee.

(b) Le syst`eme permet de calculer les filtres de n’importe quelle valeur de rang, ce qui donne l’acc`es a` une multitude des filtres diff´erents, utilis´es a` des fins diff´erentes.

(c) L’emploi des algorithmes en bit-s´erie permet de maximiser le nombre d’unit´es de traitements pour un circuit FPGA de haute densit´e ainsi que leur vitesse de fonctionnement. Ces deux points ont pour corollaire la possibilit´e d’un haut d´ebit des pixels trait´es, beaucoup plus important que celui obtenu avec des architectures universelles.

9 Chapitre 1. Introduction

1.3 Traitement

Traitement Machine ...we would like to recall that the present knowledge of the hu- man visual system indicates that it possesses nonlinear cha- racteristics. This should be taken into account in image filte- ring. Fundamentals of non linear digital filtering. Jakko Astola, Pauli Kuosmannen. Performance

1.3.1 Images et transformations

1.3.1.1 Notations

Une image num´erique monochromatique est un signal de luminosit´e bidimensionnel, dis- cret, pr´esent´e sous forme d’une matrice not´ee I[i, j] avec 0 i < Ix et 0 j < Iy. Pour ≤ ≤ des raisons de simplicit´e d’´ecriture, nous allons noter l’image sous forme d’un vecteur I[i], ou` chaque pixel est identifi´e par un seul indice i avec 0 i < NI et ou` NI = Ix Iy. ≤ ∗ On d´efinit le voisinage d’un pixel comme un ensemble de pixels qui se trouvent dans son entourage directe, dans un espace de forme rectangulaire. La taille de cette espace est d´efini par les distances Vx1, Vx2, Vy1 et Vy2 dans les quatre principales directions en partant du pixel consid´er´e (voir Figure 1.1). Comme pour l’image, le voisinage d’un pixel est pr´esent´e sous forme d’une matrice not´ee V [m, n]. Pour des raisons de simplicit´e d’´ecriture nous utiliserons un seul indice pour d´esigner un ´el´ement de ce voisinage : V [m] avec 0 m < NV et ou` ≤ NV = Vx Vy = (Vx + Vx + 1) (Vy + Vy + 1). ∗ 1 2 ∗ 1 2 Pour tous les ´el´ements du vecteur I, i.e. tous les pixels de l’image, dont l’indice i respecte la condition suivante :

i + n (Inx + Vx ) i i + n (Inx + Vx ) + Inx (1.1) 0 · 1 ≤ ≤ 0 · 1 ou` :

n 0, . . . , Iny ∈ { } i = Ix Vy + Vx 0 · 1 1 Inx = Ix (Vx + Vx ) − 1 2 Iny = Iy (Vy + Vy ) (1.2) − 1 2 on peut d´efinir un voisinage V , not´e Vi. Le parcours du vecteur I a` l’aide de l’indice i permet donc d’obtenir un voisinage V “glissant” sur l’image. Signalons que les pixels du vecteur I qui ne satisfont pas l’´equation 1.1 appartiennent au bord de l’image.

10 1.3. Traitement

On d´efinit une fenˆetre de l’image I comme une partie de cette image, de forme rectangulaire, not´ee sous forme d’une matrice F [k, l] avec 0 k < Fx, 0 l < Fy et ou` Fx, Fy d´esignent ≤ ≤ respectivement la taille horizontale et verticale de la fenˆetre. Pour une fenˆetre F et une image I nous avons toujours Fx Ix et Fy Iy. Tout comme pour l’image et le voisinage, une ≤ ≤ fenˆetre sera not´ee sous forme d’un vecteur F [k], avec 0 k < NF . ≤ L’image I est d´ecoup´ee en un ensemble de fenˆetres F qui pr´esentent un recouvrement de Vx1 + Vx2 et Vy1 + Vy2 pixels (voir Figure 1.1). Cet ensemble de fenˆetres permet d’acc´eder a` tous les voisinages Vi d´efinis par l’´equation 1.1.

La Figure 1.1 montre une image et deux fenˆetres successives de cette image (en trait pointill´e et en trait plein). Pour chaque fenˆetre on peut d´efinir (Fx Vx Vx ) (Fy Vy Vy ) − 1 − 2 ∗ − 1 − 2 voisinages : les pixels appartenant aux deux rectangles gris´es. Pour la premi`ere fenˆetre il s’agit du rectangle gris clair et pour la deuxi`eme fenˆetre du rectangle gris fonc´e. Un agrandissement de la premi`ere fenˆetre illustre deux voisinages successifs des pixels i (en trait plein) et i + 1 (en trait pointill´e).

Ix

Inx

V V x1 Fi x2 Fi+1

Fx

Iy Iny Vx1 Vx2

V Fy y1

Vy2

Vi Vi+1

Fig. 1.1: Notations utilis´ees pour l’image, la fenˆetre et le voisinage.

On consid`ere toutes les fenˆetres F d’une image I permettant de couvrir tous les pixels d´efinis par l’´equation 1.1. Comme en toute g´en´eralit´e nous avons :

Ix mod(Fx Vx ) = 0 − 2 6 Iy mod(Fy Vy ) = 0 (1.3) − 2  6 un certain recouvrement des fenˆetres aux extr´emit´es de l’image est n´ecessaire afin de couvrir tous les pixels indiqu´es.

11 Chapitre 1. Introduction

Dans le domaine spatial, le filtrage d’une image num´erique consiste a` appliquer un op´erateur de transformation de chaque pixel de l’image initiale I[i] en fonction des valeurs des pixels d´efinis dans le voisinage Vi. D’une mani`ere tout a` fait g´en´erale cette transformation est not´ee :

I˜ = T I, Vi , ou alors I˜(i) = T I(i), Vi (1.4) { } { } ou` I˜ repr´esente l’image r´esultante.

1.3.1.2 Transformations ponctuelles

Si le voisinage du pixel est nul, les transformations appliqu´ees sont alors dites ponctuelles (les op´erateurs de pixel). L’exemple type d’un tel traitement est le seuillage, couramment utilis´e pour s´eparer les objets de leur arri`ere plan. Un autre exemple sont les modifica- tions lin´eaires ou non-lin´eaires de l’histogramme qui peuvent ˆetre utilis´ees pour am´eliorer le contraste de l’image. De telles op´erations peuvent ˆetre r´ealis´ees a` l’aide de tables pr´e-calcul´ees avant le traitement, afin de limiter le temps de calcul exclusivement au temps d’acc`es a` la m´emoire.

1.3.1.3 Transformations spatiales

Si le voisinage Vi n’est pas nul, nous avons des transformations dites spatiales (les op´erateurs de voisinage), permettant de s’attaquer aux divers probl`emes habituellement rencontr´es dans le traitement des images num´eriques : la suppression du bruit, le rehaussement, la restauration, l’analyse morphologique et autres. La transformation doit ˆetre calcul´ee pour chaque voisinage en particulier, car pour les tailles habituelles de voisinage, a` savoir les voisinages carr´es de 3 3, 5 5 et 7 7 pixels et pour le nombre des niveaux diff´erents sur lesquels la luminosit´e d’un × × × pixel est quantifi´ee, les tables pr´e-calcul´ees d´epasseraient largement la limite des m´emoires actuelles.

Filtres lin´eaires et non-lin´eaires Il existe une analogie entre les transformations spatiales et la notion de filtrage d´efini par la th´eorie du traitement des signaux analogiques, unidimensionnels. Le filtrage y est d´efini comme une transformation du signal a` l’entr´ee par un syst`eme lin´eaire, invariant dans le temps7 : le filtre.

La notion de filtrage d’un signal unidimensionnel et continu peut ˆetre ´etendue aux signaux discrets, bi-dimensionnels, telles qu’une image num´erique. Dans ce cas l’op´eration de filtrage consiste a` calculer le produit de convolution entre l’image et la r´eponse impulsionnelle d’un filtre h, de taille Hx Hy : ×

Hx Hy I˜(x, y) = I(i, j) h(x i, y j) (1.5) ∗ − − i j X=0 X=0 7 Le syst`eme est lin´eaire si la transformation du signal a` l’entr´ee est lin´eaire : T (af1[t] + bf2[t]) = aT (f1[t])+ bT (f2[t]). Le syst`eme est invariant dans le temps si une translation dans le temps du signal a` l’entr´ee se traduira par une mˆeme translation dans le temps du signal de sortie.

12 1.3. Traitement

En fonction du type de filtre choisi, les diff´erents effets peuvent ˆetre obtenus : suppression des fortes transitions des niveaux de luminosit´e et apparition de flou ; ou justement le contraire : suppression de la composante continue dans l’image et mise en ´evidence des variations rapides.

Par opposition aux filtres lin´eaires ou` la valeur filtr´ee de l’image est obtenue par une combi- naison lin´eaire des pixels du voisinage, dans le filtrage non-lin´eaire cette valeur est obtenue sur base de l’information statistique de pixels voisins. Ainsi, chaque voisinage Vi est tri´e au pr´ealable, et la valeur filtr´ee est choisie sur base d’une fonction de rang.

Dans le cadre de cette th`ese nous allons nous limiter aux filtres non-lin´eaires pour des raisons suivantes : 1. La parall´elisation des filtres lin´eaires est un probl`eme d´ej`a largement ´etudi´e et leur impl´ementation dans les FPGAs est devenu une pratique courante (voir par exemple [CME93]). 2. La diversit´e des filtres non-lin´eaires est tr`es importante et leur application fr´equente pour un grand nombre des probl`emes en traitement des images, comme nous allons le voir par la suite. Pour certains d’entre eux ils se montrent extrˆemement efficaces, beaucoup plus efficaces que les filtres lin´eaires. 3. L’op´eration de tri est couteuseˆ malgr´e l’existence d’algorithmes rapides et la grande vitesse des architectures actuelles. En effet, le tri dans le voisinage, mˆeme d’une petite taille, doit ˆetre effectu´e pour tout pixel de l’image initiale, c’est a` dire de l’ordre du million de fois par image.

1.3.2 Filtres non-lin´eaires

1.3.2.1 Classification

Astola et Kuosmanen d´ecrivent dans [AK97], un grand nombre de filtres non-lin´eaires appliqu´es au traitement des images num´eriques et proposent deux taxinomies de ces filtres. La premi`ere introduit les classes suivantes : les filtres lin´eaires g´en´eralis´es, les filtres bas´es sur le tri, les filtres morphologiques et une classe “autre”. La deuxi`eme taxinomie est faite sur base de l’interpr´etation de filtre en tant qu’estimateur ou en tant que filtre g´eom´etrique (filtres morphologiques). Les deux auteurs soulignant qu’aucune des deux taxinomies ne pr´etend ˆetre compl`ete. En outre, ils ´emettent une r´eserve quant a` l’existence d’une taxinomie parfaite permettant de classer tous les filtres non-lin´eaires existants.

Comme nous nous int´eressons aux aspects de calcul de ces filtres, nous proposons ici une classification bas´ee sur la complexit´e des op´erations impliqu´ees. Nous d´efinissons alors deux classes des filtres non-lin´eaires : la Classe I et la Classe II.

Les filtres de la Classe I n´ecessitent toujours une op´eration de tri, sur un voisinage complet ou sur un ensemble de sous-voisinages. D’autres op´erations telles que la pond´eration, la s´election, le calcul de la valeur moyenne peuvent pr´ec´eder ou suivre l’op´eration de tri.

Les filtres de la Classe II ne doivent pas forcement impliquer un op´erateur de tri, mais peuvent impliquer le calcul de toute fonction non-lin´eaire imaginable.

13 Chapitre 1. Introduction

La Table 1.1 montre l’appartenance des diff´erents filtres non-lin´eaires d´ecrits dans [AK97] aux deux classes introduites.

Filtres non-lin´eaires Classe I Classe II Filtres de rang M´edians hybrides Filtres de rang s´electif Moyens tronqu´es M´edians a` multi-´etages Moyens non-lin´eaires Morphologiques Filtres L et C Filtres de piles Polynˆomiaux

Tab. 1.1: Classification des filtres non-lin´eaires

1.3.2.2 Filtres non-lin´eaires de Classe I

Filtres de rang et filtres pond´er´es de rang8 t Pour le calcul des filtres de rang on consid`ere un voisinage Vi , correspondant au voisinage Vi, tri´e par l’ordre croissant. Le pixel de l’image r´esultante I˜[i], pour un rang r correspond a` la r 1 valeur du vecteur V t : − i t I˜[i] = V [r 1], r [1, NV ], 0 i < NI (1.6) i − ∈ ≤

Les filtres particuli`erement int´eressants sont ceux d´etermin´es par les rangs : r = 1, r = NV et r = NV /2. Il s’agit des filtres minimum, maximum et m´edian not´es respectivement : min I , { } max I et med I . Les deux premiers filtres sont des op´erateurs de base permettant la { } { } construction des filtres morphologiques tandis que le filtre m´edian est le plus souvent utilis´e pour supprimer le bruit impulsionnel dans une image.

Les filtres pond´er´es de rang introduisent la possibilit´e de favoriser et/ou d´efavoriser certains pixels de voisinage Vi et ainsi palier au probl`eme des filtres m´edians classiques ayant tendance a` supprimer les petits d´etails de l’image. Le calcul de ces filtres implique la recherche de la valeur m´ediane d’un voisinage initial Vi transform´e : tous les ´el´ements de Vi ont ´et´e r´ep´et´es un certain nombre de fois. Le nombre de r´ep´etition de chaque ´el´ement de Vi est d´efini par le vecteur de poids P et l’op´erateur de r´ep´etition, not´e . ♦ Pour un vecteur de poids P et un voisinage Vi nous avons donc un nouvel ensemble :

P Vi = Vi[0], , Vi[0], . . . , Vi[NV 1], , Vi[NV 1] (1.7) ♦ { · · · − · · · − } p[0] fois p[N 1] fois V − Le filtre de rang pond´er´e peut| alors{z ˆetre }´ecrit comme| : {z }

I˜[i] = med P Vi , 0 i < NI (1.8) { ♦ } ≤ Filtre de rang s´electif Dans les filtres de rang classiques, le rang choisi est le mˆeme pour toute l’image. Or il est

8Dans la litt´erature anglo-saxonne Rank ordered et Weighted Rank Orderded Filters.

14 1.3. Traitement tout a` fait possible d’imaginer que le rang r soit variable pour chaque voisinage de l’image I. Dans ce cas, une fonction f des attributs A calcul´es sur le voisinage Vi d´etermine le rang qui sera d’application pour le voisinage en question :

t I˜[i] = V [f(A(Vi))], 0 i < NI (1.9) i ≤ Filtres m´edians a` plusieurs ´etages Ces filtres impliquent le calcul de la valeur m´ediane de plusieurs filtres m´edians r´ealis´es sur q sous-voisinages diff´erents, construits a` partir d’un voisinage Vi :

I˜[i] = med med Vi , , med Viq , 0 i < Ni (1.10) { { 1} · · · { }} ≤ Pour un voisinage de forme carr´ee, on d´efinit habituellement quatre sous-voisinages ´el´ementaires typiques : V1, V2, V3 et V4 (Figure 1.2) ainsi que leurs diff´erentes combinaisons, par exemple V V et V V . 1 ∪ 2 3 ∪ 4

V1 V3 V4

¨©  > &' 01 GHv QR [\ ef opu

¦§  = $% ./ EF OPw YZ cdt mn

¤¥243457698 < "# ,- CD MN WXsx ab kl

V2

¢£ ; ! *+ AB KLr UV _`y ij

¡ :  () ?@q IJ ST ]^ ghz

Fig. 1.2: Sous-voisinages types pour le calcul de filtre m´edian multi-´etage

Filtres moyens tronqu´es Les valeurs extrˆemes d’un voisinage tri´e peuvent jouer un rˆole important sur le r´esultat final du filtrage. Afin de d´efavoriser les pixels trop ´eloign´es de la valeur m´ediane, que l’on peut supposer moins significatifs, un filtre moyen tronqu´e calcule la moyenne d’un certain nombre t d’´el´ements du vecteur de voisinage tri´e Vi . Les diff´erentes fa¸cons de choisir ces ´el´ements vont donner naissance aux diverses variantes de ce filtre. Ainsi, le filtre (r,s) fold trimmed mean t filter fait exclusion des r premi`eres et s derni`eres valeurs du vecteur Vi :

NV s 1 − t I˜[i] = V [m], 0 i < NI (1.11) N r s i ≤ V m r − − X= +1 t t ou encore remplace les r premi`eres et s derni`eres valeurs par les valeurs V [r+1] et V [NV s] : i i − NV s 1 t − t t I˜[i] = (r V [r + 1] + V [m] + s V [NV s]), 0 i < NI (1.12) N ∗ i i ∗ i − ≤ V m r X= +1 Il est ´egalement possible de sp´ecifier un intervalle, born´e par des valeurs q1 et q2. Le filtre t t est alors calcul´e comme une moyenne de Vi uniquement pour des valeurs Vi [m] telles que t q1 < Vi [m] < q2 (filtre tronqu´e modifi´e). Une autre variante de ce filtre consiste a` calculer la moyenne des K ´el´ements les plus proches de l’´el´ement central de la suite Vi (filtre de K plus proches voisins).

Les filtres moyens tronqu´es permettent de combiner les effets positifs des filtres lin´eaires et non-lin´eaires et s’appliquent aux images pr´esentant a` la fois un bruit Gaussien et un bruit impulsionnel.

15 Chapitre 1. Introduction

Filtres morphologiques Les filtres morphologiques d´erivent de la morphologie math´ematique introduite par Mathe- ron et Serra en 1964[MS00] et dont l’application au traitement des images est d´ecrite dans deux ouvrages cl´es [Mat74, Ser82]. Initialement, la morphologie math´ematique ´etait destin´ee aux images binaires, mais son extension aux images en niveaux de gris futˆ rendue possible, grˆace a` l’´equivalence entre les notions ensemblistes et les fonctions (pour plus de d´etails voir [CC89] ou encore [Soi99]).

Les op´erateurs de base de la morphologie math´ematique sont dus a` Minkowski qui en 1903 d´efinit des op´erations ensemblistes d’addition (dilatation) et de soustraction (l’´erosion). On consid`ere une image binaire I comme un ensemble occup´e partiellement par un ensemble d’objets9 not´e X. On d´efinit alors les deux op´erateurs de base par la question : pour toute position p de l’espace de l’image I, est-ce que le voisinage10 V est enti`erement inclu dans l’ensemble X ou est-ce qu’il touche l’ensemble X ? L’ensemble de p des r´eponses positives forme l’image ´erod´ee/dilat´ee. De fa¸con un peu plus formelle :

Dilatation : I˜ = DIL I, V = I V = XV = p, Vp X = O { } ⊕ ∪ { ∩ 6 } Erosion´ : I˜ = ERO I, V = I V = XV = p, Vp X (1.13) { } ∩ { ⊆ } A partir des op´erateurs de base il est possible de d´efinir d’autres op´erateurs, notamment :

Ouverture : I V = (I V ) V ◦ ⊕ Fermeture : I V = (I V ) V • ⊕ Gradient morphologique : g(I, V ) = (I V ) (I V ) (1.14) ⊕ − ou` V repr´esente le voisinage transpos´e.

L’extension des op´erateurs morphologiques de base aux images en niveau de gris est d´efinie par la plus grande valeur de I dans le voisinage Vi et la plus petite valeur pour l’´erosion :

I˜ = DIL I, V = I V = sup I(u) : u V (1.15) { } ⊕ { ∈ } I˜ = ERO I, V = I V = inf I(u) : u V (1.16) { } { ∈ } Du point de vue du calcul, les deux op´erateurs ne sont donc rien d’autre que les deux filtres caract´eristiques de rang, mentionn´es plus haut. Nous avons donc : ERO V = min V = t t { } { } V [0] pour l’´erosion et DIL V = max V = V [NV 1] pour la dilatation. { } { } − 9Dans une image binaire, une valeur est attribu´ee au fond de l’image et l’autre aux objets qui s’y trouvent. 10En morphologie math´ematique le voisinage est appel´e l’´el´ement structurant. Comme nous d´efinissons les op´erateurs morphologiques comme une classe des filtres non-lin´eaires, d´efinis avec la notion de voisinage, nous avons pr´ef´er´e, par souci de clart´e, de garder l’appellation de voisinage. 10Le voisinage V d’un voisinage V est transpos´e par rapport au centre de celui-ci :

V V

Si le voisinage est sym´etrique par rapport a` son centre, on peut alors ´ecrire V = V .

16 1.3. Traitement

Les diff´erents filtres morphologiques classiques ne peuvent pas ˆetre utilis´es pour le filtrage du bruit dans une image. Cependant, les filtres morphologiques mous (Soft Morphological Filters), introduits par Kuosmanen dans [KA95] sont utilis´es pour une ´elimination tr`es efficace du bruit impulsionnel. Pour les op´erateurs mous de base, la notion de voisinage (de l’´el´ement structurant), est ´etendue au syst`eme structurant compos´e d’un voisinage V , d’un centre C d’une certaine forme et taille11 et d’un rang r. Les op´erateurs de base sont alors d´efinis comme :

DIL I, V = sup r♦Vm : m C Vm : m (V C) I˜[i] = { } {{ ∈ } ∪ { ∈ \ }} (1.17) ERO I, V = inf r♦Vm : m C Vm : m (V C) ( { } {{ ∈ } ∪ { ∈ \ }} avec ♦ l’op´erateur de r´ep´etition d´efini a` l’´equation 1.7.

A partir des op´erateurs de base on peut d´efinir les mˆemes op´erateurs d´eriv´es de la morphologie math´ematique classique tels que l ’ouverture, la fermeture et autres.

Filtres de piles Il est possible de d´efinir toute une nouvelle classe des filtres non-lin´eaires grˆace a` un codage des images particulier. Ce codage, d´esign´e dans la litt´erature anglo-saxonne par threshold decomposition, consiste a` transformer chaque pixel de l’image initiale I[i] en un vecteur binaire P [o] de 2b bits, ou` b repr´esente le nombre de bits utilis´es pour coder la couleur. Les ´el´ements de ce vecteur sont d´etermin´es selon l’expression suivante :

1, I[i] o P [o] = ≥ , 0 o < 2b (1.18) (0, I[i] < o ≤

b Pour un voisinage V transform´e, not´e V¨ , nous avons donc 2 plans de bits de NV bits chacun, not´es V¨ [o]. Notons que l’image n’a subi aucune transformation de contenu de l’information, il s’agit tout simplement d’une autre repr´esentation de la mˆeme information.

Le filtre g´en´eralis´e de piles consiste a` appliquer a` chaque plan de bits une fonction Bool´eenne positive12dans la litt´erature anglo-saxonne Positive Boolean Function ou PBF qui satisfait la propri´et´e de piles :

si f(V¨ [k]) = 1 (1.19) alors f(V¨ [o]) = 1 o k ∀ ≤ Pour chacun des 2b niveaux nous allons obtenir une valeur binaire. La somme alg´ebrique de 2b bits ainsi obtenus donne la valeur du voisinage filtr´e.

Les filtres minimum et maximum poss`edent la propri´et´e des piles et il est possible de les calculer en employant les fonctions logiques ET et OU sur le V¨ [o]. Le filtre m´edian poss`ede ´egalement cette propri´et´e, avec comme fonction Bool´eenne la m´ediane binaire (MED)13.

11En fait le centre est aussi un voisinage du pixel central, plus petit que V , nous avons donc toujours C ⊂ V . Lorsque C = 0, le centre est le pixel central lui-mˆeme. 12Une fonction Bool´eenne positive est une fonction qui peut ˆetre ´ecrite sous forme d’une expression compos´ee de variables non-complem´ent´ees. 13Une fonction Bool´eenne binaire qui renvoie la valeur m´ediane d’un vecteur tri´e des ´el´ements binaires, par exemple MED0, 0, 1, 1, 1 = 1.

17 Chapitre 1. Introduction

La Figure 1.3 montre un exemple de calcul des filtres de rang classiques a` l’aide des filtres de piles. Examinons les vecteurs V¨ [o] d’un voisinage V initialement compos´e des valeurs 1, 5, 3, 7, 3, 9, 5, 9, 1 . Le voisinage tri´e et d´ecompos´e V¨ t est alors pr´esent´e sous la forme d’un { } tableau.

r V t V¨ [0] V¨ [1] V¨ [2] V¨ [3] V¨ [4] V¨ [5] V¨ [6] V¨ [7] V¨ [8] min → 1 1 1 0 0 0 0 0 0 0 0 2 1 1 0 0 0 0 0 0 0 0 3 3 1 1 1 0 0 0 0 0 0 4 3 1 1 1 0 0 0 0 0 0 med → 5 5 1 1 1 1 1 0 0 0 0 6 5 1 1 1 1 1 0 0 0 0 7 7 1 1 1 1 1 1 1 0 0 8 9 1 1 1 1 1 1 1 1 1 max → 9 9 1 1 1 1 1 1 1 1 1

min ET 1 1 0 0 0 0 0 0 0 0 med MED 5 1 1 1 1 1 0 0 0 0 max OU 9 1 1 1 1 1 1 1 1 1

Fig. 1.3: Filtres de piles

Depuis la table, on peut ais´ement voir comment l’application des fonctions logiques ET, MED et OU conduit au calcul de minima/median/maxima du voisinage.

1.3.2.3 Filtres non-lin´eaires de Classe II

Filtre m´edian hybride Il est possible de combiner les avantages des filtres lin´eaires et non-lin´eaires dans un seul filtre qui s’attaquera a` la fois au bruit impulsionnel et au bruit Gaussien d’une image. Un filtre m´edian hybride implique le calcul de q filtres lin´eaires fil sur le voisinage Vi avant l’application d’un filtre m´edian :

I˜[i] = med fil Vi , , filq Vi , 0 i < NI (1.20) { 1{ } · · · { }} ≤

Si le nombre q de filtres lin´eaires appliqu´es est faible devant la taille du voisinage NV , l’impl´ementation d’un tel filtre peut se faire de mani`ere efficace puisque la recherche de la valeur m´ediane n’implique pas le tri du voisinage complet.

Filtres moyens non-lin´eaires La forme g´en´erale d’un filtre moyen non-lin´eaire est donn´ee par :

NV 1 1 m=0− P [m] g(Vi[m]) I˜[i] = g− ∗ (1.21) NV 1 P m=0− P [m] ! 18 P 1.3. Traitement ou` P est le vecteur des poids et g est une fonction. Dans le traitement des images les fonctions g le plus souvent employ´ees sont :

x , moyenne arithm´etique log x , moyenne g´eom´etrique g(x) = (1.22)  1  x , moyenne harmonique  p x R 1, 0, 1 , filtre moyen Lp.  ∈ \{− }  Les moyennes arithm´etiqueet g´eom´etrique sont largement utilis´ees pour combattre le bruit Gaussien, tandis que la moyenne harmonique et le filtre moyen Lp sont plutˆot utilis´es pour le filtrage du bruit impulsionnel.

Filtres polynˆomiaux La forme g´en´erale d’un filtre polynˆomial d’ordre M est donn´ee par :

N 1 N 1 N 1 V − V − V − I˜[i] = h (i )V [NV i ] + . . . + . . . hM (i , . . . , iM )V [NV i ] . . . V [NV iM ] 1 1 − 1 1 − 1 − i i i X1=0 X1=0 MX=0 (1.23) ou` les fonctions hj(i1, . . . , ij), 0 < j < M sont les kernels de Volterra. Les filtres polynˆomiaux sont caract´eris´es par un important accroissement du temps de calcul pour les ordres sup´erieurs, la raison pour laquelle ils ne sont employ´es que tr`es rarement dans le traitement des images. N´eanmoins signalons que les filtres d’ordres inf´erieurs ont ´et´e utilis´es avec succ`es pour la r´eduction du bruit des images faiblement contrast´ees [RS95], l’am´elioration de la nettet´e [Ram95], la restauration [JBH95] et l’am´elioration d’images num´eriques [BMM97].

Filtres L L’un des principaux inconv´enients des filtres m´edians classiques concerne le d´eplacement des bords et l’apparition des artefacts [Bov87]. Les filtres L permettent de palier ce probl`eme en combinant les effets d’un filtrage lin´eaire et non-lin´eaire. Ils consistent a` calculer la moyenne t des ´el´ements du vecteur tri´e Vi , pond´er´es par un vecteur des poids P :

NV I˜[i] = P [m] V t[m] (1.24) ∗ i m=1 X Filtres C L’information spatiale de chaque pixel n’intervient pas dans le calcul des filtres de rang. Deux voisinages compl`etement diff´erents peuvent avoir le mˆeme vecteur de voisinage tri´e et par cons´equence le mˆeme r´esultat de filtrage. L’exclusion de l’information spatiale se traduit par une perte de l’information visuelle des petits d´etails de l’image. Les filtres C peuvent ˆetre consid´er´es comme des filtres L mais a` la place d’un simple vecteur des poids, on dispose d’une matrice. Le choix des poids utilis´es pour la pond´eration de chaque pixel de V est fonction du rang et de sa position spatiale au sein du voisinage. On peut alors ´ecrire :

N 1 V − I˜[i] = P [R(Vi[m]), m] Vi (1.25) ∗ m=0 X i ou P repr´esente la matrice des poids et R(V [m]) le rang de la valeur Vi[m] du voisinage V .

19 Chapitre 1. Introduction

1.3.2.4 Exemples d’application des filtres non-lin´eaires

La Figure 1.4 montre le r´esultat suite a` l’application d’un filtre lin´eaire et un filtre non- lin´eaire sur une image pr´esentant un bruit impulsionnel. A l’image bruit´ee de la Figure 1.4.a ont ´et´e appliqu´es : – un filtre lin´eaire classique : la moyenne d’un voisinage de 5 5 pixels - Figure 1.4.b, × – suivi d’un filtre m´edian de mˆeme taille - Figure 1.4.c La Figure 1.4.d montre une zone d’int´erˆet agrandie et riche en d´etails : on peut remarquer sur les deux images filtr´ees une perte de d´etails (la texture de tissu), plus importante dans le cas d’un filtre m´edian.

a) b)

c) d)

Fig. 1.4: Elimination´ de bruit impulsionnel : filtre lin´eaire (moyenne) et filtre m´edian 20 1.3. Traitement

La Figure 1.5 montre qu’il est possible d’arriver a` un r´esultat de filtrage semblable avec des filtres morphologiques mous. La mˆeme image de l’exemple pr´ec´edant - Figure 1.5.a, a ´et´e soumis : – a` une ouverture classique avec un voisinage de 5 5 pixels - Figure 1.5.b. × – et puis a` une ouverture “molle”, aussi sur un voisinage 5 5 avec un centre C de rayon × z´ero et le rang r = 5 - Figure 1.5.c L’agrandissement d’une zone d’int´erˆet - la Figure 1.5.d, montre une plus mauvaise conserva- tion de d´etails par rapport au filtrage m´edian.

a) b)

c) d)

Fig. 1.5: Elimination´ de bruit impulsionnel : filtres morphologiques mous

21 Chapitre 1. Introduction

La Figure 1.6 montre l’application a` l’image initiale - Figure 1.6.a d’un gradient mor- phologique - Figure 1.6.b. Les op´erations morphologiques : la dilatation et l’´erosion ont ´et´e calcul´ees avec des voisinages de taille 5 5 pixels. ×

a) b)

Fig. 1.6: Gradient morphologique

22 1.4. Machine

1.4 Machine

Ordinateur - Calculateur ´electronique dot´e de m´emoires a` grande capacit´e, de moyens de traitement des informa- tions a` grande vitesse, capable de r´esoudre des probl`emes Traitement Machine arithm´etiques et logiques complexes grˆace a` l’exploitation au- tomatique des programmes enregistr´es. Dictionnaire Robert.

Computer architecture - The attributes of a [computing] system as seen by the programmer, i. e. the conceptual struc- Performance ture and functional behavior, as distinct from the organization of the data flows and controls, the logic design, and the phy- sical implementation. Amdahl, Blaaw, et Brooks, 1964

1.4.1 Historique

L’histoire des machines permettant de r´ealiser le calcul de fa¸con automatis´ee peut ˆetre divis´ee en trois p´eriodes remarquables. Les premi`eres machines a` calculer m´ecaniques capables de r´ealiser des op´erations arithm´etiques simples, ont ´et´e d´evelopp´ees lors la premi`ere p´eriode remarquable, situ´ee entre le d´ebut de XVI-`eme et la fin de XIX-`eme si`ecle. Dans la deuxi`eme p´eriode, qui couvre la premi`ere moiti´e du XX-`eme si`ecle, les grandes d´ecouvertes li´ees aux math´ematiques et a` la logique ont permis de poser les bases th´eoriques de l’informatique. D`es les ann´ees quarante, plusieurs machines construites, dites de la premi`ere g´en´eration des ordinateurs, marquent le d´ebut de la troisi`eme p´eriode remarquable qui s’´etend jusqu’`a nos jours.

La premi`ere machine m´ecanique a` calculer14 futˆ construite par John Napier, math´ematicien ´ecossais qui au d´ebut de XVI-`eme si`ecle (probablement vers 1610) construit les r`egles (dites de Napier), permettant d’effectuer les op´erations arithm´etiques de multiplication, de division et de racine carr´ee. En 1623, ind´ependamment de Napier, un autre “calculateur num´erique” m´ecanique futˆ introduit par Wilhelm Schickard, dont la connaissance nous est parvenue uniquement par ces ´ecrits avec Kepler. Le seul exemplaire de cette machine a` ´et´e brulˆ ´e en 1624, dans un incendie, probablement volontaire, afin de prot´eger son auteur des accusations d’actes de sorcellerie.

Ind´ependamment de Napier et de Schickard, Blaise Pascal construit en 1643 la Pas- caline, un autre calculateur num´erique capable d’additionner et de soustraire les nombres a` plusieurs chiffres avec un report automatique. Quelques ann´ees plus tard, en 1673, Gott- fried Leibniz con¸coit une machine qui effectue les quatre op´erations arithm´etiques de base a` l’aide des engrenages. Sa machine r´ealise pour la premi`ere fois la multiplication comme l’ad- dition successive dans un accumulateur. Leibniz soul`eve ´egalement l’id´ee de l’existence d’un proc´ed´e universel permettant de trouver une solution a` tout probl`eme de fa¸con m´ecanique, par le calcul et sans “r´efl´echir”.

14Quoique en Chine, depuis 1300, on utilise couramment l’abacus pour effectuer les calculs arithm´etiques. Les origines de ce “calculateur” remontent aux Babyloniens - 500 AJC.

23 Chapitre 1. Introduction

En 1801, Joseph-Marie Jacquard con¸coit une machine de tissage programmable par des cartes perfor´ees contenant l’information du motif. Plus tard, en 1822, Charles Bab- bage travaille sur la r´ealisation de la “Machine Diff´erentielle” et de la “Machine Analy- tique”, mais aucune de ces machines ne fonctionna correctement. A cette mˆeme ´epoque on constate la premi`ere commercialisation d’un calculateur num´erique - l’arithmom`etre de Tho- mas, construit par Charles Xavier Thomas de Colmar. Ce calculateur futˆ vendu en quelques centaines d’exemplaires entre 1821 et 1878[Mar94].

La fin de XIX-`eme et le passage au XX-`eme si`ecle marquent le d´ebut de la deuxi`eme p´eriode remarquable et la reprise des id´ees de Leibniz sur la recherche des proc´ed´es permettant une automatisation de calcul. La reprise de ces id´ees trouve ses racines dans la volont´e des math´ematiciens de formaliser les math´ematiques de fa¸con a` ´eviter tout paradoxe qu’elles pour- raient engendrer, notamment ceux relev´es par Cesare Burali-Forti (1899) et Bertrand Russell (1901) de la th´eorie des ensembles, formul´ee par Georg Ferdinand Cantor15 d`es 1874.

L’id´ee d’une formalisation compl`ete des math´ematiques culmine avec le math´ematicien David Hilbert qui est a` l’origine d’un programme dans lequel toute d´emonstration serait purement syntaxique, d´epourvu de son sens s´emantique. En outre, toute d´emonstration peut ˆetre ramen´e a` un proc´ed´e, une proc´edure effective i.e. un algorithme16, qui d´ecrit seulement l’ordre de manipulation des symboles.

Le programme de Hilbert17 vise la recherche d’un syst`eme formel18 ainsi qu’une th´eorie de d´emonstration tels qu’il serait possible de : 1. Prouver la consistance19 2. R´epondre aux questions de compl´etude20 3. R´esoudre le probl`eme de d´ecision (Entscheidungsproblem)21. Le th´eor`eme de compl´etude, d´emontr´e par Kurt Godel¨ en 1928, r´epond positivement aux deux premi`eres questions pour la logique du premier ordre. Au sein de ce syst`eme formel, il est donc possible de m´ecaniser toute d´emonstration.

15Le paradoxe de Russell concerne la question de la taille d’un ensemble universel. Pour un tel ensemble a` la question : “quelque chose se trouve-t-il dans l’ensemble universel ?”, nous avons toujours une r´eponse positive. Selon Cantor la taille d’un ensemble compos´e de tous les sous-ensembles d’un ensemble donn´e est toujours plus grande que la taille de l’ensemble mˆeme. Or, ceci ne peut ˆetre appliquer sur l’ensemble universel car il contient d´ej`a tout ! 16En 820 AD, Muhammed idn Musa Al-Khwarizmi, ´ecrit une encyclop´edie des proc´ed´es de calcul connus de son temps. A l’´epoque m´edi´evale cet ouvrage futˆ diffus´e dans le monde entier et son nom futˆ latinis´e en algorithmus, pour ˆetre repris au XIX-`eme si`ecle par Lady Ada Lovelace pour designer l’ensemble des r`egles op´eratoires propres a` un calcul. 17On peut consulter l’excellent ouvrage [CN01] sur la vie et le programme de Hilbert. 18Un ensemble d’axiomes et de r`egles d’inf´erences. 19La question de la consistance a ´et´e soulev´e par Hilbert pour la premi`ere fois en 1900, lors de son dis- cours au Congr`es International des Math´ematiciens a` Paris[Hil02] et peut ˆetre ´enonc´e comme suit : Certains raisonnements valides peuvent-ils conduire vers des absurdit´es ? 20Tout ´enonc´e peut-il ˆetre soit prouv´e soit r´efut´e ? 21Le probl`eme de d´ecision a ´et´e formul´e par Hilbert et Ackermann dans [HA28] et peut ˆetre ´enonc´e comme suit : Existe-il une proc´edure effective (i.e. algorithme), qui, en un nombre fini d’op´erations, permet de dire si un ´enonc´e math´ematique est vrai ou faux ?

24 1.4. Machine

Mais en 1931 avec le c´el`ebre th´eor`eme d’incompl´etude, Godel¨ d´emontre que d`es que l’on fait intervenir dans un syst`eme formel l’arithm´etique, mˆeme ´el´ementaire, il existe des propositions ind´ecidables : on ne peut donc pas trouver une proc´edure effective permettant de dire si ces propositions sont vraies ou fausses. Ce r´esultat r´efute d´efinitivement le programme d’ Hilbert et l’id´ee m´ecaniste des math´ematiques.

Quant a` la question du probl`eme de d´ecision, une r´eponse n´egative a ´et´e donn´ee par les mod`eles abstraits de calcul d´evelopp´ees dans les ann´ees ’30 - les fonctions r´ecursives et le λ- calcul. En 1936, Alan Turing apporte ´egalement une r´eponse n´egative a` ce probl`eme avec le c´el`ebre article “On computable numbers, with an application to the Entscheidungsproblem”. Dans cet article il d´ecrit les concepts d’une machine universelle - la machine de Turing et il d´emontre qu’une telle machine ne peut r´esoudre le probl`eme d’arrˆet (Halting Problem)22.

A cette ´epoque des importantes avanc´ees th´eoriques, on constate ´egalement la r´ealisation des premiers circuits ´el´ementaires n´ecessaires pour une mat´erialisation des concepts th´eoriques. Ainsi le premier additionneur d’un bit a` ´et´e construit a` l’aide de relais en 1937 par George Stibitz. Deux ans plus tard, John V. Attanassoff construit le premier additionneur des mots de 16 bits enti`erement ´electronique (`a tubes) et en 1941 ach`eve la construction d’une machine permettant de r´esoudre un syst`eme de 29 ´equations.

Le d´ebut de la troisi`eme p´eriode remarquable, celle qui va donner naissance aux ordinateurs de la premi`ere g´en´eration, est li´e a` la construction de deux calculateurs universelles (calculateurs contrˆol´es par un programme) en 1943. Le premier, Automatic Sequence Controlled Calculator - ASCC, plus connu sur le nom de Harvard Mark 1 futˆ construit par Howard Aiken de l’Universit´e de Harvard en collaboration avec IBM. Ce calculateur, bas´e sur des technologies mixtes : ´electriques et m´ecaniques, pouvait r´ealiser des op´erations arithm´etiques et calculer des fonctions logarithmiques et trigonom´etriques. Le deuxi`eme, Colossus, a ´et´e construit en Angleterre par Turing dans le but d’automatiser le d´ecryptage des messages cod´es par les Allemands dans la deuxi`eme guerre mondiale.

Trois ans plus tard, la construction d’un autre calculateur universel, nom´e Electronic Numeri- cal Integrator and Computer - ENIAC futˆ achev´ee a` la Moore School of Electrical Engineering par John Mauchly et Presper Eckert. D`es 1944, le nouveau collaborateur de cette ´equipe est John Von Neumann, qui en 1945 d´ecrit, dans un rapport intitul´e ”The first draft of a Report on the Electronic Discrete Variable Automatic Computer - EDVAC”, une machine algorithmique universelle a` programme enregistr´e, donc un ordinateur, et les principes de son exploitation23. Dans cette description un ordinateur est compos´e : d’une unit´e de traitement (UT) et d’une unit´e de contrˆole (UC)24, de la m´emoire (M) et des unit´es d’entr´ee et de sor- tie. L’unit´e de traitement ex´ecute les instructions (i.e. le programme), ´emises par l’unit´e de contrˆole, sur les donn´ees ´el´ementaires. Les instructions ainsi que les donn´ees sur lesquelles elles agissent se trouvent dans la mˆeme m´emoire. L’ex´ecution de chaque instruction passe par plusieurs ´etapes : recherche de l’instruction, le d´ecodage et l’ex´ecution proprement dit (le cycle fetch-decode-execute). Les descriptions mat´erielle et logicielle d´efinissent ce que l’on

22Est-il possible de pr´evoir l’arrˆet d’un algorithme particulier. 23Mˆeme si ce rapport porte la signature exclusive de Von Neumann, les principaux r´esultats d´ecrits sont dus ´egalement a` Eckert et Mauchly. Par ailleurs, l’id´ee du programme enregistr´e dans la m´emoire du syst`eme a d´ej`a ´et´e ´elabor´ee par Eckert en 1944[McC01]. 24Dans le texte original Central Arithmetical part - CA et Central Control part - CC.

25 Chapitre 1. Introduction appelle habituellement l’architecture de Von Neumann.

EDVAC futˆ r´ealis´e seulement en 1952, bien apr`es quelques autres machines qui se disputent le titre de premier ordinateur r´ealis´e. Ainsi, en janvier 1948, le Selective Sequence Electronic Calculator - SSEC est achev´e par Wallace Eckert (IBM). Cette machine pouvait lire des instructions sur une bande en papier (Machine de Turing !) voire mˆeme en m´emoire, r´ealis´ee a` l’aide des relais. Quelque mois plus tard, en juin 1948, le Small Scale Experimental Machine - SSEM futˆ construite a` l’universit´e de Manchester. Elle ´etait capable d’ex´ecuter un programme charg´e en m´emoire, construite au tour des ´ecrans a` tubes cathodiques dont un point allum´e repr´esentait un bit d’information sauvegard´ee. Enfin le troisi`eme : Electronic Delay Storage Automatic Computer - EDSAC, fortement inspir´e de l’EDVAC, a ´et´e r´ealis´e en 1949 par Maurice Wilkes de l’Universit´e de Cambridge.

En 1953, on compte dans le monde entier une centaine d’ordinateurs de premi`ere g´en´eration. Ce chiffre va atteindre en 1995 [JPJ96] plus de 257 millions. Il est g´en´eralement admis que dans cet intervalle de temps l’´evolution des ordinateurs a travers´e cinq g´en´erations distinctes.

La deuxi`eme g´en´eration des ordinateurs (1956-1967)25 est caract´eris´e par un important chan- gement technologique. Les tubes ´electroniques et les relais ´electro-m´ecaniques utilis´es dans la premi`ere g´en´eration ont ´et´e remplac´es par des transistors, beaucoup plus fiables et d’un temps de commutation plus faible. Les syst`emes deviennent de plus en plus robustes et ra- pides. Le calcul en virgule flottante n’est plus r´ealis´e par des sous-routines mais par des unit´es mat´erielles sp´ecifiques. Dans cette ´epoque on remarque ´egalement l’apparition des premiers langages de programmation : Fortran en 1956, Algol en 1958 et Cobol en 1959.

La g´en´eration suivante (1967-1978) est marqu´ee par un nouveau changement technologique : l’introduction des circuits int´egr´es a` faible et moyen degr´e d’int´egration de quelque dizaines voir des centaines des transistors par circuit. La r´ealisation des circuits int´egr´es de plus en plus denses a permis la r´ealisation de premier processeur26, Intel 4004, en 1971. La notion de pipeline est introduite pour les diff´erentes ´etapes d’ex´ecution des instructions et l’unit´e de contrˆole n’est plus cˆabl´ee mais micro-programm´ee. Entre 1969 et 1973, nous avons le d´eveloppement du langage C [Sec93] et de syst`eme d’exploitation UNIX.

La quatri`eme g´en´eration(1978-1988) des architectures informatiques est bas´ee sur des circuits int´egr´es de type LSI et VLSI (Large et Very Large Scale of Integration) ayant entre 1.000 et 100.000 transistors. Dans cette g´en´eration on voit apparaˆıtre les premiers ordinateurs person- nels, d’un prix abordable et destin´es donc aux grand public.

Les ordinateurs de la cinqui`eme g´en´eration (1988-1995) sont caract´eris´es par l’emploi des circuits ULSI (Ultra Large Scale of Integration) a` plus d’un million de transistors par puce. On constate ´egalement l’apparition des syst`emes parall`eles d’une centaine de processeurs et le d´eveloppement des ordinateurs permettant un parall´elisme extensible. Un autre aspect du d´eveloppement des architectures informatiques est li´e au d´eveloppement des r´eseaux informa- tiques, de plus en plus performants en terme de d´ebit de transmission, permettant un calcul distribu´e. 25On ne peut pas parler des dates pr´ecises de d´ebut et de fin de chaque g´en´eration. Les dates, repris de [HZ98], sont cit´ees dans le but de mieux situer les diff´erentes g´en´erations dans le temps. 26Le terme processeur sera utilis´e pour designer un circuit int´egr´e complexe dot´e de plusieurs unit´es de contrˆole, d’une ou plusieurs unit´e(s) de traitement et ´eventuellement de la m´emoire.

26 1.4. Machine

Aujourd’hui, nous sommes a` la sixi`eme g´en´eration des ordinateurs dont les caract´eristiques essentiels sont li´ees a` la conception et a` l’exploitation des syst`emes informatiques massivement parall`eles. La quantit´e des op´erations ex´ecut´ees par une seule machine sont actuellement mesur´es par des teraflops (1012 op´erations en virgule flottante par seconde).

1.4.2 Classification des architectures

La description des diff´erentes g´en´erations d’ordinateurs introduit d´ej`a une premi`ere classi- fication des architectures se basant sur le crit`ere des grandes changements technologiques. Ce crit`ere est cependant insuffisant lorsqu’il s’agit d’´etudier toutes les architectures d’ordinateurs possibles. Plusieurs taxinomies tentent a` syst´ematiser la classification des diff´erentes archi- tectures existantes et ´etudier les architectures possibles ind´ependamment de la technologie. Signalons toutefois qu’aucune de ces taxinomies n’est parfaite, car il est tr`es difficile d’isoler des crit`eres pertinents permettant une classification compl`ete.

1.4.2.1 Taxinomies des architectures universelles

Taxinomie selon Flynn La classification des architectures la plus couramment utilis´ee, celle de Flynn pr´esent´ee dans [Fly72], est bas´ee sur le nombre d’occurrences d’instructions et de donn´ees ´el´ementaires (mots d’information) a` chaque pas d’ex´ecution. Il est alors possible d’introduire quatre classes d’ar- chitectures diff´erentes :

SISD (Single Instruction Single Data) est caract´eris´ee par une seule unit´e de traitement et un seul espace m´emoire. Une unit´e de contrˆole unique (un g´en´erateur d’instructions) ´emet un flux d’instructions qui est appliqu´e a` un flux de donn´ees. Une instruction ´el´ementaire est ex´ecut´ee sur une donn´ee ´el´ementaire a` la fois. Si l’on admet l’analogie entre le couple instruction - donn´ee et le couple fonction - argument, pour une architecture SISD on peut alors ´ecrire : y = f(x).

SIMD (Single Instruction Multiple Data) sont des architectures a` multiples unit´es de traite- ment qui appliquent le mˆeme flux d’instructions aux diff´erents flux de donn´ees : →−y = f(→−x ). MISD (Multiple Instruction Single Data) implique ´egalement l’existence de plusieurs unit´es de traitement, mais chaque unit´e dispose de son propre g´en´erateur d’instructions qui agit sur le mˆeme flux de donn´ees :→−y = →−f (x). MIMD (Multiple Instruction Multiple Data) permet l’ex´ecution simultan´ee de diff´erents flux d’instructions sur diff´erents flux de donn´ees : →−y = →−f (→−x ). Taxonomie selon Skillicorn L’approche de Skillicorn a` la taxinomie des diff´erentes architectures informatiques [Ski85] se base plutˆot sur le crit`ere mat´eriel et le nombre d’occurrences des diff´erentes unit´es fonc- tionnelles : – le nombre d’unit´es de contrˆole, des m´emoires associ´ees et de connexions, – le nombre d’unit´es de traitement, des m´emoires associ´ees et de connexions

27 Chapitre 1. Introduction ainsi que sur le type de connexions entre les unit´es de contrˆole et les unit´es de traitement et les unit´es de traitement mˆemes. Le nombre d’occurrences peut ˆetre nul, unitaire ou ´egale a` n.

En consid´erant les diff´erentes unit´es fonctionnelles et leur nombre d’occurrences, il est possible d’´enoncer toutes les architectures possibles de fa¸con purement combinatoire. Il existe cepen- dant des combinaisons non permises car certaines unit´es fonctionnelles doivent exister pour qu’une architecture ait un sens. Ainsi il faut qu’il y ait au moins une unit´e de traitement, une m´emoire et une connexion entre les deux. En ´eliminant toutes les combinaisons non-permises, Skillicorn parvient a` d´efinir 28 architectures diff´erentes possibles.

Taxonomie selon Duncan La classification selon Duncan propos´ee dans [Dun90] ne se concentre que sur des archi- tectures parall`eles27 qu’elle divise en trois classes : architectures synchrones, MIMD et le paradigme MIMD (Figure 1.7). Cette classification permet d’introduire un nombre important de nouvelles architectures, omises dans les deux taxinomies d´ecrites pr´ec´edemment.

Architectures parall`eles

Synchrone MIMD Paradigme MIMD

Vecteur SIMD Systolique M´emoire partag´ee M´emoire distribu´ee MIMD/SIMD Data Flow Reduction

Processor Array M´emoires associatives

Fig. 1.7: Classification selon Duncan

Architectures vectorielles On appelle les architectures vectorielles des ordinateurs qui exploitent les processeurs vecto- riels. Un processeur vectoriel poss`ede plusieurs unit´es de traitement dispos´ees en s´erie. Une donn´ee ´el´ementaire (une op´erande) n’est plus un simple mot d’information mais bien un vecteur compos´e d’un nombre fixe d’´el´ements.

Array des processeur Ce type d’architecture correspond au concept SIMD de calcul au sens de Flynn : le mˆeme flux d’instructions est ex´ecut´e par un ensemble d’unit´es de traitement sur des donn´ees diff´erentes. L’architecture de l’unit´e de traitement peut ˆetre a` plusieurs ou a` un seul bit, comme par exemple la Connection Machine dot´ee de pas moins de 65536 processeurs d’un bit [Shi96].

27Cette taxinomie fait distinction entre les machines qui utilisent le parall´elisme de bas niveau : pipeline des instructions, multiples unit´es arithm´etiques logiques au sein d’un mˆeme unit´e de traitement etc. et les architectures proprement dites en tant que machines autonomes.

28 1.4. Machine

M´emoires/processeurs associatifs La composante principale d’un processeur associatif est une m´emoire associative invent´ee par Slade and McMahon en 1956 [SM56]. Par opposition a` une m´emoire conventionnelle ou chaque mot d’information est acc´ed´e par le biais d’une adresse unique, dans une m´emoire associative l’acc`es parall`ele a` un ensemble de mots est fait par le contenu. Un mot d’infor- mation que l’on souhaite retrouv´e dans une m´emoire associative est compar´e avec le contenu de la m´emoire enti`ere, ou seulement d’une partie, d´efinie par un masque de recherche. Les adresses qui contiennent le mot de l’information recherch´e, ou ´eventuellement une portion de ce mot si l’on travaille avec un registre de masque du mot recherch´e, seront valid´ees et lues. En ajoutant a` chaque mot d’une telle m´emoire une unit´e de traitement, on obtient alors une architecture de type SIMD capable de r´ealiser des calculs d’un parall´elisme massif.

La Figure 1.8 montre l’exemple d’une m´emoire associative. Une partie de mot 00111 est masqu´ee avec le mots 10011 et le mot r´esultant (0–11) est recherch´e dans la m´emoire. Certains mots de la m´emoire sont s´electionn´es par un masque de m´emoire (les cellules gris clair). Les unit´es de traitement vont travailler sur les mots trouv´es dans la m´emoire (les cellules gris fonc´e).

Mot 0 0 1 1 1

Masque 1 0 0 1 1

Donnée 0 - - 1 1

0 0 0 0 1 1

1 1 0 0 0 1

1 0 1 1 1 1

0 1 1 1 1 1

1 1 1 0 1 1

1 0 0 1 1 1

0 0 0 1 1 1

1 0 1 0 1 1

0 0 0 0 1 1

Masque de Mémoire UT la mémoire

Mots masqués de mémoire Mots de mémoire sélectionnés

Fig. 1.8: M´emoire associative

Quelques exemples d’algorithmes destin´es a` ce type d’architectures peuvent ˆetre trouv´es dans [FE63] et [Fet95]. Malheureusement de telles architectures ne sont pas beaucoup ex- ploit´ees, principalement a` cause de la quantit´e des ressources mat´erielles n´ecessaires pour leur r´ealisation. Il faut cependant noter que le concept de la m´emoire associative est couramment utilis´e dans la r´ealisation des m´emoires caches.

Architectures systoliques La architectures systoliques, introduites par Kung et Leiserson dans [KL78] sont des r´eseaux d’unit´es de traitement (processeurs) identiques qui re¸coivent, calculent et ´echangent des donn´ees de fa¸con synchrone a` travers un r´eseau d’interconnexions r´egulier. Elles doivent leur

29 Chapitre 1. Introduction nom a` l’analogie que l’on peut tirer entre le sang et les donn´ees. La phase de diastole, ou` le sang est amen´e dans le coeur, correspond a` la r´eception et la distribution de donn´ees. La phase de systole, lorsque le sang est chass´e dans les art`eres, correspond a` la phase de calcul.

Le grand avantage des r´eseaux systoliques r´eside dans le fait qu’elles minimisent les goulots d’´etranglement li´es aux acc`es a` la m´emoire, en rempla¸cant les op´erations d’´ecriture et de lecture des r´esultats interm´ediaires par le calcul organis´e de fa¸con similaire au pipeline. Dans [Kun80] un ensemble d’algorithmes permettant d’effectuer des op´erations vectorielles et matri- cielles est propos´e et une librairie des algorithmes systoliques peut ˆetre trouv´ee dans [Fru92]. Le exemple type d’une telle architecture est le syst`eme Intel iWarp ainsi que le processeur GAPP - Geometry Arithmetical Parallel Processor d´evelopp´e dans les ann´ees ’80.

Architectures a` m´emoire distribu´ee Dans une architecture a` m´emoire distribu´ee chaque unit´e de traitement (processeur) poss`ede sa propre m´emoire locale qui ne peut ˆetre acc´ed´ee directement par d’autres processeurs. Cependant les diff´erents couples processeur-m´emoire peuvent ´echanger les donn´ees via un r´eseau de connexions. En fonction de type de connexion ´etablie entre un certain nombre de couples processeur-m´emoire, i.e. la topologie du r´eseau, on peut obtenir des architectures diff´erentes. On parle alors des topologies fixes (l’anneau, le mesh, l’arbre, l’hypercube,...) ou encore programmables lorsque les connexions sont d´efinies par l’utilisateur ou encore par le programme.

Architectures a` m´emoire partag´ee Les architectures a` m´emoire partag´ee sont construites autour d’un mˆeme espace m´emoire uti- lis´e par plusieurs unit´es de traitement (processeurs) : chaque processeur peut acc´eder a` chaque m´emoire. Cet espace m´emoire peut ˆetre constitu´e d’une seule m´emoire physique (exemple : les ordinateurs personnels multi-processeur) ou de plusieurs m´emoires accessibles par chaque pro- cesseur. Lorsque une architecture a` m´emoire partag´ee poss`ede plusieurs m´emoires physiques, l’acc`es des diff´erents processeurs aux diff´erentes m´emoires peut ˆetre assur´e par : – le bus - un seul processeur acc`ede a` une seule m´emoire a` la fois, – le crossbar - chaque processeur peut acc´eder directement a` chaque m´emoire via une connexion programmable, – le r´eseau d’interconnexion multi-´etage - r´eduisent le nombre de connexions d’un crossbar en introduisant plusieurs ´etages de connexions programmables.

Architectures MIMD/SIMD Il est rare qu’en pratique l’algorithme d’un probl`eme a` r´esoudre soit parfaitement adapt´e a` une architecture particuli`ere : SIMD ou MIMD. Les architectures hybrides MIMD/SIMD permettent de faire face aux probl`emes “mixtes” en exploitant les avantages de chaque archi- tecture. Ainsi un ou plusieurs syst`emes SIMD seront utilis´es pour contrˆoler certaines parties d’une architecture MIMD. L’exemple type d’une telle machine est la combinaison de Cray T3D, une machine MIMD et Cray C90 une machine vectorielle.

Architectures flot de donn´ees Dans une architecture flot de donn´ees l’ex´ecution d’une instruction est possible d`es que les op´erandes n´ecessaires sont prˆetes (approche du “bas vers le haut”). Pour une telle architecture le programme est d´efini sous forme d’un graphe. Chaque noeud est une tˆache asynchrone (une expression a` calculer - une instruction) a` laquelle on pourrait associer une unit´e de

30 1.4. Machine traitement. Plusieurs noeuds (unit´es de traitement) peuvent donc fonctionner en parall`ele. Les arcs repr´esentent les communications n´ecessaires pour les instructions suivantes a` ex´ecuter. Le calcul de l’expression : a = d + e f g, n´ecessite les op´erandes d, e, f, g. Lorsque les − ∗ op´erandes sont prˆetes, il est possible de calculer d + e et f g de fa¸con concurrentielle a` l’aide ∗ de deux noeud distincts. Lorsque les deux expressions sont ´evalu´ees, un dernier noeud peut calculer le r´esultat final.

Architectures r´eduites Contrairement aux architectures flot de donn´ees, l’ex´ecution d’une instruction dans une archi- tecture r´eduite a lieu lorsque son r´esultat est n´ecessaire pour l’ex´ecution de l’instruction d´ej`a en cours d’ex´ecution (approche du “haut vers le bas”). L’ex´ecution d’un programme consiste donc a` calculer une expression imbriqu´ee complexe. Ainsi, le calcul de la mˆeme expression a = d + (e (f g)) est d´ecompos´ee en calcul des expressions : f g, puis e (f g) et − ∗ ∗ − ∗ finalement d + (e (f g)) ce qui impose un ordre de recherche d’op´erandes particulier : − ∗ d’abord g et f puis e et enfin d.

Architectures wavefront L’efficacit´e d’un r´eseau systolique d´epend de la r´egularit´e des tˆaches distribu´ees entre les diff´erentes unit´es de traitement. Dans un r´eseau systolique, traitant des probl`emes r´eels, l’´equilibre de charge de calcul entre les diff´erentes unit´es de traitement n’est pas toujours assur´ee : les unit´es ayant termin´e une partie de calcul seront oblig´ees d’atteindre. Les ar- chitectures wavefront apportent aux architectures systoliques la possibilit´e de fonctionner en monde asynchrone grˆace a` un syst`eme de requˆete-accus´e de r´eception entre les diff´erentes unit´es de traitement.

1.4.2.2 Taxinomies des architectures d´edicac´ees

Les diff´erentes taxinomies abord´ees concernent les machines universelles, capables de r´esoudre n’importe quel probl`eme calculable (th`ese de Church-Turing28). De telles architec- tures traitent des probl`emes avec une certaine efficacit´e qui est, on peut s’en douter intuitive- ment, inversement proportionnelle a` son universalit´e. En d’autres termes, plus une machine est universelle moins elle sera efficace [BAK96].

Afin d’am´eliorer l’efficacit´e d’un calcul automatique des probl`emes particuliers et complexes, des architectures “moins universelles” et plus d´edicac´ees apparaissent comme solution id´eale. Le principal avantage d’un syst`eme d´edicac´e est li´e au caract`ere dual de l’approche a` la r´esolution du probl`eme : celui de l’algorithme et celui de la machine qui ex´ecutera l’algorithme en question.

Comme les architectures universelles, les architectures d´edicac´ees peuvent faire l’objet d’une classification. Ainsi, Buell et al. introduisent dans [BAK96] une r´epartition des architec- tures d´edicac´ees en trois classes distinctes : 1. Les unit´es d´edicac´ees - il s’agit de syst`emes autonomes qui ne visent aucune universalit´e si ce n’´est pour des applications semblables.

28La forme la plus courante de cette th`ese est : “Tous ce qui est calculable, peut ˆetre calcul´e par une machine de Turing”.

31 Chapitre 1. Introduction

2. Les co-processeurs - qui se pr´esentent sous forme de syst`emes destin´es a` un syst`eme hˆote particulier et permettent de r´ealiser certaines fonctionnalit´es de fa¸con plus efficace29. 3. Les processeurs attach´es - qui ont un rˆole fort semblable de celui des co-processeurs, mais ne se limitent pas a` un syst`eme hˆote particulier et visent une plus grande universalit´e.

1.4.2.3 Taxinomies des architectures selon la configurabilit´e

Une classification qui impliquerait a` la fois des architectures universelles et des archi- tectures d´edicac´es peut ˆetre faite selon la relation entre le support physique - le mat´eriel et l’information concernant la description fonctionnelle du syst`eme - la configuration. Nous pouvons alors parler de quatre classes d’architectures diff´erentes : I. Architectures universelles (programmables) II. Architectures configurables III. Architectures reconfigurables IV. Architectures dynamiquement reconfigurables

Architectures universelles (programmables) La configuration des architectures programmables est ´etablie une fois pour tout. Le support physique re¸coit l’information sur la configuration lors de la fabrication et il n’est plus possible de la modifier. Une telle architecture apparaˆıt a` l’utilisateur comme une boˆıte noire car elle offre un ensemble de fonctionnalit´es d´efinies au pr´ealable par la configuration. L’ex´ecution en s´equence de plusieurs de ces fonctionnalit´es permet la r´ealisation des fonctionnalit´es plus complexes : la machine universelle - le programme.

Architectures configurables En utilisant un mat´eriel sp´ecifique, tel que les circuits ASIC ou FPGA, il est possible de r´ealiser n’importe quelle fonctionnalit´e d´esir´ee. La limitation de la complexit´e d’une ou plu- sieurs fonctionnalit´es a` r´ealiser r´eside dans la taille du support qui re¸coit la configuration. La configuration du support ´etablie une fois ne change pas en cours d’utilisation.

Architectures reconfigurables Elles diff´erent des architectures configurables par le fait que la configuration du support peut changer selon la volont´e du concepteur/utilisateur ou du programme/application. Ceci est possible grˆace aux certaines supports physiques : les circuits FPGA a` m´emoire statique par exemple. Le processus de changement de la configuration comprends la destruction compl`ete au pr´ealable de la configuration actuelle et implique une interruption du fonctionnement normal du syst`eme.

Architectures dynamiquement reconfigurables Dans les architectures dynamiquement reconfigurables une partie de la configuration, i.e. une partie du support physique qui d´efinit une ou plusieurs fonctionnalit´es, peut ˆetre chang´ee a` n’importe quel instant, sans compromettre le fonctionnement du reste de la configuration. Le support physique permettant la r´ealisation de telles architectures reconfigurables sont des circuits DPGA (Dynamicaly Programmable Gatte Arrays).

29Exemple : la CM2-X de Thinking Machines Corp. utilise les unit´es de calcul en virgule flottante sous forme des co-processeurs r´ealis´es en FPGAs [CR93].

32 1.5. Performance

1.5 Performance

The amount of information you could process if you were to use all the energy and matter of the universe is 1090 bits and the number of elementary operations that it can have perfor- Traitement Machine med since the Big Bang is about 10120 ops. Perhaps the uni- verse is itself a computer and what it’s doing is performing a computation. If so, that’s why the universe is so complex and these numbers say how big that computation is. The Computational Universe, Seth Lloyd

Performance

En informatique, la conception d’un programme pour un probl`eme particulier a` r´esoudre commence par le choix (ou l’´elaboration) d’un ou plusieurs algorithmes. A ce stade-ci il est possible d’´evaluer la complexit´e th´eorique des algorithmes choisis en termes de nombre de pas de calcul d’une machine hypoth´etique et/ou d’espace m´emoire n´ecessaire. Cette complexit´e est exprim´ee sous forme d’une fonction, not´ee O, le plus souvent : lin´eaire, logarithmique, quadratique, cubique ou exponentielle, de la taille du probl`eme n.

L’´evaluation de la complexit´e algorithmique nous permet de classer les algorithmes et de se rendre compte de la faisabilit´e du calcul que l’on souhaite automatiser. Ainsi pour certains probl`emes, la complexit´e algorithmique est tellement grande que le temps d’ex´ecution est tr`es long, quelque soit la technologie employ´ee. Parfois mˆeme ce temps est suffisamment long pour que nous n’ayons aucun espoir de les r´esoudre dans un temps raisonnable.

Les probl`emes qui nous int´eressent ont typiquement une complexit´e algorithmique lin´eaire, lo- garithmique ou quadratique, avec des tailles n de l’ordre de quelque millions. Les algorithmes, les programmes qui les codent et le mat´eriel utilis´e pour l’ex´ecution de ces programmes sont caract´eris´es par des temps de calcul relativement faible : entre quelque millisecondes et quelque dizaines de secondes. Pour de tels probl`emes la performance du mat´eriel devient alors impor- tante d’ou` l’int´erˆet de pouvoir la quantifier a` priori.

1.5.1 Performance du mat´eriel

La performance d’un syst`eme informatique est le plus souvent exprim´ee a` travers la per- formance de ses deux parties clefs : la m´emoire et l’unit´e de traitement. Pour la m´emoire, la bande passante est un tr`es bon indicateur de sa performance. Pour les unit´es de traitement, le param`etre le plus courant est le nombre d’instructions que celui-ci peut ex´ecuter par unit´e de temps. Malheureusement ce dernier ne peut ˆetre utilis´e pour un circuit FPGA, pour lequel on quantifie le plus souvent la quantit´e de ressources logiques. D`es lors une comparaison entre les deux sur base des donn´ees caract´eristiques de constructeur devient impossible.

Avant de passer a` la description d’un param`etre commun qui nous permettra de faire cette comparaison, examinons d’un peu plus pr`es les param`etres classiques de la puissance de calcul du mat´eriel.

33 Chapitre 1. Introduction

1.5.1.1 Param`etres classiques

Processeurs Le nombre d’instructions qu’un processeur peut ex´ecuter par unit´e de temps est souvent mise en valeur par le fabricant afin de favoriser son produit et n’est pas toujours repr´esentative de la performance r´eelle. Dans le but d’offrir une information plus pr´ecise et en tenant compte de la difficult´e de r´eduire la performance du mat´eriel a` seulement quelques param`etres, il est d’usage courant de consid´erer la performance d’un processeur ou d’un syst`eme informatique a` travers sa performance r´eelle. Cette performance est ´etablie pour un certain nombre d’applications types. Diff´erents bancs d’essais existent, les plus connus ´etant ceux propos´es par Standard Performance Evaluation Corporation - SPEC. Si l’´evaluation des performances des diff´erents processeurs et des syst`emes informatiques est couramment faite sur base de ces bancs d’essais, leur utilisation pour les architectures d´edicac´ees s’av`ere tr`es difficile, voir impossible. En effet, pour chaque application d’un banc d’essai il faudrait r´ealiser un syst`eme d´edicac´e pour pouvoir effectuer la comparaison.

FPGA La plupart des constructeurs des FPGA expriment la performance de leurs circuits a` tra- vers un param`etre li´e a` la quantit´e des ressources logiques disponibles, la cons´equence directe de la densit´e d’int´egration. Un autre param`etre important est li´e au temps de commutation des diff´erentes parties du FPGA. La quantit´e des ressources logiques disponible est sou- vent exprim´ee par le nombre ´equivalent de portes logiques Npl, calcul´e selon un protocole g´en´eralement propre a` chaque constructeur.

Le protocole utilis´e pour le calcul de nombre ´equivalent de portes logiques Npl pour les circuits Xilinx [Xil97], se base sur le fait qu’une partie des ressources logiques du FPGA est utilis´ee pour la logique (combinatoire ou s´equentielle) et une autre partie pour la m´emoire. Pour un ensemble des circuits typiques la proportion des ressources logiques allou´ees pour la m´emoire a ´et´e estim´e empiriquement a` 20 - 30% des ressources logiques totales.

Ce mˆeme protocole d´efini ensuite comment ´evaluer le nombre ´equivalant de portes logiques pour la logique et pour la m´emoire : – Nombre maximal de portes pour la logique Le nombre maximal des portes logiques est calcul´e pour une cellule ´el´ementaire, dans les FPGAs Xilinx une m´emoire de 16 bits (une Look Up Table - LUT) et d’un flip-flop. Une m´emoire de 16 bits a son ´equivalent en portes logiques qui varie entre 2 et 18 portes. Ce nombre est d´eduit a` partir des circuits logiques complexes que l’on peut r´ealiser a` l’aide d’une m´emoire de 16 bits, tels qu’un OU exclusif sur 4 variables, ou encore un additionneur complet sur 4 bits etc. Un flip-flop est construit avec un nombre de portes logiques qui varie entre 6 et 12. – Nombre maximal de portes pour la m´emoire La m´emoire de chaque bloc logique de FPGA peut fonctionner non seulement comme un g´en´erateur de fonctions logiques - lorsqu’il contient la table de v´erit´e programm´ee lors de la configuration - mais aussi comme une m´emoire conventionnelle, avec son contenu qui peut ˆetre modifi´e en cours de fonctionnement. On consid`ere que la sauvegarde d’un bit d’information n´ecessite 4 portes logiques. En suivant le protocole expos´e, il est possible de proc´eder a` l’estimation de Npl pour un FPGA donn´e, dot´e d’un certain nombre de blocs logiques.

34 1.5. Performance

La comparaison entre les diff´erents circuits FPGA sur base de nombre ´equivalent des portes logiques pr´esente certains d´esavantages. Les approximations et les hypoth`eses admises dans le protocole expos´e laissent beaucoup de marge et peuvent conduire a` d’importantes diff´erences. Si en suivant le mˆeme protocole on peut parler d’une comparaison entre les diff´erents FPGAs au sein d’une mˆeme famille et d’un mˆeme producteur, la comparaison entre les FPGAs des producteurs diff´erents devient tr`es difficile.

Prenons un exemple concret. En 2002 le circuit le plus dense de chez Xilinx (Virtex-II XC2V8000) affiche un nombre ´equivalent de portes logiques de 8 millions [Xil02]. Chez Altera, le circuit le plus dense (Apex - HC2A70), selon les donn´ees constructeur [Alt03a], poss`ede un ´equivalant de 3 millions de portes logiques. Peut on conclure que les circuits FPGA Xi- linx sont alors 3 fois plus puissants ? Certainement pas. Les deux FPGAs utilisent les mˆemes proc´ed´es de fabrication (dans les deux cas la taille du plus petit objet int´egr´e dans le circuit est de l’ordre de 0.12µm), sur une mˆeme surface de silicium et doivent par cons´equence avoir une puissance de calcul semblable.

S’il s’av`ere difficile de comparer les FPGAs entre les diff´erents producteurs ou familles, la situation est pire si l’on souhaite r´ealiser une comparaison entre les FPGA et les processeurs en tant qu’unit´es de traitement. Dans ce cas la comparaison devient tout simplement impossible.

1.5.1.2 Param`etre commun

Afin de pouvoir faire la comparaison entre les processeurs et les FPGA en tant qu’unit´es de traitement il est n´ecessaire d’introduire un autre crit`ere de comparaison. Vuillemin pro- pose dans [Vui94] une ´evaluation de la puissance de calcul bas´ee sur la notion d’un bit actif programmable (Programmable Active Bit - PAB) d´efini comme un circuit s´equentiel a` deux entr´ees et une fonction de r´etroaction (un bit de m´emoire). La notion de PAB permet d’intro- duire la puissance virtuelle de calcul30 - P V qui est alors d´efinie comme le nombre de PABs n qui fonctionnt a` la fr´equence f : P V = n f (1.26) × La dimension de P V est exprim´ee en unit´es appel´ees BOPs, l’acronyme de Binary Operations Per Second.

Pour un processeur quelconque n repr´esente la taille des op´erandes des unit´es arithm´etiques et logiques. Pour un FPGA quelconque, n repr´esente le nombre de LUTs qui peuvent ˆetre lues simultan´ement. Sur base de ces informations, nous pouvons d´eduire la puissance virtuelle de calcul d’un processeur grande s´erie et celle d’un FPGA et effectuer la comparaison entre les deux.

Ainsi, le noyau de calcul de processeur Pentium 4 peut produire 128 bits simultan´ement puisqu’il poss`ede deux unit´es de traitement (des entiers) de 64 bits chaque qui fonctionnent a` la fr´equence de 3.0GHz. D`es lors sa puissance virtuelle de calcul s’´el`eve a` 384 GBOPs.

Pour un circuit FPGA, un Xilinx - XC2V8000 par exemple, le nombre de PABs passe a` 93184, le nombre d´eduit a` partir des donn´ees constructeur. Ainsi le circuit XC2V8000 poss`ede 46,592

30La puissance virtuelle de calcul est vu comme la puissance maximale th´eorique qu’un circuit peut pr´esenter. Pour plusieurs raisons, dont on peut s’en douter les origines, cette puissance n’est jamais atteint en r´ealit´e.

35 Chapitre 1. Introduction tranches - slices et chaque tranche poss`ede 2 m´emoires de 16 bits et deux ´el´ements de m´emoire. L’acc`es a` cette m´emoire peut se faire a` une fr´equence de 420 MHz. La puissance virtuelle de calcul de ce FPGA est donc 38220 GBOPs, ce qui repr´esente une puissance virtuelle de calcul environ 100 fois plus grande que celle de processeur envisag´e.

Si la puissance virtuelle de calcul repr´esente un moyen simple et efficace de comparaison, elle ne tiens pas compte d’un fait important, l’universalit´e de l’unit´e de traitement. Intuitivement, on peut s’imaginer que les processeurs apparaissent comme des unit´es plus universelles que les FPGAs.

De Hon introduit dans [Hon96] deux param`etres selon lesquelles toute comparaison entre les unit´es de traitement devrait se faire :

– Capacit´e fonctionnelle Cf - une m´etrique qui vise a` quantifier le nombre de fonctions r´ealisables par circuit. Cette m´etrique est bas´e sur la notion de nombre ´equivalent de portes logiques, normalis´e par la fr´equence f et la technologie λ31 :

N C = pl (1.27) f fλ

– Diversit´e fonctionnelle FD - une m´etrique bas´ee sur le nombre des fonctions diff´erentes Ni qu’il est possible de d´efinir par une configuration donn´ee et pour une surface de circuit A :

N F = i (1.28) D A

Dans une ´evaluation exhaustive des diff´erentes moyens techniques permettant la r´ealisation des unit´es de traitement32, De Hon montre que les FPGA montrent une capacit´e de calcul de 15 a` 75 fois sup´erieure par rapport aux processeurs standards avec une diversit´e fonctionnelle nettement moindre.

En th´eorie, les FPGAs et les syst`emes informatiques qui les utilisent pr´esentent donc une puis- sance de calcul par circuit nettement plus importante que celle des processeurs conventionnels. Ils repr´esentent donc un moyen tr`es int´eressant d’acc´el´eration.

En pratique, plusieurs syst`emes d’architecture (re)configurables bas´ees sur des FPGAs ont pu montrer une performance sup´erieure aux architectures programmables. On peut citer Pro-

31Par λ on d´esigne la taille du plus petit objet int´egr´e dans un circuit int´egr´e et qui d´epend de stade actuel de technologie de fabrication. 32M´emoires en tant qu’unit´es de traitement fonctionnant en mode LUT, les syst`emes SIMD a` plus de 1024 unit´es de traitement, les FPGAs, les UAL reconfigurables, les FPGA, les DPGA, les architectures vectorielles, les processeurs standards et les DSP.

36 1.5. Performance grammable Active Memories(PAM)33 ou encore le projet SPLASH 34. Signalons enfin l’exis- tence d’une liste assez exhaustive des diff´erentes machines reconfigurables construites jusqu’`a nos jours propos´ee par Guccione dans [Guc00].

1.5.2 Performance d’une application

1.5.2.1 Temps d’ex´ecution

La complexit´e algorithmique d’un probl`eme et les param`etres classiques d’´evaluation de la puissance de calcul d’un syst`eme informatique ne peuvent conduire qu’`a une approximation tr`es grossi`ere de temps de calcul. Ces param`etres sont insuffisants pour mod´eliser le temps d’ex´ecution d’un programme. Un grand nombre de facteurs vont jouer un rˆole important dans la performance d´efinitive et la seule mesure pertinente de l’efficacit´e d’un programme ex´ecut´e sur une machine est le temps de calcul effectif.

1.5.2.2 Acc´el´eration

La notion d’acc´el´eration exprime habituellement le gain en temps d’ex´ecution obtenu par une architecture parall`ele a` N unit´es de traitement (le temps d’ex´ecution t2) par rapport a` une architecture a` une seule unit´e de traitement (le temps d’ex´ecution t1) :

t A = 1 (1.29) t2

Si A = N, nous parlons d’une acc´el´eration id´eale : la charge de calcul peut ˆetre divis´ee entre N unit´es de traitement identiques et le temps d’ex´ecution est donc r´eduit d’un facteur N.

33DECPeRLe-1 Ce syst`eme a ´et´e r´ealis´ee dans le Laboratoire de recherche de Digital Equipment Corporation-DEC a` Paris en 1992. Il est compos´e de 23 circuits FPGA Xilinx 3090-100 dont 16 ont ´et´e utilis´es pour la r´ealisation du noyau purement computationnel, le reste ´etant utilis´ee pour la gestion de 8MB de m´emoire statique et l’aiguillage de donn´ees vers le noyau computationel. Une douzaine d’applications : la multiplication de grands nombres, comparaisons des chaˆınes de caract`eres, la convolution binaire etc. ont pu d´emontrer que l’approche PAM et sa r´ealisation mat´erielle sous forme d’un syst`eme co-processeur offre des r´esultats sup´erieures en termes de performance-prix que n’importe quelle autre syst`eme : super ordinateur, ordinateur massivement parall`ele et le mat´eriel d´edicac´es inclus[VBD+96]. 34SPLASH D´evelopp´e dans le laboratoire Supercomputing Research Center - SRC le syst`eme SPLASH2 est construit au tour de 32 unit´es Xilinx XC3090. D’apr`es [GHC+92] la performance de ce syst`eme pr´esente une acc´el´eration d’un facteur 300 en comparaison avec un super-ordinateur Cray II et de 200 en comparaison avec le processeur 16k de la Connection Machine 2.

37 Chapitre 1. Introduction

En r´ealit´e, une telle acc´el´eration ne se produit jamais et pour diverses raisons35 nous avons toujours : t1/t2 < N.

Dans ce qui va suivre la notion d’acc´el´eration ne sera pas utilis´ee uniquement pour la com- paraison entre une architecture parall`ele et une architecture s´equentielle mais aussi pour les ´eventuels gains obtenus entre les diff´erents algorithmes ex´ecut´ees sur une mˆeme machine ou les diff´erentes impl´ementations d’un mˆeme algorithme.

1.5.2.3 Mesure sp´ecifique pour le traitement d’images

La mesure du temps d’ex´ecution nous permet de dire si un probl`eme peut ˆetre calcul´e dans un temps t. Cette r´eponse est valide pour un algorithme particulier, son programme correspondant, une taille du probl`eme n, un niveau de technologique particulier et une archi- tecture informatique pr´ecise. Afin d’exclure l’influence de la taille du probl`eme et le rˆole de la technologie nous pr´ef´erons travailler avec un param`etre qui en est ind´ependant : le nombre d’op´erations ´el´ementaires n´ecessaires pour calculer un pixel de l’image r´esultante, not´e BOP s.

Pour une architecture programmable universelle le BOP s peut ˆetre calcul´e a` partir du temps d’ex´ecution t mesur´e, comme suit : t f BOP s = × (1.30) NI ou` f d´esigne la fr´equence de fonctionnement du processeur utilis´e et NI la taille de l’image (le nombre de pixels calcul´es).

Pour des architectures d´edicac´ees, le nombre de BOP s est d´eduit de fa¸con triviale a` partir du nombre de pas de calcul de la nouvelle architecture.

Afin de caract´eriser la performance d’une architecture nous allons ´egalement utiliser la notion du d´ebit des pixels trait´es, d´efini comme le nombre de pixels calcul´es par unit´e de temps. Duˆ a` la taille des images habituellement rencontr´ees, ce d´ebit sera exprim´e en millions de pixels par seconde (Mpx/sec).

35Une des raisons explique pourquoi A < N est qu’en pratique la plupart de programmes pr´esentent ne fut-ce qu’une petite partie de programme qu’il est impossible de rendre parall`ele. L’influence de cette partie s´equentielle d’un programme sur la performance globale d’une architecture parall`ele est exprim´ee par la loi d’Amdahl. Ainsi, pour un programme P d´efini par une charge de calcul CP (la charge de calcul est exprim´ee par le nombre d’instructions a` ex´ecuter) dont la partie s´equentielle est pond´er´ee par un facteur α et la partie parall`ele par un facteur (1 − α) nous avons :

CP A = α CP +(1 α) (CP /N) ∗ − ∗ et la loi d’Amdahl pour un grand nombre d’unit´es de traitement est ´enonc´ee comme suit :

lim A = N = 1 N 1+(N 1) α α →∞ − ∗ l’acc´el´eration d’un syst`eme parall`ele est inversement proportionnelle a` la partie s´equentielle d’un programme.

38 Chapitre 2

Architecture universelle

La premi`ere approche de l’impl´ementation des diff´erents filtres de rang vise les architec- tures universelles et en particulier l’architecture universelle la plus r´epandue de nos jours - l’ordinateur personnel. Ce chapitre propose une ´etude d´etaill´ee de la performance de tels syst`emes pour les applications envisag´ees et comprend 5 sections :

Section 1 - Propose une introduction g´en´erale sur les notions du parall´elisme des archi- tectures universelles actuelles et offre une description d´etaill´ee du mat´eriel qui sera utilis´e pour l’´evaluation des performances de diff´erents algorithmes envisag´es.

Section 2 - Dans un premier temps l’impl´ementation des filtres non-lin´eaires est bas´ee sur les algorithmes classiques de tri, cod´es a` travers un langage de programmation ´evolu´e. C’est une approche du mat´eriel que l’on pourrait qualifier de ”boite noire”, car l’impl´ementation de ces algorithmes peut se faire sans aucune connaissance du mat´eriel cibl´e.

Section 3 - Les ordinateurs personnels peuvent se montrer nettement plus performants en exploitant les diff´erents niveaux de parall´elisme du processeur employ´e. Dans cette section on peut trouver la description de plusieurs algorithmes et les proc´edures correspondantes, optimis´ees pour l’architecture de l’ordinateur cible. Ces r´ealisations permettent de quantifier le facteur d’acc´el´eration d’une telle approche par rapport a` l’approche dite de ”boite noire”.

Section 4 - Les meilleurs algorithmes (proc´edures) d´evelopp´es pr´ec´edemment peuvent ˆetre encore acc´el´er´es en faisant intervenir le parall´elisme des stations multi-processeurs. De tels ordinateurs personnels, dot´e de deux, voir quatre processeurs sont de plus en plus courants de nos jours. Cette section d´ecrit les m´ethodes et les proc´ed´es permettant de quantifier le facteur d’acc´el´eration qu’il est possible d’obtenir avec un ordinateur ayant deux processeurs identiques.

Section 5 - Les diff´erents r´esultats obtenus des trois approches d’impl´ementation nous permettrons de conclure sur l’impl´ementation des filtres non-lin´eaires sur des architectures universelles.

39 Chapitre 2. Architecture universelle

2.1 Parall´elisme des architectures universelles

Un regard superficiel sur les syst`emes informatiques universels d’aujourd’hui peut nous mener a` la conclusion hˆative que leur architecture est la mˆeme que celle introduite par John Von Neumann dans le c´el`ebre article de 1945 ”The fist draft of a Report on the Electronic Discrete Variable Automatic Computer - EDVAC”. En effet, le mat´eriel est dans la plupart des cas encore con¸cu autour d’un seul processeur et d’une m´emoire centrale. La conception des programmes consiste en codage d’algorithmes a` l’aide des langages de programmation ´evolu´es (typiquement C, C++) et de leur traduction en langage machine a` l’aide des compilateurs appropri´es. Le programme ex´ecutable g´en´er´e est compos´e d’une suite d’instructions, suppos´ees ˆetre ex´ecut´ees de fa¸con s´equentielle.

En r´ealit´e, les syst`emes informatiques d’aujourd’hui sont tr`es loin de cette vision simplifi´ee et cachent dans leurs couches sous-jacentes les diff´erentes manifestations de parall´elisme que l’on pourra situer a` deux niveaux : 1. Parall´elisme intra-processeur - le parall´elisme propre au processeur en tant qu’unit´e fonctionnelle et mat´erielle (un circuit int´egr´e). 2. Parall´elisme inter-processeur - le parall´elisme au sein d’un mˆeme syst`eme informa- tique compos´e de plusieurs processeurs.

2.1.1 Parall´elisme intra-processeur

Les processeurs actuels int`egrent deux types de parall´elisme interne : le parall´elisme des instructions, dans la litt´erature anglo-saxonne Instruction Level Parallelism - ILP, li´e a` la possibilit´e d’ex´ecution de plusieurs instructions dans un seul cycle machine et le parall´elisme de donn´ees, lorsque un processeur permet le traitement de plusieurs mots d’information a` l’aide d’une seule instruction.

2.1.1.1 Parall´elisme des instructions

Le traitement d’une instruction est habituellement d´ecompos´e en plusieurs ´etapes : la recherche de l’instruction (FI), le d´ecodage de l’instruction (DI), l’ex´ecution de l’instruction proprement dit (EX) et l’´ecriture des op´erandes (WO). Chacune de ces ´etapes peut ˆetre r´ealis´ee par une unit´e mat´erielle cˆabl´ee ou par une suite des micro-instructions : un micro- programme.

Le parall´elisme des instructions est ´etroitement li´e a` la fa¸con dont les diff´erentes ´etapes d’ex´ecution sont r´ealis´ees par le processeur. On admet g´en´eralement l’existence de 7 grandes classes d’architectures.

Architectures scalaires Un processeur scalaire ex´ecutera les diff´erentes ´etapes d’ex´ecution d’une instruction de fa¸con s´equentielle, une ´etape apr`es l’autre avant de proc´eder a` l’ex´ecution de l’instruction suivante (Figure 2.1).

40 2.1. Parall´elisme des architectures universelles

1 2 3 4 5 6 7 8 9 11 12 13 14 15 Temps instruction1 FI DI EX WO instruction2 FI DI EX WO instruction3 FI DI EX WO

Instructions

Fig. 2.1: Architecture scalaire

Ce type d’architecture ne poss`ede aucun parall´elisme si ce n’est ´eventuellement au niveau des bits d’un mˆeme mot.

Par souci de simplification nous supposons que toutes les instructions sont compos´ees d’un mˆeme nombre k d’´etapes d’ex´ecution et que chaque ´etape n´ecessite le mˆeme temps d’ex´ecution τ.

Le temps d’ex´ecution T de N instructions sera alors :

T = N k τ (2.1) ∗ ∗ Architectures pipeline L’ex´ecution de chaque ´etape peut ˆetre faite par une unit´e fonctionnelle ind´ependante, dont le r´esultat est sauvegard´e localement. L’ensemble des ces unit´es, mises en s´erie, peut fonctionner selon le principe de pipeline (Figure 2.2).

1 2 3 4 5 6 7 8 9 11 12 13 14 15 instruction1 FI DI EX WO instruction2 Temps Scalaire FI DI EX WO { instruction3 FI DI EX WO instruction1 FI DI EX WO instruction2 FI DI EX WO instruction3 FI DI EX WO Pipeline instruction4 FI DI EX WO instruction5 FI DI EX WO { instruction6 FI DI EX WO

Instructions

Fig. 2.2: Architecture pipeline

Un processeur d’une telle architecture peut donc ´emettre et terminer une instruction par chaque cycle machine, a` partir du moment ou le pipeline est rempli. D’une mani`ere tout a` fait g´en´erale, le nombre d’instructions ´emises par cycle sera not´e m et le nombre d’instruction termin´ees sera not´e n.

Le temps d’ex´ecution, not´e T (m, n), n´ecessaire pour r´ealiser N instructions1 a` l’aide d’une architecture pipeline est alors donn´e par l’expression suivante :

T (m, n) = T (1, 1) = (k + N 1) τ (2.2) − ∗ 1L’ex´ecution de la premi`ere instruction a n´ecessit´e un temps : k ∗ τ. Les N − 1 instructions qui restent vont chacune n´ecessiter un temps τ.

41 Chapitre 2. Architecture universelle

L’acc´el´eration th´eorique d’une telle architecture par rapport a` une architecture scalaire peut ˆetre calcul´e comme : T N k A = = ∗ (2.3) cc T (1, 1) k + N 1 − et pour un grand2 nombre d’instructions N, l’acc´el´eration deviens alors : N k Acc = lim ∗ = k (2.4) N k + N 1 →∞ − L’acc´el´eration est donc proportionnelle au nombre d’´etages de pipeline, pour autant qu’il y ait peu de ruptures de s´equences.

La premi`ere application d’une architecture pipeline dans un processeur commercial date des ann´ees 60 [Tho61]. Aujourd’hui cette architecture est devenue une norme3 et en g´en´eral sert de r´ef´erence lorsqu’il s’agit de comparer les diff´erentes architectures [JW89].

Architectures super-pipeline Chaque ´etape d’ex´ecution peut ˆetre associ´ee a` un micro-programme particulier compos´e de plusieurs micro-instructions a` ex´ecuter. Une ´etape n’est donc plus une op´eration atomique mais elle mˆeme constitu´e de plusieurs ´etapes. Si au sein d’une mˆeme ´etape d’ex´ecution, associ´ee a` un ´etage du pipeline de processeur, les micro-op´erations qui composent cette ´etape sont ex´ecut´ees dans un pipeline (un ´etage de pipeline est lui mˆeme un pipeline) on parle alors d’une architecture super-pipeline (Figure 2.3).

1 2 3 4 5 6 7 8 9 11 12 13 14 15

instruction1 FI DI EX WO Temps instruction2 Pipeline FI DI EX WO { instruction3 FI DI EX WO

instruction1 FI DI EX WO instruction2 Super-pipeline FI DI EX WO { instruction3 FI DI EX WO

Instructions

Fig. 2.3: Architecture super-pipeline

Le temps d’ex´ecution de N instructions deviens alors : N 1 T (1, n) = (k + − ) τ (2.5) n ∗ ou` n repr´esente le nombre d’´etages du pipeline (on dit que l’architecture est pipeline d’ordre n).

L’acc´el´eration obtenue par rapport a` une architecture pipeline de r´ef´erence et pour un grand nombre des instructions est alors : T (1, 1) k + N 1 Acc(1, n) = = lim − = n (2.6) T (1, n) N N 1 →∞ k + n− 2Le nombre N d’instructions est beaucoup plus grand que le nombre d’´etapes k. 3Un tel syst`eme informatique est souvent appel´ee Single Issue Base Machine.

42 2.1. Parall´elisme des architectures universelles

Architectures super-scalaire Si un microprocesseur poss`ede plusieurs unit´es d’ex´ecution permettant la r´ealisation simul- tan´ee de plusieurs ´etapes EX, on parle alors d’une architecture super-scalaire. Notons que chaque unit´e d’ex´ecution peut avoir son propre pipeline. L’architecture d’un tel processeur est alors dite super-scalaire/pipeline et la Figure 2.4 montre l’exemple d’une telle architecture d’ordre 2 (deux unit´es d’ex´ecution avec deux pipelines d’´etapes d’ex´ecution).

1 2 3 4 5 6 7 8 9 11 12 13 14 15

instruction1 FI DI EX WO instruction2 Temps Pipeline FI DI EX WO { instruction3 FI DI EX WO instruction1 FI DI EX WO instruction2 FI DI EX WO Super-scalaire/ instruction3 FI DI EX WO Pipeline { instruction4 FI DI EX WO

Instructions

Fig. 2.4: Architecture super-scalaire

Le temps d’ex´ecution de N instructions est : N m T (m, 1) = (k + − ) τ (2.7) m ∗ Le nombre d’instructions ´emise par cycle machine m (i.e. le nombre d’instructions qui peuvent ˆetre ex´ecut´ees simultan´ement) correspond au nombre d’unit´es de traitement d’un processeur super-scalaire.

A partir des ´equations 2.2 et 2.7 il est possible de calculer l’acc´el´eration d’une architecture super-scalaire par rapport a` l’architecture pipeline de r´ef´erence : T (1, 1) k + N 1 Acc(m, 1) = = lim − = m (2.8) T (m, 1) N N m →∞ k + m− En comparant l’expression d’acc´el´eration d’une architecture super-pipeline (2.6) avec celle d’une architecture super-scalaire (2.8), nous pouvons remarquer que les deux architectures offrent un mˆeme facteur d’acc´el´eration si elles sont de mˆeme ordre : le nombre d’unit´es d’ex´ecution est le mˆeme que celui d’´etages de pipeline (n = m).

Architectures super-scalaire/super-pipeline Les deux architectures d´ecrites pr´ec´edemment peuvent ˆetre combin´ees afin d’offrir le meilleur facteur d’acc´el´eration possible (Figure 2.5).

1 2 3 4 5 6 7 8 9 11 12 13 14 15 instruction1 FI DI EX WO Temps instruction2 Pipeline FI DI EX WO { instruction3 FI DI EX WO instruction1 FI DI EX WO instruction2 FI DI EX WO Super-scalaire/ instruction3 FI DI EX WO Super-pipeline { instruction4 FI DI EX WO

Instructions

Fig. 2.5: Architecture super-scalaire/super-pipeline

43 Chapitre 2. Architecture universelle

Le temps d’ex´ecution de N instructions pour une architecture super-scalaire/super-pipeline est : N m T (m, n) = k + − τ (2.9) n m ∗  ∗  et l’acc´el´eration par rapport a` l’architecture de r´ef´erence est :

T (1, 1) k + N 1 Acc(m, n) = = lim − = m n (2.10) T (m, n) N N m ∗ →∞ k + n−m ∗ Architectures VLIW L’architecture VLIW4, comme l’architecture super-scalaire, poss`ede plusieurs unit´es de trai- tement mais un seul pipeline des diff´erentes ´etapes d’ex´ecution. L’exploitation de multiples unit´es de traitement est assur´ee par l’existence de plusieurs ´etapes d’ex´ecution (EX) cod´ees aux sein d’une mˆeme instruction VLIW (Figure 2.6).

1 2 3 4 5 6 7 8 9 11 12 13 14 15 instruction1 FI DI EX WO EX Temps EX instruction2 EX FI DI EX WO EX EX instruction3 EX FI DI EX WO EX EX EX

Instructions

Fig. 2.6: Architecture VLIW

L’acc´el´eration d’une architecture VLIW par rapport a` l’architecture de r´ef´erence est la mˆeme que celle d’une architecture super-scalaire. L’avantage de ces architectures r´eside surtout dans le fait que le d´ecodage des instructions VLIW semble plus simple que dans le cas d’une architecture super-scalaire. On b´en´eficie ´egalement d’une ´economie des ressources en mat´eriel, puisque le nombre de d´ecodeurs des instructions ne se voit pas multipli´e par le nombre d’unit´es d’ex´ecution en jeu.

Un autre avantage des architectures VLIW est li´e a` l’exploitation de parall´elisme des ins- tructions, faite lors de la compilation et non plus lors de l’ex´ecution. En effet, le temps que l’on peut consacrer a` la recherche automatique (par le biais de compilateur) d’un ´eventuel parall´elisme d’instructions est beaucoup plus important permettant, a` priori, d’obtenir un code ex´ecutable plus performant.

Architectures vectorielles Dans une architecture vectorielle (Figure 2.7) lorsque une instruction est d´ecod´ee, l’´etape d’ex´ecution (EX) travaille sur un vecteur de donn´ees, d’une taille quelconque, plutˆot que sur un nombre fixe et g´en´eralement faible d’op´erandes.

Les architectures vectorielles pr´esentent deux avantages. Tout d’abord une op´eration sur deux vecteurs n´ecessite seulement une op´eration de d´ecodage d’instruction a` ex´ecuter qui sera ap- pliqu´ee au vecteur entier. Le deuxi`eme avantage r´eside dans le fait qu’une op´eration vectorielle

4Acronyme de Very Large Instruction Word.

44 2.1. Parall´elisme des architectures universelles une fois lanc´ee permet de pr´edire les donn´ees qui vont ˆetre acc´ed´ees et les acheminer de fa¸con a` exploiter le pipeline au maximum (minimiser les arrˆets du pipeline pour cause d’atteintes de donn´ees).

1 2 3 4 5 6 7 8 9 11 12 13 14 15

instruction1 FI DI EX WO EX Temps EX EX instruction2 EX FI DI EX WO EX EX EX EX

Instructions

Fig. 2.7: Architecture vectorielle

2.1.1.2 Probl`emes li´es a` l’exploitation du parall´elisme des instructions

Architectures pipeline Si une architecture pipeline apporte un gain th´eorique consid´erable par rapport a` une archi- tecture purement scalaire, en r´ealit´e un tel gain n’est jamais atteint. Les principales raisons pour lesquelles l’acc´el´eration r´eelle diff`ere de l’acc´el´eration th´eorique sont li´ees aux trois types d’al´eas diff´erents : 1. Al´eas structurels - Il s’agit de conflits li´es a` l’exploitation des ressources mat´erielles, lorsque plusieurs instructions doivent acc´eder aux mˆemes ressources mat´erielles en mˆeme temps. L’exemple typique de tels al´eas est le conflit entre deux instructions, issues l’une apr`es l’autre, destin´ees a` la mˆeme unit´e d’ex´ecution, et de longueur diff´erente pour que les ´etapes d’ex´ecution arrivent en mˆeme temps5. 2. Al´eas des donn´ees - Ces al´eas font r´ef´erence aux conflits d’acc`es aux donn´ees (collision d’op´erandes) et on en distingue trois cas particuliers : RAW (Read After Write) - lorsque une instruction en cours d’ex´ecution lit la donn´ee issue de l’instruction pr´ec´edente n’ayant pas encore termin´ee sa phase d’´ecriture (l’instruction en cours obtient l’ancienne valeur qui n’a pas encore ´et´e modifi´ee par l’instruction pr´ec´edente). WAW (Write After Write) - lorsque une instruction en cours ´ecrit avant que l’instruc- tion pr´ec´edente ait termin´e (´ecriture faite dans le mauvais ordre). WAR (Write After Read) - lorsque une instruction en cours ´ecrit la donn´ee avant que celle-ci soit lue par l’instruction pr´ec´edente. Ce dernier al´eas n’intervient jamais lorsque la lecture et l’´ecriture se passent toujours a` des mˆemes moments, mais cela ne doit pas forcement ˆetre toujours le cas.

5Dans un ordinateur de type CISC - (Complex Instruction Set Computer) les instructions sont compos´ees d’un nombre variable de micro-instructions. Par consequent, la taille de mot qui code l’instruction n’est pas constante. Dans une architecture purement RISC - (Reduced Instruction Set Computer) les instructions ont par contre le mˆeme nombre de micro-instructions. Aujourd’hui, mˆeme si le combat entre les d´efenseurs des deux approches continue, les processeurs commerciaux ne sont plus ni purement RISC, ni purement CISC, mais bien un m´elange des deux.

45 Chapitre 2. Architecture universelle

3. Al´eas de contrˆole - Ce type d’al´eas est li´e a` la pr´esence des sauts conditionnels qui impliquent le branchement du code en deux chemins d’ex´ecution exclusifs.

Afin d’´eviter les al´eas et assurer un fonctionnement correct, le pipeline doit ˆetre suspendu ou vid´e. Ces deux actions ont pour cons´equence une perte de cycles machine, ce qui conduit in´evitablement a` un abaissement des performances globales.

Les deux premiers types d’al´eas impliquent que l’ordre d’ex´ecution des instructions a de l’im- portance sur la performance d’ex´ecution d’un programme. Il existe donc un ordre pr´ef´erentiel d’ex´ecution des instructions permettant de minimiser le temps d’ex´ecution total. La recherche de l’ordre optimal d’ex´ecution constitue le probl`eme de l’ordonnancement6, un probl`eme NP - complet7.

Afin de maximiser leur performances, la plupart des processeurs d’aujourd’hui emploient des m´ethodes heuristiques permettant de r´ealiser le meilleur ordonnancement possible des instruc- tions en cours d’ex´ecution. Mais ´etant donn´e la difficult´e du probl`eme d’ordonnancement et le temps qui lui est attribu´e (surtout lorsqu’il s’agit d’ordonnancement en cours d’ex´ecution), les r´esultats sont fort variables. Les meilleurs performances d´ependent encore et toujours de l’intervention de programmeur [Lec99].

Architectures super-scalaires Si l’ordonnancement des instructions est important pour une bonne performance des archi- tectures pipeline, il est d’une importance capitale pour les architectures super-scalaires en raison de la pr´esence de multiples unit´es d’ex´ecution. La performance d’une application va donc d´ependre de la qualit´e du code assembleur g´en´er´e par le compilateur ainsi que des unit´es mat´erielles qui r´ealisent l’ordonnancement.

Afin d’illustrer l’importance de l’ordonnancement sur la performance d’une architecture super- scalaire, prenons l’exemple de deux codes assembleurs suivants (Figure 2.8) qui pourraient ˆetre g´en´er´es par deux compilateurs (ou programmeurs) diff´erents et dans le but de calculer la mˆeme chose : a = b + c + d + e.

Si les deux codes en question sont ex´ecut´es par une mˆeme machine super-scalaire d’ordre 2, le code avec une optimisation de l’ordonnancement sera plus performant mˆeme si l’on compte

6Etan´ t donn´e un programme p, trouver l’ordre optimal des instructions, tel que le temps d’ex´ecution de ce programme p pour une machine M soit minimal. 7Tout probl`eme formalisable et d´ecidable peut ˆetre calcul´e par une machine de Turing (th`ese de Church). Afin d’exprimer la faisabilit´e de calcul d’un probl`eme par un algorithme, on parle de sa complexit´e en temps et la complexit´e en espace qui dans le cas d’une machine de Turing peut ˆetre vu comme le nombre de d´eplacement de la tˆete de lecture/´ecriture et la taille de ruban n´ecessaires. Si pour un probl`eme donn´e la complexit´e de l’algorithme permettant son calcul est une fonction polynomiale (ou exponentielle) de la taille du probl`eme (n) on dit alors que le probl`eme appartient a` la classe P (ou la classe E) des probl`emes. Il existe cependant des probl`emes pour lesquels on ne connaˆıt pas d’algorithme de complexit´e polyno- miale, mais on peut toujours v´erifier une solution propos´ee dans un temps polynomial (machine de Turing non-d´eterministe). De tels probl`emes appartiennent a` la classe dite NP (non-deterministic polynomial) des probl`emes. Un probl`eme NP -complet est un probl`eme NP particuli`erement difficile (au moins tout aussi difficile que toute autre probl`eme NP ) mais avec la propri´et´e que si l’on trouve un algorithme polynomial pour un des probl`emes NP -complet on aurait trouv´e un algorithme polynomial pour tous les probl`emes de la classe NP (r´eduction polynomiale).

46 2.1. Parall´elisme des architectures universelles une instruction a` ex´ecuter en plus (Figure 2.9).

Dans le premier exemple un seul registre est utilis´e et les trois instructions d’addition ne peuvent pas ˆetre ex´ecut´ees de fa¸con concurrentielle. De plus, la deuxi`eme et la troisi`eme addition, doivent attendre la terminaison de l’instruction pr´ec´edente provoquant ainsi un arrˆet de pipeline (les al´eas de donn´ees).

r1 b r1 b ← ← r2 d r1 r1 + c ← ← r1 r1 + c r1 r1 + d ← ← r2 r2 + e r1 r1 + e ← ← r1 r1 + r2 a r1 ← ← a r1 ← Fig. 2.8: Exemple de programmes non-optimis´e et optimis´e pour un processeur super-scalaire

t0 t1 t2 t3 t0 t1 t2 r1 ← b r1 ← b r1 ← r1 + c r2 ← d r1 ← r1 + d r1 ← r1 + c r1 ← r1 + e r2 ← r1 + e r1 ← r1 + r2

Fig. 2.9: Ex´ecution de programme non-optimis´e et optimis´e

Le deuxi`eme code, cette fois-ci avec une autre affectation de registres et un meilleur ordonnan- cement permet une ex´ecution simultan´ee des deux chargements (load) et des deux additions.

A l’heure actuelle, les unit´es d’ordonnancement sont capables d’alt´erer l’ordre des instructions impos´e par l’utilisateur (ou par le compilateur) afin d’exploiter au mieux les ressources dis- ponibles. De plus, elles peuvent changer l’affectation des diff´erents op´erandes a` des registres diff´erents de ceux impos´es par le programme afin d’´eviter les al´eas de donn´ees (Register rena- ming). Mais de telles techniques se montrent efficaces dans des cas particuliers et ne peuvent donc pas ˆetre consid´er´ees comme universelles.

En g´en´eral, on distingue deux types d’ordonnancements diff´erents : l’ordonnancement dy- namique lorsque l’ordre des instructions est ´etabli a` l’ex´ecution du programme par une unit´e mat´erielle d´edicac´ee et l’ordonnancement statique lorsque celui-ci est ´etabli par un programme, lors de la compilation (les architectures VLIW p.e.).

Pour l’ordonnancement dynamique on distingue trois strat´egies diff´erentes selon l’ordre dans lequel sont r´ealis´ees les deux phases de ”vie” d’une instruction : le lancement et la terminaison. 1. Lancement et terminaison des instructions dans l’ordre8 Ici, l’ordre des instructions, tel qu’il apparaˆıt dans le programme, est respect´e pour le 8In Order Issue, In Order Completition

47 Chapitre 2. Architecture universelle

lancement et pour la terminaison. Il s’agit de la plus mauvaise strat´egie d’ordonnan- cement, jamais employ´ee mˆeme pour les processeurs ´emettant qu’une seule instruction par cycle. 2. Lancement selon l’ordre, terminaison dans le d´esordre9 Les instructions sont lanc´ees dans l’ordre, mais peuvent ˆetre termin´ees a` des moments diff´erents de celui impos´e par le programme. 3. Lancement et terminaison des instructions dans le d´esordre10 Les instructions sont d´ecod´ees dans l’ordre dans lequel elles apparaissent dans le pro- gramme et plac´ees dans une fenˆetre d’ex´ecution. Depuis cette fenˆetre d’ex´ecution elles peuvent ˆetre retir´ees pour l’ex´ecution dans un ordre d´etermin´e par l’unit´e d’ordonnan- cement et qui ne doit pas forcement respecter l’ordre impos´e par le programme. Architectures VLIW L’exploitation du parall´elisme au niveau des instructions pour les architectures VLIW est directement li´e a` la capacit´e du compilateur d’extraire le parall´elisme a` partir d’un code ´ecrit en langage de programmation ´evolu´e et de r´ealiser un bon ordonnancement statique des ins- tructions (ce qui n’a rien d’imm´ediat). Un autre d´esavantage r´eside dans la d´ependance des applications du mat´eriel sous-jacent. Tout changement a` l’architecture implique l’incompati- bilit´e des applications r´ealis´ees sur des architectures ult´erieures et par cons´equent n´ecessite une re-compilation pour la nouvelle architecture cible.

2.1.1.3 Parall´elisme des donn´ees

Dans tous les processeurs actuels, les unit´es d’ex´ecution sont sp´ecialis´ees pour le type de donn´ees a` traiter (les entiers et les r´eels). Pour le calcul des entiers la taille maximale des op´erandes est fix´e a` 32, 64, voir 128 bits. Les unit´es d’ex´ecution permettent de r´ealiser en une seule ´etape d’ex´ecution (EX) une quelconque op´eration arithm´etique ou logique pour la taille maximale des op´erandes.

En pratique, la taille des donn´ees ´el´ementaires a` traiter par un programme est nettement inf´erieure a` ces chiffre : un caract`ere de texte ou une composante de couleur d’une image sont des entiers cod´es sur 8 bits. Si les donn´ees seront sauvegard´ees dans la m´emoire de fa¸con a` occuper l’espace qu’il leur est strictement n´ecessaire, l’ex´ecution des instructions se fera toujours a` l’aide de la mˆeme unit´e d’ex´ecution quelle que soit leur taille. Dans cette optique, si les op´erandes sont cod´ees a` l’aide d’un seul octet, l’unit´e d’ex´ecution apparaˆıt comme sous- exploit´ee, car elle ne fonctionne qu’avec 1/4 ou 1/8 de ces capacit´es. Cette sous-exploitation est un mal n´ecessaire si l’on souhaite assurer une mˆeme performance de processeur quelque soit la taille d’op´erandes.

Les extensions a` une architecture standard ont pour but de permettre le meilleur emploi des unit´es d’ex´ecution lorsque la taille de la donn´ee ´el´ementaire (l’op´erande) est plus petite que la taille maximale de l’op´erande pour laquelle cette unit´e a ´et´e initialement pr´evue. En s’inspirant des processeurs vectoriels et du mod`ele SIMD11 de calcul, ces extensions offrent

9In Order Issue, Out Of Order Completition 10Out Of Order Issue, Out Of Order Completition (OOOC) 11Single Instruction Multiple Data

48 2.1. Parall´elisme des architectures universelles un parall´elisme des donn´ees a` l’aide du mat´eriel existant et avec un minimum des ressources mat´eriels suppl´ementaires.

L’int´erˆet de ces extensions est d’autant plus important que l’architecture de la plupart des processeurs actuels est super-scalaire et que le facteur d’acc´el´eration se voit alors multipli´e par le nombre d’unit´es d’ex´ecution int´egr´ees.

En g´en´eral, les extensions de l’architecture standard se pr´esentent sous forme d’un mode de fonctionnement particulier qui nous permet d’acc´eder a` un jeu d’instructions suppl´ementaire, sp´ecifique a` l’extension en question. Ce jeu d’instructions suppl´ementaire int`egre les instruc- tions classiques : de transfert de donn´ees, des op´erations arithm´etiques/logiques, de d´ecalage et de conversion de format, mais qui s’appliquent a` des vecteurs dont la taille d´epend de la taille des op´erandes de l’unit´e d’ex´ecution et de la taille des donn´ees avec lesquelles on travaille.

Certaines de ces instructions sont particuli`erement int´eressantes pour des applications mul- tim´edia et les jeux vid´eo, la raison pour laquelle ces extensions portent les noms qui font souvent r´ef´erence a` ce type d’applications.

2.1.2 Parall´elisme inter-processeur

Mis a` part la classification des syst`emes a` plusieurs processeurs en architectures SIMD et MIMD 12, le parall´elisme inter-processeur peut ˆetre class´e de fa¸con tr`es grossi`ere selon la mani`ere d’exploiter la m´emoire centrale. Ainsi, on distingue les syst`emes a` m´emoire partag´ee et les syst`emes a` m´emoire repartie.

Les syst`emes a` m´emoire partag´ee sont construit autour d’une seule m´emoire centrale partag´ee entre plusieurs processeurs de nombre g´en´eralement faible (de l’ordre de quelques dizaines de processeurs identiques au plus).

Pour les syst`emes a` m´emoire repartie, chaque processeur poss`ede son propre espace m´emoire, mais peut communiquer avec les autres via un r´eseau de communication de topologie et de technologie quelconque. Il s’agit en g´en´eral des syst`emes compos´es d’un grand nombre de processeurs et engendre une certaine redondance de donn´ees.

2.1.2.1 Parall´elisme des syst`emes a` m´emoire partag´ee

Au courant de la derni`ere d´ecennie sont apparus les premiers ordinateurs personnels dot´es de plusieurs processeurs qui partagent une mˆeme m´emoire centrale. L’exploitation de pa- rall´elisme inter-processeur est assur´ee a` haut niveau, par le syst`eme d’exploitation qui pr´esente la caract´eristique de fonctionnement dit en multi-tˆache. De tels syst`emes d’exploitation par- tagent en effet le temps d’un processeur entre diff´erentes applications en cours, de fa¸con que leur ex´ecution apparaˆıt simultan´ee a` l’utilisateur.

12Multiple Instruction Multiple Data

49 Chapitre 2. Architecture universelle

Le fonctionnement avec des processeurs multiples ne fait qu’´etendre la notion de partage des tˆaches entre plusieurs processeurs. Le fonctionnement multi-tˆache d’un syst`eme d’exploitation est ´etroitement li´e aux deux notions fondamentales li´ees a` l’ex´ecution d’un programme : le process et le thread.

Process Un process est d´efini comme un programme charg´e en m´emoire centrale du syst`eme, par le syst`eme d’exploitation ou par l’utilisateur, et en cours d’ex´ecution. Chaque process est d´efini et identifi´e au sein du syst`eme d’exploitation par un ensemble de variables13. Cet ensemble de variables, appel´e le contexte d’ex´ecution, d´efini de fa¸con univoque l’´etat du process. Le syst`eme d’exploitation est le propri´etaire de chaque process et de chaque contexte d’ex´ecution correspondant. Le changement de contexte d’ex´ecution, i.e. partage de temps d’un processeur entre diff´erentes process (tˆaches), comprend la sauvegarde du contexte d’ex´ecution en cours et le chargement du contexte d’ex´ecution du process qui a obtenu le temps processeur.

Le changement de contexte d’ex´ecution peut ˆetre inconditionnel pour des tˆaches qui doivent imp´erativement ˆetre ex´ecut´ees au moment ou elles sont initi´ees : par exemple lors d’une in- terruption syst`eme. Pour toute autre tˆache, le syst`eme d’exploitation sur base d’un certain crit`ere d´ecide de leur attribuer le temps processeur. L’´etablissement de crit`ere pour la prise de d´ecision de changement de contexte d’ex´ecution (l’ordonnancement des tˆaches) peut se faire sur base de strat´egies diff´erentes, ´etablies au pr´ealable et qui r´esultent d’un compromis entre le temps pass´e au calcul pur, la rapidit´e de r´eponse du syst`eme a` l’utilisateur et l’effi- cacit´e de gestion des entr´ees/sorties. Comme l’ordonnancement des instructions, le probl`eme d’ordonnancement des tˆaches n’a pas de solution optimale.

Il est important de savoir que le changement de contexte d’ex´ecution entre les diff´erents pro- cess (tˆaches) n’est pas une op´eration gratuite en termes de temps processeur, bien au contraire. Afin de minimiser le temps perdu lors de changement de contexte et permettre l’ex´ecution d’un plus grand nombre de flots d’instructions ind´ependantes, la plupart des syst`emes d’ex- ploitation actuels int`egrent la notion des threads.

Thread Un thread repr´esente une partie de programme d´ej`a en cours d’ex´ecution, donc un process, mais ex´ecut´ee de fa¸con tout a` fait ind´ependante de ce mˆeme process. Chaque process en cours d’ex´ecution peut d´emarrer un ou plusieurs threads relatives a` la mˆeme ou les diff´erentes parties d’un mˆeme programme. Tous les threads initi´es par un mˆeme process partagent le mˆeme contexte d’ex´ecution, celui de process qui les a cr´ees. Le partage de mˆeme contexte d’ex´ecution implique que les diff´erents threads initi´es par ce mˆeme process partagent un mˆeme espace m´emoire, a` savoir le code et les donn´ees d’un programme.

Chaque thread, tout comme process, est d´efini de fa¸con univoque au moment de sa cr´eation par un ensemble des variables (l’´etat du thread). La quantit´e d’information n´ecessaire pour d´ecrire un thread est nettement inf´erieure compar´ee a` celle n´ecessaire pour d´ecrire un process. De ce fait le passage de l’ex´ecution d’un thread a` l’ex´ecution d’un autre peut se faire avec un moindre coutˆ en temps processeur, d’ou leur int´erˆet.

13Les ´etats des registres du (ou des) processeur(s), les donn´ees associ´ees au process tels que : l’identificateur de process, la priorit´e etc.

50 2.1. Parall´elisme des architectures universelles

D’une mani`ere tout a` fait g´en´erale, la technologie des threads pr´esente les avantages suivantes :

1. Meilleur usage des ressources mat´erielles Aujourd’hui les syst`emes informatiques sont compos´es d’un grand nombre d’unit´es p´eriph´eriques dont les constantes de temps varient fortement. Ecrire´ une application a` travers plusieurs threads permet d’exploiter les diff´erentes ressources mat´erielles a` leur rythme sans pour autant ”bloquer” l’ex´ecution d’autre tˆaches en cours. L’exemple typique est l’attente de donn´ees depuis une unit´e de sauvegarde, g´en´eralement lente, qui n’empˆeche pas l’ex´ecution d’autres tˆaches en cours.

2. Fonctionnement par ´ev´enement Il est souvent n´ecessaire de r´ealiser un traitement particulier pour un ´ev´enement donn´e. La technique traditionnelle implique la r´ealisation d’une boucle qui effectue un polling sur l’´ev´enement en question. Si cette boucle est r´ealis´e au sein d’un thread, celui-ci sera trait´e comme tout autre thread et le temps processeurs lui sera attribu´e. Pour ´eviter cette d´epense inutile de temps processeur, les threads int`egrent la possibilit´e d’ˆetre pi- lot´es par des ´ev´enements - les objets ind´ependants qui ne subissent pas les m´ecanismes habituels d’attente et de gestion propres aux threads. Lorsque un ´ev´enement a lieu, c’est l’objet ´ev´enement qui enverra des messages d`es son activation a` tous les threads qui y sont attach´es. En attendant l’´ev´enement, les threads concern´es peuvent ˆetre mis dans un ´etat bloqu´e et ne plus devoir ˆetre servis par le processeur.

3. Exploitation de parall´elisme inter-processeur Dans le cas d’une machine multi-processeurs, nous disposons d’autant de files d’at- tentes pour l’ex´ecution des threads que des processeurs. De ce fait autant de threads que des processeurs peuvent ˆetre ex´ecut´es simultan´ement. Une application multi-thread peut donc b´en´eficier d’une acc´el´eration lorsqu’elle est ex´ecut´ee sur un syst`eme multi- processeur tout en pr´eservant la compatibilit´e avec un syst`eme mono-processeur.

Dans les deux premiers cas, les threads peuvent am´eliorer le temps d’ex´ecution d’une appli- cation au sein mˆeme d’un syst`eme informatique mono-processeur. Mais le principal avantage des threads r´eside, en ce qui nous concerne, dans la simplicit´e avec laquelle ils permettent d’exploiter le parall´elisme inter-processeur d’un syst`eme multi-processeurs.

Multi threading simultan´e La technologie de multi threading simultan´e permet a` plusieurs threads ind´ependants d’ex- ploiter de fa¸con concurrentielle les diff´erents ressources physiques d’un processeur d’architec- ture super-scalaire. En outre, plusieurs threads ind´ependants peuvent demander l’ex´ecution simultan´ee de plusieurs instructions par chaque cycle machine, a` condition que ces instruc- tions n’utilisent pas les mˆeme ressources physique14. Les ressources mat´erielles du processeur

14Consid´erons par exemple le cas d’un processeur dot´e d’une unit´e de traitement sp´ecialis´ee pour le calcul des entiers et d’une unit´e de traitement sp´ecialis´ee pour le calcul des nombres cod´es en virgule flottante. Deux threads, un compos´e des instructions de calcul uniquement sur les entiers et un deuxi`eme compos´e des instructions de calcul en virgule flottante, peuvent ˆetre ex´ecut´es en mˆeme temps puisque ils ne demandent pas les mˆemes ressources physiques. Dans la technologie traditionnelle des threads, un thread en ex´ecution immobilise toutes les ressources de calcul quelque soit les ressources r´eellement n´ecessaires pour son ex´ecution.

51 Chapitre 2. Architecture universelle peuvent ˆetre donc partag´ees entre plusieurs threads mais en mˆeme temps. L’exploitation de cette technologie permet d’obtenir, pour un ensemble d’applications standards (SPEC), un gain allant jusqu’`a quatre fois plus d’instructions ex´ecut´ees par rapport au mˆeme processeur ne permettant pas ce partage de ressources mat´erielles [TEL95].

L’exemple commercial d’une telle technologie, appel´e hyper-threads [Int01], est disponible sur les processeurs Xeon de chez Intel. Un tel processeur physique apparaˆıt au syst`eme d’exploi- tation comme deux processeurs logiques. Pour un coutˆ faible des ressources mat´erielles, il s’agit seulement de 5 % de la taille du processeur, le gain en performance peut atteindre le chiffre de 65 % pour certains applications [MBH+02].

2.1.2.2 Parall´elisme des syst`emes a` m´emoire repartie

Les syst`emes informatiques a` m´emoire repartie ont dans le pass´e repr´esent´e la classe des super-ordinateurs. Il s’agissait de syst`emes couteux,ˆ difficilement accessibles et destin´es a` l’emploi d’un ensemble d’utilisateurs plutˆot qu’`a l’utilisation d’une seule application.

Actuellement on voit de plus en plus apparaˆıtre des solutions de calcul massivement pa- rall`eles impliquant de r´eseaux des ordinateurs personnels ou de stations de travail, appel´es les clusters. Un ensemble d’ordinateurs personnels, de performance moyenne, donc d’un coutˆ faible, peuvent atteindre la performances de super-ordinateurs, notamment a` cause du grand nombre de processeurs employ´es et de r´eseaux tr`es performants permettant la communication de donn´ees a` haut d´ebit.

2.1.3 Processeurs actuels

Aujourd’hui l’architecture de la plupart des processeurs employ´es dans les syst`emes in- formatiques universels est de type super-scalaire/super-pipeline. Le degr´e de scalarit´e varie entre 2 et 8 et le pipeline comporte entre 6 a` 20 ´etages15.

Tous les processeurs actuels int`egrent des extensions a` l’architecture standard et exploitent le parall´elisme de donn´ees. Ainsi, Intel int`egre deux extensions diff´erentes : l’une destin´e uniquement pour le traitement des entiers - Multi Media Enhancement - MMX et l’autre pour le traitement et des entiers et des r´eels - Streaming SIMD Extension - SSE et SSE2 plus r´ecamment16. Chez MIPS (Silicon Graphics) on parle de Digital Media Extensions - MDMX, chez SUN de Visual Instruction Set - VIS et finalement chez Hewlett Packard de Multimedia Acceleration Extensions 2 - MAX2.

La Tableau 2.1 indique quelques architectures phares des principaux fabricants d’aujourd’hui. On donne ´egalement le nombre d’unit´es de traitement d´edicac´ees au calcul des entiers (E) et au calcul en virgule flottante (VF).

15Le nombre d’´etages de pipeline peut varier fortement d’un producteur a` l’autre selon la strat´egie d’impl´ementation adopt´ee. Ainsi les concepteurs des microprocesseurs UltraSPARC optent pour un plus faible nombre d’´etages de pipeline avec l’argument que l’emploi d’un plus grand nombre d’´etages ne sert qu’`a aug- menter de fa¸con artificielle la vitesse des processeurs bon march´e. 16Pour le concurrent direct d’Intel, AMD, cette extension fort semblable porte le nom 3DNow ! est destin´ee plutˆot pour des applications de la 3D.

52 2.1. Parall´elisme des architectures universelles

Producteur Intel MIPS Sun HP IBM Processeur Pentium4 Itanium2 R14000 UltraSPARC 3 PA-8700[Hew00] PowerPC970 Architecture IA32 EPIC MIPS SparcV9 PA PowerPC UT 3E/2VF 2E/2VF 2E/3VF 4E/4VF 2E/2VF Vitesse(GHz) > 1.5 1 >0.5 1.4 > 0.8 > 1 Extensions SSE2 Max-2 MDMX VIS Max-2 Altivec

Tab. 2.1: Quelques microprocesseurs actuels.

2.1.4 Architectures universelles cibl´ees

Dans cette ´etude, le choix de l’architecture cible a ´et´e port´ee sur le mat´eriel commun, bas´e sur les processeurs actuels de grande s´erie, pour des raisons de leur accessibilit´e, de leur prix et de leur usage universel. L’impl´ementation des diff´erents algorithmes qui seront pro- pos´es et la mesure de leur efficacit´e ont ´et´e effectu´es sur un ordinateur personnel dot´e d’un processeur Pentium 4 fonctionnant a` 1.5 GHz. Ce processeur int`egre les diff´erents niveaux de parall´elisme intra-processeur d´ecrits pr´ec´edemment. Le syst`eme d’exploitation utilis´e est Win- dows 2000, permettant la programmation des threads et donc l’exploitation de parall´elisme inter-processeur.

En ce qui concerne les r´esultats de l’exploitation de parall´elisme inter-processeur, une station dot´e de deux processeurs Pentium 2 fonctionnant a` 450MHz a ´et´e utilis´e. Etan´ t donn´ee l’ˆage certain de ces processeurs, les r´esultats sont donn´ees a` titre indicatif et ont pour but de montrer le facteur d’acc´el´eration relatif lors d’utilisation d’un syst`eme informatique multi-processeur a` m´emoire partag´ee.

Dans ce qui va suivre nous nous contentons de donner une description un peu plus d´etaill´ee du processeur Pentium 4 et seulement souligner les diff´erences majeures par rapport a` l’ar- chitecture de Pentium 2.

2.1.4.1 Architecture standard

La base de l’architecture de processeur Pentium 4 (une description tr`es d´etaill´e peut ˆetre trouv´ee dans ([Int99b], [Int99c], [Int99d]) est le noyau IA-3217 introduit d´ej`a depuis la g´en´eration 386 de la famille . Les diff´erentes g´en´erations qui ont suivi le 386 ont apport´e des modifications majeures a` ce noyau, mais toujours en assurant la compatibilit´e avec des pro- cesseurs des g´en´erations pr´ec´edentes. Le Pentium 4 n’est pas une exception, tout en int´egrant les diff´erents niveaux de parall´elisme dont nous avons parl´e dans la section pr´ec´edente.

Pentium 4 est un processeur : – Super-scalaire d’ordre 3 : trois instructions peuvent ˆetre d´ecod´ees, ex´ecut´ees et retir´ees par chaque cycle machine ; – Super-pipeline : le pipeline d’ex´ecution est compos´e de 20 ´etages ; – CISC : la longueur des mots qui codent les instructions varie entre 8 et 108 bits ;

17Intel Architecture 32.

53 Chapitre 2. Architecture universelle

Pentium 4 int`egre le mod`ele SIMD de calcul a` travers trois extensions a` l’architecture standard MMX18, SSE19 et SSE220.

Pentium4

Cache niveau 1 (L1-8KB)

Cache niveau 2 (L2) Port 0 Port 1 Port 2 Port 3 256KB ALU 1 FP 1 ALU 2 Integer FP 2 Add/Sub move Add/Sub SSE op. Load Store Logic SSE shift MMX Store MMX rotate add Branch mul/div

Fetch/Decode Trace cache (L1)

Out-of-order-execution Unité de retrait

Prédiction de branchement

Fig. 2.10: Architecture de processeur Pentium 4.

Les unit´es d’ex´ecutions sont s´epar´ees pour les nombres entiers et les nombres r´eels. Le noyau de calcul des entiers poss`ede 2 unit´es arithm´etiques/logiques proprement dites, plus une unit´e d´edi´ee uniquement aux op´erations de d´ecalage (indiqu´ees ALU1, ALU2 et Integer op. sur la Figure 2.10). Les deux ALUs fonctionnent a` une vitesse deux fois plus ´elev´ee que l’horloge principale, permettant ainsi la r´ealisation jusqu’`a quatre op´erations arithm´etiques/logiques par un cycle machine.

Le noyau de calcul en virgule flottante est compos´e d’une unit´e arithm´etique/logique propre- ment dite (FP2 de la Figure 2.10) et une unit´e de mouvement des donn´ees entre les registres locaux (FP1). Ces mˆemes unit´es d’ex´ecution sont utilis´ees par les trois extensions a` l’archi- tecture standard. Le choix de sp´ecialisation pour chaque unit´e de calcul en virgule flottante a ´et´e dirig´e par le compromis entre le coutˆ mat´eriel et la performance obtenue. Pour des applications multim´edia standards, le gain de deux unit´es identiques serait trop faible ´etant donn´e que les d´eplacements entre les diff´erents registres ont autant d’importance que le calcul mˆeme [HSU+01].

Aux diff´erentes unit´es d’ex´ecution sont associ´e deux ports d’ex´ecution distincts : le Port 0 regroupe une unit´e d’ex´ecution pour les entiers et l’unit´e de d´eplacement des registres en virgule flottante ; le Port 1 comprends l’autre unit´e d’ex´ecution pour les entiers, l’unit´e de calcul en virgule flottante proprement dit et l’unit´e de d´ecalage des entiers (voir Figure 2.10).

Deux ports d’ex´ecution suppl´ementaires (Port 2 et Port 3) se chargent des acc`es a` la m´emoire :

18Disponible d´ej`a sur certains processeurs Pentium. 19Streaming SIMD Extension, disponible a` partir de la g´en´eration Pentium 3. 20SSE2 est la deuxi`eme g´en´eration de l’extension SSE disponible a` partir de la g´en´eration Pentium 4.

54 2.1. Parall´elisme des architectures universelles l’un pour le chargement des donn´ees vers le processeur et l’autre pour la sauvegarde vers la m´emoire. Une telle architecture permet donc d’´emettre jusqu’`a 6 instructions d’ex´ecution par cycle machine21.

Le processeur Pentium 4 int`egre deux niveaux de la m´emoire cache (L1, L2) dans le mˆeme circuit int´egr´e. La m´emoire cache de niveau 2 est une m´emoire de 256 kB avec une bande passante de 48GB/s22. Une unit´e mat´erielle est d´edi´e a` l’exploitation dynamique (en cours d’ex´ecution) de cette m´emoire en pr´evoyant les acc`es allant jusqu’au 256 octets en amont de l’adresse en cours de lecture. En ce qui concerne la m´emoire cache de niveau 1, elle est s´epar´ee pour les instructions (12 Ko) (Trace Cache) de celle pour les donn´ees (8 Ko). La m´emoire cache de niveau 1 est plus petite que d’habitude, Pentium 3 int`egre deux m´emoires de 32KB s´epar´ees pour les donn´ees et les instructions par exemple, mais ces m´emoires ont l’avantage d’avoir une latence extrˆemement faible.

Le d´ecodage des instructions se fait dans l’ordre impos´e par le programme. Par contre l’ex´ecution des instructions est faite dans le d´esordre (Out-Of-Order-Execution - OOOE). L’unit´e de retrait se charge de respecter l’int´egrit´e de programme initial en r´eorganisant, dans l’ordre impos´e par le programme, les instructions ex´ecut´ees et en g´erant les cas exceptionnels.

Afin de combattre les al´eas structurels23, le Pentium 4 int`egre une unit´e de pr´ediction de branchement permettant, sur base d’un historique et de fa¸con sp´eculative, de d´ecoder les instructions a` ex´ecuter, avant mˆeme que le chemin d’ex´ecution soit r´eellement calcul´e.

2.1.4.2 Extensions

Extension MMX L’extension MMX poss`ede son propre espace m´emoire pour les op´erandes, compos´e de huit registres de 64 bits, appel´es MM0 a` MM7, permettant la sauvegarde de quatre types de donn´ees diff´erents : les entiers cod´es sur 8 (byte), 16 (word), 32 (doubleword) et 64 bits (quadword). Ces registres sont consid´er´es comme des vecteurs de 64 bits, l’interpr´etation de type de donn´ees est r´esolue par l’instruction utilis´ee. La gestion des entr´ees/sorties de registres MM0 a` MM7 se fait a` l’aide des registres de l’architecture standard (General Purpose Registers - GPR).

Tout transfert de donn´ees entre l’espace m´emoire global (m´emoire centrale du syst`eme) et ces registres se fait par une adresse sauvegard´ee dans un des registres GPR pointant vers un bloc contigu de m´emoire de 4 ou 8 octets.

La Figure 2.11 montre le m´ecanisme d’adressage de la m´emoire centrale, le transfert vers l’espace m´emoire pour les op´erandes et la r´esolution de type d’op´erande selon l’instruction utilis´ee. Deux registres GPR edx et ebx pointent vers deux tableaux de donn´ees (huit octets en tout) de la m´emoire centrale. Une seule instruction (movq) effectue le transfert du tableau vers un des registres (mm0 et mm1). Les instructions paddb, paddw, paddq r´ealisent la somme

21Quatre additions sur des entiers, plus un chargement plus une sauvegarde. 22Il s’agit de la bande passante pour le Pentium 4 fonctionnant a` la vitesse de 1.5 GHz. En fait, la bande passante de cette m´emoire est fonction de la vitesse de fonctionnement du processeur mˆeme. 23Il s’agit des sauts conditionnels et inconditionnels, et d’appels de fonctions.

55 Chapitre 2. Architecture universelle des deux registres (mm0 et mm1) en mode byte , word et quadword de 8, 4 et 2 ´el´ements respectivement.

edx 1 8 7 6 5 4 3 2 1 mm0 mov mm0,edx 2 7 6 5 4 3 2 1 0 mm1 mov mm1,ebx mode byte 3 4 15 13 11 9 7 5 3 1 mm1 paddb mm1,mm0 } 5 6 7 ebx 8 2055 1541 1027 513 mm0 mov mm0,edx 0 1798 1284 770 256 mm1 mov mm1,ebx mode word 1 3853 2825 1797 769 mm1 paddw mm1,mm0} 2 3 4 5 134678021 67305985 mm0 mov mm0,edx 6 mode quad word 7 117835012 50462976 mm1 mov mm1,ebx } 252513033 117768961 mm1 paddw mm1,mm0 Mémoire centrale

Fig. 2.11: M´emoire centrale, les registres MMX et r´esolution de type d’op´erande. Avec les quatre types de donn´ees diff´erents, l’extension MMX permet l’utilisation des unit´es d’ex´ecution en mode vectoriel, la taille de vecteur ´etant variable en fonction du type de donn´ees employ´e. Remarquons que le parall´elisme est maximal pour les donn´ees de type octet, ce qui s’av`ere particuli`erement int´eressant pour les applications envisag´ees.

Le jeu d’instructions comprends 6 classes d’instructions diff´erentes : 1. Instructions de transfert entre la m´emoire centrale et les registres et inversement. 2. Instructions arithm´etiques d’addition, de soustraction, de multiplication et de multipli- cation/addition24 sur les donn´ees de type byte, word et doubleword. Ces instructions apparaissent sous deux formes diff´erentes : – Wrap around : le report g´en´er´e par une addition (soustraction) est ignor´e, le r´esultat est tronqu´e25. – Sign´e (ou Non - sign´e) avec saturation : Le r´esultat d’une addition (soustraction) d´epassant la limite permise par la d´efinition du type de donn´ee va saturer le r´esultat a` cette limite permise26. 3. Instructions de comparaison d’´egalit´e et en ”plus grand que” pour tous les types de donn´ees. 4. Instruction de conversion permettant le passage entre les diff´erents types d’entiers. 5. Instructions logiques AND, NAND, OR et XOR. 6. Instructions de d´ecalage a` gauche et a` droite. Extension SSE L’objectif de l’extension SSE est d’apporter le mˆeme mod`ele de calcul SIMD introduit pour

24R´ealise le produit de deux vecteurs et la somme des ´el´ements du vecteur en une seule instruction. 25Par exemple : 11111111 + 00000010 = 00000001 26Par exemple : 11111111 + 00000001 = 11111111

56 2.1. Parall´elisme des architectures universelles les entiers, pour les nombres r´eels. L’espace m´emoire des op´erandes est compos´e de nouveau de huit registres, mais de 128 bits (not´es XMM0 - XMM7), permettant d’utiliser les unit´es d’ex´ecution en mode vectoriel avec quatre ´el´ements27 par vecteur.

Le jeu d’instructions associ´e propose non seulement les instructions de calcul sur des nombres r´eels, mais ´egalement les nouvelles instructions pour le calcul sur des entiers, mais ex´ecutables exclusivement sur les registres de l’extension MMX.

L’extension SSE introduit ´egalement des instructions de contrˆole explicite de la m´emoire cache, permettant d’agir de fa¸con logicielle sur cette m´emoire (chargement des donn´ees depuis la m´emoire centrale, dans la m´emoire cache d’un certain niveaux) et non plus uniquement a` travers l’unit´e mat´erielle de contrˆole.

Extension SSE2 L’apport de l’extension SSE2 est double car les donn´ees qu’elle peut traiter peuvent ˆetre aussi bien les r´eels (cette fois-ci en mode double pr´ecision) que les entiers. Pour les r´eels on retrouve un jeu d’instructions semblable a` l’extension SSE. Pour les entiers, cette extension int`egre toutes les instructions introduites par les extensions MMX et SSE mais sur des registres XMM de 128 bits. Pour les entiers, les unit´es d’ex´ecution apparaissent alors comme des unit´es vectorielles qui doublent le parall´elisme de donn´ees par rapport a` l’extension MMX.

2.1.4.3 Diff´erences entre Pentium 2 et Pentium 4

Etan´ t donn´e que le mat´eriel utilis´e pour explorer le parall´elisme inter-processeur est bas´e sur les processeurs Pentium 2, il est important de constater la diff´erence entre ces deux processeurs. Mˆeme si ces deux architectures partagent le mˆeme noyau IA-32 compatible, les diff´erences entre leurs architectures standard respectives sont significatives. Nous n’allons pas entrer dans les d´etailles des diff´erences de l’architecture standard, l’architecture de Pentium 2 ´etant d´ecrite dans [Int97b]. L’important c’est de souligner qu’au point de vue des extensions le processeur Pentium 2 int`egre uniquement la technologie MMX, avec un jeu d’instructions r´eduit par rapport a` celui de Pentium 4. Les instructions manquantes, h´elas fort utiles dans les applications envisag´ees, seront donc r´ealis´ees a` l’aide des instructions disponibles r´eduisant ainsi la performance globale, comme nous allons le voir par la suite.

2.1.4.4 Performance de la m´emoire

L’´evolution rapide des processeurs au courant des deux derni`eres d´ecennies n’a pas ´et´e suivie par les m´emoires. En effet, les comparaisons (p.e. dans [VL96]) montrent une ´evolution des m´emoires plutˆot lin´eaire et beaucoup plus faible que celle des processeurs. Ainsi, en 1996, les m´emoires pr´esentent une performance 75 fois inf´erieure par rapport a` celle des processeurs. Ce d´es´equilibre a ´et´e combl´e par l’introduction des m´emoires caches28, nettement plus rapides que les m´emoires conventionnelles29. De ce fait la m´emoire d’une architecture universelle doit

27Les nombres r´eels cod´es en virgule flottante en simple pr´ecision n´ecessitent 32 bits de m´emoire. 28Il s’agit des m´emoires statiques de faible temps d’acc`es, mais couteuses.ˆ 29M´emoires dynamiques n´ecessitant le rafraˆıchissement a` des intervalles de temps r´eguliers.

57 Chapitre 2. Architecture universelle

ˆetre consid´er´ee comme un syst`eme complexe compos´e de plusieurs maillons ou sous syst`emes dont les caract´eristiques propres vont influencer la performance globale d’une application.

Le sous syst`eme m´emoire-bus de donn´ees d’un syst`eme informatique va jouer un rˆole tr`es important dans la performance d´efinitive d’une application et en particulier dans les appli- cations de traitement des images ´etant donn´e la quantit´e de donn´ees qui est en jeu. Si nous pouvons calculer la bande passante th´eorique en tenant compte de la vitesse et la largeur de bus30, en r´ealit´e de tels taux de transfert ne seront jamais atteints.

Le Tableau 2.2 montre la performance th´eorique des diff´erents m´emoires du syst`eme consid´er´e.

D´ebit [GB/s] Principale 3.2 Cache L2 48 Cache L1 96

Tab. 2.2: Performance de la m´emoire.

Un simple test impliquant la lecture/´ecriture de donn´ees (pour plus de d´etails voir Section A.4 de l’Annexe A) nous permet de conclure que dans les meilleurs des cas on peut parler des transferts d’un d´ebit r´eel de l’ordre de 1GB/s.

Les temps d’acc`es a` la m´emoire centrale constituent la borne inf´erieure de temps d’ex´ecution, car quelque soit l’algorithme employ´e ce temps sera n´ecessaire pour acheminer les donn´ees de l’image jusqu’au processeur et r´ealiser la sauvegarde de l’image r´esultante.

2.1.5 Exploitation des diff´erents niveaux de parall´elisme

Aux cours des sections pr´ec´edentes nous avons explor´e les diff´erents niveaux de parall´elisme des architectures universelles actuelles et en particulier celles des ordinateurs personnels. Nous avons ´egalement donn´e une description plus pr´ecise des ´el´ements essentiels, a` savoir le processeur et la m´emoire du mat´eriel qui sera utilis´e. Il reste a` d´eterminer dans quelle mesure et comment, un utilisateur peut r´eellement b´en´eficier de tout le potentiel offert par ces syst`emes, car contrairement a` ce que l’on pourrait croire, leur exploitation n’a rien d’imm´ediat.

2.1.5.1 Acc`es au parall´elisme intra-processeur

Le parall´elisme au niveau des instructions (ILP) est r´esolu lors de l’ex´ecution du pro- gramme et reste en dehors de contrˆole explicite de l’utilisateur, surtout si celui-ci ´ecrit un programme a` l’aide d’un langage de programmation ´evolu´e. L’emploi (ou non) de parall´elisme des ce type d´epend exclusivement du code g´en´er´e (qualit´e de compilateur) et de la qualit´e de l’ordonnancement dynamique des instructions. Comme le probl`eme d’ordonnancement n’a

30Pour l’architecture cibl´ee (Intel NetBurst Architecture) le constructeur annonce une vitesse de transmission de 400Mhz pour le bus de 64 bits de large. Ce qui ´equivaut a` des taux de transferts th´eoriques de 3.2 GB/s.

58 2.1. Parall´elisme des architectures universelles pas de solution optimale, l’utilisateur peut seulement esp´erer que toutes les ressources dispo- nibles au sein d’une architecture super-scalaire / super-pipeline seront effectivement utilis´ees au mieux et que la performance obtenue sera la meilleure possible.

Si une telle approche de l’exploitation de parall´elisme ILP peut offrir des r´esultats satisfaisants dans plupart de cas, les performances obtenues ne seront certainement pas les meilleures. Afin d’am´eliorer le temps d’ex´ecution d’un programme ´ecrit en langage ´evolu´e, il est possible de proc´eder a` l’optimisation du code en suivant les directives connues, issues d’une profonde connaissance du mat´eriel et du comportement du compilateur employ´e. Certaines de ces directives sont ´edict´ees par le fabricant mˆeme (pour les processeurs Intel on peut consulter [Int97a] et [Int99e] p.e.). D’autres, bas´ees sur des exp´eriences personnelles de gens travaillant dans le domaine peuvent provenir de sources moins officielles telles que diff´erents groupes de discussion cr´e´es autour de ce sujet.

Il faut cependant souligner que de telles optimisations sont souvent ´etroitement li´ees a` une architecture bien pr´ecise et peuvent ne pas ˆetre applicables sur d’autres processeurs, mˆeme s’il s’agit des processeurs d’une mˆeme famille mais de g´en´erations diff´erentes. Ainsi, certaines recommandations valables pour le processeur Pentium 3 ne sont plus d’actualit´e et ne doivent plus ˆetre prises en compte ´etant donn´e les changements apport´es sur l’architecture de proces- seur Pentium 4[Int99e].

Une approche moins empirique a` l’optimisation du cod´e g´en´er´e consiste en l’emploi des outils sp´ecifiques de simulation et d’analyse des programmes ex´ecutables. Pour les processeurs Intel, il s’agit de l’outil VTune [Wol99] permettant de simuler l’ex´ecution du programme et offrir a` l’utilisateur les informations pr´ecises sur son fonctionnement ´etant donn´e un processeur particulier.

A l’aide de logiciel VTune il est possible d’envisager l’analyse d’un programme a` deux niveaux diff´erents : – Analyse au niveau de programme : l’identification des goulots d’´etranglements au sein d’un programme volumineux faisant appel a` beaucoup de fonctions diff´erentes. Il s’agit d’une analyse macroscopique de l’application.

– Analyse au niveau d’une fonction : analyse des instructions au niveau assembleur d’une fonction particuli`ere.

Grˆace a` ce deuxi`eme niveau d’analyse, particuli`erement int´eressant dans notre cas, un pro- grammeur peut ´etudier non seulement l’exploitation du parall´elisme des instructions : usage des pipelines (leur suspensions et/ou attentes), l’ordonnancement des instructions et l’usage des diff´erents unit´es d’ex´ecution, mais ´egalement l’exploitation de la m´emoire cache, le facteur clef d’une application performante.

En ce qui concerne l’exploitation des extensions a` l’architecture standard, le compilateur C/C++ de chez Intel peut, dans certaines conditions d´enicher au sein d’un code ´ecrit en langage ´evolu´e, le parall´elisme de donn´ees et le traduire en langage machine sp´ecifique pour ces extensions. Si l’utilisateur veut ˆetre surˆ que son application b´en´eficie pleinement de ces extensions il est oblig´e de les programmer de mani`ere explicite.

Pour ce faire nous avons le choix entre :

59 Chapitre 2. Architecture universelle

1. La programmation en assembleur, possible mˆeme au sein d’un langage de programma- tion ´evolu´e grˆace a` la capacit´e de certains compilateurs de traiter le code assembleur en ligne (“in-line assembly”).

2. L’emploi des fonctions intrinsics (d´evelopp´ees par Intel) qui codent les instructions assembleur des extensions avec une syntaxe de langage C. L’avantage des fonctions in- trinsics est dans une programmation plus claire : on peut travailler avec les variables plutˆot que des registres, et plus universelle car tous les compilateurs n’int`egrent pas la possibilit´e de traiter le code assembleur en ligne.

Dans le cadre de cette ´etude j’ai opt´e pour la premi`ere approche, afin d’ˆetre le plus pr`es possible de la machine et minimiser l’influence de la qualit´e des diff´erents outils sur le r´esultat final. Le compilateur utilis´e pour le d´eveloppement de l’application est le Microsoft Visual C++ 6.031, quoique son rˆole est r´eduit au minium lorsqu’il s’agit de traiter le code assembleur en ligne. Tout programme est analys´e et optimis´e au niveau microscopique a` l’aide de logiciel VTune32.

2.1.5.2 Acc`es au parall´elisme inter-processeur

Les syst`emes d’exploitation WindowsNT et Windows2000 utilis´es int`egrent tous les deux les notions du process et du thread expos´e dans la section 2.1.2.1. Pour ces syst`emes d’exploi- tation une application en cours d’ex´ecution est appel´ee un module. Un module est compos´e du code (le programme mˆeme), des donn´ees et des ´eventuelles ressources suppl´ementaires n´ecessaires pour l’ex´ecution (les librairies dynamiques p.e.). A chaque module cr´e´e, le syst`eme d’exploitation attache automatiquement un process, c’est a` dire un contexte d’ex´ecution et un thread initial a` travers qui l’ex´ecution du programme a effectivement lieu.

Si le mat´eriel sous-jacent poss`ede plusieurs processeurs, a` chaque processeur disponible, le syst`eme d’exploitation associe une file d’attente des threads a` ex´ecuter. Lorsque l’ex´ecution d’un thread est demand´e, le syst`eme d’exploitation va l’attribuer a` la premi`ere file d’attente la moins charg´ee. Sur une machine multi-processeur, plusieurs threads ´emis l’un apr`es l’autre, peuvent donc ˆetre ex´ecut´es par diff´erents processeurs de fa¸con concurrentielle. L’attribution des diff´erents threads aux diff´erents processeurs est faite de fa¸con automatique et apparaˆıt transparente a` l’utilisateur.

Les syst`emes d’exploitation envisag´es permettent a` l’utilisateur d’acc´eder aux diff´erents ser- vices concernant les threads a` travers des fonctions sp´ecifiques, de haut niveau, regroup´ees au sein de l’interface API - Application Programming Interface, appel´e Win32. Mis a` part des fonctions ´evidentes de cr´eation, de suspension et de destruction d’un thread, il est possible de prendre contrˆole explicite d’un processeur sp´ecifique. Attribuer un thread pr´ecis a` un pro- cesseur pr´ecis33 peut apporter un facteur d’acc´el´eration proche de 3 pour les applications en traitement des images[CD99]. Il est donc pr´ef´erable de partager la charge de calcul entre les

31Service Pack 6, avec Processor Pack 5.0 32VTune versions 5.0 et 7.0 33Les fonctions API SetThreadIdealProcessor(), SetThreadAffinityMask()

60 2.1. Parall´elisme des architectures universelles diff´erents processeurs de fa¸con manuelle, plutˆot que de se fier aux automatismes propos´es par le syst`eme d’exploitation mˆeme.

Les diff´erentes fonctions API ont ´et´e int´egr´ees au sein d’une classe sp´ecifique de la librairie Microsoft Foundation Classes - MFC, fourni avec le compilateur Visual C++. L’exploitation de parall´elisme inter-processeur apparaˆıt alors triviale si son exploitation consiste a` ex´ecuter le mˆeme code, c’est a` dire la mˆeme fonction (le mˆeme filtre) a` travers plusieurs threads diff´erents avec les donn´ees provenant de la mˆeme image ou des images diff´erentes.

61 Chapitre 2. Architecture universelle

2.2 Exploitation de l’architecture standard

Le premier objectif de l’impl´ementation des filtres non-lin´eaires sur des architectures uni- verselles vise l’emploi de l’architecture standard d’un ordinateur personnel. Pour r´ealiser les diff´erents filtres, nous allons nous baser sur des algorithmes de tri bien connus, cod´es avec un langage de programmation ´evolu´e, C++ en l’occurrence, tout en faisant l’abstraction du mat´eriel utilis´e. C’est une approche qualifi´ee de ”boite noire”, car les connaissances n´ecessaires pour une telle r´ealisation se limitent uniquement a` la description de l’algorithme employ´e et aux r`egles de codage impos´ees par le langage de programmation choisi.

Dans cette approche nous faisons distinction entre deux types de r´ealisations diff´erentes : 1. Impl´ementation de filtre de rang g´en´eralis´e Il s’agit d’une seule proc´edure (d’un seul algorithme) qui permet le calcul d’une multi- tude de filtres. En fait, le rang recherch´e apparaˆıt comme un argument de la fonction en question. Il est important de souligner que le choix de filtre (le choix de rang) n’influence pas la performance de l’algorithme. 2. Impl´ementation des filtres sp´ecifiques Si l’impl´ementation d’un filtre de rang g´en´eralis´e est tr`es int´eressante, principalement a` cause de son caract`ere universel, la r´ealisation des filtres sp´ecifiques est a priori plus avantageuse puisque la connaissance du rang recherch´e conduit a` des algorithmes (proc´edures) plus performantes. Les deux approches d’impl´ementation envisag´ees vont faire appel a` des algorithmes de tri fortement d´evelopp´es dans les ann´ees ’70, lors de la perc´ee des premiers ordinateurs, machines parfaitement adapt´ees a` ce genre de tˆaches.

Actuellement on compte des dizaines d’algorithmes de tri diff´erents, chaque algorithme ayant de nombreuses variantes permettant d’am´eliorer la performance dans des cas particuliers. Le choix d’un algorithme a` employer va d´ependre de nombreux facteurs tels que le nombre d’´el´ements a` trier, la distribution initiale des ´el´ements au sein de la suite (si la suite est compl`etement ou partiellement d´esordonn´ee ou si la suite est d´ej`a tri´ee), la diff´erence de coutˆ entre la comparaison et le d´eplacement des ´el´ements (les facteurs li´es au mat´eriel) etc.

Notre objectif n’est pas de comparer tous les algorithmes de tri existants, mais de d´eduire l’effi- cacit´e r´eelle, celle de l’impl´ementation, de ceux les plus couramment utilis´es. Les algorithmes employ´es sont largement d´ecrits dans la litt´erature sp´ecialis´ee (on peut voir par exemple [Knu73, Sed98, PTVF02]), mais les impl´ementations propos´ees permettant de quantifier de fa¸con pr´ecise le temps de calcul obtenu lorsqu’il s’agit de les appliquer au probl`eme des filtres non-lin´eaires et ceci pour quelques tailles de voisinages les plus couramment utilis´ees.

Le traitement a ´et´e effectu´e sur l’image de r´ef´erence, une image en niveaux de gris de 1024x1024 pixels cod´es sur 8 bits, et ceci pour les tailles de voisinages les plus couramment utilis´es : 3 3 (9 valeurs), 5 5 (25 valeurs), 7 7 (49 valeurs). × × × Les temps d’ex´ecution donn´es repr´esentent une moyenne de 25 temps d’ex´ecution (cf. Annexe A.2) obtenus pour le traitement de la mˆeme image lorsque celle-ci se trouve dans la m´emoire centrale du syst`eme (le temps de chargement de l’image dans la m´emoire centrale depuis la source, disque dur en l’occurrence, n’est pas pris en compte).

62 2.2. Exploitation de l’architecture standard

Sur base des temps d’ex´ecution obtenus et la vitesse de processeur nous pouvons d´eduire le nombre d’instructions ´el´ementaires a` ex´ecuter : les BOPs (cf. Section 1.5.2.3), n´ecessaire pour produire un pixel de l’image r´esultante.

La priorit´e de process et de thread ex´ecutant ces proc´edures a ´et´e fix´ee a` la plus haute valeur possible (cf. Annexe A.3.2), afin d’´eviter l’interference avec d’autres threads en cours d’ex´ecution.

2.2.1 Impl´ementation de filtre de rang g´en´eralis´e

2.2.1.1 Tri a` bulle (Bubble sort)

Le tri a` bulle consiste a` comparer un a` un tous les ´el´ements adjacents de la suite (Vi) a` trier, en les permutant s’ils ne respectent pas l’ordre de tri souhait´e. Les permutations auront lieu tant que la suite enti`ere n’est pas compl`etement tri´ee. La complexit´e de cet algorithme est de O(n2), ou` n repr´esente le nombre d’´el´ements a` trier, mais peut approcher O(n) dans les meilleurs des cas, lorsque la suite est d´ej`a tri´ee.

Malgr´e la complexit´e ´elev´ee de cet algorithme et de sa tr`es mauvaise r´eputation, son utilisation peut ˆetre justifi´ee lorsque n est petit, principalement a` cause d’une extrˆeme simplicit´e de code correspondant. Les diverses techniques, notamment concernant la condition d’arrˆet peuvent am´eliorer le temps d’ex´ecution d’une proc´edure bas´ee sur cette algorithme, mais ce gain est observable uniquement lorsque n est grand (de l’ordre de mille).

Le Tableau 2.3 montre les r´esultats de la proc´edure bas´ee sur l’algorithme de tri a` bulle.

Voisinage 3 × 3 5 × 5 7 × 7 Proc´edure T[sec] σ BOPs T[sec] σ BOPs T[sec] σ BOPs Pr-1. Bulle 0.474 0.01 716 3.552 0.06 5373 11.741 0.1 17764

Tab. 2.3: Tri a` bulle.

2.2.1.2 Tri par s´election (Selection sort)

Dans cet algorithme de tri on effectue la recherche d’un ´el´ement pour une position par- t ticuli`ere de la future suite tri´ee Vi . Ainsi, pour le premier ´el´ement d’une suite croissante on cherchera le minimum (ou le maximum dans le cas d’une suite d´ecroissante) de la suite enti`ere a` trier. Lorsqu’un tel ´el´ement a ´et´e trouv´e, il est permut´e avec le premier ´el´ement. La recherche de l’´el´ement de la position suivante peut ensuite avoir lieu, avec le parcours qui se fait uniquement sur la partie de la suite non tri´ee. Le mˆeme proc´ed´e est r´ep´et´e tant que la derni`ere position de la suite tri´ee n’ait pas trouv´ee.

Cette m´ethode ne convient pas pour des tableaux partiellement tri´e, car la recherche d’une position particuli`ere implique le parcours complet du tableau. La complexit´e th´eorique de

63 Chapitre 2. Architecture universelle cet algorithme est O(n2), mˆeme d’ailleurs comme pour le tri a` bulle, mais la performance d’une proc´edure peut s’av´erer meilleure principalement a` cause d’un plus petit nombre de permutations a` r´ealiser.

En effet, les r´esultats du Tableau 2.4 montrent une am´elioration par rapport au tri a` bulle, plus importante lorsque le voisinage devient grand.

Voisinage 3 × 3 5 × 5 7 × 7 Proc´edure T[sec] σ BOPs T[sec] σ BOPs T[sec] σ BOPs Pr-2. S´election 0.487 0.012 737 2.356 0.036 3564 6.691 0.114 10123

Tab. 2.4: Tri par s´election.

2.2.1.3 Tri par insertion (Insertion sort)

Dans la m´ethode de tri pas insertion, pour chaque ´el´ement Vi de la suite a` trier on cherche un index m de la suite tri´ee V t tel que V t[m 1] < V t[m] (ou V t[m 1] > V t[m]). Tous les i i − i i − i ´el´ements de la suite tri´ee a` partir de l’index m doivent ˆetre d´ecal´es d’une place pour permettre l’insertion de ce nouvel ´el´ement. L’algorithme est ensuite r´ep´et´e tant qu’il existe des ´el´ements a` ins´erer.

Nous constatons l’existence des deux boucles : une pour la recherche de l’index m et la deuxi`eme pour le d´eplacement des ´el´ements. Nous en d´eduisons que dans le meilleur des cas (la suite est d´ej`a tri´ee) la complexit´e algorithmique est de O(n), tandis que dans le pire des cas (la suite est tri´ee mais dans l’ordre inverse) la deuxi`eme boucle sera toujours ex´ecut´ee et la complexit´e algorithmique passe alors a` O(n2).

Les r´esultats (Tableau 2.5) se montrent assez proches de ceux obtenus par l’algorithme de s´election.

Voisinage 3 × 3 5 × 5 7 × 7 Proc´edure T[sec] σ BOPs T[sec] σ BOPs T[sec] σ BOPs Pr-3. Insertion 0.464 0.011 702 2.107 0.064 3188 5.631 0.135 8520

Tab. 2.5: Tri par insertion.

2.2.1.4 Tri rapide (Quicksort)

Dans la version de base un ´el´ement de la suite non tri´ee est choisi arbitrairement - le pivot. On construit ensuite deux suites : une, dont tous les ´el´ements sont plus petits de pivot choisi et une autre avec des ´el´ements plus grands (la phase de partition). Les ´el´ements de ces deux suites sont ensuite tri´es r´ecursivement (la phase de tri proprement dit).

64 2.2. Exploitation de l’architecture standard

Le tri rapide est le plus grand classiques de tous les algorithmes de tri. Sa complexit´e moyenne est O(nlogn). Dans le pire des cas, lorsque le choix de pivot produit des sous tableaux compl`etement d´esordonn´ees, la complexit´e passe a` O(n2). Le grand avantage de tri rapide est li´e a` l’efficacit´e de l’impl´ementation qui approche r´eellement la complexit´e th´eorique. Les programmes de tri rapide se montrent plus performants compar´es aux programmes bas´es sur des algorithmes dont la complexit´e th´eorique dans le pire des cas est O(nlogn). Le seul in- conv´enient de cette m´ethode r´eside dans son caract`ere r´ecursif, car une importante partie de temps est consomm´ee dans la sauvegarde et la r´ecup´eration de l’´etat du processeur lors d’appels r´ecursif. Il est possible de se d´ebarrasser compl`etement de la r´ecursivit´e mais au d´etriment d’une importante complexit´e de programmation.

Il existe de nombreuses variantes de cet algorithme qui visent a` am´eliorer les trois principales phases de la m´ethode, a` savoir : le choix de pivot, la partition et le tri proprement dit.

L’algorithme de tri rapide ´equilibr´e (Balanced quicksort algorithm) concerne le choix de pivot en introduisant la recherche et la s´election du pivot de tel fa¸con pour que a` chaque fois il approche au mieux la valeur m´ediane. Ainsi on ´evite le cas de la performance th´eorique la plus basse ou les sous-tableaux sont compl`etement d´esordonn´es.

Une autre am´elioration mais concernant cette fois-ci la phase de la partition est directement inspir´e de un algorithme connu sous le nom de Dutch Natinal Flag - DNF ([Dij76], [McM78] et [Bit82]). Il s’agit d’un algorithme permettant de classer les balles de trois couleurs diff´erents (bleue, blanc et rouge), m´elang´ees au d´epart, en une suite qui rappelle le drapeau national hollandais. Au d´ebut, la suite des balles est divis´ee en quatre zones (il s’agit bien des indexes diff´erents de la mˆeme suite) rouge, blanc, gris et bleue marqu´ees par des pointeurs r, w, g et b. La m´ethode consiste a` choisir arbitrairement une balle non class´ee (une balle de la zone grise) et de s’interroger sur sa couleur. Si elle est bleue elle sera ´echang´ee avec la derni`ere balle grise ; si elle est blanche elle sera ´echang´ee avec la premi`ere balle grise ; si elle est rouge elle sera ´echang´e avec la premi`ere blanche puis cette blanche sera ´echang´ee avec la premi`ere rouge. A la fin de chaque op´eration les pointeurs sur des zones diff´erents sont mis a` jour.

Il est possible d’appliquer le mˆeme principe pour r´ealiser le tri d’une suite de nombres. Le crit`ere permettant de diviser la suite en trois zones n’est plus la couleur mais bien la valeur du pivot. Si un ´el´ement non tri´e est ´egal a` la valeur de pivot nous faisons grandir la zone blanche ; si cette valeur est plus petite nous ´echangeons les ´el´ements en cours de la zone blanche et bleue (les zones bleu et blanc grandissent) ; si cette valeur est plus grande nous l’´echangeons avec la valeur courante de la zone rouge en diminuant la zone rouge (Figure 2.12).

Bleue Blanc Gris Rouge

b w g r

Fig. 2.12: Algorithme :Dutch Natinal Flag

Afin de diminuer l’effet de la r´ecursivit´e sur le temps d’ex´ecution, il est conseill´e, lorsque la taille de la suite est de l’ordre d’une dizaine d’´el´ements, de faire le tri a` l’aide d’autres

65 Chapitre 2. Architecture universelle m´ethodes plus adapt´ees a` un tel type de tri. Pour la r´ealisation d’un tel algorithme hybride, le tri a` bulle a ´et´e utilis´e.

L’algorithme de base, l’algorithme avec l’am´elioration de la phase de partition (Dutch natinal Flag) et l’algorithme hybride ont ´et´e r´ealis´e et leur performance ´evalu´ee (Tableau 2.6). Les proc´edures am´elior´ees montrent un gain non n´egligeable par rapport aux algorithmes d´ecrits pr´ec´edemment.

Voisinage 3 × 3 5 × 5 7 × 7

Proc´edure T[sec] σ BOPs T[sec] σ BOPs T[sec] σ BOPs Pr-4. Rapide de base 0.591 0.008 894 2.257 0.017 3415 4.732 0.015 7160 Pr-5. Rapide DNF 0.760 0.014 1150 2.205 0.036 3337 4.014 0.041 6074 Pr-6. Rapide Hybride33 0.5 0.005 756 1.795 0.006 2716 3.845 0.009 5818

Tab. 2.6: Diff´erentes versions du tri rapide.

2.2.1.5 Tri par fusion (Merge sort)

Le tri par fusion est un algorithme bas´ee sur le principe diviser pour r´egner, tout comme le tri rapide. Le d´eroulement de l’algorithme comprends ´egalement trois phases. Dans la phase initiale la suite est divis´ee en deux parties, qui sont ensuite tri´ees r´ecursivement. Dans la derni`ere phase les deux suites tri´ees sont fusionn´ees.

La complexit´e th´eorique de cet algorithme est O(nlogn) dans tous les cas. Pour effectuer le tri, l’algorithme n´ecessite un espace m´emoire suppl´ementaire, proportionnel a` la taille de la suite. Lors d’utilisation de cet algorithme dans la r´ealisation d’un filtre de rang g´en´eralis´e, mˆeme pour des voisinages tr`es grands, ceci n’est pas vraiment un inconv´enient ´etant donn´e la taille actuelle des m´emoires centrales.

Comme pour le tri rapide il est possible d’utiliser des m´ethodes moins efficaces lorsque la taille de la suite devienne petite, mais ceci n’est int´eressant que pour des suites compos´ees de plusieurs milliers d’´el´ements.

Les r´esultats obtenus (Tableau 2.7) sont de loin les plus mauvais par rapport aux algorithmes d´ecrits pr´ec´edemment, duˆ principalement a` la lourdeur de son codage.

Voisinage 3 × 3 5 × 5 7 × 7 Proc´edure T[sec] σ BOPs T[sec] σ BOPs T[sec] σ BOPs Pr-7. Fusion 1.885 0.008 2852 6.344 0.029 9598 12.81 0.031 19378

Tab. 2.7: Tri par fusion.

33Le tri hybride est r´ealis´e avec le tri a` bulle lorsque la taille de tableau est inf´erieure a` 10.

66 2.2. Exploitation de l’architecture standard

2.2.1.6 Tri par tas (Heap Sort)

L’algorithme consiste a` cr´eer le ”Heap”, un arbre binaire ayant la propri´et´e suivante : la valeur contenue dans le noeud parent est plus grande (ou plus petite) que celle de ces deux enfants. Cette propri´et´e reste valable pour tous les enfants.

La m´ethode de tri consiste donc a` construire le ”heap” dans un premier temps et d’y effectuer la recherche d’un ´el´ement pour un rang r pr´ecis par la suite. La complexit´e de cet algorithme est O(nlogn) dans tous les cas.

Le principal inconv´enient de cette m´ethode r´eside dans la lourdeur de son impl´ementation, qui en moyenne ne pr´esente pas des aussi bons r´esultats que le tri rapide, comme le montre les r´esultats du Tableau 2.8.

Voisinage 3 × 3 5 × 5 7 × 7 Proc´edure T[sec] σ BOPs T[sec] σ BOPs T[sec] σ BOPs Pr-8. Fusion 0.888 0.012 1344 3.349 0.022 5067 7.43 0.02 11241

Tab. 2.8: Tri par tas.

2.2.1.7 Tri par classement (Bucket sort)

Le principe de cet algorithme consiste en classement des ´el´ements a` trier ayant la mˆeme valeur qu’un certain attribut, par exemple le premier chiffre d’une suite des nombres, dans des groupes (classes) ind´ependants. Apr`es cette premi`ere phase de groupement, les diff´erentes classes sont ensuite tri´ees individuellement35. La concat´enation des diff´erents groupes permet d’aboutir au r´esultat final : la suite tri´ee.

Un tel algorithme apparaˆıt particuli`erement adapt´e au calcul des filtres non-lin´eaires, car le nombre des valeurs diff´erentes utilis´ees pour coder la couleur est faible : pour des pixels cod´es sur 8 bits nous n’avons que 256 valeurs diff´erents. Il est donc tout a` fait envisageable de choisir comme attribut de classement la couleur et travailler avec 256 classes diff´erentes. Dans ce cas, le groupe (ou ”le seau”) n’est rien d’autre qu’un histogramme local du voisinage consid´er´e 36.

Dans sa version adapt´ee au filtre de rang g´en´eralis´e, l’algorithme commence par le calcul d’un premier histogramme local H de voisinage Vi. Sur base de cet histogramme la valeur K (index de la couleur) qui correspond au rang r recherch´e est trouv´ee en sommant (en comptant) le nombre de pixels pour chaque valeur de niveau de gris tant que cette somme soit inf´erieure a` K la valeur de rang r ( k=0 = H(k) < r).

La recherche de la valeurP correspondante au rang r de voisinage suivant Vi+1 est faite a` partir d’un nouvel histogramme, calcul´e tous simplement en ”retirant” la premi`ere colonne (ou la

35Ceci n’est pas toujours n´ecessaire, notamment lorsque le nombre d’´el´ements diff´erents correspond au nombre de classes choisies. 36Pour cette raison, le tri par classement est ´egalement appel´e le tri par histogramme ou encore le tri par comptage.

67 Chapitre 2. Architecture universelle ligne) de l’histogramme calcul´e pr´ec´edemment et en y ”rajoutant” la colonne (ou la ligne) suivante de l’image. Ainsi, le calcul de la valeur filtr´ee de voisinage suivant n’implique que tr`es peu d’op´eration suppl´ementaires.

La Figure 2.13 montre le principe de d´eplacement de la fenˆetre, n´ecessaire pour le calcul des histogrammes suivants37 : 1 2 3 1 2 3

Fig. 2.13: Construction de la fenˆetre glissante.

et le Listing 2.1 le pseudo-code correspondant.

1 CalculHistogramme ( ) ; // c a l c u l d ’ un p r e m i e r histogramme 2 for ( j =0; j

L’avantage majeur de tri par classement r´eside dans la complexit´e algorithmique th´eorique qui n’est plus fonction de taille de voisinage mais de nombre de classes, des groupes, d´etermin´e par le nombre de bits utilis´es pour la quantification d’un pixel de l’image. De ce fait, un tel algorithme devrait pr´esenter une tr`es bonne performance mˆeme pour des voisinages de tr`es grande taille.

Il faut cependant noter que la performance r´eelle d’une proc´edure bas´ee sur cet algorithme et r´ealis´ee en pratique est influenc´ee par la taille du voisinage, en fait d’une de ses dimensions, lorsqu’il s’agit de retirer et d’ajouter des colonnes (des lignes) pour le calcul de l’histogramme.

37Pour cette raison cet algorithme est ´egalement appel´e l’algorithme de la fenˆetre glissante.

68 2.2. Exploitation de l’architecture standard

Le temps d’ex´ecution d´efinitif va d´ependre ´egalement de la valeur de rang recherch´ee, suite au parcours de l’histogramme. Le cas des filtres Min/Max, lorsque r = 1, r = NV , est le cas le plus favorable car il s’agit de trouver un premier ´el´ement dans l’histogramme en faisant NV son parcours dans le sens qui conviens le mieux. Le cas d’un filtre m´edian, lorsque r = 2 , est le cas le plus d´efavorable car il faut r´ealiser la somme des valeurs de l’histogramme pour arriver a` la valeur de rang r. Signalons enfin que le temps d’ex´ecution d´ependra du contenu de l’image38.

La Table 2.9 indique la performance de cet algorithme pour des voisinages habituels et montre la diff´erence entre les deux cas extrˆemes : le filtre Min/Max et le filtre M´edian.

Voisinage 3 × 3 5 × 5 7 × 7 Proc´edure T[sec] σ BOPs T[sec] σ BOPs T[sec] σ BOPs Pr-9 a). Classement-Min/Max 0.265 0.01 525 0.290 0.01 442 0.347 0.01 529 Pr-9 b). Classement-M´ed 0.413 0.02 625 0.433 0.02 656 0.459 0.02 694

Tab. 2.9: Tri par classement - filtres Min/Max, M´edian.

Pour illustrer l’efficacit´e de cet algorithme lorsqu’il s’agit de calculer les filtres de rang pour des voisinages de tr`es grande taille, nous comparons, a` la Table 2.10, la performance d’un algorithme de tri classique performant : l’algorithme de tri rapide hybride et l’algorithme de tri par classement.

La colonne Rapide donne le temps d’ex´ecution ainsi que le nombre de BOPs correspondant au tri rapide hybride. Rappelons ici que dans le cas de cette algorithme les temps d’ex´ecution sont les mˆemes quelque soit la valeur de rang r recherch´e (i.e. quelque soit le filtre choisi).

La colonne Classement montre les r´esultats de l’algorithme de tri par classement pour les deux cas limites : filtres Min/Max et le filtre m´edian, ainsi que le facteur d’acc´el´eration obtenu par rapport au tri rapide hybride.

Rapide Classement Min/Max M´edian

T1 T1 Voisinage T1[sec] BOPs T2[sec] BOPs Acc = T3[sec] BOPs Acc = T2 T3 9 × 9 6.72 10182 0.28 431 24 0.53 808 12 11 × 11 10.5 15887 0.27 411 39 0.52 800 20 15 × 15 20.93 31670 0.32 479 65 0.56 860 37 25 × 25 64.33 97338 0.41 619 156 0.66 1002 97 35 × 35 131.78 199392 0.51 776 258 0.71 1088 186

Tab. 2.10: Tri par classement pour des grandes voisinages.

38La recherche des minima dans une image sombre (ou des maxima dans une image claire) est plus rapide que la recherche des minima dans une image claire (ou des maxima dans une image claire).

69 Chapitre 2. Architecture universelle

2.2.2 Impl´ementation des filtres sp´ecifiques

Les algorithmes employ´es pour la r´ealisation d’un filtre de rang g´en´eralis´e effectuent le tri complet du voisinage donn´ee. Or ceci n’est pas vraiment n´ecessaire si la valeur de rang est connue avant le traitement mˆeme. Pour certains algorithmes, tel que l’algorithme de tri par s´election, il est possible d’arrˆeter le tri avant, d`es que le rang recherch´e a ´et´e trouv´e et ainsi diminuer le nombre d’op´erations a` effectuer.

Comme dans le cas de tri par classement, la performance d’un tel algorithme d´epend de la valeur du rang recherch´e. En effet, plus le rang recherch´e est grand, plus on doit avancer dans l’op´eration du tri et a` nouveau deux cas extrˆemes se pr´esentent :

1. La recherche de minimum (ou de maximum) - l’algorithme est le plus performant car dans les deux cas il ne faut parcourir le voisinage complet qu’une seule fois 2. La recherche de la valeur m´ediane - c’est le cas le plus d´efavorable puisqu’il faut parcourir NV NV 2 fois le voisinage pour en enlever syst´ematiquement les 2 minima (ou des maxima) pour arriver a` la valeur m´ediane

Le Tableau 2.11 montre la performance de l’algorithme de tri par s´election modifi´e pour les deux cas extrˆemes a` savoir les filtres Min/Max et M´edian.

Voisinage 3 × 3 5 × 5 7 × 7 Proc´edure T[sec] σ BOPs T[sec] σ BOPs T[sec] σ BOPs Pr-10. Min/Max 0.111 0.005 169 0.198 0.009 300 0.289 0.026 437 Pr-11. M´edian 0.306 0.008 402 1.566 0.025 2370 4.61 0.076 6975

Tab. 2.11: Performance des algorithmes sp´ecifiques.

2.2.3 Conclusion

Le graphique de la Figure 2.14 permet de comparer la performance des diff´erentes proc´edures pour le filtre de rang g´en´eralis´e, bas´ees sur des algorithmes classiques de tri.

Nous pouvons constater la tr`es mauvaise performance des proc´edures de tri par fusion et par tas (Pr-7, Pr-8). Les proc´edures bas´ees sur des algorithmes de tri les plus connus, tels que le tri a` bulle, par s´election ou par insertion (Pr-1, Pr-2 et Pr-3), pr´esentent des performances int´eressantes lorsqu’il s’agit de travailler avec le plus petit des voisinages : un 3 3. Malheu- × reusement ces proc´edures ne pr´esentent pas d’int´erˆet lorsque la taille de voisinage devient plus importante. Les proc´edures bas´ees sur les diff´erentes variantes de l’algorithme de tri rapide (Pr-4, Pr-5 et Pr-6) se montrent cependant plus avantageux d`es que la taille de voisinage d´epasse les habituelles 9 voisins.

70 2.2. Exploitation de l’architecture standard

Temps[sec.] Temps[sec.] Temps[sec.] 2 15 1.885 6.344 12.81 6 11.741

10

3.552 7.43 3.349 1 .888 6.691 3 .76 5.631 2.356 2.2572.205 4.732 .591 2.107 5 4.014 .5 1.795 3.845 .487 .474 .464

0 0 Pr-7 Pr-8 Pr-5 Pr-4 Pr-6 Pr-2 Pr-1 Pr-3 Pr-7 Pr-1 Pr-8 Pr-2 Pr-4 Pr-5 Pr-3 Pr-6 0 Pr-7 Pr-1 Pr-8 Pr-2 Pr-3 Pr-4 Pr-5 Pr-6 Proc. Proc. Proc.

Voisinage : 3 3 5 5 7 7 × × × Pr-1 - Tri a` bulle Pr-3 - Tri par insertion Pr-5 - Tri rapide DNF Pr-7 - Tri par fusion Pr-2 - Tri par s´election Pr-4 - Tri rapide de base Pr-6 - Tri rapide hybride Pr-8 - Tri par tas Fig. 2.14: Performance des diff´erentes proc´edures de filtre de rang g´en´eralis´e bas´ees sur des algorithmes de tri classiques.

Les meilleurs temps obtenus par les proc´edures de filtre de rang g´en´eralis´e (la proc´edure Pr-3 pour le voisinage 3 3 et la proc´edure Pr-6 pour les voisinages 5 5 et 7 7) sont ensuite × × × compar´es avec la proc´edure qui r´ealise l’algorithme de tri par classement pour le Min/Max (Pr-9a) et m´edian (Pr-9b) et avec ceux des filtres sp´ecifiques Min/Max (Pr-10) et M´edian (Pr-11). La Figure 2.15 montre la comparaison pour les filtres Min/Max, ou` on constate une meilleure performance des algorithmes sp´ecifiques. Il faut cependant noter que par rapport a` l’algorithme de tri par classement le facteur d’acc´el´eration devient moins important pour des plus grandes voisinages. Temps[sec.] Temps[sec.] .464 Temps[sec.] 0,5 2 1.795 3.845 4 .266

.111 2 .29 .198 .35 .289 0,0 Pr-3 Pr-9a Pr-10 0 Pr-6 Pr-9a Pr-10 0 Pr-6 Pr-9a Pr-10 Proc. Proc. Proc.

Voisinage : 3 3 5 5 7 7 × × × Pr-3 - Tri par s´election Pr-6 - Tri rapide hybride Pr-9 a - Tri par classement Pr-10 - Sp´ecifique pour Min/Max

Fig. 2.15: Performance de l’algorithme le plus rapide pour le filtre g´en´eralis´e, l’algorithme de tri par classement et la proc´edure de filtre sp´ecifique utilis´es pour le calcul d’un filtre Min/Max.

71 Chapitre 2. Architecture universelle

La Figure 2.16 montre la comparaison des performances des proc´edures qui correspondent au filtre m´edian cette fois-ci. Ici, seulement pour le voisinage 3 3 il est plus int´eressant de × travailler avec un algorithme sp´ecifique. Pour des voisinages plus grands, le tri par classement reste de loin le plus efficace. Temps[sec.] Temps[sec.] Temps[sec.] 4.61 2 1.795 .464 3.85 0,5 1.566 .413 4

.306

2 .433 .459

0,0 Pr-3 Pr-9b Pr-11 0 Pr-6 Pr-11 Pr-9b 0 Pr-11 Pr-6 Pr-9b Proc. Proc. Proc.

Voisinage : 3 3 5 5 7 7 × × × Pr-3 - Tri par s´election Pr-6 - Tri rapide hybride Pr-9 b - Tri par classement Pr-11 - Sp´ecifique pour m´edian

Fig. 2.16: Performance de l’algorithme le plus rapide pour le filtre g´en´eralis´e, l’algorithme de tri par classement et la proc´edure de filtre sp´ecifique utilis´e pour le calcul d’un filtre M´edian.

Cette comparaison nous permet de d´eduire les meilleures proc´edures pour les filtres et voisi- nages envisag´ees lorsqu’il s’agit de les calculer avec une architecture standard (Tableau 2.12).

Voisinage 3 3 5 5 7 7 × × × Proc´edure T[sec] BOPs T[sec] BOPs T[sec] BOPs Min/Max 0.111 (Pr-10) 169 0.198 (Pr-10) 300 0.289 (Pr-10) 437 M´edian 0.306 (Pr-11) 402 0.433 (Pr-9) 656 0.459 (Pr-9) 694

Tab. 2.12: Performance de l’architecture universelle.

72 2.3. Exploitation de parall´elisme intra-processeur

2.3 Exploitation de parall´elisme intra-processeur

La performance des proc´edures qui calculent les diff´erents filtres non-lin´eaires peut ˆetre sensiblement am´elior´ee en exploitant les deux niveaux de parall´elisme des architectures Pen- tium : le parall´elisme de donn´ees et le parall´elisme des instructions.

L’exploitation de parall´elisme des donn´ees des extensions a` l’architecture standard n’est pas automatique. Cette partie de mat´eriel ne sera donc pas utilis´ee lorsqu’il s’agit de compiler les programmes ´ecrits en langages de programmation ´evolu´es39. Un utilisateur souhaitant que son application b´en´eficie r´eellement des ces extensions a le choix entre : employer les librairies commerciales ou programmer les extensions lui mˆeme.

L’emploi des librairies commerciales repr´esente la mani`ere la plus simple et la plus directe d’acc´eder au parall´elisme de donn´ees. Dans ce cas, aucune connaissance pr´ealable du mat´eriel sous-jacent et des extensions en question n’est a` priori n´ecessaire, si ce n’est le format de donn´ees utilis´ees et la syntaxe d’appel des fonctions propos´ees. Une telle librairie, d´evelopp´ee par Intel et sp´ecifique aux applications de traitement des images a ´et´e utilis´ee dans un pre- mier temps pour ´evaluer le gain en performance des extensions par rapport a` l’architecture standard.

L’emploi de librairies existantes offre l’avantage d’ˆetre imm´ediat. Par contre la programmation des extensions demande un temps consid´erable de d´eveloppement et une bonne connaissance de l’architecture du processeur et de son jeu d’instructions. En contre partie les performances de telles proc´edures justifient l’effort d´eploy´e car il est possible d’am´eliorer consid´erablement les r´esultats obtenus par rapport aux libraires. De plus, la maˆıtrise des extensions permets a` l’utilisateur de r´ealiser ses propres fonctions et de les optimiser pour des cas particuliers souvent rencontr´es dans la conception des programmes destin´es au traitement des images.

L’exploitation de parall´elisme des instructions est enti`erement automatis´ee et ne laisse pas beaucoup de place a` l’intervention de l’op´erateur. Cependant les r´esultats obtenus ne sont pas forcement les meilleurs duˆ a` la nature complexe du probl`eme d’ordonnancement des instructions et le temps qui lui est consacr´e. En effet, l’ordonnancement est fait pendant l’ex´ecution et donc doit ˆetre le plus rapide possible. L’optimisation des programmes a` ce niveau est r´esum´ee par le suivi de quelques r`egles de bonne pratique p.e. [Lec99], en g´en´eral propres a` la programmation en assembleur et qui visent a` minimiser les diff´erents al´eas propres au fonctionnement en pipeline (al´eas structurels et de donn´ees en particulier). Enfin, un outil d’analyse de programme en ex´ecution : VTune, offre la possibilit´e de v´erifier si l’ordre des instructions impos´e par le programme est efficace ou pas et permet a` l’utilisateur d’agir en cons´equence.

39Dans le compilateur de langage C/C++ d’Intel, il existe une option qui force le compilateur d’explorer le code est d´eterminer un ´eventuel parall´elisme exploitable par les extensions, mais nous n’avons aucune garantie que cela aura effectivement lieu. La r´eussite, donc le passage entre un langage ´evolu´e et un code machine qui exploite r´eellement ces extensions, n’arrive que dans des situations bien pr´ecises, fort d´ependantes du style d’´ecriture de programme[Int02].

73 Chapitre 2. Architecture universelle

2.3.1 Librairie de traitement des images Intel

Les extensions a` l’architecture standard et le parall´elisme de donn´ees ont fait leur appari- tion d`es la premi`ere g´en´eration des processeurs Pentium. Au d´ebut, ces extensions n’ont pas ´et´e fort exploit´ees, probablement a` cause d’un usage de plus en plus fr´equent des langages de programmation ´evolu´es. Comme le seul moyen possible de profiter des nouveaut´es dans l’ar- chitecture des processeurs Pentium implique la programmation en assembleur, marginalis´ee depuis un certain temps, cette partie de mat´eriel est rest´ee longuement sous-exploit´ee.

Afin de d´emontrer la capacit´e de calcul de leur processeurs et favoriser l’emploi des extensions, Intel a d´evelopp´e une suite des librairies nomm´ee Intel Performance Libraries. Cette suite, compos´ee de plusieurs librairies ind´ependantes, sp´ecifiques aux domaines particuliers40, a ´et´e dans un premier temps propos´e gratuitement. Actuellement cette suite, am´elior´ee, mise a` jour et portant un nouveau nom (Integrated Performance Primitives) est devenu payante.

Ici nous nous int´eressons plus particuli`erement a` la librairie IPL, destin´ee au traitement des images. Cette librairie41, largement d´ecrite dans [Int99a], a ´et´e ´evalu´ee pour la mˆeme image de test utilis´ee dans l’´evaluation de la performance de l’architecture standard 42. Les performances des diff´erents filtres sont repr´esent´ees dans le Tableau 2.13.

Voisinage 3 × 3 5 × 5 7 × 7 Proc´edure T[sec] BOPs T[sec] BOPs T[sec] BOPs

Min/Max 0.041 59 0.056 80 0.087 124 M´edian 0.171 245 0.236 338 0.312 446

Tab. 2.13: Performance de la librairie de traitement des images Intel - IPL

2.3.2 Programmation des extensions : filtres sp´ecifiques Min/Max

2.3.2.1 Description g´en´erale de l’algorithme

Consid´erons un pixel i de l’image I et un voisinage Vi correspondant a` ce pixel, de forme carr´ee, de taille Vx Vx, not´e sous forme d’une matrice Vi[m, n]. Le calcul d’un filtre de rang ∗ sp´ecifique (le filtre Min ou Max) pour ce pixel peut ˆetre r´ealis´e en deux temps. Tout d’abord on calcule Vx valeurs interm´ediaires : les maxima (ou les minima) locaux des ´el´ements de m vecteurs colonnes de Vi, not´es vci (voir Figure 2.17). Nous avons donc :

m max v = max V [m, 0], . . . , V [m, Vx 1] m, m [0, Vx 1] (2.11) ci − ∀ ∈ −    40Math Kernel Library, Image Processing Library, Signal Processing Library, Recognition Primitives Library et JPEG Library 41La version utilis´e est la 2.1. 42Il s’agit d’une image de 1024x1024 pixels, cod´es sur 8 bits.

74 2.3. Exploitation de parall´elisme intra-processeur

Pour calculer la valeur filtr´ee du pixel i de voisinage Vi donn´e il suffit de calculer le maximum (ou le minium) des tous les maxima (ou les minima) locaux des vecteurs colonnes :

I˜[i] = max I[i], Vi

0 Vx 1 = max max v , . . . , max v − i, i [0, (Ix 1) (Iy 1)] (2.12) ci ci ∀ ∈ − ∗ −    V Vi x

Vx

m V -1 max( ) max( ) x ~I[i]=max( vci vci max( vci ) )

Fig. 2.17: Calcul des minima/maxima locaux dans un voisinage.

Le mˆeme principe peut ˆetre appliqu´e pour le calcul d’un ensemble des voisinages d’une fenˆetre de l’image. Consid´erons une fenˆetre Fi de taille Fx Fy, avec Fy = Vy = Vx : la fenˆetre Fi est ∗ de la mˆeme hauteur que le voisinage. Comme pr´ec´edemment, nous allons d’abord chercher les k maxima (ou les minima) locaux des diff´erents vecteurs colonnes de la fenˆetre Fi, not´es fci :

k max f = max Fi[k, 0], . . . , Fi[k, Fx 1] k, k [0, Fx 1] (2.13) ci − ∀ ∈ −   Pour calculer les valeurs  de la fenˆetre filtr´ee il suffit de calculer le maxima (ou les minima) des maxima/minima locaux des vecteurs colonnes qui correspondent aux diff´erents voisinages. Nous avons donc :

˜ 0 Vx 1 F [0] = max max fci , . . . , max fci −

˜  1  Vx  F [1] = max max fci , . . . , max fci .    . Fx Vx 1 Fx 1 F˜[Fx Vx 2] = max max f − − , . . . , max f − (2.14) − − ci ci    Notons que le calcul d’une fenˆetre filtr´ee produit seulement Fx (Vx 1) et pas Fx ´el´ements − − a` cause de l’effet de bord.

L’algorithme pr´esent´e convient parfaitement bien a` l’architecture SIMD des extensions a` l’architecture standard. En effet, la fenˆetre Fi enti`ere est sauvegard´ee dans le m´emoire des

75 Chapitre 2. Architecture universelle registres. Le calcul des maxima (ou des minima) locaux des diff´erents vecteurs colonnes de la fenˆetre Fi est alors imm´ediat. Un registre particulier contient les valeurs des maxima locaux 0 des vecteurs colonnes de Fi, le vecteur ligne not´e tl :

0 0 Fx 1 t [k] = max f , . . . , max f − k, k [0, Fx 1] (2.15) l ci ci ∀ ∈ − h  i 0 Les Fy 1 vecteurs suppl´ementaires sont ensuite obtenus en appliquant au vecteur ligne tl − 43 l’op´erateur de d´ecalage a` droite, not´e . Nous avons donc au total Fy vecteurs suivants : 

0 0 Fx 1 tl = max fci , . . . , max fci −

1 0 h 0 Fx i2 t =t 1 = 0, max f , . . . , max f − l l  ci ci 2 1 h 0 Fx i3 t =t 1 = 0, 0, max f , . . . , max f − l l  ci ci . h i .  

Fy 1 Fy 2 0 Fx Fy 1 t − =t − 1= 0, . . . , max f , . . . , max f − − (2.16) l l  ci ci h  i La recherche des maxima (des minima) locaux des diff´erents vecteurs colonnes, obtenus a` partir des Fy vecteurs lignes (Equation´ 2.16), nous permet de calculer les valeurs de la fenˆetre filtr´ee, le vecteur F˜i, dont les Fx (Vx 1) derniers valeurs repr´esentent les valeurs filtr´ees : − −

˜ 0 1 Fx 1 Fi[k] = max(tc), max(tc ), . . . , max(tc − )

h 0 i = max fci, 0, . . . , 0 ,

h  1 0  max fci, fci, . . . , 0 ,

 2 1 0  max fci, fci, fci, . . . , 0 , .   .

Fx 1 Fx 2 Fx Fy max fci − , fci − , . . . , fci − (2.17)  i

La Figure 2.18 a) illustre le principe de calcul des maxima locaux pour une fenˆetre Fi de 0 l’image et la formation du vecteur ligne tl correspondant. La Figure 2.18 b) montre le d´ecalage 0 de vecteur tl et la formation des Fy vecteurs des maxima (des minima) locaux permettant le calcul des valeurs filtr´ees.

43L’op´erateur de d´ecalage r´ealise le d´eplacement a` droite  (l’op´erateur a` gauche ´etant not´e ) des ´el´ements du vecteur d’une place. Dans le cas d’un d´ecalage a` droite, le dernier ´el´ement du vecteur est perdu et le premier ´el´ement peut prendre n’importe quelle valeur (en l’occurrence 0).

76 2.3. Exploitation de parall´elisme intra-processeur

Fi Fx-1 0 F -1 F -V -2 0 f f t x t x x t ci ci c c c 0 f t 0 li l 0 t 0 >> 1 l 0 0 t 0 >> 2 l

Vx-1 0 >> f 0 0 t Fy-1 li l

x-1 0 -V -2 0 ) max ( ) x x ) max ( ) ci ci c c

t 0 l

a) b)

0 Fig. 2.18: Calcul des maxima locaux (vecteur tl ) et de la fenˆetre filtr´ee.

Pour le calcul des valeurs d’une nouvelle fenˆetre F , nous avons le choix pour le d´eplacement de la fenˆetre F dans l’image I entre : – d´eplacement horizontal - selon l’axe des indices i (Figure 2.19 a)) – d´eplacement vertical - selon l’axe des indices j (Figure 2.19 b)).

Fi 0 15 31

i j

F i+1 Fi+1 0 15 31 0 15 31

a) b)

Fig. 2.19: Parcours horizontal et vertical de l’image.

A ce stade ci il serait difficile de justifier un choix particulier car les deux m´ethodes pr´esentent des avantages et des inconv´enients qui peuvent jouer un rˆole important sur le temps d’ex´ecution final. Pour s’en rendre compte il est n´ecessaire de prendre en consid´eration certains aspects

77 Chapitre 2. Architecture universelle mat´eriels de l’architecture cibl´ee. Dans l’architecture de l’ordinateur vis´e les processus de lecture/´ecriture des donn´ees et le calcul sont des taches g´er´ees par des unit´es mat´erielles ind´ependantes et peuvent donc ˆetre ex´ecut´ees de fa¸con concurrentielle. Dans un cas id´eal les deux sont dans un ´equilibre : on r´ealise un pipeline entre la lecture, le calcul et l’´ecriture. Mais ceci n’est pas toujours possible, soit parce que nous avons trop de calcul a` faire : c’est le processeur qui ne parviens pas a` suivre le d´ebit de donn´ees, soit parce que la m´emoire ne parviens pas a` d´elivrer la quantit´e de donn´ees n´ecessaire au calcul. Pour combler la faible latence de la m´emoire centrale une m´emoire cache est plac´ee entre la m´emoire centrale et le processeur, et son emploi sera tout a` fait diff´erent dans les deux cas envisag´es.

Si le d´eplacement de la fenˆetre est “horizontal”, pour chaque fenˆetre F de l’image I il faut r´ealiser le chargement de Fy lignes de l’image depuis la m´emoire centrale (NF Fy chargements × au total avec NF le nombre de fenˆetres total dans l’image). Dans ce cas, les donn´ees d´ej`a pr´esentes dans les registres internes de processeur et utilis´ees pour le calcul d’une fenˆetre Fi ne sont pas r´eutilis´ees pour le calcul de la fenˆetre Fi+1 suivante.

Mˆeme si cet algorithme peut paraˆıtre a` priori d´esavantageux, a` cause d’une ´evidente redon- dance en lecture, l’impl´ementation peut s’av´erer int´eressante. En effet, lorsque la fenˆetre F est charg´ee dans les registres de processeur, une zone m´emoire plus large, situ´ee imm´ediatement apr`es la zone lue, est automatiquement plac´ee dans la m´emoire cache de niveau 2. Lorsque le calcul exige les donn´ees de la fenˆetre suivante, la lecture ne devra pas se faire dans la m´emoire centrale, mais bien dans la cache. En sachant que le temps d’acc`es a` cette m´emoire est net- tement plus faible que celui de la m´emoire centrale (en th´eorie 48GB/s contre 3.2GB/s) on peut n´eanmoins esp´erer obtenir un bon r´esultat.

Le pseudo-code de l’algorithme d´ecrit, pour un voisinage 3 3 est donn´e dans le Listing 2.2. ×

1 for ( j =0; j

Pour un d´eplacement “vertical” de la fenˆetre F , le nombre de chargements des vecteurs lignes depuis la m´emoire peut ˆetre r´eduit a` un seul chargement par fenˆetre F a` calculer. Le nombre de chargements total des lignes de l’image est alors r´eduit a` NF , puisque on peut b´en´eficier des chargements d´ej`a effectu´es.

78 2.3. Exploitation de parall´elisme intra-processeur

Si le nombre de chargement est ici inf´erieur a` celui de parcours horizontal, l’impl´ementation d’un tel algorithme pr´esente a` priori un inconv´enient majeur. Pour les tailles des images et des m´emoires caches habituellement rencontr´ees44, la lecture de la ligne suivante de l’image n´ecessaire pour la construction de la fenˆetre suivante se passera certainement dans la zone de la m´emoire centrale qui n’a pas encore ´et´e copi´ee dans la m´emoire cache. Si le processeur effectue le calcul suffisamment vite, il sera amen´e a` attendre le transfert.

Le pseudo-code de l’algorithme d´ecrit et pour un ´el´ement structurant de taille 3 3 est donn´e × dans le Listing 2.3).

1 for ( j =0; j

Les deux pseudo-codes peuvent ˆetre facilement adapt´es pour des voisinages plus grands.

L’impl´ementation des deux algorithmes expos´es d´epend fortement de l’extension utilis´ee i.e. de l’architecture du processeur cible et de la taille de voisinage choisi.

Ainsi avec l’extension MMX il est possible de travailler avec une fenˆetre de 8 pixels de large. Pour des voisinages de taille inf´erieure a` 8 8 les mˆemes instructions calculent alors 8 (Vx 1) × − − pixels de r´esultat avec un seul acc`es a` la m´emoire pour la fenˆetre F .

L’extension SSE introduit un jeux d’instructions plus large que celui de l’extension MMX dont l’usage permet une impl´ementation nettement plus efficace, comme nous allons le voir par la suite.

44Dans plupart des cas l’image est cod´e sur une quantit´e d’information beaucoup plus importante que celle de la m´emoire cache. Dans notre cas l’image de r´ef´erence fait un m´egaoctets et la m´emoire cache seulement 256 kiloctets.

79 Chapitre 2. Architecture universelle

Les registres de l’extension SSE2 permettent de doubler le nombre de pixels de la fenˆetre. Par cons´equence nous avons 16 (Vx 1) de pixels calcul´es par fenˆetre F de l’image. − − Signalons que les mˆemes algorithmes peuvent ˆetre utilis´es pour des voisinages plus grands que ceux envisag´es mais avec une impl´ementation plus particuli`ere due, principalement, a` la gestion des r´esultats temporaires.

2.3.2.2 Parcours horizontal

L’implementation des algorithmes pour le parcours horizontal a ´et´e r´ealis´ee a` l’aide des extensions MMX, SSE et finalement SSE2 propre au processeur Pentium 4. Plusieurs tech- niques d’optimisation, d´ecrites par la suite, sont utilis´ees avec succ`es pour am´eliorer le temps d’ex´ecution final.

Impl´ementation a` l’aide des extension MMX et SSE L’´etape cl´e de l’algorithme d´ecrit est le calcul des valeurs de minima/maxima locaux entre les diff´erents vecteurs lignes de la fenˆetre F (pseudo-instruction compare du Listing 2.2). La r´ealisation de cette op´eration d´epend fortement de l’extension utilis´ee.

Pour le MMX, seules les instructions permettant d’effectuer une comparaison en plus grand que - pcmpgtb dst,src et en plus petit que - pcmpltb dst,src sont disponibles. Ces instructions gˆen`erent dans le registre dst un vecteur masque, qui dans le cas de l’instruction pcmpgtb dst,src place la valeur 1 l`a ou la valeur du vecteur contenu dans le registre dst est plus grande de celle de registre src (0 dans le cas contraire)45. A partir de ce vecteur, il est possible d’extraire des valeurs maximales ou minimales effectives comme le sugg`ere le pseudo-code du Listing 2.4.

// compare r0 e t r1 e t s a u v e g a r d e max t o r0 r6 r0 ; // s a u v e une c o p i e de r0 r6 ← r6 r1 ; // compare r1 e t r0 r0 ← r0 and≥ r6 ; // v a l e u r s max de l a l i g n e 1 r6 ← not ( r6 ) and r1 ; // v a l e u r s max de l a l i g n e 2 r0 ← r0 or r6 ; // groupement r0 = max ( r0 , r1 ) ← Listing 2.4: Extraction de maxima locaux

Le temps d’ex´ecution moyen de cette proc´edure calcul´e sur 25 passes sur l’image de r´ef´erence est de 16.62 ms (Proc´edure MMXProc1. de Tableau 2.14).

Pour l’extension SSE, les instructions sp´ecifiques de recherche de minimum/maximum entre deux registres46 permet de remplacer le code d´ecrit (Listing 2.4) par une seule instruction. Dans le cas d’une proc´edure travaillant sur un voisinage de 3 3, l’introduction de ces instruc- × tions permet d’obtenir un facteur d’acc´el´eration de 1.8 par rapport a` la proc´edure pr´ec´edente (Proc´edure SSEProc1. de Tableau 2.14).

45 Si le registre mm0 contient 2 2 0 5 7 8 3 9 et le registre mm1 contient 0 5 0 5 9 2 5 0 alors apr`es l’instruction pcmpgtb dst,src nous allons retrouver dans mm0 1 0 0 0 0 1 0 1 46Les instructions pminub dst,src et pmaxub dst,src calcul mindst, src et maxdst, src pour les vecteurs d’octets non-sign´es. Le r´esultat est plac´e dans le registre dst.

80 2.3. Exploitation de parall´elisme intra-processeur

Pour les deux proc´edures en question, le parcours de l’image est fait de la mˆeme mani`ere, a` l’aide de deux boucles ´ecrites en langage C. Ces deux boucles peuvent ˆetre remplac´ees par une seule boucle, ´ecrite en assembleur (SSEProc2. de Tableau 2.14). L’avantage en est double : – la gestion d’une deuxi`eme boucle imbriqu´ee est supprim´ee, – le calcul des adresses est r´eduit au strict minimum.

Une optimisation suppl´ementaire (SSEProc3. de Tableau 2.14), qui consiste en emploi de mode d’adressage dit de d´eplacement afin d’acc´eder aux diff´erents vecteur lignes de la fenˆetre F d’image I, permet d’obtenir un facteur d’acc´el´eration de 1.2, toujours par rapport a` la proc´edure pr´ec´edente. Au lieu de travailler avec des pointeurs (registres) diff´erents vers les diff´erentes lignes de l’image, on peut utiliser un seul pointeur (en seul registre) et sp´ecifier explicitement le d´eplacement entre deux lignes de l’image I (Listing 2.5).

movq mm0 , [ eax ] ; // chargement de l a p r e m i`e r e l i g n e movq mm1 , [ eax + 1 0 2 4 ] ; // chargement de l a deuxi`eme l i n e movq mm2 , [ eax + 2 0 4 8 ] ; // chargement de l a t r o i s i `e m e l i n e

Listing 2.5: Adressage de d´eplacement

On pourrait reprocher a` la sp´ecification explicite de d´eplacement un certain manque d’uni- versalit´e car le programme compil´e impose une constante pour la dimension horizontale de l’image. Le traitement d’une image de taille horizontale diff´erente impliquerait la re- compilation du programme. Il est possible de rendre la valeur d’offset de d´eplacement va- riable en utilisant la technique de code auto-modifiable. Avant l’ex´ecution de la proc´edure en question, le programme va modifier la valeur de l’offset de d´eplacement en ´ecrivant la valeur d´esir´ee dans la zone m´emoire correspondante. L’adressage reste bien celui de d´eplacement mais il est r´esolu lors de l’ex´ecution du programme et plus lors de compilation 47.

La derni`ere optimisation consiste en emploi de la technique dite de d´eroulement des boucles. Cette m´ethode pr´esente l’avantage de diminuer la charge de calcul des boucles et ´eventuellement permettre un meilleur ordonnancement des instructions. Elle consiste a` tout simplement r´epliquer le mˆeme code : il s’agit d’un simple ”copier-coller” du code a` l’int´erieur de la boucle et d’adaptation des offsets de lecture des donn´ees et d’´ecriture des r´esultats. Le code ajout´e va donc effectuer le calcul sur un autre set de donn´ees, dans notre cas typiquement la fenˆetre Fi+1 suivante de l’image I. L’utilisation de d´eroulement des boucles (SSEProc4. de Tableau 2.14) permet d’observer une acc´el´eration de 1.3 par rapport a` l’ex´ecution sur une seule fenˆetre, toujours pour un voisinage 3 3. × Un d´eroulement suppl´ementaire de boucle n’apporte pas de gain majeur, le temps d’ex´ecution ne change pratiquement pas pour l’´el´ement structurant 3 3 (SSEProc5. de Tableau 2.14). × Seules les trois derni`eres proc´edures ont ´et´e adapt´ees pour les voisinages 5 5 et 7 7. On × × constate que pour les voisinages 5 5 et 7 7 le deuxi`eme d´eroulement de boucle n’apporte × × pas de gain, au contraire la performance est pire que dans le cas d’un d´eroulement simple.

47Pour des explications plus d´etaill´ees concernant l’impl´ementation d’un code auto-modifiable voir Annexe A.5).

81 Chapitre 2. Architecture universelle

Voisinage 3 × 3 5 × 5 7 × 7 Extension Proc´edure T[msec] BOPs T[msec] BOPs T[msec] BOPs MMX MMXProc1. 16.62 24 - - - - SSEProc1. 9.27 13 - - - - SSEProc2. 9.09 13 - - - - SSE SSEProc3. 7.24 10 14.23 20 33.72 48 SSEProc4. 5.69 8 10.74 15 29.56 42 SSEProc5. 5.67 8 14.80 21 31.60 45

Tab. 2.14: Extensions MMX et SSE - Filtres Min/Max

Impl´ementation a` l’aide de l’extension SSE2 L’extension SSE2, avec ces 8 registres XMM de 128 bits chaque, permet de travailler sur une fenˆetre F de 16 pixels de large. Les instructions sp´ecifiques pour le calcul des entiers, celles de comparaison et de d´ecalage en mode octet48 peuvent ˆetre ´egalement utilis´ees sur ces registres.

La proc´edure la plus performante d´ecrite pour l’extension SSE (SSEProc5.), a ´et´e adapt´ee pour l’extension SSE2, le Tableau 2.15 r´esume les r´esultats obtenus pour les diff´erentes voi- sinages typiques.

Voisinage 3 × 3 5 × 5 7 × 7 Extension Proc´edure T[msec] BOPs T[sec] BOPs T[sec] BOPs SSE2 SSE2Proc1. 4.760.01 7 6.50.01 9 100.01 14

Tab. 2.15: Extension SSE2 - Filtres Min/Max

Dans le cas d’un voisinage 3 3 et contrairement a` ce que l’on pouvait imaginer, le temps × d’ex´ecution n’a pas ´et´e divis´e par deux, malgr´e les 14 pixels calcul´es avec le mˆeme nombre d’instructions ex´ecut´ees (contre 6 pour l’extension MMX). Nous sommes donc limit´e par la lecture de donn´ees qui ne parviennent plus a` suivre la vitesse de calcul de processeur.

Pour des voisinages 3 3 et 5 5 le facteur d’acc´el´eration non-n´egligeable obtenu est de 1.6 × × et de 2.9 par rapport a` la proc´edure la plus performante utilisant l’extension SSE.

2.3.2.3 Parcours vertical

L’algorithme de parcours vertical a ´et´e cod´e pour l’extension SSE2 avec les mˆemes as- tuces de programmation mentionn´ees pour le parcours horizontal : une boucle de parcours,

48Il s’agit des instructions pmaxub dst,src, pminub dst,src et psrldq src,s avec s nombre d’octets de d´ecalage.

82 2.3. Exploitation de parall´elisme intra-processeur l’adressage explicite mais sans d´eroulement de boucle. Pour la mˆeme image de r´ef´erence et un voisinage de taille 3 3, le temps d’ex´ecution de ce programme est nettement plus important × que celui obtenu pour un parcours horizontal : 20ms. Ce temps est donc 4 fois plus grand que le temps affich´e par la meilleure proc´edure de parcours horizontal. La lecture redondante49 des donn´ees s’av`ere donc plus avantageuse duˆ a` la meilleure exploitation de la m´emoire cache. Nous sommes bien dans le cas d’un fort d´es´equilibre de pipeline entre la lecture, le calcul et l’´ecriture des r´esultats, car la latence de la m´emoire centrale n’est pas couverte par la m´emoire cach´e.

2.3.2.4 Analyse a` l’aide de VTune

L’impl´ementation des deux algorithmes propos´es nous laisse supposer que si une ´eventuelle acc´el´eration est possible, elle devrait se faire de cˆot´e de la lecture de donn´ees. Une analyse des deux proc´edures a` l’aide de logiciel VTune a permis de confirmer cette hypoth`ese et d’isoler deux probl`emes distincts quant a` l’emploi de la m´emoire : le probl`eme des acc`es en dehors de la m´emoire cache soup¸conn´e d`es le d´epart et le probl`eme d’alignement de donn´ees50.

M´emoire cache Une meilleure exploitation de la m´emoire cache peut ˆetre obtenue a` l’aide de deux solutions diff´erentes. Une premi`ere solution consiste a` d´ecouper l’image a` traiter en sous-images de fa¸con a` ce que chaque sous-image tienne en enti`eret´e dans la m´emoire cache de niveau 2. Les diff´erentes sous-images seront trait´ees s´epar´ement et les r´esultats assembl´es a` posteriori. L’ex´ecution de la proc´edure SSE2Proc1. sur une image de 128 12851 prend 0.036 ms ce qui × pourrait nous faire croire qu’il serait possible de traiter l’enti`eret´e de l’image de r´ef´erence en seulement 2.3 ms. En r´ealit´e l’ex´ecution sur l’image de r´ef´erence ne se fait qu’en 5 ms si l’on tiens compte des temps de d´ecoupe et d’assemblage de l’image. Mˆeme si le facteur d’acc´el´eration obtenu est de 4 par rapport a` la proc´edure de parcours vertical normal, on constate aucune acc´el´eration par rapport a` la proc´edure de parcours horizontal.

La deuxi`eme solution concernant une meilleure exploitation de la m´emoire cache consiste a` utiliser l’instruction prefetch d´ej`a mentionn´ee. La technique de prefetching logicielle consiste a` r´ealiser des chargements explicites d’une ligne de donn´ees de 128 octets dans la m´emoire cache d’un certain niveau52. Les tests effectu´es ne montrent aucune diff´erence significative

49Pour l’image de r´ef´erence et pour un parcours vertical, la quantit´e de donn´ees a` lire est d’environs 2 m´egaoctets quelque soit la taille de voisinage. Pour cette mˆeme image et pour un parcours horizontal cette quantit´e de donn´ees passe a` 4, 6 et 7 m´egaoctets pour des voisinages 3 × 3, 5 × 5, 7 × 7. 50Le logiciel VTune compte le nombre d’acc`es r´ealis´es en dehors de la m´emoire cache. Sur base de nombre des cycles effectifs pass´es a` l’ex´ecution il est dans la mesure de indiquer les endroits dans le code qui sont des potentielles source de ralentissement. 51La taille de la m´emoire cache nous permet de travailler avec des sous-images plus grandes. Cependant [Int99e] pr´econise de travailler avec des vecteurs dont la taille correspond a` la moiti´e de la m´emoire cache. 52Le processeur Pentium 4 int`egre deux modes de prefetching : un mat´eriel et un logiciel. Pour le prefetching mat´eriel - automatique, une unit´e d´edicac´ee r´ealise ce pr´e-chargement. Dans sa strat´egie de base, cette unit´e copi´e syst´ematiquement dans la m´emoire cache de niveau 2 les 256 octets en amont de l’adresse lu. Dans [Int99e] on pr´ecise que l’unit´e mat´erielle de prefetch est capable de ”comprendre” des patterns d’acc`es simples et de modifier la strat´egie de base. Etan´ t donn´ee le temps d’ex´ecution des proc´edures envisag´ees, nous d´eduisons que le processeur n’arrive pas a` comprendre le pattern impos´e par le parcours vertical, pourtant tr`es simple. Pour le prefetching logiciel c’est l’utilisateur qui d´etermine la partie de la m´emoire centrale qui sera copi´ee dans la m´emoire cache.

83 Chapitre 2. Architecture universelle par rapport a` la version de la proc´edure sans pr´e-chargement. L’absence de gain peut ˆetre expliqu´ee par le coutˆ d’appel de l’instruction prefetch non-n´egligeable mais surtout par la rapidit´e de calcul de processeur : le temps de calcul est ici nettement plus faible que le temps n´ecessaire pour r´ealiser le transfert.

Alignement des donn´ees Le deuxi`eme probl`eme d’acc`es a` la m´emoire est li´e a` l’alignement des donn´ees. Dans toutes les proc´edures consid´er´ees la lecture depuis la m´emoire vers des registres internes du processeur est faite a` l’aide des instructions permettant de charger un vecteur de 16 octets depuis n’im- porte quelle adresse de la m´emoire centrale. On appelle un tel acc`es non-align´e (instruction movdqu xmm, mem). Cette instruction de lecture est caract´eris´e par un grand nombre des cycles processeur effectifs n´ecessaires pour son ex´ecution. Par opposition a` un acc`es non-align´e, un acc`es align´e (instruction movdqa xmm, mem) sur des adresses multiples de 16 est nette- ment plus efficace [Int99e]. Malheureusement le calcul des filtres dans le voisinage implique les effets de bords : pour certains pixels nous sommes oblig´es d’effectuer des lectures/´ecriture non-align´es. La Figure 2.20 montre :

a. le calcul sur une fenˆetre align´ee aux adresses multiple de 16 (les pixels calcul´es gris´es en plus fonc´e) et le ”trou” laiss´e par l’effet de bord et b. les pixels a` calculer au bord de la fenˆetre pour un voisinage 3 3 avec une fenˆetre × non-align´ee.

Fi Fi+1 Fi Fi+1 0 15 31 0 15 31

a) b)

Fig. 2.20: Calcul des pixels dont les adresses sont align´ees a) et non- align´ees b).

La proportion des pixels qu’il est possible de calculer avec un acc`es align´e (14/16 dans le cas d’un voisinage 3 3) justifierait la d´ecoupe de probl`eme en deux : un calcul sur des adresses × align´ees et un calcul sur des adresses non-align´ees. Le temps de calcul sur des pixels qui se trouvent sur des adresses align´ees est de 3.83ms. Malheureusement l’inclusion de calcul sur des pixels des adresses non-align´ees fait monter le temps d’ex´ecution a` 8.1ms car nous avons pour le restant de 2/16 des pixels le mˆeme nombre d’instructions a` ex´ecuter puisque nous travaillons avec une unit´e de traitement vectorielle.

L’analyse des diff´erentes possibilit´es d’am´elioration de temps d’ex´ecution a` travers l’action sur des acc`es m´emoire nous permet de dire qu’il serait tr`es difficile d’aller plus loin avec les algorithmes pr´esent´es. Nous avons donc des temps d’ex´ecution de r´ef´erence pour des filtres sp´ecifiques Min/Max exploitant le parall´elisme de donn´ees.

84 2.3. Exploitation de parall´elisme intra-processeur

2.3.3 Programmation des extensions : filtre M´edian

Pour le calcul d’un filtre m´edian sur un voisinage 3 3 on peut utiliser un arbre de × comparateurs, repr´esent´e sch´ematiquement a` la Figure 2.21. Chaque nœud de l’arbre est un comparateur de deux valeurs a et b a` l’entr´ee et permet de calculer : max a, b et min a, b . { } { } Trois nœuds sont ensuite utilis´es pour compl`etement trier un vecteur de trois ´el´ements : – un min(a, b, c) - la branche sortante de gauche, – un med(a, b, c) - la branche de milieux, – un max(a, b, c) - la branche sortante de droite.

V[8] V[7] V[6] V[5] V[4] V[3] V[2] V[1] V[0]

a b c

min med max r=1 r=9 r=2 r=8

r=5; med{V} Fig. 2.21: Arbre de comparateurs pour le calcul de filtre m´edian sur un voisinage de 3 3 pixels. ×

L’arbre d´ecrit peut ˆetre facilement cod´e a` l’aide de l’extension SSE2. Pour des voisinages plus grandes la conception des arbres similaires s’av`ere particuli`erement difficile a` cause d’un nombre fort limit´e de registres internes (8 en tout). Dans ce cas la gestion des r´esultats interm´ediaires implique des acc`es fr´equents a` la m´emoire, ce qui se traduit par un abaissement de la performance.

L’impl´ementation de cet algorithme fait appel a` la proc´edure la plus performante des filtres Min/Max : une boucle de parcours de l’image en assembleur, un adressage explicite et un seul d´eroulement de boucle. La performance obtenue de cette proc´edure pour les voisinages typiques est indiqu´ee dans la Table 2.16.

Voisinage 3 × 3 5 × 5 7 × 7 Architecture Proc´edure T[msec] BOPs T[msec] BOPs T[msec] BOPs P4 - SSE2 D´eroulement 1 7.80.01 11 24.10.01 34 450.01 65

Tab. 2.16: Extension SSE2 - Filtre m´edian

85 Chapitre 2. Architecture universelle

2.3.4 Programmation des extensions : filtre d’un rang quelconque

A l’aide de la m´ethode expos´ee dans la section pr´ec´edente il est possible de calculer les filtres de n’importe quel rang r. Etan´ t donn´ee que la recherche de la valeur m´ediane est le cas le plus d´efavorable et la recherche des Min/Max le cas le plus favorable, le temps d’ex´ecution pour tout autre rang sera certainement entre les deux.

2.3.5 Filtres d´eriv´es et/ou la chaˆıne de traitement

Les filtres de rang constituent la brique de base dans la construction des filtres d´eriv´es et repr´esentent souvent juste une ´etape dans la chaˆıne de traitement des images. La r´ealisation d’une s´equence d’algorithmes implique alors plusieurs parcours de l’image et le calcul des r´esultats interm´ediaires qui doivent faire au moins un aller-retour entre le processeur et la m´emoire. Or comme nous l’avons montr´e c’est pr´ecis´ement les transferts qui repr´esentent le goulot d’´etranglement.

Pour illustrer l’influence de plusieurs parcours sur le temps d’ex´ecution totale, prenons l’exemple de calcul d’un gradient morphologique :

g(I, V ) = (I V ) (I V ) (2.18) ⊕ − Le calcul de cette expression comprend l’application de deux filtres morphologiques, plus une op´eration arithm´etique sur les deux r´esultats interm´ediaires de filtrage.

Les meilleurs proc´edures pour les filtres morphologiques de dilatation/´erosion sur un voisinage de 3 3 n´ecessitent environ 5 ms et nous avons besoin de ce mˆeme temps pour la soustraction × des deux images. De ce fait, l’ex´ecution des trois proc´edures mis “en s´erie” prends environs 15 ms.

Une autre fa¸con de faire la mˆeme chose serait de cr´eer une proc´edure sp´ecifique qui implique une seule lecture de la fenˆetre F et d’effectuer le calcul complet. Dans ce cas les r´esultats interm´ediaires restent dans la m´emoire des registres minimisant ainsi les acc`es a` la m´emoire. Le temps d’ex´ecution d’une telle proc´edure est de seulement 7 ms, avec un facteur d’acc´el´eration de 2.4 par rapport a` la proc´edure avec des appels s´equentiels des proc´edures.

2.3.6 Filtre de rang g´en´eralis´e

Lors de l’exploitation de l’architecture standard un algorithme tr`es performant pour le filtre g´en´eralis´e a ´et´e pr´esent´e - l’algorithme de tri par classement. Cet algorithme, mis a` part sa tr`es bonne performance pour des tr`es grandes tailles de voisinage a l’avantage de produire le vecteur du voisinage tri´e complet : la r´ealisation de n’importe quel filtre de rang comprend alors tout simplement un acc`es diff´erent au vecteur tri´e et donc un mˆeme temps d’ex´ecution quel que soit le rang recherch´e.

Il est alors naturel de se poser la question suivante : ”Peut on adapter cet algorithme de fa¸con a` exploiter le parall´elisme de donn´ees des extensions a` l’architecture standard ?”.

86 2.3. Exploitation de parall´elisme intra-processeur

La r´eponse est non, comme d’ailleurs pour la plupart des algorithmes de tri classiques. Dans le cas particulier de l’algorithme de tri par classement le principal obstacle repr´esente le calcul de l’histogramme fait pour chaque voisinage Vi, r´ealis´e NV fois pour une image compl`ete. En effet, avec une unit´e de traitement vectorielle, la manipulation de l’histogramme (l’enl`evement et l’ajout des colonnes de l’image) est possible mais au d´etriment d’une importante lourdeur de l’impl´ementation. Avec une unit´e de traitement vectorielle nous ne sommes plus dans la mesure de r´ealiser un adressage de la m´emoire par le contenu et donc une impl´ementation efficace de calcul de l’histogramme.

87 Chapitre 2. Architecture universelle

2.4 Exploitation du parall´elisme inter-processeur

Pour explorer le parall´elisme inter-processeur, un syst`eme a` m´emoire partag´ee dot´e de deux processeurs d’architecture Pentium 2 a ´et´e utilis´e. Un tel syst`eme permet l’ex´ecution simultan´ee des deux threads avec deux flots d’instructions ind´ependants sur deux flots de donn´ees ind´ependants provenant d’une mˆeme m´emoire centrale53. Si une application souhaite b´en´eficier de ce type de parall´elisme elle doit initier deux threads au sein du thread principal d’ex´ecution. Comme il s’agit d’un ordinateur ´equip´e des processeurs Pentium 2, seules les proc´edures d´evelopp´ees pour l’architecture standard et celles qui exploitant l’extension MMX peuvent donc ˆetre ex´ecut´ees.

2.4.1 Ex´ecution sur deux processeurs

Etan´ t donn´e le nombre de processeurs disponibles, l’image a` traiter est divis´ee en deux parties, les deux sous-images appel´e ”haut” et ”bas” (Figure 2.22). Afin d’´eviter les effets de bord et permettre la reconstruction de l’image r´esultante apr`es le calcul, les deux sous- images pr´esentent un recouvrement de l’image initiale de Vy lignes. En toute g´en´eralit´e, la sous-image ”haut” couvre Vy1 lignes suppl´ementaires de la sous-image ”bas” et la sous-image ”bas” couvre Vy2 lignes de la sous-image ”haut”. I Ix

V "haut"

Vy1 V I y1 y Vy2 Vy2

"bas"

Fig. 2.22: D´ecoupage de l’image pour une ex´ecution sur deux proces- seurs.

Le choix de sens de la coupure de l’image, horizontal plutˆot que vertical, a ´et´e dict´e par la fa¸con dont l’image est sauvegard´ee dans la m´emoire centrale et vise une meilleure exploitation de la m´emoire cache.

Les parties ”haut” et ”bas” de l’image seront trait´ees par la mˆeme proc´edure, ex´ecut´ee a` tra- vers deux threads distincts (cf. Section A.3 de l’Annexe A). Les deux threads en question vont

53Signalons qu’`a la taille de la m´emoire cache prˆet, nous pouvons consid´erer un tel syst`eme comme une architecture MIMD a` m´emoire partag´ee.

88 2.4. Exploitation du parall´elisme inter-processeur

´ecrire leur r´esultats respectifs dans deux zones m´emoires distinctes mais faisant partie d’un mˆeme bloc de m´emoire contigu¨e de l’image r´esultante. Signalons qu’aucune synchronisation entre deux threads ne pas n´ecessaire car il n’existe aucun risque d’´ecriture concurrentielle.

En ce qui concerne l’ordonnancement des threads, deux situations diff´erentes peuvent ˆetre envisag´ees : 1. Affectation des deux threads aux processeurs est laiss´ee libre au syst`eme d’exploitation - l’ordonnancement automatique 2. Chaque thread est explicitement associ´e a` un processeur particulier grˆace a` la fonction API SetThreadAffinityMask() - l’ordonnancement manuel. Aucune diff´erence significative n’a pas ´et´e relev´ee entre les deux modes d’ordonnancement malgr´e un facteur d’acc´el´eration proche de 3 ´enonc´e par Cutler et Davis dans [CD99]. Afin d’assurer une ex´ecution concurrentielle la strat´egie de l’ordonnancement manuel a ´et´e utilis´e syst´ematiquement.

Le Tableau 2.17 montre les r´esultats obtenus en termes de temps de calcul et de BOPs par pixel correspondant pour les deux proc´edures envisag´ees : l’algorithme rapide DNF et celui bas´e sur l’extension MMX. La premi`ere colonne (T1) donne les r´esultats lorsqu’un seul 54 thread a ´et´e initi´e, ce qui ´equivaut a` la performance d’un seul processeur . La colonne T2 montre les r´esultats obtenus lorsqu’il s’agit de travailler avec deux threads selon le sch´ema d’ordonnancement manuel.

1 CPU 2 CPUs

T1 Proc´edure Voisinage T1[sec] BOPs T2[sec] BOPs Acc = T2 3 × 3 3.152 1353 1.584 680 1.99 DNF 5 × 5 6.01 2575 3.024 1298 1.98 7 × 7 13.52 5802 6.8 2918 1.99

MMX 3 × 3 0.432 185 0.24 102 1.8

Tab. 2.17: Performance d’un ordinateur personnel bi-processeur.

On constate un facteur d’acc´el´eration proche de 2, observ´e lors de l’exploitation des proc´edures pour l’architecture standard et lors de l’exploitation des proc´edures utilisant l’extension MMX.

Une remarque est cependant n´ecessaire. Si le facteur d’acc´el´eration observ´e est proche du facteur d’acc´el´eration th´eorique d’une machine parall`ele il ne doit pas forcement le rester pour une machine bi-processeur bas´ee sur des processeurs Pentium-4. En effet, comme nous l’avons montr´e dans la Section 2.3 le goulot d’´etranglement se situe au niveau de la m´emoire, mˆeme pour une machine dot´e d’un seul processeur. Dans ce cas, la multiplication des processeurs dans une architecture de type m´emoire partag´ee ne pourrait en aucun cas apporter ce mˆeme facteur d’acc´el´eration.

54Ceci est n´ecessaire puisque les r´esultats obtenus pr´ec´edemment sont relatifs a` l’emploi d’une architecture Pentium 4.

89 Chapitre 2. Architecture universelle

2.5 Conclusion

L’impl´ementation des filtres non-lin´eaires sur des architectures universelles a ´et´e abord´ee de trois fa¸cons diff´erentes : 1. En exploitant l’architecture standard, sur base des algorithmes classiques de tri. Il s’agit d’une approche que l’on peut qualifier de haut niveau a` cause d’une abstraction compl`ete de mat´eriel, possible grˆace aux compilateurs de langages de programmation ´evolu´e. 2. L’approche du parall´elisme intra-processeur, principalement bas´e sur l’exploitation de parall´elisme de donn´ees (le mode SIMD de fonctionnement). Ce type de parall´elisme a ´et´e exploit´e a` travers les libraires commerciales et avec des programmes sp´ecifiques con¸cus pour les extensions en question. Lors de ce dernier, le choix d’algorithmes et la conception des proc´edures correspondants ont ´et´e dirig´es par le mat´eriel sous-jacent. 3. Les meilleurs algorithmes et leur proc´edures correspondantes ont ´et´e ´evalu´e sur une machine bi-processeur, l’exemple type de parall´elisme inter-processeurs des architectures universelles. La performance d’un ordinateur personnel tout a` fait standard a ´et´e ´etablie pour chaque approche envisag´e. Le Tableau 2.18 r´esume les performances obtenus : les temps de traitement pour une image de 1024*1024 pixels, le nombre de BOPs n´ecessaire pour le traitement d’un seul pixel et les d´ebits correspondants : D0 pour l’architecture universelle standard et D1 pour l’architecture universelle parall`ele.

D´ebit des pixels trait´es [Mpx/sec] Universelle standard Universelle parall`ele Acc

T0 Filtre Voisinage T0[sec] BOP s D0 T1[sec] BOP s D1 T1 3 × 3 0.111 169 9 0.005 7 200 22 Max/Min 5 × 5 0.198 300 5.1 0.007 10 143 28 7 × 7 0.289 437 3.5 0.010 14 100 29

3 × 3 0.306 402 3.3 0.008 11 125 38 M´edian 5 × 5 0.433 656 2.3 0.024 34 42 12 7 × 7 0.459 694 2.2 0.045 64 22 8

Tab. 2.18: Performance de l’architecture universelle.

Ces r´esultats montrent que les syst`emes informatiques universels d’aujourd’hui, mˆeme ceux appartenant a` la classe des ordinateurs de bas de gamme (les ordinateurs personnels) pr´esentent une importante puissance de calcul lorsqu’il s’agit de les utiliser pour le calcul de filtres non- lin´eaires. La condition ´etant bien entendu d’exploiter “manuellement” les diff´erents niveaux de parall´elisme existant.

Si l’on souhaite am´eliorer d’avantage la performance de tels traitements, l’implication d’un plus grand nombre d’unit´es de traitement apparaˆıt n´ecessaire.

90 Chapitre 3

Architectures d´edicac´ees

Dans le chapitre pr´ec´edant nous avons ´etabli la performance des architectures univer- selles utilis´ees pour le calcul des diff´erents filtres non-lin´eaires employ´es dans le traitement des images num´eriques. Les ordinateurs de bureau, en tant qu’exemple le plus repr´esentatif de ces architectures, ont ´et´e abord´es a` l’aide de deux approches diff´erentes : l’une purement algorithmique faisant abstraction du mat´eriel sous-jacent et l’autre qui tient compte de l’ar- chitecture du processeur utilis´e. Nous avons montr´e que la deuxi`eme approche pr´esente un important facteur d’acc´el´eration par rapport a` la premi`ere et c’est elle qui a ´et´e retenue en tant que performance significative de tels syst`emes.

Dans ce chapitre nous allons examiner les diff´erents algorithmes et syst`emes d´edicac´es exis- tants utilis´es pour le calcul de filtres non-lin´eaires. Il est organis´e autour de 3 sections, dont voici un bref aper¸cu :

Section 1 - Dans cette premi`ere section nous retrouvons une courte description des circuits FPGAs, l’´el´ement clef utilis´e pour la construction des syst`emes d´edicac´es et des syst`emes reconfigurables. Nous nous int´eressons aux aspects mat´eriels des circuits FPGA ainsi qu’aux logiciels utilis´es pour l’impl´ementation des circuits logiques complexes. Un autre point abord´e est li´e a` la probl´ematique de la qualit´e du processus d’impl´ementation automatis´ee, car son influence sur la performance finale du syst`eme est d’une importance capitale.

Section 2 - Nous enchaˆınerons par un aper¸cu des diff´erents algorithmes et des syst`emes d´edicac´es existants utilis´es pour le calcul des filtres non-lin´eaires. La performance des diff´erents algorithmes et architectures pr´esent´es est quantifi´ee a` l’aide des deux param`etres d´ecrits dans le Chapitre 1 : le nombre de BOPs par pixel et le d´ebit des pixels trait´es lorsque l’architecture propos´ee a ´et´e effectivement r´ealis´ee.

Section 3 - Enfin la derni`ere section propose un r´esum´e des r´esultats, une discussion concernant les limites des algorithmes et des architectures d´ecrits et pointe sur la difficult´e de comparaison de ces r´esultats. La motivation et la raison d’ˆetre d’une autre approche pour l’impl´ementation des filtres non-lin´eaires, objet du Chapitre 4, apparaˆıtra d´ej`a de fa¸con beaucoup plus claire.

91 Chapitre 3. Architectures d´edicac´ees

3.1 Circuits FPGAs

3.1.1 Architecture

3.1.1.1 Description g´en´erale

Les circuits logiques programmables sont des circuits int´egr´es qui permettent la r´ealisation de circuits logiques a` grand nombre de variables d’entr´ee et de sortie, selon la sp´ecification de l’utilisateur et en utilisant un mˆeme support mat´eriel. Dans la litt´erature anglo-saxonne on rencontre deux appellations diff´erentes pour de tels circuits int´egr´es : le Programmable Logic Device - PLD et le Field Programmable Device - FPD. La diff´erence entre ces deux appellations est li´ee a` la quantit´e et a` la complexit´e de la logique r´ealisable au sein de ces circuits, en g´en´eral beaucoup plus importantes dans le cas des circuits FPD [BR96].

Les circuits Field Programmable Gate Arrays - FPGAs sont des circuits FPD, construits autour d’une matrice r´eguli`ere (array) constitu´ee d’un grand nombre de cellules logiques ´el´ementaires programmables, d’un r´eseau dense d’interconnexions, lui aussi programmable et d’un certain nombre de bornes d’entr´ees et de sorties.

La disposition des diff´erents ´el´ements qui constituent un circuit FPGA est repr´esent´ee de fa¸con sch´ematique a` la Figure 3.1.

Cellule logique élémentaire

Borne d'entrée/sortie

Réseau d'interconnexions

Fig. 3.1: Architecture des circuits FPGAs.

L’architecture d’une cellule logique ´el´ementaire varie d’un concepteur et d’une famille de FPGA a` l’autre. Quelque soit le producteur ou la famille consid´er´ee, une cellule logique ´el´ementaire est toujours compos´ee de quelques m´emoires de mots d’un bit, g´en´eralement de quelques bits d’adresse. Ces m´emoires sont destin´ees a` la sauvegarde des diff´erentes tables

92 3.1. Circuits FPGAs de v´erit´e des fonctions logiques d´efinies par le circuit a` r´ealiser. Chaque cellule logique est ´egalement dot´ee de bi-stables programmables1 permettant la r´ealisation des circuits syn- chrones.

Les cellules logiques ´el´ementaires sont entour´ees d’un r´eseau dense d’interconnexions program- mables. Ce r´eseau permet de r´ealiser des connexions sp´ecifiques entre les diff´erentes cellules logiques utilis´ees pour la r´ealisation d’un circuit particulier et de connecter ce circuit avec le monde ext´erieur via les bornes d’entr´ee/sortie.

L’ensemble des cellules logiques ´el´ementaires et le r´eseau d’interconnexions qui lui est associ´e constituent les ressources logiques disponibles pour un circuit FPGA donn´e. La quantit´e de ces ressources va limiter la complexit´e d’un ou plusieurs circuits logiques qu’il serait possible de r´ealiser au sein de ce FPGA. Une autre limitation de la complexit´e de circuit r´ealisable est due au nombre de bornes d’entr´ee/sortie disponibles. Celle-ci auront une influence directe sur le nombre maximal de variables et de fonctions logiques r´ealisables.

En fonction de la technologie employ´ee pour la fabrication des m´emoires des cellules logiques ´el´ementaires et de r´eseau d’interconnexions, il est possible de faire la distinction entre les FPGAs programmables et les FPGAs reprogrammables. Les premiers permettent de fixer d´efinitivement la configuration du circuit, tandis que pour les derniers, le processus de pro- grammation peut recommencer a` chaque nouvelle mise sous tension du circuit FPGA (ou lors d’un nouveau cycle de programmation). Nous nous int´eressons ici uniquement aux FP- GAs reprogrammables car ils peuvent servir a` la conception et la r´ealisation des syst`emes reconfigurables.

Une description plus d´etaill´ee de l’architecture d’une famille particuli`ere des FPGAs repro- grammables, Virtex II de Xilinx, peut ˆetre trouv´ee dans l’Annexe B.

3.1.1.2 Ressources typiques des FPGAs actuels

La quantit´e des ressources logiques disponibles dans un circuit FPGA d´epend du degr´e d’int´egration et de la taille du support utilis´e pour sa construction. Elle sera ´egalement in- fluenc´ee par le choix concernant l’architecture de la cellule logique ´el´ementaire : taille et le nombre des m´emoires, leur agencement et le type d’interconnexions, pr´esence ou non d’une quelconque logique et/ou de circuits arithm´etiques d´edicac´es, etc... La quantit´e des ressources logiques disponibles est le plus souvent exprim´ee par le nombre de cellules ´el´ementaires et/ou par le nombre ´equivalent de portes logiques, le param`etre d´ej`a introduit dans le Chapitre 1.

En fonction de la quantit´e des ressources logiques disponibles, on distingue des circuits FPGA de faible, moyenne et haute densit´e. Actuellement les circuits FPGA de haute densit´e d´etiennent une importante puissance de calcul et peuvent ˆetre utilis´es pour la r´ealisation de syst`emes logiques combinatoires et/ou s´equentiels complexes sur un grand nombre de variables d’entr´ee.

Le Tableau 3.1 indique la quantit´e des ressources logiques qui caract´erisent quelques circuits FPGAs actuels de faible, moyenne et haute densit´e produits par les trois principaux produc-

1Par un bi-stable programmable on sous-entend un ´el´ement m´emoire qui peut ˆetre programm´e de fa¸con a` reproduire le fonctionnement des bi-stables habituels : D, T, SR, JK.

93 Chapitre 3. Architectures d´edicac´ees teurs de circuits logiques programmables : Xilinx, Actel et Altera. L’architecture d’une cellule logique ´el´ementaire (CLE) varie fortement d’un producteur a` l’autre. Ainsi chez Xilinx une seule CLE poss`ede 8 m´emoires a` 4 bits d’adresse (16 mots d’un bit), huit bi-stables program- mables et une logique d´edicac´ee par m´emoire pour des op´erations arithm´etiques. Chez Actel, une CLE est compos´ee d’une m´emoire a` 5 bits d’adresse (32 mots d’un bit) et d’un bi-stable programmable toutes les deux m´emoires. Enfin une CLE de chez Altera est une m´emoire a` 4 bits d’adresse (16 mots d’un bit), associ´ee a` un bi-stable programmable et une logique d´edicac´ee pour l’addition.

Les circuits FPGA ayant une mˆeme quantit´e de ressources logiques sont disponibles dans des boˆıtiers standards d’un nombre variable de bornes d’entr´ee/sortie. Ainsi pour une application donn´ee et par souci d’´economie un utilisateur peut choisir le circuit FPGA le plus appropri´e non seulement en termes des ressources logiques requises mais aussi en termes de nombre de bornes d’entr´ee/sortie n´ecessaires.

La derni`ere colonne du Tableau 3.1 indique le nombre maximal de bornes d’entr´ee/sortie pour des circuits FPGAs mentionn´ees.

Producteur Famille Circuit CLE Np Nes

XC2V250 64 0.250 200 Virtex-II [Xil03f] XC2V1500 1920 1.5 528 XC2V8000 11648 8 1108 Xilinx XC2VP2 1408 nc. 2 204 Virtex-II-Pro [Xil03g] XC2VP30 13696 nc. 644 XC2VP125 55616 nc. 1200

AX125 1344 0.125 168 Axcelerator Actel [Act03] AX500 5376 0.5 336 AX2000 21504 2 684

EP1S10 10570 nc. 426 Stratix Altera [Alt03b] EP1S30 32470 nc. 726 EP1S80 79040 nc. 1238

Tab. 3.1: Quelques circuits FPGAs typiques en 2004 : la quantit´e des res- sources logiques exprim´ee par le nombre de cellules logiques ´el´ementaires (CLE) et le nombre de portes logiques ´equivalant (Np) en million de portes ; le nombre maximal de bornes d’entr´ees/sorties (Nes).

2Le nombre ´equivalant de portes logiques n’est pas communiqu´e pour ce circuit.

94 3.1. Circuits FPGAs

3.1.2 Impl´ementation des circuits logiques dans les FPGA

3.1.2.1 Processus d’impl´ementation

L’expansion du monde des circuits logiques programmables et en particulier des circuits FPGAs est ´etroitement li´ee au d´eveloppement de la technologie de fabrication des circuits int´egr´es permettant la fabrication d’unit´es de plus en plus denses. Mais cette expansion n’au- rait jamais pu avoir une telle ampleur sans le d´eveloppement, en parall`ele, d’outils performants permettant de faciliter le processus de conception des circuits logiques avec de la logique pro- grammable. Ces outils assurent d’une part la description ais´ee des circuits logiques complexes et d’autre part la r´ealisation automatique de circuit a` partir de ces descriptions.

La r´ealisation d’un circuit logique, en fait le passage de sa description a` l’information n´ecessaire pour la r´ealisation d’une impl´ementation physique du circuit dans un FPGA (i.e la configu- ration), est dans la litt´erature anglo-saxonne appel´e design flow. Ce processus est habituel- lement d´ecompos´e en plusieurs ´etapes distinctes, repr´esent´ees sch´ematiquement a` la Figure 3.2. Actuellement, grˆace aux outils informatis´es, certaines ´etapes de ce processus peuvent ˆetre r´ealis´ees de fa¸con enti`erement automatique (notamment la synth`ese, l’impl´ementation ainsi que la g´en´eration de la configuration pour le FPGA cible).

Analyse Simulation fonctionnelle

Description de Synthèse Implémentation Configuration FPGA circuit

Fig. 3.2: Diff´erentes ´etapes du processus Design Flow depuis la descrip- tion d’un circuit logique a` la configuration d’un circuit FPGA.

Description La premi`ere ´etape du design flow comprend la description formelle du circuit a` partir des sp´ecifications. Aujourd’hui la description des circuits logiques est faite la plupart de temps a` l’aide des langages de description de mat´eriel (dans la litt´erature anglo-saxonne Hardware Description Language - HDL) a` haut niveau d’abstraction tels que Verilog ou VHDL. Souvent, lorsque l’utilisateur souhaite rester proche du mat´eriel afin d’obtenir la meilleure performance possible de son circuit, la description est faite de fa¸con sch´ematique3. Il existe d’autres for- malismes permettant de d´ecrire un circuit logique, souvent propos´es par un producteur de

3Ici on pourrait faire une analogie entre les langages de programmation orient´e objet et les langages HDL et entre la description sch´ematique et le langage assembleur. Si les deux premiers permettent une description ais´ee de probl`emes volumineux et complexes, ils le font parfois au d´etriment de la performance. Dans le Chapitre 2, nous avons pu montrer qu’une approche qui tient compte du mat´eriel et utilise l’assembleur permet d’obtenir d’importants facteurs d’acc´el´eration par rapport a` une approche purement algorithmique, dans laquelle le langage de programmation hautement ´evolu´e permet de faire abstraction compl`ete du mat´eriel.

95 Chapitre 3. Architectures d´edicac´ees

FPGA particulier, comme par exemple l’´editeur graphique des machines a` ´etats finis chez Xilinx. La description d’un circuit peut ˆetre faite exclusivement a` l’aide d’un formalisme bien particulier, ou combiner des formalismes diff´erents. Les diff´erentes parties d’un mˆeme circuit logique complexe peuvent donc ˆetre d´ecrites de fa¸con diff´erente avant d’ˆetre traduites en une configuration particuli`ere pour un (ou plusieurs) FPGA cible.

Synth`ese Lors de l’´etape de la synth`ese, les diff´erentes descriptions ´etablies lors de la premi`ere ´etape sont ramen´ees a` une description du circuit unique, optimis´ee pour une performance maximale ou une occupation minimale des ressources. Apr`es l’´etape de la synth`ese il est possible d’effec- tuer une analyse fonctionnelle du circuit (v´erification de la description a` travers la simulation) et de se rendre compte d’´eventuelles erreurs, avant de passer a` l’´etape de l’impl´ementation, g´en´eralement consid´er´ee comme lente4. L’analyse fonctionnelle n’est qu’une v´erification par- tielle car elle ne peut tenir compte des d´elais introduits par le circuit r´eel, celui-ci n’´etant pas encore r´ealis´e. Lors d’une analyse fonctionnelle tous les d´elais du circuit obtenu apr`es la

4Afin de s’assurer que la traduction des sp´ecifications en description formelle est correcte, il faut passer par une ´etape de v´erification. La v´erification de la description peut ˆetre faite a` travers : la simulation - on ne peut pas garantir qu’elle soit correcte ; la v´erification formelle - on dispose d’une preuve rigoureuse que la description r´epondra toujours aux sp´ecifications. Bien entendu une description formelle des sp´ecifications correcte ne peut encore garantir une r´ealisation mat´erielle qui lui serait enti`erement ´equivalente. On peut supposer que dans le processus de mat´erialisation d’une description correcte il existe des choses ind´ecidables, c’est pour quoi il est impossible de garantir la fiabilit´e absolue d’un syst`eme physique. Pour la v´erification formelle des descriptions des syst`emes combinatoires on dispose des techniques et des outils permettant de facilement traiter mˆeme des syst`emes a` un grand nombre de variables [McF93]. Il n’en est pas de mˆeme pour des syst`emes qui int`egrent la notion de l’´etat, principalement a` cause de tr`es grand nombre de s´equences d’entr´ees possibles. Dans ce cas, lorsque il s’agit de v´erifier formellement des programmes informatiques ou des syst`emes s´equentiels par exemple, d’autres m´ethodes doivent ˆetre employ´ees. Ainsi pour v´erifier formellement un programme (on dit encore ´etablir la correction d’un programme) on peut utiliser la premi`ere m´ethode propos´ee historiquement, mais toujours d’actualit´e, celle des assertions introduite par Floyd et Hoare (voir [Flo67, Hoa69]). On consid`ere un triplet (appel´e aussi le triplet de Hoare) not´e {P }S{Q} ou S d´esigne le programme consid´er´e et {P } et {Q} d´esignent respectivement les assertions (ou ´enonc´es sur l’´etat du programme) avant l’ex´ecution de S (pr´e-condition) et apr`es son ex´ecution (post-condition). V´erifier la correction d’un programme consiste donc a` prouver que pour tout ´etat initial qui satisfait la pr´e- condition {P }, l’application de S am`enera le programme dans un nouvel ´etat qui satisfait la post-condition {Q}. Comme il est impossible de pr´evoir si S termine (Halting Problem de Turing), on parle plutˆot de la possibilit´e de prouver une correction partielle d’un programme (dans l’´enonc´e ”l’application de S” est alors remplac´e par ”lorsque S termine”). Si une telle m´ethode permet de formellement prouver la correction (partielle !) d’un programme, elle est ra- rement utilis´ee en pratique principalement par la lourdeur de sa mise en oeuvre mˆeme pour des programmes simples. Signalons toutefois l’existence des outils permettent son automatisation (voir [BM85, Fra97]) en utilisant un g´en´erateur automatique des assertions et un d´emonstrateur de th´eor`emes. De tels outils sont g´en´eralement utilis´es pour la validation de programmes sensibles qui exigent une grande robustesse (nucl´eaire, aviation, m´edical etc.). En ce qui concerne la v´erification formelle des syst`emes s´equentiels on peut utiliser les r´eseaux de Petri. En effet, en montrant que le r´eseau de Petri correspondant poss`ede des bonnes propri´et´es pour un marquage initial donn´e (M0), c’est a` dire qu’il est : – vivant - chaque transition du r´eseau reste franchissable – sauf - que le r´eseau est K-born´e avec K=1 ; une place de r´eseau ne peut contenir plus qu’un jeton, – r´einitialisable - si pour un marquage accessible M depuis le marquage initial M0 il existe une s´equence de franchissement telle qui permet d’arriver au M0 on peut ˆetre surˆ que dans le syst`eme mod´elis´e par ce r´eseau de Petri il n’y aura ni de blocage, ni des incoh´erences pour toute s´equence de franchissement envisag´ee. Mˆeme si ce processus dans certains cas peut ˆetre automatis´e, il ne peut pas ˆetre utilis´e pour des circuits actuels complexes. Dans ce cas on fait appel a` d’autres m´ethodes. Dans [McF93, CW96] on peut trouver un recueil des diff´erentes m´ethodes actuelles de v´erification formelle.

96 3.1. Circuits FPGAs synth`ese sont consid´er´es comme nuls5.

Impl´ementation L’´etape de l’impl´ementation est g´en´eralement divis´ee en trois sous-´etapes distincts : le map- ping, le placement et le routage. Le mapping consiste a` “traduire” le circuit logique obtenu par le processus de synth`ese en m´emoires des cellules logiques ´el´ementaires d’un circuit FPGA particulier. Lors de la sous-´etape de placement, une cellule logique existante, avec sa posi- tion unique au sein du FPGA cible, est attribu´ee a` chaque cellule logique n´ecessaire pour la r´ealisation du circuit. Ceci est bien entendu fait sous la contrainte des longueurs minimales des connexions entre les diff´erentes cellules. Enfin la derni`ere sous-´etape, le routage, consiste a` ´etablir les diff´erentes connexions physiques entre les cellules ´el´ementaires plac´ees. Lorsque l’´etape de l’impl´ementation est achev´ee, il est possible de r´ealiser une simulation r´ealiste de fonctionnement du circuit, car a` ce stade on dispose de l’information pr´ecise sur les d´elais r´eels qui seront introduits par le circuit physique (v´erification de l’impl´ementation).

Configuration Le processus de design flow se termine par la g´en´eration du fichier de configuration corres- pondant au circuit r´ealis´e. Ce fichier peut ˆetre directement transf´er´e dans le circuit FPGA cible depuis la plate-forme du d´eveloppement ou depuis une m´emoire programmable dans le cas d’une solution embarqu´ee. Le circuit con¸cu devient alors op´erationnel.

3.1.2.2 Perspectives de la description des circuits

Dans la section pr´ec´edente nous avons mentionn´e que la description des circuits logiques est le plus souvent faite a` l’aide de langages de description mat´eriel (HDL). Dans ce cas, la conception d’un circuit consiste en l’´ecriture d’un “programme” correspondant au probl`eme donn´e, tout comme en informatique traditionnelle. Cependant le formalisme d’un langage de programmation de mat´eriel est propre a` la description du mat´eriel et n’a rien a` voir avec le formalisme des langages de programmation utilis´es pour la conception des programmes informatiques.

Au cours de ces derni`eres ann´ees nous assistons a` un rapprochement entre les langages de programmation propres a` l’informatique, tels que C/C++ et mˆeme JAVA, et les langages de description de mat´eriel. Une telle tendance se justifie par le fait que la densit´e des circuits FPGAs devient tellement importante qu’il est d´esormais possible de concevoir des syst`emes tr`es complexes, mˆeme au sein d’un seul circuit int´egr´e. La gestion de la description d’un tel syst`eme peut s’av´erer difficile, mˆeme si on utilise des langages de description de mat´eriel tels que VHDL ou Verilog.

Selon une ´etude r´ecente (voir [HT03]) les trois exemples peut-ˆetre les plus repr´esentatifs des langages “hybrides”, c’est a` dire les langages qui tentent de combiner les formalismes soft et le hard sont : – HardwareC - d´evelopp´e a` l’Universit´e de Stanford [Kup95, Mic99] – SA-C - d´evelopp´e a` l’Universit´e de Colorado [DBH+00].

5Pour un circuit r´eel, en fait le circuit logique physiquement r´ealis´e dans un FPGA, on peut d´eduire les d´elais de propagation des signaux a` travers le r´eseau d’interconnexion, les temps d’acc`es aux m´emoires des cellules ´el´ementaires, etc...

97 Chapitre 3. Architectures d´edicac´ees

– SpecC - d´evelopp´e a` l’Universit´e de Californie [CG02] Les trois langages d’une syntaxe proche de C proposent des extensions n´ecessaires pour la description du mat´eriel. Il s’agit des notions de calcul concurrent et de d´elais, ainsi que de la possibilit´e de sp´ecification de contraintes sur les d´elais et l’espace utilis´e pour le circuit final. Il est ´evidant que la principale difficult´e rencontr´ee dans l’´elaboration de tels langages r´eside dans la conception de compilateurs suffisamment performants en termes de qualit´e du circuit obtenu : la plus grande vitesse de fonctionnement de circuit possible pour la moindre occupation d’espace possible.

Si de tels langages ne sont pas encore d’un usage courant pour le processus complet de l’impl´ementation, les langages de programmation traditionnels tel que C++ sont couram- ment utilis´es pour l’´elaboration de mod`eles de circuits et de syst`emes complexes. Ces mod`eles visent a` reproduire le plus fid`element possible le fonctionnement r´eel d’un syst`eme physique. L’exemple type d’un tel outil de mod´elisation est le SystemC (voir [GR00, Swa01, Ger00]). Il s’agit de l’ensemble des librairies ´ecrites a` l’aide d’un langage de programmation typique- ment logiciel, le C++. Grˆace a` ces librairies il est possible d’´ecrire un programme, en fait le mod`ele d’un syst`eme tr`es complexe, ind´ependamment de la technologie cible utilis´ee pour la r´ealisation mat´erielle (FPGAs, ASIC,...). Apr`es la construction du mod`ele, il est possible d’effectuer une simulation, a` l’aide d’un simple ordinateur personnel et de tester le mod`ele dans son ensemble. Mis a` part la possibilit´e de simulation, l’utilisateur peut produire un ca- hier des charges tr`es pr´ecis du syst`eme final, permettant de passer ais´ement du mod`ele a` la r´ealisation finale. Le SystemC apparaˆıt donc comme un outil puissant, mais limit´e lorsqu’il s’agit d’automatiser le processus de r´ealisation de circuit car le passage du cahier des charges a` l’information n´ecessaire a` l’impl´ementation doit se faire manuellement.

Les tendances actuelles de la recherche visent donc a` ´etablir un langage unifi´e qui serait utilis´e aussi bien pour la description des programmes informatiques que pour la description de mat´eriel. Le choix entre la r´ealisation d’un fichier de configuration pour un circuit FPGA ou d’un programme ex´ecutable a` partir d’une mˆeme description faite en langage de haut niveau d’abstraction, pourrait se faire sans aucune intervention sur la description formelle du probl`eme et de fa¸con tout a` fait automatique. Nous n’´emettrons pas de doute quant a` la faisabilit´e de tels langages et compilateurs associ´es, mais nous attirons l’attention sur la qualit´e des r´esultats obtenus a` l’aide des outils d’aujourd’hui. Pour les ordinateurs de bureau nous avons pu voir que les compilateurs actuels n’exploitent que tr`es peu le parall´elisme d’un processeur de grande s´erie et que les meilleurs performances sont obtenues en programmant ce processeur en langage machine, en tenant compte de son architecture.

Qu’en est-il de la performance des outils de synth`ese et d’impl´ementation lorsqu’il s’agit de construire des circuits logiques complexes a` l’aide des FPGAs ?

3.1.2.3 Efficacit´e des outils actuels d’impl´ementation

Nous avons pr´ecis´e que les outils de synth`ese et d’impl´ementation peuvent de fa¸con enti`erement automatique, assurer le passage d’un ensemble de descriptions diff´erentes a` l’in- formation n´ecessaire pour la r´ealisation d’un circuit dans un FPGA.

98 3.1. Circuits FPGAs

Cependant les questions relatives a` l’efficacit´e d’un processus d’impl´ementation enti`erement automatis´e sont toujours d’actualit´e. Ainsi on peut s’interroger :

– Dans quelle mesure les outils automatiques d’aujourd’hui produisent de bons r´esultats en termes de la quantit´e des ressources logiques mobilis´ees et de vitesse de circuit ob- tenue pour une description de circuit donn´ee ?

– Peut-on, et a` quel prix, obtenir une am´elioration de performances en faisant intervenir le facteur humain dans le processus de l’impl´ementation automatique ?

– Dans le cas d’une r´eponse positive a` la question pr´ec´edente, qu’elle est l’ordre de gran- deur de l’am´elioration que cette intervention peut apporter ?

Aujourd’hui on ne dispose pas de r´eponse d´efinitive a` ces questions. Les communaut´es scienti- fiques et industrielles actives dans le domaine de la logique programmable sont plutˆot divis´ees.

La r´eponse de certains est assez cat´egorique : les impl´ementations automatiques ne pourront jamais remplacer l’intervention d’un op´erateur humain [AFSS00, TT01]. D’autres, de fa¸con plus mod´er´ee, sugg`erent que les r´esultats obtenus a` l’aide des outils automatis´es sont en g´en´eral “satisfaisants” [VSS99].

Afin de se passer des jugements subjectifs et de donner une r´eponse claire a` ce genre de ques- tions, Singh propose une ´etude comparative (voir [Sin00]) sur l’efficacit´e de l’impl´ementation automatique et “manuelle” (en fait l’impl´ementation automatique assist´ee par un op´erateur humain). Pour ce faire, il propose une comparaison des performances d’un ensemble de circuits correspondants aux quelques applications types : les arbres d’additionneurs, les multiplica- teurs a` coefficient constant, les filtres systoliques etc... Ces circuits ont ´et´e r´ealis´es d’une part a` l’aide d’un processus d’impl´ementation enti`erement automatis´e et d’autre part avec l’in- tervention d’un expert dans le domaine de l’impl´ementation optimale des circuits logiques dans les FPGAs. Son intervention dans le processus d’impl´ementation se situe au niveau de placement d’une part et au niveau de sp´ecification des contraintes explicites des d´elais de propagation.

Pour la plupart d’applications les r´esultats obtenus montrent un gain en vitesse de fonction- nement de circuit variable entre 30 % et 50 % en faveur des impl´ementations assist´ees par l’op´erateur humain. Curieusement, l’impl´ementation manuelle d’un filtre systolique n’a pas abouti a` des am´eliorations semblables malgr´e une structure r´eguli`ere qui, a priori, pourrait faire croire a` la sup´eriorit´e d’un homme devant la machine, pour ce qui est, au moins, de la remarquer.

L’origine de ces am´eliorations r´eside dans le fait que l’op´erateur humain fait intervenir dans le processus d’impl´ementation un certain nombre de contraintes sur le placement. Ces contraintes limitent l’espace des solutions dans lequel le programme de placement et de routage effectue la recherche. Ensuite comme le premier objectif pour le programme devient le respect des contraintes et plus le compromis entre la qualit´e de la solution et le temps consomm´e pour la trouver, le programme de placement et de routage mettra plus de temps de recherche d’une solution (dans l’´etude propos´ee par Singh dans [Sin00] jusqu’`a trois fois plus que dans un processus automatique).

99 Chapitre 3. Architectures d´edicac´ees

D`es lors nous pouvons tirer deux conclusions importantes : 1. La taille des circuits FPGAs est de plus en plus importante, au point qu’il devient de plus en plus difficile pour un op´erateur humain d’intervenir dans le processus de l’impl´ementation physique du circuit. N´eanmoins cela reste toujours possible. 2. Les outils de synth`ese et d’impl´ementation ne sont pas parfaits et la performance de circuit obtenue peut, dans certains cas, ˆetre sensiblement am´elior´ee en assistant le pro- cessus d’impl´ementation.

3.1.3 Applications des FPGAs

L’augmentation de la densit´e des circuits FPGAs, combin´ee avec le d´eveloppement de langages ´evolu´es de description de mat´eriel et des outils permettant de passer de fa¸con auto- matique de la description a` la r´ealisation mat´erielle, a ouvert la voie a` l’application des FPGAs dans l’acc´el´eration du temps de traitement d’un grand nombre d’applications. Les domaines abord´es sont tr`es vari´es et touchent la cryptographie, le traitement des images num´eriques, la 3D,... la liste annonc´ee des applications est loin d’ˆetre exhaustive.

Dans ce qui va suivre nous nous int´eresserons uniquement aux algorithmes et architectures FPGAs associ´es aux probl`emes de traitement des images num´eriques et plus particuli`erement a` ceux destin´es au calcul des filtres non-lin´eaires.

100 3.2. Parall´elisation du calcul des filtres non-lin´eaires

3.2 Parall´elisation du calcul des filtres non-lin´eaires

Le calcul des filtres non-lin´eaires implique le tri, l’un des probl`emes les plus r´ecurrents de l’informatique appliqu´ee. Dans le but d’acc´el´erer ce type de traitement, un grand nombre d’algorithmes ont ´et´e propos´es en vue de r´ealiser des programmes destin´es a` l’ex´ecution sur des architectures universelles parall`eles. Malheureusement, le coutˆ et la taille de ces syst`emes les rendent inutilisables pour des applications de tous les jours. C’est pour cette raison que nous nous int´eresserons uniquement aux architectures d´edicac´ees qui, dans certains cas pr´ecis peuvent rivaliser de performance avec les architectures universelles parall`eles, tout en affichant un coutˆ nettement moins ´elev´e6.

Au cours des derni`eres ann´ees de nombreux algorithmes et architectures associ´ees ont ´et´e propos´es pour des applications li´ees au domaine de traitement des images num´eriques. Dans cette section nous tenterons de donner un aper¸cu aussi complet que possible des diff´erents algorithmes et de syst`emes existants, utilis´es pour le calcul des filtres non-lin´eaires.

Avant de donner des explications plus d´etaill´ees, nous proposons plusieurs classifications des solutions existantes concernant les algorithmes et les architectures associ´ees d´ej`a r´ealis´ees aujourd’hui. Ceci nous permettra de cerner la probl´ematique de l’impl´ementation des filtres non-lin´eaires dans les syst`emes d´edicac´es de fa¸con plus syst´ematique et compl`ete.

3.2.1 Classification des algorithmes et des architectures existants

Une premi`ere classification des diff´erents algorithmes et des architectures existantes pour le calcul des filtres non-lin´eaires peut ˆetre faite sur base du nombre d’op´erandes et du nombre de bits calcul´es simultan´ement par l’unit´e de traitement. Si on se base sur un tel crit`ere, il est alors possible de faire la distinction entre deux modes de fonctionnement suivants : – le mode bit-parall`ele et – le mode bit-s´erie.

Remarquons que ce crit`ere de classification n’est pas uniquement applicable aux algorithmes et architectures destin´es au traitement des images, son caract`ere est beaucoup plus g´en´eral.

Une unit´e de traitement est habituellement construite autour d’une unit´e arithm´etique/logique permettant de calculer des fonctions (les op´erations) sur deux arguments (les op´erandes) : y = f(x0, x1). Le calcul d’une fonction f de n arguments : y = f( x ) = f(x[0], x[1], . . . , x[n 1]) (3.1) →− − peut ˆetre effectu´e a` l’aide d’une seule unit´e de traitement a` deux op´erandes en d´ecomposant le calcul comme suit :

y = f x[0], f x[1], . . . , f(x[n 2], x[n 1]) (3.2) − − · · ·     6Une comparaison de performance pour quelques applications types entre les architectures universelles parall`eles et les syst`emes reconfigurables peut ˆetre trouv´ee dans [Vui94]. D’un coutˆ moindre, les syst`emes reconfigurables montrent une meilleure performance que les architectures parall`eles universelles.

101 Chapitre 3. Architectures d´edicac´ees

Une telle unit´e de traitement calcule donc la fonction f de n arguments de fa¸con s´equentielle, en n 1 ´etapes. Malgr´e le caract`ere s´equentiel du calcul, l’unit´e de traitement pr´esente un − certain parall´elisme, situ´e au niveau des bits qui codent le r´esultat de l’op´eration et les argu- ments. En effet, l’Equation´ 3.2 fait abstraction compl`ete du codage binaire des mots y et x[i]. Une architecture (un algorithme) qui effectue le calcul d’une fonction a` plusieurs arguments comme une succession de calculs interm´ediaires, mais qui fait l’abstraction du codage binaire des arguments, sera alors consid´er´ee comme bit-parall`ele.

Par opposition au calcul bit-parall`ele, le calcul effectu´e en mode bit-s´erie remplace le pa- rall´elisme des deux arguments au niveau de leur codage par le parall´elisme situ´e au niveau du nombre d’arguments. Dans ce cas, l’unit´e de traitement op`ere sur un nombre d’op´erandes ´egal au nombre d’arguments, chaque op´erande ´etant constitu´ee d’un seul bit.

Nous avons donc pour le calcul de y = f(→−x ) : y[0] = f(x[0, 0], x[1, 0], . . . , x[n 1, 0]) (3.3) − . . y[b 1] = f(x[0, b 1], x[1, b 1], . . . , x[n 1, b 1]) − − − − − avec :

b 1 − j xi = x[i, j]2 , i 0, , n 1 (3.4) ∈ { · · · − } j X=0 b 1 − y = y[j]2j j X=0 ou` : – x[i, j] d´esigne le bit de poids j du mot i de vecteur d’arguments →−x et

– y[j] est le bit de poids j du mot y.

Comme on peut le voir le nombre de pas de calcul n´ecessaires pour ´evaluer f(→−x ) ne d´epend plus du nombre d’op´erandes mais bien du nombre de bits utilis´es pour coder les arguments. Bien entendu une telle unit´e de traitement manque d’universalit´e puisqu’elle doit ˆetre adapt´ee pour chaque type de calcul et en fonction du nombre d’op´erandes requises.

Mis a` part cette classification, tr`es g´en´erale mais tr`es importante quant a` la parall´elisation des probl`emes en traitement des images, on peut citer celle de Charot, propos´ee dans [Cha93b]. Cette classification, destin´ee aux syst`emes parall`eles en traitement des images, combine les taxinomies des architectures universelles d´ej`a pr´esent´ees au Chapitre 1 : les syst`emes MIMD, SIMD, pipeline, la topologie des interconnexions des unit´es de traitement : lin´eaire, matricielle, tore, . . . et le mode de fonctionnement pour l’unit´e de traitement mˆeme : les modes bit-s´erie et bit-parall`ele. Malheureusement son caract`ere trop g´en´eral ne permet pas de d´efinir toutes les architectures d´edicac´ees qui ont ´et´e propos´ees depuis pour le calcul des filtres non-lin´eaires.

Une classification, consacr´ee uniquement aux architectures d´edicac´ees destin´ees au calcul des filtres non-lin´eaires, est propos´ee par Chakrabarti et Lucke dans [CL98].

102 3.2. Parall´elisation du calcul des filtres non-lin´eaires

Cette classification distingue trois architectures possibles : – Les architectures matricielles (Array architectures) – Les r´eseaux de tri (Sorting Network Architectures) – Les architectures d´edi´ees aux filtres de piles

Architectures matricelles Dans le cas d’une architecture matricielle, la valeur de rang est calcul´ee pour chaque pixel de voisinage Vi en cours de traitement. Lors du d´eplacement de la fenˆetre, les rangs des pixels d´ej`a calcul´es mais pr´esents dans le voisinage suivant Vi+1, sont mis a` jour. Les rangs des nouveaux pixels d´efinis par Vi+1 sont ensuite calcul´es : le voisinage compl`etement tri´e est obtenu avec peu d’op´erations suppl´ementaires. La valeur filtr´ee est obtenue en identifiant le pixel de rang voulu.

Les architectures matricielles sont construites autour d’unit´es de traitement qui fonctionnent en mode bit-s´erie ou en mode bit parall`ele. Souvent, lorsque cela est possible, ces architectures int`egrent le fonctionnement en pipe-line afin d’augmenter le d´ebit des pixels trait´es.

R´eseaux de tri Dans une architecture de type r´eseau de tri, les unit´es de traitement manipulent les valeurs de niveaux de gris des pixels du voisinage V plutˆot que les valeurs de rang. A l’aide d’un ensemble de comparateurs chaque voisinage est tri´e individuellement, ou mis a` jour lors de l’avancement de le fenˆetre. En sortie nous disposons d’un vecteur V˜ compl`etement tri´e. Dans le cas d’une recherche de rang particulier on peut se contenter d’un tri partiel dans un souci d’´economie des ressources utilis´ees. Le r´esultat du filtrage est obtenu par l’indexation du vecteur a` la sortie.

Si l’impl´ementation des r´eseaux de tri implique a priori des architectures bit-parall`eles, cer- tains algorithmes en mode bit-s´erie les utilisent pour les calculs interm´ediaires, comme nous le verrons par la suite. Comme pour les architectures matricielles, les r´eseaux de tri int`egrent le fonctionnement en mode pipe-line pour un plus grand d´ebit des pixels trait´es.

Architectures d´edi´ees aux filtres de piles Dans le Chapitre 1 une classe particuli`ere de filtres non-lin´eaires a ´et´e d´ecrite, les filtres de piles. Nous avons vu comment ces filtres peuvent ˆetre utilis´es pour le calcul des filtres de rang classiques : Min, m´edian, Max. Du fait du codage particulier des valeurs des pixels, ces filtres se prˆetent bien a` une impl´ementation dans les syst`emes d´edicac´es parall`eles. Dans ces architectures les unit´es de traitement sont forc´ement de type bit-s´erie, mais il s’agit bien d’une architecture a` part enti`ere du fait du codage particulier des arguments.

Pour donner un aper¸cu des diff´erents syst`emes de calcul des filtres non-lin´eaires nous retien- drons cette derni`ere classification en faisant la distinction entre deux modes de fonctionnement pour l’unit´e de traitement : le mode bit-s´erie et le mode bit-parall`ele. Egalemen´ t nous ne li- miterons pas l’appellation d’architecture matricielle uniquement aux celles bas´ees sur des algorithmes manipulant les valeurs de rang. Par architecture matricielle nous allons entendre toute architecture de topologie mesh utilis´ee pour le calcul des filtres de rang.

103 Chapitre 3. Architectures d´edicac´ees

3.2.2 Architectures matricielles

3.2.2.1 Mode bit-s´erie

Les architectures matricielles en mode bit-s´erie sont g´en´eralement dot´ees d’unit´es de traitement simples, permettant d’arriver a` un parall´elisme massif, mˆeme avec un seul cir- cuit int´egr´e. Plusieurs syst`emes bas´es sur ce type d’architecture particuli`ere ont ´et´e con¸cus sp´ecifiquement pour les probl`emes de traitement des images. Nous en citerons ici les exemples les plus repr´esentatifs : – GAPP ([CH84, Clo88, Clo91]), – PAPIA-2 ([BCCM91]), – MGAP ([BOI93a, BOI93b, OINB93]), – SliM [CSC96] sans parler des architectures plus classiques (et plus anciennes) telles que : MPP, CLIP7A, MasPar MP-1 etc...

GAPP Le processeur GAPP (l’acronyme de Geometric Arithmetic Parallel Processor), con¸cu par Holsztynski et Marietta et fabriqu´e par NCR dans les ann´ees ’80, est une matrice de 6 12 unit´es de traitement qui fonctionnent selon le mod`ele SIMD de calcul. Chaque unit´e de × traitement est dot´ee de quatre registres d’un bit, d’une unit´e de calcul permettant d’effectuer des op´erations logiques sur trois des quatre registres internes et d’une m´emoire de 128 bits. Les instructions du GAPP sont de type LIW (Long Instruction Word) et permettent une exploitation directe du parall´elisme des instructions propre a` son architecture. Les unit´es de traitement peuvent communiquer dans deux directions principales : nord-sud et ouest-est et ainsi effectuer des ´echanges de donn´ees. Les unit´es de traitement au bord du circuit peuvent ˆetre connect´ees soit entre elles, de fa¸con a` constituer un tore et permettre un ´echange de donn´ees cyclique au sein des unit´es de traitement d’un mˆeme circuit, soit avec d’autres cir- cuits permettant la r´ealisation de syst`emes massivement parall`eles. R´ecemment, une nouvelle version du GAPP, mise a` jour au niveau de la technologie de fabrication, a ´et´e mise en service dans le domaine de la compression et de la transmission de la vid´eo num´erique (voir [Ack02]).

Le processeur GAPP peut ˆetre utilis´e pour l’ex´ecution des diff´erents algorithmes qui se prˆetent a` une parall´elisation de type SIMD. Dans le domaine du traitement des images, son architec- ture est parfaitement adapt´ee au calcul sur des images binaires avec des voisinages de petite taille. Dans ce cas, la surcharge en communication entre les unit´es de traitement est faible, car le voisinage ne concerne que les huit voisins directs du pixel consid´er´e. Il en r´esulte donc un bon ´equilibre entre le temps pass´e pour l’´echange de donn´ees et le calcul proprement dit.

Pour des voisinages plus grands, des traitements sur des images en niveau de gris plutˆot que binaire ou dans le pire des cas, lorsqu’il s’agit d’un traitement qui combine les deux, le coutˆ en communication devient tr`es important. Dans ce cas l’´equilibre entre l’´echange des donn´ees et le calcul est rompu : le syst`eme passe plus de temps a` obtenir les donn´ees qu’`a calculer. Pour illustrer ce propos, on peut comparer le nombre d’op´erations n´ecessaires au calcul des op´erateurs morphologiques classiques sur des images binaires, avec celui d’un filtre de rang sur des images en niveau de gris. Pour calculer un op´erateur morphologique sur une image binaire dans un voisinage 3 3 il faut compter une dizaine d’op´erations, alors que le calcul × 104 3.2. Parall´elisation du calcul des filtres non-lin´eaires de la valeur m´ediane d’un mˆeme voisinage pour des pixels cod´es sur 8 bits n´ecessite plusieurs milliers d’op´erations (source : [HSB84]).

PAPIA-2 La surcharge en communications peut ˆetre r´eduite en utilisant une meilleure connectivit´e entre les unit´es de traitement. Le syst`eme PAPIA-2 permet, grˆace aux connexions directes de chaque unit´e de traitement avec ses huit voisins, de r´eduire consid´erablement le nombre d’op´erations a` effectuer dans le cas de calcul sur des images en niveau de gris. Pour des pixels cod´es sur 8 bits, le calcul d’un filtre Min/Max, le filtre de rang le plus favorable en termes de nombre de pas de calcul, n´ecessite n´eanmoins 745 op´erations (source : [BCCM91]).

MGAP Le filtre m´edian peut ˆetre calcul´e avec un mˆeme nombre d’instructions a` l’aide de syst`eme MGAP (Micro Grained Array Processor). D’une architecture tr`es proche de celle du GAPP, le syst`eme MGAP calcule le filtre m´edian d’un voisinage 3 3 pixels cod´es sur 8 bits en 675 × op´erations (source : [BOI93b]).

SliM En gardant la mˆeme structure d’interconnexions que GAPP et MGAP, mais avec une unit´e de traitement a` 9 op´erandes et une possibilit´e de transfert des donn´ees et de calcul simultan´e, le syst`eme SliM (Sliding Memory Plane), propos´e par Chang (voir [CSC96]) permet d’effectuer le calcul d’un filtre m´edian sur un voisinage 3 3 en seulement 228 instructions. ×

3.2.2.2 Mode bit-parall`ele

Les unit´es de traitement fonctionnant en mode bit-parall`ele requi`erent une plus grande quantit´e de ressources logiques lors de leur impl´ementation que celles fonctionnant en mode bit-s´erie. Ceci est principalement duˆ a` la complexit´e de l’unit´e de traitement et a` la taille des m´emoires utilis´ees pour la sauvegarde des op´erandes. Etan´ t donn´e une mˆeme technologie de fabrication et une mˆeme surface du circuit int´egr´e, ceci conduira inexorablement vers un plus faible parall´elisme des architectures fonctionnant en mode bit-parall`ele. Cependant ces architectures pr´esentent un avantage majeur : le nombre de pas de calcul, a priori plus faible que dans le cas des architectures matricielles. Parfois les unit´es de traitement fonctionnent en mode pipe-line, permettant ainsi d’augmenter le d´ebit de pixels trait´es.

Deux architectures matricielles avec des unit´es de traitement fonctionnant en mode bit- parall`ele et destin´ees au calcul des filtres de rang ont ´et´e propos´ees par Hwang et Lucke (voir [HJ90, LP92]). L’algorithme associ´e implique NV unit´es de traitement identiques qui permettent de calculer la valeur m´ediane d’un voisinage V de NV pixels en √NV pas de temps.

Une autre architecture matricielle de type bit-parall`ele a ´et´e propos´ee par Chakrabarti dans [Cha94]. Son principal avantage r´eside dans le choix que l’on peut faire entre deux objectifs oppos´es : la performance et les ressources utilis´ees. Lorsque l’objectif vise la performance, avec un coutˆ maximal en termes de ressources mobilis´ees, l’architecture propos´ee permet de calculer le filtre m´edian a` chaque cycle. Une ´economie des ressources peut cependant ˆetre obtenue en sacrifiant un certain nombre de cycles par pixel calcul´e. Ainsi, si l’on admet un

105 Chapitre 3. Architectures d´edicac´ees

nombre T de cycles d’ex´ecution par pixel de l’image r´esultante, avec 0 T √NV , alors la ≤ ≤ surface occup´ee par unit´e de traitement diminue de ce mˆeme facteur T .

3.2.3 R´eseaux de tri

En 1968 Batcher introduit la notion des r´eseaux de comparateurs et des r´eseaux de tri pouvant ˆetre utilis´es pour une impl´ementation parall`ele du probl`eme du tri a` l’aide de la logique programmable (voir [Bat68]). Nous exposerons ici bri`evement le principe de fonction- nement des diff´erents algorithmes. Pour une d´efinition plus formelle de ces r´eseaux on peut se rapporter a` [Knu73].

Un r´eseau de comparateurs est constitu´e d’un certain nombre de nœuds. Chaque nœud est constitu´e de deux entr´ees, ae et be, d’un comparateur sur ces entr´ees, d’une unit´e de permuta- tion et de deux sorties, as et bs. Lorsque, par exemple, ae > be, les deux mots a` l’entr´ee seront permut´es et nous avons a` la sortie as = be, bs = ae (dans le cas contraire, lorsque ae be, les ≤ deux mots ne seront pas permut´es et nous aurions as = ae, bs = be).

Habituellement on repr´esente un r´eseau de tri sous la forme d’un graphique compos´e de lignes horizontales parall`eles. A chaque ligne de ce graphique est associ´ee un ´el´ement particulier du vecteur a` trier. Sur ces lignes on dispose des nœuds qui effectuent les op´erations de compa- raison et de permutation. Les nœuds seront repr´esent´es par une fl`eche orient´ee dans le sens du chemin emprunt´e par le plus grand ´el´ement comme le montre la Figure 3.3. a b a a

b a b b a > b a < b

Fig. 3.3: Le nœud comparateur dans un r´eseau de tri.

Si plusieurs nœuds se trouvent sur une mˆeme ligne verticale, les op´erations de comparaison et de permutation peuvent ˆetre ex´ecut´ees en parall`ele. Le nombre de lignes verticales indique donc le nombre d’´etapes de calcul a` effectuer, tandis que le nombre de fl`eches orient´ees indique le nombre de comparateurs a` mettre en œuvre.

Un r´eseau de tri est un r´eseau de comparateurs permettant de trier compl`etement un vecteur a` son entr´ee.

En fonction du nombre de comparateurs et de leur disposition dans le r´eseau, on distingue trois principaux types de r´eseau :

1. Bubble, Figure 3.4) - Dans ce r´eseau NV 1 nœuds sont utilis´es pour trouver le maximum − du vecteur V qui est mis a` la place du dernier ´el´ement. La proc´edure est ensuite appliqu´ee r´ecursivement pour les ´el´ements encore non-class´es. Un tel r´eseau est compos´e de NV (NV 1)/2 nœuds qui trient compl`etement V ∗ − en 2NV 3 ´etapes, en tenant compte de la possibilit´e d’une ex´ecution simultan´ee de − certaines op´erations.

106 3.2. Parall´elisation du calcul des filtres non-lin´eaires

V[0] min, r=0 V[1] V[2] V[3] V[4]

V[5] max, r=5

Fig. 3.4: R´eseau de tri Bubble.

2. Odd-even, Figure 3.5) - Le mˆeme nombre de nœuds peut ˆetre utilis´e pour la construction d’un r´eseau qui permet de trier compl`etement le vecteur a` l’entr´ee, en seulement NV ´etapes de calcul. Dans un tel r´eseau les nœuds effectuent les op´erations de comparaison et de permutation entre les ´el´ements d’index pair est les ´el´ements d’index impair pour une ´etape impaire et inversement pour une ´etape paire.

V[0] min, r=0 V[1] V[2] V[3] V[4]

V[5] max, r=5

Fig. 3.5: R´eseau de tri Odd-even.

3. Bitonique, Figure 3.6) - Le tri a` l’aide de ce r´eseau particulier se d´eroule en deux phases : dans un premier temps, le vecteur a` l’entr´ee, compos´e de 2p ´el´ements, est tri´e de fa¸con a` ce qu’il constitue une suite bitonique7. La suite croissante et la suite d´ecroissante de la suite bitonique obtenue sont ensuite fusionn´ees de fa¸con a` produire une suite p 2 2 1 2 compl`etement tri´ee. Le nombre de nœuds n´ecessaires est 2 − (p + p) pour 2 (p + p) ´etapes de calcul.

V[0] V[1] V[2] V[3] V[4] V[5] V[6] V[7] { { suite fusionnement bitonique

Fig. 3.6: R´eseau de tri bitonique.

7 Une suite de n ´el´ements a0, a1, . . . , an, est dite bitonique si ∃i, 0 ≤ i ≤ n tel que si la suite a0, a1, . . . , ai est croissante (ou d´ecroissante) alors la suite ai+1, ai+2, . . . , an est d´ecroissante (croissante).

107 Chapitre 3. Architectures d´edicac´ees

Les diff´erents r´eseaux de tri ont ´et´e adapt´es pour le calcul de filtre m´edian : Bubble dans [Ofl83, KOA90], Odd-even dans [Cha93a] et le bitonique dans [CS92]. Dans le cas particulier des voisinages habituellement utilis´es (les voisinages de 9, 25 et 49 pixels), le r´eseau bitonique peut ˆetre optimis´e quant au nombre de comparateurs utilis´es, comme le montrent Gupta dans [RP93] et Chung dans [Chu96].

Le Tableau 3.2 indique le nombre de nœuds (i.e le nombre de circuits comparateurs) et le nombre d’´etapes n´ecessaires au calcul d’un filtre m´edian, pour des voisinages consid´er´es avec un r´eseau de tri de type odd-even et avec le r´eseau bitonique le plus performant, celui de Chung.

Voisinage R´eseau de tri 3 × 3 5 × 5 7 × 7 Odd-even 36 9 300 25 1176 49 Bitonique - Chung 24 8 50 17 84 25

Tab. 3.2: Le nombre de nœuds et d’´etapes de calcul pour la r´ealisation des r´eseaux de tri odd-even et bitonique de Chung.

La r´ealisation d’un r´eseau de tri quelconque implique donc n´ecessairement l’emploi d’un grand nombre de circuits comparateurs, mˆeme dans le cas des algorithmes tr`es optimis´es. N´eanmoins, l’impl´ementation de ces circuits particuliers dans des FPGAs pourrait ˆetre justifi´ee par le fait que ces circuits poss`edent actuellement une logique d´edicac´ee pour la r´ealisation des additionneurs/soustracteurs rapides. Ces ressources suppl´ementaires peuvent ˆetre facilement exploit´ees pour la construction de comparateurs tr`es performants [ELS00].

Ainsi, un comparateur de deux mots de 8 bits a` l’entr´ee et 1 bit a` la sortie (1 si a > b et 0 dans le cas contraire) n´ecessitera 13 cellules ´el´ementaires lors d’une impl´ementation efficace8 sur la famille Virtex II des FPGA Xilinx. Il faut cependant noter qu’une telle performance ne peut ˆetre obtenue en suivant le flot de conception automatique. Afin d’arriver a` de tels r´esultats, une m´ethodologie sp´ecifique utilis´ee pour la description de circuit est a` suivre, comme par exemple celle donn´ee dans par Fulton dans [Ful99].

Pour des voisinages de petite taille, ´etant donn´e le faible nombre des noeuds, la quantit´e des ressources logiques n´ecessaires pour la r´ealisation d’un seul noeud et la densit´e des circuits FPGAs actuels (comme par exemple celle de la famille Virtex II, cf. Tableau B.1 de l’Annexe B), l’impl´ementation des filtres de rang sur base d’algorithmes de r´eseaux de tri peut donc constituer une solution valable au probl`eme.

L’impl´ementation d’un r´eseau de comparateurs permettant de trouver la valeur m´ediane d’un voisinage 3 3 dans un FPGA a ´et´e propos´ee par Smith (voir [Smi96]). Pour cette × impl´ementation, un r´eseau de tri particulier a ´et´e utilis´e, bas´e sur l’´elimination successive des minima et des maxima locaux, comme le montre la Figure 3.7. Un tel r´eseau permet de r´eduire le nombre de nœuds n´ecessaires, en sacrifiant le tri complet de V .

8Une impl´ementation efficace signifie que le logiciel de synth`ese et d’impl´ementation a effectivement exploit´e les ressources logiques additionnelles disponibles.

108 3.2. Parall´elisation du calcul des filtres non-lin´eaires

V[0] V[1] V[2] V[3] V[4] V[5] med V[6] V[7] V[8] Fig. 3.7: R´eseau de tri utilis´e pour l’impl´ementation de filtre m´edian sur un voisinage de 3 3 pixels dans le FPGA 4000E. ×

Ce r´eseau peut ˆetre adapt´e au fonctionnement en mode pipe-line avec un avantage double. D’une part nous avons une r´eduction de la quantit´e des ressources logiques n´ecessaires : le nombre de comparateurs requis passe de 19 a` 13 ; et d’autre part nous avons une augmentation du d´ebit des pixels trait´es.

Une unit´e de traitement qui calcule la valeur m´ediane de 9 pixels cod´es sur 8 bits n´ecessite 85 cellules logiques ´el´ementaires lorsqu’elle est r´ealis´ee dans un FPGA Xilinx, de la famille 4000E9. Malheureusement aucune information sur la fr´equence de fonctionnement de l’unit´e de traitement propos´ee n’est communiqu´ee.

3.2.4 Architectures bit-s´erie

3.2.4.1 Algorithme pour le filtre de rang

L’algorithme le plus connu permettant de trouver la valeur correspondante a` un certain rang dans un vecteur en mode bit-s´erie est certainement celui d´ecrit par Danielsson dans [Dan81]. Contrairement aux diff´erents algorithmes propos´es pr´ec´edemment, qui se basent sur la recherche de la valeur correspondante au rang r par comparaisons, celle-ci est calcul´ee en fonction des valeurs des diff´erents plans de bits.

Consid´erons un pixel de l’image I en cours de traitement et son voisinage correspondant Vi. L’algorithme effectue le calcul sur les plans de bits du Vi. Chaque bit sera not´e Vi[m, q] avec m l’indice du pixel dans le voisinage et donc m 0, . . . , NV 1 et q l’indice de plan de ∈ − bits q 0, . . . , b 1 (en fait son poids). Pour chaque plan de bits q on compte le nombre ∈ − d’occurrences des 0, not´e n0, ou des 1 (n1), dans le voisinage Vi en cours de traitement. Ce nombre est ensuite compar´e avec la valeur de rang r recherch´e.

Dans la premi`ere it´eration on commence par le plan de bits de poids le plus fort (q = b 1) − et on compte le nombre d’occurrences de 0. En comparant la valeur de n0 avec le rang, deux situations diff´erentes peuvent apparaˆıtre.

9Une cellule logique ´el´ementaire pour ce FPGA compte 2 m´emoires de 16 et une m´emoire de 8 bits.

109 Chapitre 3. Architectures d´edicac´ees

Soit n0 < r : Alors le bit de poids b 1 du pixel r´esultant I˜[q], q = b 1 est mis a` 1, car il − − existe au mois r ´el´ements ayant un 1 pour ce poids. Tous les pixels de Vi ayant pour le poids b 1 la valeur de 0 peuvent ˆetre exclus, car leur niveau de gris est − certainement plus petit que celui indiqu´e par la valeur de rang r.

Dans l’it´eration suivante on cherchera le nombre de voisins ayant pour les deux bits de poids les plus fort la combinaison 10, not´e n10. Ce nombre est ensuite additionn´e a` n0 et le r´esultat est de nouveau compar´e avec la valeur de rang r. Soit n r : 0 ≥ Dans ce cas le bit de poids b 1 du pixel r´esultant est mis a` 0, car il existe au moins − r ´el´ements ayant un 0 pour ce poids. Tous les pixels de Vi ayant pour le poids b 1 la valeur de 1 peuvent ˆetre exclus, car leur niveau de gris est certainement − plus grand que celui indiqu´e par la valeur de rang r.

Dans l’it´eration suivante on cherchera le nombre de voisins ayant pour les deux bits de poids plus fort la combinaison 01, not´e n01. Ce nombre est ensuite soustrait de n0 et le r´esultat est de nouveau compar´e avec la valeur du rang r. Les plans de bits des poids plus faible sont trait´es de fa¸con similaire. A chaque it´eration les valeurs qui ne correspondent certainement pas a` la valeur de rang r de Vi sont exclus tout en calculant la valeur de bit de r´esultat pour ce poids.

La Figure 3.8 montre la succession de comptage des 0 (des 1) et des comparaisons a` effectuer sous forme d’un arbre pour des mots cod´es sur trois bits.

1 n0

non, ~I[2]=0 ~I[2]=1

2 n0-n01

non, ~I[1]=0 ~I[1]=1 non, ~I[1]=0 ~I[1]=1

3 n0-n01-n001

non, ~I[0]=0 ~I[0]=1 non, ~I[0]=0 ~I[0]=1 non, ~I[0]=0 ~I[0]=1 non, ~I[0]=0 ~I[0]=1 000 001 010 011 100 101 110 111

Fig. 3.8: L’arbre utilis´e pour le calcul de la valeur correspondante a` un rang r en mode bit-s´erie pour des mots cod´es sur trois bits.

La ligne en pointill´e de la Figure 3.8 indique le chemin dans l’arbre a` parcourir dans le cas de calcul de la valeur de rang r = 2 pour un voisinage de 5 pixels cod´es sur 3 bits.

110 3.2. Parall´elisation du calcul des filtres non-lin´eaires

Le tableau de la Figure 3.9 indique les valeurs du vecteur envisag´e et les trois ´etapes de calcul marqu´ees ①, ② et ③ pour chacun des trois plans de bits permettant d’arriver a` la valeur filtr´ee I˜ = 001, exprim´ee en binaire.

Index Voisinage V Rang ① ② ③ 0 0 1 0 0 0 1 4 4 1 0 0 2 1 2 0 0 1 3 3 3 0 1 1 4 7 5 1 1 1

① n < 2, 3 < 2 non I˜[2] = 0 0 → → ② n n < 2, 3 1 < 2 non I˜[1] = 0 0 − 01 − → → ③ n n n < 2, 3 1 1 < 2 oui I˜[0] = 1 0 − 01 − 001 − − → →

Fig. 3.9: L’exemple de recherche de la valeur qui correspond au rang r = 2 d’un vecteur de 5 ´el´ements.

L’arbre propos´e peut ˆetre facilement adapt´e pour le calcul d’un filtre de rang des mots cod´es sur un plus grand nombre de bits.

Le principal avantage de l’algorithme de Danielsson r´eside dans le fait que la complexit´e algorithmique n’est plus fonction du nombre de pixels dans le voisinage V , mais bien du nombre de bits b utilis´es pour coder la couleur de chaque pixel. Cependant la r´ealisation des compteurs des 0 (des 1) ainsi que la comparaison avec la valeur de rang peut s’av´erer couteuseˆ en termes de ressources logiques requises pour une r´ealisation mat´erielle.

3.2.4.2 Cas particulier de filtre m´edian

Dans le cas particulier d’un filtre m´edian, la comparaison du nombre d’occurrences de 0 ou des 1 d’un plan des bits avec le rang r peut ˆetre r´eduit au calcul de la fonction majorit´e, comme le montrent Hiasat et al. dans [HAIG99]. Il est ainsi possible de b´en´eficier, pour cette ´etape de calcul, d’une importante ´economie de ressources logiques n´ecessaires.

La Figure 3.10 illustre le d´eroulement de l’algorithme de Danielsson utilis´e pour le calcul de la valeur m´ediane d’un vecteur V de 5 ´el´ements cod´es sur 4 bits en utilisant la fonction majorit´e. Les colonnes t0 a` t3 montrent les diff´erentes ´etapes du calcul en partant du plan des bits de poids le plus fort vers les plans de bits de poids plus faibles. L’exclusion des pixels du voisinage est obtenue en rempla¸cant les valeurs qui ne doivent pas ˆetre prises en compte lors

111 Chapitre 3. Architectures d´edicac´ees de l’it´eration suivante par la valeur minimale (0) ou maximale (2b) des niveaux de gris10. Les pixels exclus dans l’it´eration suivante sont marqu´es en gras.

m V [m] t0 t1 t2 t3 0 8 1 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 2 0 0 1 0 0 0 1 0 0 0 0 0 0 0 0 0 2 5 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 3 9 1 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 4 3 0 0 1 1 0 0 1 0 0 0 0 0 0 0 0 0 l l l l M´ediane 0 - - - 0 1 - - 0 1 0 - 0 1 0 1

Fig. 3.10: Exemple de calcul de la valeur m´ediane de 5 ´el´ements cod´es sur 4 bits a` l’aide de l’algorithme de Danielsson.

Dans la premi`ere it´eration, la fonction majorit´e du plan des bits de poids le plus fort donne un 0 (colonne t0) et cette valeur sera retenue pour le bit de poids plus fort du r´esultat. Les mots 8 et 9 (indexes m = 0 et m = 3) ont un 1 pour ce poids, donc tous les bits de ces mots sont mis a` 1 pour le calcul des it´erations suivantes. Pour le plan de bits de poids suivant (colonne t1) la fonction majorit´e retourne la valeur 1. Les mots 2 et 3 (indexes m = 1 et m = 4) ont un 0 pour ces poids et tous les bits de ces mots sont mis a` 0. En appliquant le mˆeme proc´ed´e pour l’avant dernier et le dernier plan de bits on obtient la valeur m´ediane de vecteur V .

Lorsque l’on envisage la r´ealisation mat´erielle d’une unit´e de traitement ex´ecutant cet al- gorithme, le point sensible de l’impl´ementation se situe au niveau du calcul de la fonction majorit´e. Pour des voisinages envisag´es habituellement de taille de 3 3, 5 5 et 7 7 pixels, × × × il s’agit des fonctions logiques de 9, 25 et 49 variables. Etan´ t donn´e le nombre de variables impliqu´ees, l’impl´ementation d’un grand nombre de ces fonctions dans les FPGAs actuels peut encore s’av´erer limitatif.

Lee et al. proposent un algorithme de calcul de la fonction majorit´e permettant une impl´ementation plus ´economique quant a` la quantit´e des ressources logiques n´ecessaires pour sa r´ealisation (voir [LLC03]). L’algorithme expos´e, bas´e sur le calcul des valeurs des maximas, m´edianes et minimas locaux des vecteurs colonnes est destin´e exclusivement aux voisinages 3 3. × On consid`ere un plan de bits d’un voisinage V de taille 3 3 not´e : × V [0] V [1] V [2] V = V [3] V [4] V [5] = V 1, V 2, V 3 (3.5)   c c c V [6] V [7] V [8]     10 On consid`ere un voisinage V compos´e de NV pixels. Dans ce voisinage (NV − 1)/2 pixels ont le niveau b de gris minimal (0), (NV − 1)/2 pixels ont le niveau de gris maximal (2 ) et un pixel a un niveau de gris quelconque. Du fait d’un mˆeme nombre de pixels ayant le niveau de gris 0 et 2b, la valeur m´ediane de V sera forc´ement ce dernier pixel. Pour chaque plan de bits nous avons donc un mˆeme nombre de 0 et de 1, plus un bit donn´e par ce dernier mot. La fonction majorit´e, calcul´ee sur un plan de bits, va donc donner le bit de la valeur m´ediane pour ce poids.

112 3.2. Parall´elisation du calcul des filtres non-lin´eaires

On calcule les valeurs des maximas, m´edianes et minimas locaux des vecteurs colonnes :

1 2 3 tt1 = max[t0, t1, t2] = max min(Vc ), min(Vc ), min(Vc ) 1 2 3 tt2 = med[t3, t4, t5] = med med(Vc ), med(Vc ), med(Vc ) 1 2 3 tt3 = min[t6, t7, t8] = minmax(Vc ), max(Vc ), max(Vc ) (3.6) La fonction majorit´e maj(V ) est alors calcul´ee comme : 

maj(V ) = med[tt3, tt2, tt1] (3.7)

La r´ealisation mat´erielle de cet algorithme peut ˆetre faite a` l’aide des modules comparateurs permettant de trier des vecteurs de trois valeurs binaires (Figure 3.11). Un module re¸coit un vecteur binaire de trois ´el´ements en entr´ee et sort un vecteur tri´e dont les ´el´ements sont plac´es dans des registres. Trois autres modules, dispos´es en parall`ele, cherchent respectivement Min, Med et Max des valeurs temporaires. Le tout est organis´e dans une architecture pipe-line permettant de calculer un bit de majorit´e d’un plan des bits de 9 ´el´ements avec une latence d’une seule op´eration.

t0 max t1 tt1 t2 3 2 1 Vc Vc Vc min t3 med V[2] V[1] V[0] t4 tt2 med V[5] V[4] V[3] med t5 V[8] V[7] V[6] t6 min max t7 tt3 t8

étage1 étage2 étage3 étage4 étage5 Fig. 3.11: Impl´ementation efficace en termes des ressources logiques n´ecessaires de la fonction majorit´e d’un plan de bits pour un voisinage de 3 3 pixels. ×

L’impl´ementation d’une seule unit´e de traitement bas´ee sur cet algorithme, dans un FPGA Altera Flex EPF10K10, affiche une vitesse de fonctionnement de 38MHz et une occupation des ressources logiques ´equivalente a` 462 cellules logiques ´el´ementaires de 576 cellules dispo- nibles11.

Le d´elais de calcul pour le premier pixel est de 11 cycles d’horloge, tandis que pour chaque nouvelle colonne des pixels a` l’entr´ee, la valeur du pixel de r´esultat est calcul´ee apr`es un seul

11Une cellule logique ´el´ementaire de la famille Flex de chez Altera, comme d’ailleurs celle de la famille Stratix d´ej`a mentionn´ee, est compos´ee d’une m´emoire de 16 bits, d’un bi-stable programmable et d’une logique d´edicac´ee pour l’addition.

113 Chapitre 3. Architectures d´edicac´ees cycle d’horloge. En n´egligeant le d´elais de calcul pour le premier pixel, une hypoth`ese qui sera v´erifi´ee pour des images d’une taille horizontale beaucoup plus grande que la taille de voisinage, ce qui est g´en´eralement le cas, la performance d’un tel syst`eme, exprim´ee par le d´ebit des pixels trait´es, est de 38 Mpx/sec (millions de pixels par seconde).

La performance d’un syst`eme bas´e sur cet algorithme a ´et´e compar´ee avec quelques algo- rithmes efficaces de calcul de la fonction majorit´e propos´es pr´ec´edemment. Pour que la com- paraison soit pertinente, les algorithmes compar´es ont ´et´e r´ealis´es dans des circuits FPGAs de mˆeme famille. L’impl´ementation de cet algorithme particulier montre un facteur d’acc´el´eration de 1.1 par rapport a` l’algorithme de Chang et Lin bas´e sur les r´eseaux de tri de type odd/e- ven (cf. [CL92]) et de 1.8 par rapport a` l’algorithme de Benkrid, Crookes et Benkrid bas´e sur un additionneur et une LUT (cf. [BCB02]).

3.2.4.3 G´en´eralisation de l’algorithme pour les filtres Min/Max

L’algorithme utilis´e pour le calcul de la valeur m´ediane d’une voisinage V en mode bit-s´erie peut ˆetre adapt´e pour le calcul de n’importe quel rang r, comme le montrent Gasteratos, Andreadis et Tsalides dans [AIP97]. L’avantage d’une telle approche devant l’algorithme classique de Danielsson r´eside dans le fait qu’une mˆeme r´ealisation mat´erielle, celle qui calcule le filtre m´edian, peut facilement ˆetre adapt´ee pour le calcul des filtres Min/Max. En outre, au lieu de r´ealiser le comptage des 0 et des 1 pour obtenir les valeurs de n0 (ou de n1) et de comparer ces valeurs avec la valeur de rang r, on calculera toujours la fonction de majorit´e, quelque soit le rang r recherch´e. Malheureusement les auteurs ne pr´esentent aucun r´esultat en terme de performance d’une impl´ementation physique.

La m´ethode expos´ee concerne un voisinage classique de 3 3, mais ici nous en faisons la × g´en´eralisation pour une taille arbitraire de voisinage, toujours d’un nombre impair de pixels. Pour calculer le filtre de n’importe quel rang r d’un vecteur V comme si c’´etait un filtre m´edian, on consid`ere un vecteur “augment´e” V de 2NV 1 ´el´ements. La valeur m´ediane de 0 − ce vecteur est indiqu´ee par le rang r0 = NV . Le vecteur V non-tri´e est plac´e dans le vecteur V 0 de fa¸con a` ce que le rang r0 du vecteur “augment´e” V 0 indique le rang r voulu pour le vecteur V . En outre, le vecteur V est d´ecal´e dans le vecteur V en ajoutant au total NV 1 ´el´ements 0 − dont r valeurs maximales et NV 1 r valeurs minimales comme le montre la Figure 3.12. − − Nous avons donc :

Min = Med 0, 0, , 0, V [0], V [1], , V [NV 1] { · · · · · · − } N 1 V − Med = Med 0, 0, , 0, 255, 255, , 255, V [0], V [1], , V [NV 1] {| {z· · · } · · · · · · − } NV 1 NV 1 2− 2− Max = Med 255| ,{z255, } | , 255, V{z[0], V [1]}, , V [NV 1] (3.8) { · · · · · · − } N 1 V − Si l’utilisation d’un tel algorithme| p{zermet de}rendre une architecture d´edicac´ee au filtre m´edian un peu plus universelle (on calcule les filtres Min/Max avec la mˆeme architecture), cela est

114 3.2. Parall´elisation du calcul des filtres non-lin´eaires

V 0 V 0 V 0 V [NV − 1] 255 255 ...... 255 . . . V [NV − 1] V [2] . 255 V [1] . 255 V [0] V [NV /2] V [NV − 1] ← r0 = Med → ← r0 = Med → 0 ...... V [0] . . . 0 . . V [2] 0 . V [1] 0 0 V [0] Min Med Max

Fig. 3.12: G´en´eralisation de l’algorithme de filtre m´edian bit-s´erie pour le calcul des filtres Min/Max. rendu possible au d´etriment d’un plus grand nombre d’op´erandes de l’unit´e de traitement. Mˆeme si le nombre d’op´erandes croit de fa¸con lin´eaire avec la taille du voisinage d’un fac- teur de 2, cela complique l’unit´e de traitement de fa¸con non-n´egligeable. Ceci peut s’av´erer contraignant lorsque l’impl´ementation dans le circuit FPGA vise un parall´elisme massif avec des voisinages de plus grande taille.

3.2.4.4 G´en´eralisation pour les autres filtres non-lin´eaires

Gasteratos et al. proposent dans [AIP00] une architecture sp´ecifique permettant le calcul de plusieurs types de filtres non-lin´eaires. L’architecture propos´ee, r´ealis´ee sous forme d’un ASIC, 12 est capable de calculer des filtres de n’importe quel rang, des filtres pond´er´es de rang et des filtres morphologiques classiques ou mous.

L’algorithme de base utilis´e dans la conception de ce circuit a d´ej`a ´et´e pr´esent´e, il s’agit de l’algorithme de tri par classement (cf. Chapitre 2, Section 2.2.1.7). Pour rappel, il consiste en le calcul et la mise a` jour de l’histogramme local du voisinage. L’algorithme est cependant modifi´e : au lieu de calculer la somme successivement pour chaque niveau de gris afin d’obtenir la valeur de rang souhait´ee, celle-ci est obtenue par une approximation successive.

(b 1) Dans un premier temps on compare tous les pixels du voisinage avec la valeur de 2 − , b indiquant le nombre de bits utilis´es pour coder le pixel. Ensuite on compte le nombre de pixels (b 1) dans le voisinage V plus grands, ´egal ou plus petits que 2 − . En outre, l’histogramme du (b 1) voisinage V est divis´e en trois zones autour du niveau de gris 2 − : une zone a` gauche, une zone pour la valeur de niveau de gris en question et une zone a` droite.

(b 1) En comparant le nombre de pixels np trouv´es dans chaque zone d´etermin´ee par 2 − et not´es pp eq pg respectivement np , np et np avec la valeur de rang r il est possible de d´eduire la valeur de bit du poids b 1 de la valeur m´ediane grˆace aux conditions suivantes : pp − – si np r, alors le bit de la valeur m´ediane pour ce poids est 0, ≥ 12Application Specific Integrated Circuit

115 Chapitre 3. Architectures d´edicac´ees

pp eq pp b 1 – si np + np r et np < r, alors la m´ediane correspond bien a` la valeur 2 − , pg ≥ – si np r, alors le bit de la valeur m´ediane pour ce poids est 1. ≥ La proc´edure est it´erative. Dans le pire des cas elle n´ecessite b it´erations. Dans le meilleur des b 1 cas, quand la valeur m´ediane de V correspond a` la valeur 2 − le calcul est fait en une seule it´eration.

Le circuit int´egr´e d´ecrit est dot´e d’une seule unit´e de traitement qui op`ere sur un voisinage de 3 3 exclusivement. Avec une latence d’un seul cycle, ce circuit permet d’arriver au d´ebit × de traitement de 3.5Mpx/sec.

3.2.5 Architectures d´edi´ees aux filtres de piles

Les diff´erents filtres de rang peuvent facilement ˆetre calcul´es a` l’aide des filtres de piles (cf. Section 1.2 du Chapitre 1). Un voisinage V [m], m 0, . . . , NV 1 est transform´e en un ∈ { − } ensemble de plans de bits en utilisant la technique dite de threshold decomposition.

Le voisinage nouvellement cod´e est not´e V¨ [m, p] avec : – m l’indice de pixel dans le voisinage (m 0, . . . , NV 1 ) et ∈ { − } – p l’indice d’un plan de bits particulier, p 0, . . . , 2b 1 , b ´etant le nombre de bits ∈ { − } utilis´es pour coder les pixels du voisinage.

L’application d’un filtre de piles sur V¨ revient a` calculer une PBF (Positive Boolean Function) pour chaque plan de bits p de tous les pixels de voisinage V consid´er´e.

L’impl´ementation physique des filtres de piles est habituellement faite a` l’aide des trois tech- niques suivantes : b 1. Threshold decomposition (voir [WCN86]) - Pour chacun de 2 plans de NV bits d’un voisinage transform´e V¨ , une PBF (le minimum, la m´ediane, le maximum, ou n’importe quelle autre fonction logique selon le filtre) est calcul´ee et le r´esultat empil´e (ou direc- tement additionn´e) pour obtenir la valeur filtr´ee. Si cette approche est assez directe et se prˆete assez bien a` une parall´elisation massive, le nombre de PBFs a` ´evaluer devient important avec un plus grand nombre de bits utilis´es pour coder le pixel d’une image. Dans le cas le plus courant, lorsque les pixels de l’image sont cod´es sur 8 bits, il faut compter 256 PBFs par voisinage trait´e. La r´ealisation d’un tel nombre de fonctions r´esulte soit d’un circuit de tr`es grande taille (calcul de 256 fonctions en parall`ele), soit d’un nombre important d’op´erations a` effectuer (256 pas de calcul). 2. Range compression (voir [ICL+94]) - Une impl´ementation des filtres de piles plus efficace viserait donc la r´eduction du nombre de PBFs a` calculer. La m´ethode dite de Range compression permet de r´eduire le nombre de PBFs a` calculer au nombre de voisins dans le V . Cette r´eduction du nombre de PBFs est possible grˆace a` la propri´et´e des piles :

b si f(V¨ [m, k]) = 1 m 0, . . . , NV 1 , k 0, . . . , 2 (3.9) ∈ { − } ∈ { } alors f(V¨ [m, o]) = 1 o k ∀ ≤ De ce fait, l’´evaluation de PBFs peut se faire uniquement pour des plans de bits p, d´etermin´es par les valeurs des pixels dans le voisinage.

116 3.2. Parall´elisation du calcul des filtres non-lin´eaires

b Nous avons donc p V [0], . . . , V [NV 1] au lieu de p 0, . . . , 2 1 . Ainsi le ∈ { b− } ∈ { − } nombre de PBFs a` calculer passe de 2 a` NV , avec NV g´en´eralement plus petit que 2b. Fort malheureusement l’impl´ementation physique d’un tel algorithme implique la mobilisation d’importantes ressources logiques, notamment pour d´eterminer les plans de bits p pour lesquels il faut effectivement calculer les PBFs. 3. Binary refinement (voir [Che89]) - Une autre fa¸con de r´eduire le nombre d’op´erations li´ees a` l’´evaluation des PBFs consiste a` employer l’algorithme de binary search pour la recherche des plans de bits sur lesquels le calcul de PBFs sera effectu´e. Pour calculer la valeur m´ediane d’un voisinage V on consid`ere les plans des bits correspondants et dans (b 1) un premier temps le plan m´edian situ´e donc au niveau 2 − . Pour ce plan de bits on calcule la PBF m´ediane. Si la valeur obtenue vaut 1, alors la m´ediane devrait se trouver dans la moiti´e “sup´erieure” de l’ensemble des plans de bits13. Dans le cas ou` on aurait obtenu un 0, la m´ediane se trouverait dans la moiti´e “inf´erieure” de l’ensemble des plans de bits. L’espace de recherche est ainsi divis´e par deux a` chaque nouveau pas de calcul. L’algorithme reste it´eratif, mais le nombre de PBF a` ´evaluer passe de 2b a` b seulement. Woolfries et al. comparent les impl´ementations dans le FPGA des trois m´ethodes ex- pos´ees de calcul des filtres de piles (voir [WLM+98a, WLM+98c, WLM+98b]). Les r´esultats montrent que la m´ethode la plus efficace en terme de ressources mobilis´ees et de vitesse de fonc- tionnement de circuit est celle bas´ee sur la m´ethode du Binary refinement. L’impl´ementation d’une seule unit´e de traitement, pour un voisinage de 3 3, a ´et´e effectu´e sur un circuit × FPGA Xilinx XC621614 pour des pixels cod´es sur 8 bits. Pour une occupation d’environ 800 cellules logiques ´el´ementaires du circuit FPGA consid´er´e, une seule unit´e de traitement est caract´eris´ee par un d´ebit de 15Mpx/sec.

13 (b 1) Dans ce cas la m´ediane de V est certainement plus grande que 2 − car il existe au moins NV /2 valeurs (b 1) plus grandes que 2 − . 14Le circuit FPGA 6216 est compos´e d’une matrice de 64 × 64 cellules logiques ´el´ementaires. Mais contrai- rement a` l’architecture habituelle des FPGAs Xilinx (les m´emoires de 16 bits par cellule), la cellule poss`ede une m´emoire de seulement deux entr´ees.

117 Chapitre 3. Architectures d´edicac´ees

3.3 Conclusion

Nous allons clˆoturer ce chapitre par une discussion sur les diff´erents syst`emes d´ecrits, leur performance, leurs avantages et inconv´enients et leurs principales limitations. Dans un premier temps et avant de donner un r´ecapitulatif des performances, nous insisterons sur la difficult´e d’une comparaison crois´ee entre les diff´erents syst`emes. Ensuite viendront les remarques, d’abord d’ordre g´en´eral avant de passer aux remarques sp´ecifiques pour chaque type d’architecture envisag´ee. Enfin la derni`ere section nous permettra de faire le point sur ces remarques et de fixer les enjeux d’une nouvelle architecture, propos´ee au Chapitre 4.

3.3.1 Performance des syst`emes d´edicac´es existants

La performance des diff´erents algorithmes est le plus souvent exprim´ee par le nombre d’op´erations n´ecessaire a` une unit´e de traitement pour calculer un seul pixel de l’image r´esultante. Si l’algorithme est accompagn´e d’une r´ealisation mat´erielle d’une unit´e de trai- tement sous forme d’un ASIC ou FPGA, sa performance est alors exprim´ee par la fr´equence maximale de fonctionnement du circuit correspondant. En connaissant l’algorithme employ´e, c’est a` dire le nombre de pas de calcul n´ecessaires pour r´ealiser le traitement (les BOPs d´efinies dans le Chapitre 1), il est alors possible de d´eduire le d´ebit des pixels trait´es par le syst`eme propos´e.

En disposant de ces chiffres on pourrait croire que pour effectuer une comparaison crois´ee des diff´erents algorithmes ou des syst`emes existants il suffirait de comparer le nombre d’instruc- tions n´ecessaires a` l’ex´ecution et/ou la fr´equence de fonctionnement (ou le d´ebit des pixels trait´es) pour une r´ealisation mat´erielle. Malheureusement, une telle comparaison hˆative peut induire en erreur.

Dans une ´etude purement th´eorique, le seul nombre d’instructions a` ex´ecuter ne permet pas d’´etablir la performance r´eelle d’un syst`eme. En effet le d´ebit r´eel de pixels trait´es que l’on pourrait obtenir d´ependra de la vitesse de fonctionnement des unit´es de traitement corres- pondantes et du nombre de ces unit´es travaillant en parall`ele.

Dans le cas d’une impl´ementation physique dans un circuit FPGA, la fr´equence du fonction- nement de circuit r´ealis´e est fortement influenc´ee par le choix du circuit FPGA cible. En effet, pour un algorithme et une description de circuit donn´ee, la performance du circuit physique d´ependra de la performance brute du FPGA (voir Annexe B). Or, comme on peut se l’imagi- ner, celle-ci est ´etroitement li´ee a` la technologie de fabrication des circuits int´egr´es et d´epend donc du moment de la r´ealisation du circuit.

La vitesse de fonctionnement du circuit est ´egalement influenc´ee par la qualit´e du processus d’impl´ementation. Malgr´e l’am´elioration constante des logiciels utilis´es pour la synth`ese et l’impl´ementation de la logique programmable, a` l’heure actuelle l’intervention humaine peut am´eliorer le processus automatique d’impl´ementation (voir Section 3.1).

Les deux approches de la parall´elisation des filtres non-lin´eaires qui ont ´et´e abord´ees dans la section pr´ec´edente : l’une purement th´eorique (notamment les architectures matricielles et les r´eseaux de tri) et l’autre pratique (les r´ealisation sous forme d’ASIC ou FPGA), fournissent

118 3.3. Conclusion des r´esultats qui sont donc difficilement comparables. Pire, comme nous venons de le constater, une comparaison entre les diff´erents r´esultats pratiques fournis a` des moments diff´erents n’est par pertinente non plus. C’est sans doute pour cette raison que les performances des syst`emes propos´es sont souvent donn´ees telles quelles, sans ou avec tr`es peu de points de comparaison avec les syst`emes semblables.

Malgr´e les difficult´es d’une comparaison crois´ee entre les diff´erents syst`emes propos´es, nous r´esumons les r´esultats cit´es dans la Section 3.2 a` titre indicatif dans le Tableau 3.3. Il serait ´eventuellement possible d’extrapoler les r´esultats en employant la loi de Moore. Ainsi toutes les donn´ees seraient ramen´ees a` un mˆeme instant de temps, mais nous avons pr´ef´er´e ne pas appliquer une telle d´emarche, a` cause de son caract`ere grossier.

Architecture Impl´ementation Filtre BOPs D´ebit [Mpx/sec]

Universelle matricielle bit-s´erie (Slim) Chang, [CSC96] Med. 228 -

Universelle matricielle bit-parall`ele Chakrabarti, [Cha94] Med. 1 -

Chung, [Chu96] Univ. 8 - R´eseaux de tri Smith, [Smi96] Med. 1 -

Lee et al., [LLC03] Med. 3x3 1 38 D´edicac´ee bit-s´erie Gasteratos et al., [AIP00] Univ.3x3 8 3.5

Filtres de piles Woolfries et al.,[WLM+98a] Univ. 8 15

Tab. 3.3: Comparaison des performances des diff´erentes architectures existantes pour le calcul des filtres non-lin´eaires.

3.3.2 Remarques

L’ensemble des solutions de la parall´elisation du calcul des filtres non-lin´eaires pr´esent´e m´erite un certain nombre de remarques. Certaines sont communes a` toutes les architectures envisag´ees, tandis que d’autres sont propres a` une architecture particuli`ere.

3.3.2.1 Remarques g´en´erales

Taille de voisinage Dans la plupart des travaux cit´es, les algorithmes propos´es et les architectures associ´ees impliquent le calcul des filtres sur un voisinages fixe, l’incontournable 3 3. Ceci peut s’av´erer × limitatif, puisque dans certains cas le traitement va n´ecessiter des calculs sur des voisinages plus grands.

La grande majorit´e des algorithmes d´ecrits peut ˆetre adapt´ee a` des plus grands voisinages, mais pas tous. Celui propos´e par Lee, par exemple ne pourra donc pas ˆetre utilis´e pour des voisinages plus grands que 3 3. × Lorsque l’algorithme permet le calcul sur des voisinages plus grands et lorsque la complexit´e th´eorique de l’unit´e de traitement en termes de ressources est exprim´e en fonction de la

119 Chapitre 3. Architectures d´edicac´ees taille de voisinage, il serait alors possible d’extrapoler les r´esultats pour des voisinages plus grands. Malheureusement, une telle approche peut s’av´erer fort impr´ecise. La complexit´e th´eorique ne peut ˆetre utilis´ee pour une ´evaluation pr´ecise des ressources logiques n´ecessaires a` la r´ealisation d’une unit´e de traitement travaillant sur un plus grand voisinage. C’est un peu comme la complexit´e algorithmique : on peut pr´evoir la croissance de temps de calcul en fonction de la taille du probl`eme, mais on ne peut pas en d´eduire un temps d’ex´ecution exact.

Faible parall´elisation La totalit´e des r´ealisations d´ecrites ne traite que des impl´ementations d’une seule unit´e de traitement. Ceci est vrai mˆeme pour des syst`emes dont la quantit´e de ressources logiques n´ecessaires pour leur r´ealisation est nettement inf´erieure a` celle disponible dans le FPGA cible. Les ressources non-exploit´ees pourraient alors ˆetre utilis´ees pour l’impl´ementation d’autres unit´es de traitement, permettant ainsi une ex´ecution en parall`ele15.

Une simple extrapolation des donn´ees obtenues pour l’impl´ementation d’une seule unit´e de traitement ne peut ˆetre a` nouveau appliqu´ee. Dans le cas d’une impl´ementation dans un FPGA, l’accroissement des ressources logiques n´ecessaires pour la r´ealisation de multiples unit´es identiques n’est pas forc´ement une fonction lin´eaire de nombre d’unit´es de traitement. Ensuite, a` cause de la pr´esence de multiples unit´es de traitement, la fr´equence maximale de fonctionnement du circuit va diminuer et ceci d’autant plus que le degr´e de parall´elisme augmente. Les deux remarques combin´ees auront pour cons´equence un d´ebit r´eel des pixels trait´es plus faible par rapport a` celui que l’on pourrait d´eduire th´eoriquement.

3.3.2.2 Remarques sp´ecifiques a` l’architecture

Architectures matricielles en mode bit-s´erie Ces architectures pr´esentent l’avantage d’un fonctionnement en mode SIMD, d’une possibilit´e de parall´elisme massif et d’une scalabilit´e16 quasi imm´ediate. Leur architecture, organis´ee autour d’unit´es de traitement identiques et simples, peut conduire a` une impl´ementation efficace dans des circuits FPGA. Cependant ces architectures, mˆeme les plus performantes, n´ecessitent un important nombre de pas de calcul lorsqu’il s’agit de travailler avec des images en niveaux de gris et avec des voisinages plus grands que l’habituel 3 3. × Un simple calcul peut montrer qu’il faudrait une grande fr´equence de fonctionnement et/ou un nombre important d’unit´es de traitement pour qu’un tel syst`eme soit comp´etitif avec une architecture universelle. En effet, comme nous l’avons montr´e dans le Chapitre 2 une archi- tecture universelle n´ecessite actuellement une dizaine de BOPs par pixel pour le calcul d’un filtre non-lin´eaire. Une architecture matricielle fonctionnant en mode bit-s´erie en n´ecessite environ 20 fois plus dans le meilleur des cas (architecture propos´ee par Chang). A la mˆeme

15L’impl´ementation propos´ee par Woolfries et al. pourrait impliquer quatre unit´es de traitement, or le d´ebit des pixels trait´es pr´esent´e ne se base que sur le fonctionnement d’une seule unit´e. 16Par scalabilit´e on fait r´ef´erence au terme anglais scalability qui signifie une possibilit´e d’augmentation sub- stantielle de degr´e de parall´elisme tout simplement en augmentant le nombre d’unit´es de traitement employ´es.

120 3.3. Conclusion fr´equence de fonctionnement17 il faudrait donc 20 fois plus d’unit´es de traitement pour arriver a` un d´ebit de pixels trait´es obtenu par une architecture universelle.

Architectures matricielles en mode bit-parall`ele Les architectures matricielles en mode bit-parall`ele permettent de r´eduire consid´erablement le nombre de pas de calcul par rapport aux architectures de mˆeme type en mode bit-s´erie. L’architecture propos´ee par Chakrabarti par exemple n´ecessite un seul pas de calcul pour la r´ealisation d’un filtre m´edian. Le prix a` payer en termes des ressources logiques employ´ees est cependant ´elev´e.

Une unit´e de traitement n´ecessitera une importante quantit´e des ressources logiques pour sa construction a` cause de ses circuits arithm´etiques et m´emoires fonctionnant en mode bit- parall`ele. Ce mode de fonctionnement mobilisera ´egalement des importantes ressources en interconnexions et en entr´ees/sorties. Si l’on envisage une impl´ementation dans un circuit FPGA ceci aura pour cons´equence un faible degr´e de parall´elisme et des faibles vitesses de fonctionnement. Donc un faible d´ebit des pixels trait´es.

R´eseaux de tri Le principal d´esavantage des r´eseaux de tri r´eside dans le nombre de comparateurs. Mˆeme dans les cas d’un r´eseau optimis´e pour le calcul d’un filtre particulier sur un voisinage de petite taille et fonctionnant en pipe-line, leur nombre reste important.

Un autre d´esavantage de ces architectures est li´e au fait que le calcul des diff´erents rangs : Min/Max d’un cˆot´e et M´edian de l’autre, implique un nombre fort diff´erent de comparateurs. Ainsi pour trouver un Min/Max d’un voisinage 3 3 on a besoin de seulement 8 comparateurs × (avec un r´eseau Bubble par exemple), alors que pour un filtre m´edian le r´eseau le plus perfor- mant (le r´eseau bitonique adapt´e par Chung) en n´ecessite 24. Ce d´es´equilibre se traduira par une sous-exploitation des ressources disponibles dans le cas d’un syst`eme reconfigurable qui viserait la r´ealisation des deux traitements puisque c’est la configuration la plus complexe qui d´eterminera le choix du circuit FPGA a` employer. Pour des r´eseaux de tri, la mˆeme remarque concernant la quantit´e des ressources en connexions internes et en entr´ees/sorties que celle faite pour des architectures matricielles en mode bit-parall`ele reste valable.

Architectures d´edicac´ees en mode bit-s´erie Les architectures d´edicac´ees fonctionnant en mode bit-s´erie semblent les plus adapt´ees a` l’impl´ementation dans des circuits logiques programmables FPGA. Les principaux arguments sont : le mode de fonctionnement SIMD, la simplicit´e des unit´es de traitement, la possibilit´e d’un parall´elisme massif et de la scalabilit´e, les faibles ressources n´ecessaires pour les inter- connexions et les entr´ees/sorties et le petit nombre de pas de calcul. Cependant les remarques g´en´erales, faite dans la Section 3.3.2.1 restent valables pour ces architectures.

Architectures d´edi´ees aux filtres de piles Malgr´e le mode de fonctionnement en mode bit-s´erie et les algorithmes qui r´eduisent le nombre

17Ce qui est un cas plus r´ealiste que celui d’une fr´equence de fonctionnement 20 fois plus grande. En comparant par exemple le temps d’acc`es a` une seule m´emoire de CLE (voir Annexe B) avec le temps d’ex´ecution d’une op´eration par le processeur, on se rend compte que ces temps sont tr`es proches : de l’ordre d’un dixi`eme de nano-seconde. Or pour un FPGA , tout circuit dont le nombre d’entr´ees d´epasse le nombre d’entr´ees d’une m´emoire de CLE sera r´ealis´e par une mise en s´erie des diff´erents m´emoires. Le temps d’acc`es ne sera donc que plus long.

121 Chapitre 3. Architectures d´edicac´ees de PBFs a` calculer, ces architectures sont caract´eris´ees par des importantes ressources lo- giques n´ecessaires mˆeme pour l’impl´ementation d’une seule unit´e de traitement. Si la partie de traitement proprement dite est simple a` r´ealiser : il s’agit d’une seule fonction logique a` NV variables d’entr´ee, ces sont les ´etapes avant et apr`es le calcul de la PBF qui sont parti- culi`erement gourmands en ressources logiques. En effet, le codage des pixels selon (threshold decomposition) d’une part et la reconstruction de la valeur finale d’autre part repr´esentent le plus gros des ressources occup´ees par l’unit´e de traitement.

3.3.3 Objectifs

Sur base des remarques expos´ees, nous pouvons d´egager trois principaux objectifs pour le syst`eme qui sera abord´e dans le Chapitre suivant :

1. Taille de voisinage Nous allons utiliser le paradigme du calcul reconfigurable a` l’aide des circuits FPGA afin de pouvoir construire une architecture qui peut facilement et de fa¸con ´equilibr´ee aborder l’impl´ementation des diff´erents filtres de rang pour les diff´erentes tailles de voisinage. De cette fa¸con seront d´epass´es les d´efauts des syst`emes d´ej`a abord´es.

2. Parall´elisation massive La densit´e des circuits FPGAs actuels et leur richesse en ressources des entr´ees et des sor- ties les rend parfaitement adapt´es a` l’impl´ementation d’un grand nombre d’unit´es de traitement. La quantification de degr´e de parall´elisme qu’il serait possible d’obte- nir a` partir d’un circuit FPGA de haute densit´e sera ´etroitement li´e a` la comparaison de performance entre un syst`eme reconfigurable et une architecture universelle.

3. Comparaison En etablissant´ la meilleure performance possible (BOPs) des architectures uni- verselles nous avons cr´e´e un point de comparaison auquel peut se r´ef´erer toute autre ar- chitecture destin´ee au calcul des filtres non-lin´eaires. Ce point de comparaison peut faci- lement ˆetre adapt´e de fa¸con a` suivre l’´evolution temporelle de la technologie, l’´evolution dont d´epend ´etroitement la performance d’un syst`eme. Ce point est essentiel dans la validation d’un quelconque syst`eme d´edicac´e devant un syst`eme universel.

122 Chapitre 4

Architecture reconfigurable

L’´etude de l’impl´ementation des filtres non-lin´eaires sur des architectures universelles, abord´ee dans le Chapitre 2, nous a permis de fixer la performance maximale de ce genre d’architectures aujourd’hui. Pour une telle architecture et malgr´e les diverses manifestations de parall´elisme (notamment le parall´elisme des instructions et le parall´elisme des donn´ees - le mod`ele SIMD de calcul) nous avons pu identifier deux principales raisons qui limitent la performance de tels syst`emes a` l’´egard du probl`eme pos´e : 1. acc`es inad´equat aux donn´ees n´ecessaires au calcul (la redondance en lecture de donn´ees pour le calcul des voisinages successifs) en raison du nombre limit´e de registres de micro-processeur et 2. faible degr´e de parall´elisme de l’unit´e de traitement.

N´eanmoins l’usage du parall´elisme des architectures universelles nous a permis d’obtenir d’im- portants facteurs d’acc´el´eration par rapport a` une approche dite classique qui ne tient compte que des aspects algorithmiques de la r´esolution du probl`eme.

Dans une chaˆıne de traitement des images num´eriques la performance des architectures uni- verselles peut s’av´erer insuffisante. Les temps de calcul restent importants lorsque la taille de l’image a` traiter et la taille du voisinage augmentent. Lorsque le filtrage non-lin´eaire est appliqu´e avant d’autres traitements, il convient alors de rechercher une solution alternative.

Le d´eveloppement d’un syst`eme d´edicac´e pour le calcul des filtres non-lin´eaires peut am´eliorer le temps de calcul des filtres non-lin´eaires. L’optimisation des algorithmes employ´es, ainsi que la multiplication des unit´es de traitement (parall´elisation) conduisent a` des architectures plus performantes, comme nous avons pu le voir dans le Chapitre 3. Cependant les solutions envi- sag´ees jusqu’`a pr´esent ne sont pas sans d´efaut, notamment en ce qui concerne les limitations au niveau de la taille des voisinages consid´er´es et le manque de parall´elisation massive (voir les commentaires de la Section 3.3.2).

Pour illustrer la n´ecessit´e d’un traitement encore plus rapide, on peut prendre comme exemple la performance des cam´eras num´eriques actuelles. Les mod`eles courants affichent d´ej`a un d´ebit de pixels qui est de l’ordre de 50MB/sec (voir [Gro00] par exemple). Pour des cam´eras num´eriques a` haute vitesse d’acquisition ces d´ebits sont encore plus importants et peuvent,

123 Chapitre 4. Architecture reconfigurable dans certain cas, atteindre les 250MB/sec ([PS04]). Clairement, la performance des architec- tures d´ecrites, aussi bien universelles que d´edicac´ees, n’est pas suffisante pour r´epondre en temps r´eel a` une telle vitesse d’acquisition.

Dans ce chapitre nous allons d´ecrire la conception d’un syst`eme original, d´edicac´e au calcul des filtres de rang, bas´e sur des circuits FPGAs, donc reconfigurable, permettant d’arriver a` de hauts d´ebits de traitement.

La notion de reconfigurablit´e est ici utilis´ee pour d´ecrire un mˆeme syst`eme d´edicac´e (un mˆeme syst`eme physique) capable de calculer les diff´erents filtres de rang pour des voisinages de tailles et de formes diff´erentes. Pour un filtre et un voisinage donn´e on aura une configura- tion particuli`ere de syst`eme permettant d’effectuer le calcul demand´e. Ainsi il serait possible d’imaginer une biblioth`eque de diff´erentes configurations, sauvegard´ees dans une m´emoire de type EPROM ou Flash par exemple. A partir de cette biblioth`eque l’utilisateur pourrait facilement faire le choix du traitement qu’il souhaite appliquer.

Les algorithmes qui seront utilis´es pour la conception des unit´es de traitement sont bas´es sur le calcul qui est de type bit-s´erie et ont l’avantage d’ˆetre plus simples que ceux bas´es sur le calcul en mode bit-parall`ele. Cette diff´erence est d’autant plus marqu´ee lorsque la taille du voisinage augmente car le nombre de pas de calcul de ces algorithmes est ind´ependant de la taille du voisinage trait´e. De plus, de tels algorithmes s’adaptent particuli`erement bien a` la structure interne des FPGAs qui est de type grain fin : un grand nombre de m´emoires permettant la r´ealisation des fonctions logiques d’un faible nombre de variables.

La technologie actuelle de fabrication des circuits FPGAs permet l’int´egration de circuits de tr`es haute densit´e. La simplicit´e des algorithmes envisag´es, combin´ee a` une importante quantit´e de ressources logiques des FPAGs de haute densit´e, r´esultent d’une possibilit´e de parall´elisation massive et donc d’un plus grand d´ebit de donn´ees trait´ees.

Ces deux constatations nous permettent de poser deux questions fondamentales : "Quelle serait la performance d’un syst`eme d´edicac´e reconfigurable bas´e sur un algorithme de calcul des filtres non-lin´eaires en mode bit s´erie, etant´ donn´ee la haute densit´e des circuits FPGAs actuels ?"

et

"Quel est le gain en performance d’un tel syst`eme par rapport aux architectures universelles classiques et aux architectures d´edicac´ees existantes ?"

Ce chapitre propose de donner la r´eponse a` ces questions a` travers cinq sections bri`evement d´ecrites ci-dessous :

Section 1 - Nous commencerons par donner une description globale du syst`eme d´edicac´e reconfigurable pour le calcul des filtres non-lin´eaires. Ici nous introduisons les principaux ´el´ements de l’architecture propos´ee : la partie traitement et les diff´erentes m´emoires n´ecessaires a` son fonctionnement. On donnera ´egalement une br`eve description d’une carte, disponible

124 actuellement sur le march´e, dot´ee d’un circuit FPGA de haute densit´e et des m´emoires per- mettant l’int´egration d’un tel syst`eme.

Section 2 - Cette section propose la description d´etaill´ee de la m´emoire locale du syst`eme reconfigurable permettant la mise en format des donn´ees de l’image a` traiter et de l’image trait´ee n´ecessaires pour un fonctionnement en mode bit-s´erie. Nous pr´esentons ´egalement la validation de la description formelle d’un tel circuit ainsi que les r´esultats des diff´erentes impl´ementations relatives a` plusieurs configurations possibles de la m´emoire. De tels r´esultats nous permettent de d´eduire la performance de ce sous-syst`eme particulier.

Section 3 - Dans cette section on offre les explications relatives a` la partie traitement : description d´etaill´ee des algorithmes utilis´es et des unit´es de traitement correspondantes. Comme pour la m´emoire locale, la description formelle de l’unit´e de traitement est accom- pagn´ee d’une validation et des r´esultats de l’impl´ementation en termes de la quantit´e des ressources logiques employ´ees et la vitesse de fonctionnement.

Section 4 - Cette section d´ecrit l’assemblage des diff´erentes parties d´ecrites dans ce que nous allons appeler un module de traitement. Le syst`eme reconfigurable complet sera compos´e de plusieurs modules de traitement ind´ependants, assurant un haut niveau de parall´elisation. Un accent particulier sera mis sur le processus d’optimisation du processus d’impl´ementation, permettant d’obtenir la meilleure performance possible ´etant donn´e un FPGA particulier de haute densit´e. Sur base des r´esultats de l’impl´ementation d’un syst`eme reconfigurable complet, nous allons d´eduire le d´ebit maximal de traitement qu’il serait possible d’obtenir avec la carte d´ecrite dans la Section 1.

Section 5 - Enfin, la derni`ere section propose une conclusion sur l’impl´ementation des filtres de rang a` l’aide de l’architecture reconfigurable d´ecrite.

125 Chapitre 4. Architecture reconfigurable

4.1 Description globale du syst`eme d´edicac´e reconfigurable

4.1.1 Introduction

Le syst`eme que nous allons d´ecrire apparaˆıt comme un syst`eme de traitement d’informa- tion num´erique entre une source de l’image et un utilisateur potentiel.

Système dédicacé reconfigurable Image Image à traiter traitée Source ? Utilisateur

Fig. 4.1: Syst`eme d´edicac´e reconfigurable.

En toute g´en´eralit´e la source de l’image peut ˆetre n’importe quel syst`eme capable de fournir l’information num´erique sur l’image a` traiter. Cela peut ˆetre bien entendu un ordinateur classique mais ´egalement tout autre syst`eme d’acquisition d’images : un scanner, une cam´era ou un appareil photo num´erique, etc.

Si la source de l’image est un ordinateur personnel, le syst`eme reconfigurable d´edicac´e apparaˆıt alors comme un processeur attach´e au syst`eme hˆote (voir la taxonomie des architectures d´edicac´ees expos´ee dans la Section 1.2.2.2). L’avantage d’une telle configuration r´eside alors dans le fait que le syst`eme d´edicac´e peut facilement acc´eder a` toute source d’image a` laquelle cet ordinateur a acc`es : tout support de stockage, toute sorte de sources analogiques via un syst`eme de capture etc.

Dans le cas ou le syst`eme reconfigurable d´edicac´e est attach´e a` un quelconque syst`eme d’ac- quisition, son emploi se limite a` l’application d’un filtre juste apr`es l’acquisition. L’utilisateur r´ecup`ere une image d´ej`a trait´ee et a peu de possibilit´e d’interaction avec le syst`eme de trai- tement, si ce n’est en ce qui concerne le type de filtre et la taille de voisinage choisi.

Quel que soit le type d’application d’un tel syst`eme, l’utilisateur d´esireux d’en connaˆıtre la performance doit pouvoir r´epondre aux questions suivantes : 1. Quel serait l’algorithme le plus appropri´e pour une impl´ementation dans un circuit FPGA ?

2. Quel est le nombre d’unit´es de traitement (i.e. le degr´e de parall´elisme) qu’il serait possible d’obtenir pour des applications envisag´ees ´etant donn´ee les FPGAs de haute densit´e ?

3. Quelle sera la fr´equence de fonctionnement maximale d’un tel syst`eme (le d´ebit des pixels trait´es) ?

126 4.1. Description globale du syst`eme d´edicac´e reconfigurable

En ce qui concerne le choix des algorithmes, nous avons vu dans le Chapitre 3 que les algo- rithmes de calcul des filtres non-lin´eaires peuvent ˆetre repartis en deux grandes classes : les algorithmes de type bit-s´erie et les algorithmes de type bit-parall`ele. La premi`ere classe d’al- gorithmes s’adapte particuli`erement bien a` une impl´ementation dans les syst`emes d´edicac´es, r´ealis´es a` base de circuits FPGAs, et ce pour deux raisons.

Tout d’abord il y a la simplification de l’unit´e de traitement due a` la suppression du pa- rall´elisme au niveau des mots qui codent les pixels de l’image. Ceci a pour cons´equence une moindre quantit´e de ressources logiques n´ecessaires pour la r´ealisation d’une unit´e de traite- ment par rapport au cas du parall´elisme de type bit-parall`ele. L’avantage en est double : la vitesse des unit´es de traitement augmente ainsi que leur nombre pour un mˆeme circuit FPGA.

Le deuxi`eme avantage d’une architecture bit-s´erie r´eside dans le fait que le nombre de pas de calculs (BOPs) n’est plus fonction de la taille du voisinage mais uniquement du nombre de bits utilis´es pour quantifier la couleur des pixels de l’image. Ainsi les unit´es de traitement auront besoin d’un mˆeme nombre de pas de calcul, qu’elle que soit la taille du voisinage consid´er´e.

Lors d’une r´ealisation pratique il est ´evident que la performance d’une unit´e de traitement fonctionnant en mode bit-s´erie va aussi d´ependre de la taille du voisinage choisi et que le d´ebit des pixels trait´es ne sera pas le mˆeme pour toutes les tailles de voisinages envisag´ees. En effet, pour des voisinages plus grands, le nombre de cellules logiques ´el´ementaires, ainsi que le nombre de ”couches“ logiques1, seront plus grands. La cons´equence de ce fait est double : la vitesse de chaque unit´e de traitement va diminuer et le nombre d’unit´es de traitement par circuit FPGAs utilis´e aussi. Ceci conduira inexorablement a` un d´ebit des pixels trait´es plus faible.

4.1.2 Parties constitutives

D’un point de vue macroscopique, l’architecture d´edicac´ee reconfigurable propos´ee est compos´ee des mˆemes modules qu’une architecture universelle classique au sens Von Neumann du terme. Nous avons donc les trois modules suivants :

1. une unit´e de contrˆole, 2. une m´emoire globale contenant l’image I a` traiter et l’image trait´ee I˜, 3. une partie traitement compos´ee d’une m´emoire locale pour les op´erandes (les valeurs des pixels des diff´erents voisinages - une fenˆetre de traitement) et pour le r´esultat (les valeurs filtr´ees - la fenˆetre filtr´ee).

Ces trois modules sont repr´esent´es sch´ematiquement a` la Figure 4.2.

1Une ”couche logique“ est d´efinie comme un ensemble des LUT s du FPGA, permettant de calculer un certain nombre de fonctions logiques en un seul temps d’acc`es a` la LUT . La d´ecomposition du calcul d’une fonction logique complexe (d’un nombre de variables plus grand que le nombre de bits d’adresse de la LUT ), comprends la mise en s´erie de plusieurs LUT s, introduisant donc plusieurs ”couches“ logiques.

127 Chapitre 4. Architecture reconfigurable

Système dédicacé reconfigurable

Unité de contrôle

Image à traiter Image traitée

Mémoire globale Unités de traitement de l'image à traiter et et mémoire locale de l'image traitée des opérandes

Fig. 4.2: Principales parties du syst`eme d´edicac´e reconfigurable pour le calcul des filtres non-lin´eaires.

L’image a` traiter et l’image trait´ee se trouvent dans la m´emoire globale. Grˆace a` l’unit´e de contrˆole, des parties de l’image a` traiter sont lues depuis la m´emoire globale, fenˆetre par fenˆetre dans la m´emoire locale des op´erandes des unit´es de traitement.

Lorsqu’une fenˆetre enti`ere est disponible dans la m´emoire locale des op´erandes, elle est trait´ee et les r´esultats sauvegard´es dans la m´emoire locale de r´esultat. Depuis la m´emoire locale, la fenˆetre trait´ee est ensuite transf´er´ee vers la m´emoire globale.

Nous allons maintenant donner une br`eve description de chacun des modules cit´e plus haut.

4.1.2.1 Partie traitement

La partie du syst`eme qui r´ealise le traitement est construite autour d’une matrice d’unit´es de traitement identiques a` laquelle sont associ´ees deux m´emoires locales : – une m´emoire pour la fenˆetre a` traiter - la m´emoire locale source, – et une autre pour la fenˆetre trait´ee - la m´emoire locale destination.

Les unit´es de traitement et les m´emoires associ´ees re¸coivent le mˆeme flux d’instructions, ´emis par l’unit´e de contrˆole. Chaque unit´e de traitement travaille sur un voisinage particulier, mais les donn´ees communes au traitement des voisinages successifs ne sont pas r´epliqu´ees. Comme la matrice des unit´es de traitement fonctionne en mode SIMD de calcul, les r´esultats de filtrage d’une fenˆetre F enti`ere de l’image sont calcul´es simultan´ement.

La Figure 4.3 illustre le principe de d´ecoupage d’une image en fenˆetres, la sauvegarde de la fenˆetre dans la m´emoire source locale, le calcul effectu´e par des unit´es de traitement associ´ees a` cette m´emoire et la sauvegarde des r´esultats dans la m´emoire locale destination. Pour cet exemple concret la taille de la fenˆetre a` trait´ee est fix´ee a` 9 9 pixels, a` quoi correspond une × matrice de 7 7 unit´es de traitement pour un filtre de taille 3 3, a` cause de l’effet de bord. × × 128 4.1. Description globale du syst`eme d´edicac´e reconfigurable

Image à traiter (mémoire source globale) Fenêtre à traiter (mémoire locale source) Fi Fi+1

Matrice des unités de traitement

Image traitée (mémoire destination globale)

Fenêtre traitée (mémoire locale destination) Fig. 4.3: L’image a` traiter, la fenˆetre en cours de traitement de 9 9 × pixels, les 7 7 unit´es de traitement associ´ees et le r´esultat de filtrage. ×

Pour une fenˆetre de taille fixe et pour des filtres travaillant sur des voisinages de tailles diff´erentes, le nombre d’unit´es de traitement sera variable a` cause de l’effet de bord. Par cons´equent la taille de la m´emoire destination locale sera aussi variable, ce qui ne pose pas de probl`eme ´etant donn´e que le syst`eme est reconfigurable.

Comme notre choix se porte sur des algorithmes de type bit-s´erie, la m´emoire source locale devrait non seulement jouer le rˆole d’une m´emoire des op´erandes mais devrait ´egalement effectuer la mise en forme des donn´ees pour un traitement en mode bit-s´erie. La m´emoire locale destination devrait a` son tour remettre les donn´ees au format habituel. Les deux m´emoires peuvent ˆetre facilement r´ealis´ees a` l’aide d’un ensemble de registres a` d´ecalage, comme nous allons le voir par la suite (Section 4.2).

4.1.2.2 M´emoire globale

La m´emoire globale contient donc l’information sur l’image a` traiter et sur l’image trait´ee et joue un rˆole d’interm´ediaire entre le syst`eme reconfigurable et le monde ext´erieur. Etan´ t donn´e que les unit´es de traitement travaillent en mode bit-s´erie, la m´emoire globale pr´esente deux modes de fonctionnement (cycles lecture/´ecriture) distincts : le mode s´erie et le mode fenˆetre. Ces deux modes de fonctionnement sont repr´esent´es sch´ematiquement a` la Figure 4.4.

129 Chapitre 4. Architecture reconfigurable

Vx-1 Ix Ix

Vy-1

Iy Iy

a) b)

Fig. 4.4: Deux modes de fonctionnement de la m´emoire : a) s´erie et b) par fenˆetre.

Lorsque la m´emoire fonctionne en mode s´erie, Figure 4.4 a), le parcours de l’image a` traiter est fait pixel par pixel de gauche a` droite et ligne par ligne de haut en bas. Le pseudo-code suivant montre ce principe :

for (j = 0 ; j < Iy ; j + +) // parcours de l ’ image s e l o n y for (i = 0 ; i < Ix ; i + +) // parcours de l ’ image s e l o n x { M[i + j ∗ Ix] ← I[i, j] // p i x e l i , j dans l a m´emoire d ’ a d r e s s e i+j ∗Ix }

Listing 4.1: Pseudo-code pour la m´emoire en mode s´erie

ou I[i, j] d´esigne les pixels de l’image a` parcourir et M le pointeur d’une zone de m´emoire de la taille de l’image I. Ce mode de lecture/´ecriture de l’image est aussi appel´e ”raster“.

En mode fenˆetre, repr´esent´e a` la Figure 4.4 b), plutˆot que des lignes de l’image, ce sont des lignes de la fenˆetre qui sont lues, l’une apr`es l’autre, ´egalement de gauche a` droite et de haut en bas (le vecteur de m´emoire est de taille de la fenˆetre F ). Remarquons le recouvrement des fenˆetres, de Vx 1 et de Vy 1 pixels, avec Vx et Vy qui d´esignent respectivement la − − taille horizontale et verticale de voisinage V . Ce recouvrement est n´ecessaire pour le calcul des pixels au bord des fenˆetres successives.

Le fonctionnement en mode fenˆetre peut ˆetre mod´elis´e a` l’aide de quatre boucles : les deux

130 4.1. Description globale du syst`eme d´edicac´e reconfigurable premi`eres relatives aux parcours des fenˆetres dans l’image2 et les deux autres relatives aux parcours des pixels a` l’int´erieur de la fenˆetre :

for (j = 0 ; j < Iy ; j+ = Fy − (Vy − 1)) // parcours de l ’ image s e l o n y for (i = 0 ; i < Ix ; i+ = Fx − (Vx − 1)) // parcours de l ’ image s e l o n x for (l = 0 ; l < Fy ; l + +) // parcours de l a f e n ˆe t r e s e l o n y for (k = 0 ; k < Fx ; k + +) // parcours de l a f e n ˆe t r e s e l o n x

M[k + l ∗ Fx] ← I[i + k, j + l] // p i x e l i , j dans l a m´emoire d ’ a d r e s s e k+l ∗Fx

Listing 4.2: Pseudo-code pour la m´emoire en mode fenˆetre

Dans le pseudo-code indiqu´e M d´esigne maintenant un pointeur vers la zone m´emoire de taille de la fenˆetre (Fx Fy). ∗ La m´emoire globale source est alors d´efinie comme une m´emoire ayant des propri´et´es sui- vantes : – en ´ecriture elle fonctionne en mode s´eriel - on effectue le chargement de l’image a` traiter, pixel par pixel, de fa¸con a` respecter la source qui g´en´eralement fourni les donn´ees en mode s´erie, – en lecture elle fonctionne en mode fenˆetre - on lit pixel par pixel de la fenˆetre en cours de traitement.

La m´emoire globale destination fonctionne en mode invers´e par rapport a` la m´emoire globale source : – en ´ecriture elle fonctionne en mode fenˆetre - on effectue le chargement de la fenˆetre trait´ee, pixel par pixel, – en lecture elle fonctionne en mode s´eriel - on lit pixel par pixel l’image trait´ee.

4.1.2.3 Unit´e de contrˆole

L’unit´e de contrˆole permet de g´erer le fonctionnement de l’ensemble. Tout d’abord elle assure les deux types de fonctionnement de la m´emoire globale, permettant les transferts vers et depuis la m´emoire locale. Ensuite, elle est responsable de la g´en´eration des instructions n´ecessaires a` la matrice des unit´es de traitement (et les m´emoires locales) lors du calcul.

Etan´ t donn´e que les algorithmes employ´es sont de type bit-s´erie et que les unit´es de traitement correspondantes sont d´edicac´ees, la partie contrˆole de celles-ci se r´esume a` des machines d’´etats extrˆemement simples, comme nous allons le voir dans la Section 4.2 et la Section 4.3.

2 Pour cette illustration on suppose que Ix et Iy sont des multiples de Fx − (Vx − 1) et de Fy − (Vy − 1). Si ce n’est pas le cas, alors il faut pr´evoir un recouvrement de l’avant derni`ere et de la derni`ere fenˆetre a` l’extrˆeme droite de l’image (il y aura une redondance de calcul).

131 Chapitre 4. Architecture reconfigurable

4.1.3 Hypoth`eses de travail

Pour une impl´ementation physique, le syst`eme d´ecrit peut ˆetre divis´e selon sa ”configura- bilit´e” 3 en deux parties distinctes :

– Partie fig´ee - La configuration mat´erielle de cette partie est fixe, mais programmable. Elle regroupe les deux m´emoires globales et leur contrˆole.

– Partie reconfigurable - Comme la partie traitement vise la r´ealisation de plusieurs filtres diff´erents pour des voisinages de tailles et de formes diff´erentes a` l’aide d’un mˆeme syst`eme physique, c’est elle qui sera r´ealis´ee dans un (ou plusieurs) circuit FPGA. Cette partie comprendra donc les m´emoires locales et la matrice des unit´es de traitement, ainsi que leur contrˆole.

Une telle d´ecomposition du syst`eme de traitement est d’autant plus justifi´e qu’actuellement il existe sur le march´e des solutions mat´erielles dont la partie fig´ee est d´ej`a d´evelopp´ee et prˆete a` l’emploi. Dans ce cas, le d´eveloppement d’un syst`eme de traitement se limite uniquement a` la r´ealisation de la partie reconfigurable.

Comme exemple d’une telle solution on peut citer la carte de Alpha Data ADP-WRC-II (voir [Alp04a], [Alp04b]).

La carte ADP-WRC-II est dot´e d’un circuit FPGA Xilinx de la famille Virtex II de haute densit´e, nous avons le choix entre le circuit xc2v6000 ou xc2v8000. Le circuit FPGA et coupl´e aux deux m´emoires de type DDR-SDRAM4. Chacune de ces m´emoires, d’une capacit´e totale de 0.5 ou 1 GB, est plac´e sur son propre bus d’adresses et le bus de donn´ees, d’une largeur de 256 bits. Une telle configuration de la m´emoire permet une bande passante th´eorique maximale de 12.8 GB/sec.

Pour la connexion avec le monde ext´erieur, la carte ADP-WRC-II est dot´ee d’une interface PCI permettant une connexion avec un syst`eme hˆote, typiquement un ordinateur personnel. On dispose ´egalement d’une connexion de type CMC (Common Mezzanine Card, le stan- dard IEEE 1386) permettant la connexion de la carte avec d’autre modules, tels que cartes d’acquisition de donn´ees.

Dans ce qui va suivre nous allons supposer avoir acc`es aux diff´erentes fenˆetres de l’image et que les deux bus de donn´ees : le premier pour l’image a` traiter et le deuxi`eme pour l’image trait´ee sont d’une largeur fixe, de 256 bits.

Nous allons ´egalement supposer disposer d’un FPGA de haut densit´e, le circuit xc2v8000 en l’occurrence. La validation des circuits propos´ees se fera donc par simulation des mod`eles des circuits g´en´er´ees automatiquement apr`es le processus d’impl´ementation.

3Voir Section 1.2.2.3 Taxonomie des architectures selon la configurabilit´e. 4L’acronyme DDR-SDRAM signifie Double Data Rate - Synchronous Dynamic RAM. Il s’agit de m´emoires rapides permettant les cycles de lecture/´ecriture sur les flancs montants et descendants, doublant ainsi la bande passante.

132 4.2. M´emoire locale des unit´es de traitement

4.2 M´emoire locale des unit´es de traitement

4.2.1 Description de la m´emoire locale source

Dans la section pr´ec´edente nous avons vu que la m´emoire locale source permet a` la matrice des unit´es de traitement d’acc´eder aux pixels des diff´erents voisinages d’une fenˆetre de fa¸con a` ce que la fenˆetre enti`ere soit trait´ee simultan´ement. Avant le traitement, les pixels d’une fenˆetre seront donc transf´er´es de la m´emoire globale source vers la m´emoire locale source. Outre son rˆole de m´emoire des op´erandes, la m´emoire locale source va donc ´egalement in- tervenir dans la mise en forme des donn´ees de la fenˆetre, de fa¸con a` ce que chaque unit´e de traitement dispose des diff´erents plans de bits requis.

Consid´erons une fenˆetre F de l’image I a` traiter, compos´ee de NF pixels et not´ee sous la forme d’un vecteur :

F = F [0], F [1], . . . , F [NF 1] (4.1) { − } La valeur de la couleur de chaque pixel est exprim´ee en binaire. Le bit de poids w, du pixel m de la fenˆetre F est not´e F [m, w]. Lorsque les pixels de l’image sont cod´es sur b bits, nous avons donc pour une fenˆetre F :

F [0] = F [0, b 1], F [0, b 2], . . . , F [0, 0] { − − } F [1] = F [1, b 1], F [1, b 2], . . . , F [1, 0] { − − } . .

F [NF 1] = F [NF 1, b 1], F [NF 1, b 2], . . . , F [NF 1, 0] (4.2) − { − − − − − } On notera l’ensemble des bits ayant le mˆeme poids w : un plan de bits de la fenˆetre F - P BF w. Nous disposons donc de b plans de bits not´es :

w P BF = F [0, w], F [1, w], . . . , F [NF 1, w] w 0, . . . , b 1 (4.3) { − } ∀ ∈ { − } La m´emoire locale source va donc g´en´erer les diff´erents plans de bits P BF w a` partir des donn´ees d’une fenˆetre F provenant de la m´emoire globale source en mode raster.

L’architecture adopt´ee pour la m´emoire locale source est repr´esent´ee sch´ematiquement a` la Figure 4.5. Elle est compos´ee : – d’une m´emoire tampon permettant la sauvegarde d’une seule ligne de la fenˆetre F a` traiter, – de la matrice de NF = Fx Fy registres a` d´ecalage. ∗ La m´emoire tampon est compos´ee d’une ligne (le bloc en trait interrompu marqu´ee tmp) de

Fx registres (marqu´ees tmp0, . . . , tmpFx 1), a` chargement et a` sortie parall`ele. −

La matrice des registres a` d´ecalage est compos´e d’une ligne (marqu´ee L0) de Fx registres

(R0,0 . . . R0,Fx 1), a` chargement parall`ele et a` un bit de sortie - le bit de poids le plus fort. La − matrice est ensuite compl´et´ee par Fy 1 lignes (not´ees L1, . . . , LFy 1) de Fx registres chacune, − − a` un bit d’entr´ee et un bit de sortie. Tous les registres ont une longueur de b bits.

133 Chapitre 4. Architecture reconfigurable

Le chargement des donn´ees dans la matrice des registres peut se faire soit depuis la m´emoire tampon, soit depuis la sortie des registres a` d´ecalage eux mˆemes (les d´emultiplexeurs a` l’entr´ee des registres que l’on peut voir a` la Figure 4.5). Avec un tel mode de fonctionnement on assure une lecture cyclique des donn´ees depuis les registres, permettant ainsi plusieurs passages pour chaque plan de bits, si n´ecessaire. La matrice des registres apparaˆıt alors comme un syst`eme

b tmp tmp tmp tmp F 0 1 2 Fx-1

tmp b b b b

R R R R 0,0 1,0 2,0 Fx-1,0 L0

1 1 1 1

R R R R 0,1 1,1 2,1 Fx-1,1

L1

Fx*Fy w R R R R 0,2 1,2 2,2 Fx-1,2 PBF L2

R R R R 0,Fy-1 1,Fy-1 2,Fy-1 Fx-1,Fy-1 L Fy-1

Fig. 4.5: M´emoire locale source : la m´emoire tampon et la matrice de registres a` d´ecalage

ayant b bits a` l’entr´ee et NF = Fx Fy bits a` la sortie. Ce syst`eme transforme un flux de × donn´ees a` son entr´ee pixel par pixel en un flux de donn´ees des plans de bits successifs.

Le choix d’une telle architecture pour la m´emoire locale des unit´es de traitement a ´et´e fait de fa¸con a` r´epondre aux deux objectifs suivants : – Minimiser la largeur des chemins de donn´ees - Comme les unit´es de traitement travaillent en mode bit-s´erie, on effectue le traitement plan de bits par plan de bits, l’acc`es aux donn´ees peut ˆetre limit´e uniquement aux donn´ees d’un seul plan de bits.

– Minimiser les ressources logiques mobilis´ees - Dans un circuit FPGA la r´ealisation des registres a` d´ecalage a` sortie et a` entr´ee parall`ele est faite a` l’aide des bi-stables pro- grammables d’une cellule logique ´el´ementaire CLE. Pour r´ealiser un registre de 8 bits

134 4.2. M´emoire locale des unit´es de traitement

il faut donc compter 8 bi-stables programmables, c’est a` dire une CLE compl`ete. Par contre un registre a` d´ecalage a` un seul bit d’entr´ee et a` un bit de sortie est r´ealis´e a` l’aide d’une seule LUT de la CLE. Dans ce cas il est possible de r´ealiser 8 registres de maximum 16 bits dans une seule CLE 5.

Les pixels de la fenˆetre sont d’abord sauvegard´es dans la m´emoire tampon de la matrice, un par un, dans l’ordre de leur arriv´ee. Lorsque une ligne de la fenˆetre est charg´ee dans la m´emoire tampon, elle est ensuite copi´ee dans la ligne L0 des registres. Comme la ligne L0 est compos´ee de registres a` chargement parall`ele, ce transfert peut ˆetre r´ealis´e en un seul cycle d’horloge. Depuis la premi`ere ligne de la matrice, les valeurs de pixels sont ensuite propag´ees dans les registres a` d´ecalage des lignes suivantes, de fa¸con a` ce que la matrice contienne la fenˆetre F enti`ere. Le transfert depuis la premi`ere ligne vers les autres lignes de la matrice est r´ealis´e bit par bit (le d´ecalage des lignes), puisqu’il s’agit des registres a` un seul bit d’entr´ee et de sortie.

Le principe de fonctionnement de la matrice et le chargement d’une fenˆetre peut ˆetre r´esum´e par le pseudo-code suivant :

for (j = 0 ; j < Fy ; j + +) // chargement d ’ une s e u l e f e n ˆe t r e { for (i = 0 ; i < Fx ; i + +) tmp[i] ← F [i + j ∗ Fx] // chargement de l a m´emoire tampon

L0 ← tmp // c o p i e de tampon v e r s L0

for (k = Fy − 2 ; k ≥ 0 ; k + +) // d´e c a l a g e des l i g n e s de l a matrice Lk+1 ← Lk }

Listing 4.3: Pseudo-code de fonctionnement de la matrice des registres a` d´ecalage

Signalons que les op´erations de chargement de la m´emoire tampon, la copie vers la ligne L0 et le d´ecalage des lignes sont des tˆaches ex´ecut´ees de fa¸con concurrentielle (le pipe-line de chargement). La Figure 4.6 montre le chronogramme des diff´erents signaux de contrˆole n´ecessaires pour le fonctionnement de la matrice des registres a` d´ecalage et met en ´evidence les taches ex´ecut´ees de fa¸con concurrentielle. On remarquera aussi les moments T1 et T3 qui correspondent aux moments d’apparition des plans de bits de poids plus fort de deux fenˆetres successives sur le bus de sortie (P BF w).

La sauvegarde des pixels de l’image se fait au rythme d’une horloge not´e Clk 6 sur le chrono- gramme de la Figure 4.6. Apr`es Fx cycles d’horloge, une ligne compl`ete de la fenˆetre F est charg´ee dans la m´emoire tampon. Au cycle suivant, cette ligne est copi´ee dans la matrice des

5Pour rappel : une CLE dans la terminologie des circuit FPGA -Virtex de Xilinx est appel´e un CLB. Un CLB est compos´e de quatre tranches, chacune ayant deux m´emoires de 16 bits. Voir Section 3.1 de l’Annexe 3 pour une explication plus d´etaill´ee de l’architecture d’une CLE. 6Afin de simplifier le dessin, les flancs descendants de ce signal ne sont pas repr´esent´es sur la figure.

135 Chapitre 4. Architecture reconfigurable registres grˆace au signal de contrˆole CopyLineIn. En mˆeme temps qu’un nouveau cycle de chargement d’une ligne dans la m´emoire tampon a lieu, le contenu de toute la matrice est d´ecal´ee de b places (le signal de contrˆole ShiftMatrix).

Lorsque Fy lignes de la fenˆetre F seront charg´ees (apr`es Fx Fy cycles), les nouveaux b cycles ∗ permettant de charger une nouvelle ligne dans la matrice donneront l’acc`es aux bits de la w fenˆetre F1 (les donn´ees de la premi`ere fenˆetre a` traiter sont disponibles sur le bus P BF a` partir de l’instant T1). C’est a` partir de l’instant T1 que le traitement plans de bits par plan de bits peut commencer.

Pour le chargement de la ligne suivante, nous avons le choix entre un d´eplacement horizontal ou un d´eplacement vertical de la fenˆetre F , comme le montre la Figure 4.7.

Etan´ t donn´e l’effet de bord li´e au calcul dans un voisinage, le traitement sur une nouvelle fenˆetre ne doit pas forc´ement comprendre le chargement de Fx Fy nouveaux pixels. En ∗ effet certains pixels, ceux appartenant aux zones gris´ees a` la Figure 4.7, sont des pixels d´ej`a pr´esents dans la matrice des registres a` d´ecalage et ils peuvent ˆetre r´eutilis´es pour le calcul de la fenˆetre suivante. Le nombre des nouveaux pixels a` charger dans la matrice est alors donn´e par :

(Fx (Vx 1)) Fy - pour un d´eplacement horizontal − − ∗ (4.4) Fx (Fy (Vy 1)) - pour un d´eplacement vertical ( ∗ − − avec Vx et Vy qui indiquent respectivement la taille horizontale et verticale de voisinage.

Comme le chargement de la matrice des registres se fait ligne par ligne de l’image (en fait de la fenˆetre) et non par colonne, c’est le d´eplacement vertical de la fenˆetre qui serait plus avantageux dans notre cas7.

De ce fait le calcul sur une nouvelle fenˆetre peut commencer a` partir de l’instant :

T3 = T1 + ∆T

= T + Fx (Fy (Vy 1)) (4.5) 1 ∗ − −

Le traitement des plans de bits aura donc lieu entre les instants T1 et T3. Afin d’assurer la plus faible latence entre deux fenˆetres successives, le choix de Fx, Fy est a` faire en fonction du nombre de pas de calcul et en fonction de la taille du voisinage consid´er´e.

Ainsi pour minimiser ∆T nous allons prendre comme taille verticale de le fenˆetre la taille verticale du voisinage (Fy = Vy). De cette fa¸con le chargement d’une seule nouvelle ligne de taille Fx dans la matrice permet le traitement de la fenˆetre suivante. En ce qui concerne la taille horizontale de la fenˆetre, elle d´ependra de l’algorithme utilis´e.

Pour des algorithmes en mode bit-s´erie ne n´ecessitant qu’un seul passage a` travers les diff´erents plans de bits, la plus faible latence sera obtenue en choisissant Fx = n, ou` n indique le nombre de pas de calcul a` effectuer (typiquement n = b). Ainsi par exemple, pour le cas concret de

7Dans le cas d’un d´eplacement par colonnes dans la matrice des registres c’est le d´eplacement horizontal qui serait plus avantageux.

136 4.2. M´emoire locale des unit´es de traitement ...... 4 5 ~ F F ...... 3 3 ~ F F ...... 2 3 ~ F F ...... x ~ F 1 2 ~ F F 3 T 2 ... T x F n 1 1 F T ...... y=Vy F y, F x* F ...... b ...... F t t w x i In r F e Clk Ou Ou at n e PB M n DataIn t f i Data opyLi Sh C opyLi C Fig. 4.6: Chronogramme de fonctionnement de la matrice des registres et des unit´es de traitement.

137 Chapitre 4. Architecture reconfigurable traitement de pixels cod´es sur 8 bits et avec les voisinages 3 3, 5 5 et 7 7 cela veut dire × × × 6, 4 et 2 unit´es de traitement par entr´ee de 8 bits.

Par contre pour des algorithmes en mode bit-s´erie n´ecessitant plusieurs passages a` travers les plans de bits, on peut choisir la taille horizontale de la fenˆetre Fx (en gardant toujours Fy = Vy) de fa¸con a` ce que le d´ebit de pixels trait´es soit toujours le mˆeme, quelque soit le nombre de passage a` effectuer. Nous avons donc Fx = r n, ou` r indique le rang recherch´e. ∗

4.2.2 Description de la m´emoire locale destination

Il est possible de sp´ecifier la m´emoire locale destination de fa¸con similaire a` la m´emoire locale source. Le nombre de registres en jeu est cependant plus petit en raison de l’effet de bord li´e au calcul dans un voisinage. En effet, lorsque la taille verticale de la fenˆetre correspond a` la taille verticale de voisinage (Fy = Vy), le nombre de pixels de la fenˆetre filtr´ee est donn´e par :

N = Fx (Vx 1) F˜ − − = F˜x (4.6)

La m´emoire locale destination est repr´esent´ee sch´ematiquement a` la Figure 4.8. Elle est com- pos´ee donc de F˜x registres a` d´ecalage de b bits. Ces registres sont charg´es en mode s´erie, mais il peuvent ˆetre lus en parall`ele pour un transfert vers la m´emoire tampon.

Image

Vx-1 Vx-1

Fi-1

Vy-1 Fi-1 Fi Fi+1 Fy

Vy-1 Fi+1

Fx

Fig. 4.7: D´eplacement de la fenˆetre dans la direction horizontale (les fenˆetres successives sont marqu´ees en trait plein) ou verticale (en trait interrompu) et recouvrement des pixels de deux fenˆetres diff´erentes duˆ a` l’effet de bord.

138 4.2. M´emoire locale des unit´es de traitement

La m´emoire tampon, not´ee tmp, est compos´ee de F˜x registres a` chargement et a` sortie pa- rall`ele. A leur entr´ee apparaissent soit les valeurs des pixels en provenance des registres a` d´ecalage, soit ceux situ´es imm´ediatement avant (les multiplexeurs repr´esent´es a` la Figure 4.8).

Lorsque le dernier bit de traitement (le bit de poids le plus faible) est arriv´e dans la ligne de registres a` d´ecalage, le contenu de ces registres est copi´e vers la m´emoire tampon (signal CopyLineOut a` la Figure 4.6). Les pixels trait´es sont ensuite transf´er´es vers la m´emoire destination globale, au rythme d’horloge Clk et en mˆeme temps que le chargement d’une nouvelle ligne de la fenˆetre.

w PB~F

NF~

R R R R 0 1 2 F~x-1

b b b b

tmp tmp tmp tmp b 0 1 2 Fx-~1 ~F tmp

Fig. 4.8: M´emoire locale destination : la matrice de registres a` d´ecalage et la m´emoire tampon de sortie.

La m´emoire source locale, la matrices des unit´es de traitement et la m´emoire destination locale fonctionnent donc en mode pipe-line. Apr`es un temps de latence li´e au chargement et le calcul de la premi`ere fenˆetre (n´egligeable par rapport a` la taille verticale de l’image), nous avons donc pour chaque chargement de Fx pixels de l’image a` traiter, F˜x pixels de l’image trait´ee a` la sortie (notons qu’`a la sortie on aura Fx valeurs effectives, mais ce sont les premi`eres F˜x valeurs a` prendre en compte).

4.2.3 Validation de la description

Les deux m´emoires locales que nous venons de voir ont ´et´e formellement d´ecrites en utili- sant le langage de description mat´erielle VHDL. Afin de faciliter la conception des diff´erentes configurations possibles, cette description fait appel a` la g´en´eration automatique d’un nombre variable d’instances des diff´erentes parties constitutives de la matrice.

Pour une m´emoire locale source il s’agit de :

139 Chapitre 4. Architecture reconfigurable

– Fx instances de registres a` d´ecalage, a` chargement et a` sortie parall`ele (m´emoire tam- pon), – Fx instances de registres a` d´ecalage, a` chargement parall`ele/s´erie et a` sortie s´erie, – Fx (Fy 1) instances de registres a` d´ecalage, a` chargement et a` sortie s´erie. ∗ − Ici, au lieu de cr´eer explicitement chacune des instances, la fonction generate, imbriqu´ee dans les boucles for, a ´et´e utilis´ee pour d´efinir les diff´erentes structures r´ep´etitives (voir [IEE00]). Dans cette description Fx, Vy, F˜x, et b apparaissent alors comme des param`etres a` fixer au d´ebut du processus d’impl´ementation.

Une telle approche permet d’automatiser enti`erement le processus de g´en´eration de la descrip- tion formelle des deux types de m´emoires pour les diff´erentes tailles de fenˆetre et en fonction du nombre de bits utilis´es pour coder la couleur d’un pixel.

La validation de la description de deux types de m´emoires a ´et´e faite en simulant le processus de chargement et d’exploitation d’une fenˆetre F de l’image a` traiter. La simulation en question a ´et´e r´ealis´ee a` l’aide du logiciel ModelSim (pour plus de d´etails techniques concernant le flot de conception utilis´e, voir Section C.1 de l’Annexe C).

Plusieurs configurations de la matrice en termes de taille et de nombre de bits utilis´es pour coder la couleur du pixel ont ´et´e r´ealis´ees et test´ees. Nous pr´esentons ici les r´esultats d’une seule simulation, qui pour des raisons de clart´e de l’expos´e a ´et´e limit´ee a` une fenˆetre de seulement 9 par 3 pixels, cod´es sur 4 bits.

Les valeurs des pixels de la fenˆetre utilis´ee sont indiqu´ees dans le Tableau 4.1.

i F [i, j, w] 0 1 2 3 4 5 6 7 8 0 0000 0001 0010 0011 0100 0101 0110 0111 1000 j 1 1001 1010 1011 1100 1101 1110 1111 0000 0001 2 0010 0011 0100 0101 0110 0111 1000 1001 1010

M w[j] 0 2 2 2 2 2 2 6 4 5 1 0 0 4 6 7 7 3 1 0 w 2 4 6 3 1 4 6 3 1 4 3 2 5 2 5 2 5 2 5 2

Tab. 4.1: Valeurs des pixels de la fenˆetre utilis´ee pour la simulation, exprim´ees en binaire et leurs ´equivalents d´ecimaux par plans de bits calcul´es selon l’Equation´ 4.7

La premi`ere partie du tableau montre les diff´erentes valeurs des pixels de la fenˆetre consid´er´ee, cod´es en binaire avec le bit de poids le plus fort a` gauche. Afin de faciliter la lecture des donn´ees sur le bus de sortie, celui-ci a ´et´e organis´e de la fa¸con suivante : on consid`ere b Fx mots de w ∗ Fy bits not´es M [j] et calcul´es en fonction des diff´erents plans de bits de la fenˆetre F selon

140 4.2. M´emoire locale des unit´es de traitement l’expression suivante :

Fy 1 − w j M [i] = F [i, j, w] 2 , w 0, . . . , b 1 , i 0, . . . , Fx 1 (4.7) ∗ ∀ ∈ { − } ∀ ∈ { − } j X=0 Dans l’expression 4.7, F [i, j, w] est utilis´e pour indiquer le bit de poids w, de pixel [i, j] de la fenˆetre F .

Dans la deuxi`eme partie du Tableau 4.1 (les quatre derni`eres lignes) on donne les ´equivalents d´ecimaux des diff´erents plans de bits en utilisant ce codage particulier.

La Figure 4.9 montre le chronogramme de fonctionnement de la m´emoire locale source obtenu pour la fenˆetre d´ecrite. On constate qu’`a partir de l’instant t1 les valeurs de sortie de la matrice des registres obtenues par simulation correspondent bien a` celles du Tableau 4.1. Les valeurs de la premi`ere ligne de la deuxi`eme partie du tableau, le plan de bits w = 0, peuvent ˆetre lues a` l’instant indiqu´e t1, la deuxi`eme (plan de bits w = 1) a` l’instant t2 et ainsi de suite.

4.2.4 Impl´ementation

Apr`es la validation de la description il est possible de passer a` l’´etape de placement et de routage du circuit afin d’obtenir d’une part la quantit´e r´eelle de ressources logiques employ´ees - Qr exprim´ee en nombre de tranches occup´ees et d’autre part la vitesse maximale de circuit. A ce stade-ci, le processus d’impl´ementation a ´et´e effectu´e avec une m´ethodologie qui privil´egie le faible temps de calcul de la solution et non la qualit´e du circuit obtenu (pour plus de d´etails concernant les diff´erentes m´ethodologies d’impl´ementation utilis´ees, voir Annexe D, Section D.2). Il s’agit donc plutˆot d’un indice de performance car les r´esultats pourraient a priori ˆetre am´elior´es, au d´etriment d’un temps d’impl´ementation plus long, ce qui sera fait lors de l’int´egration du syst`eme complet (voir Section 4.4).

Les r´esultats d’impl´ementation pour une m´emoire locale source dans un FPGA de densit´e moyenne sont indiqu´es dans le Tableau 4.2. Le mod`ele de FPGA utilis´e est un xc2v2000-6 avec une matrice de 56 48 CLEs, ce qui ´equivaut donc a` 10.752 tranches. ×

Pour une mˆeme taille verticale de fenˆetre Fy = Vy = 7, on montre les r´esultats pour diff´erentes tailles de Fx (la troisi`eme colonne du tableau indique le nombre de pixels NF dans la fenˆetre). Pour quelques Fx choisis arbitrairement on donne : – la quantit´e des ressources logiques Qr obtenue apr`es l’impl´ementation exprim´e en nombre de tranches, – le pourcentage d’occupation du circuit FPGA cible, – la fr´equence maximale du signal d’horloge - FClk, – le temps de calcul machine li´e au placement et le routage - tpar .

En ce qui concerne la m´emoire locale destination, les r´esultats sont semblables ´etant donn´e que son architecture ne diff`ere gu`ere de celle de la m´emoire locale source.

141 Chapitre 4. Architecture reconfigurable 2 2 5 2 5 2 5 2 5 2 4 t 4 4 6 3 1 4 6 4 3 t 0 0 0 4 6 7 7 3 1 0 2 t 1 1 2 2 2 2 2 2 6 4 5 7 2 t1 0 1 9 8 7 6 5 4 3 2 8 1 1 0 5 1 4 1 3 1 2 1 11 0 1 9 9 8 7 6 5 4 3 2 1 0 0 n 0 1 n 2 3 4 5 6 7 8 ei M M M M M M M M M n atai li d tmatrix f i opy h /register_matrix/clk /register_matrix/ /register_matrix/ /register_matrix/ /register_matrix/ /register_matrix/ /register_matrix/ /register_matrix/ /register_matrix/ /register_matrix/ /register_matrix/ /register_matrix/c /register_matrix/s Fig. 4.9: Chronogramme de fonctionnement d’une m´emoire locale source pour une fenˆetre de Fx = 9, Fy = 3 pixels cod´es sur 4 bits pour les donn´ees source du Tableau 4.1.

142 4.2. M´emoire locale des unit´es de traitement

r Fx Fy NF Q [tranches] Occupation FClk [MHz] tpar [sec]

10 7 70 153 1 % 172 11 25 7 175 378 3 % 197 15 45 7 280 683 6 % 163 23 65 7 385 986 9 % 158 69 85 7 595 1292 12 % 147 162

Tab. 4.2: R´esultats de l’impl´ementation d’une m´emoire locale source pour diff´erentes tailles de fenˆetre a` traiter : quantit´e r´eelle des ressources logiques et vitesse maximale de circuit. 4.2.5 Discussion

Sur la base des r´esultats d’impl´ementation obtenus nous pouvons tirer les conclusions suivantes :

1. Etan´ t donn´ee la configuration particuli`ere des m´emoires locales, la quantit´e de ressources logiques mobilis´ees pour un FPGA de moyenne densit´e est tout a` fait acceptable, per- mettant l’impl´ementation :

– soit d’un faible nombre de fenˆetres larges (Fx grand), lorsque le traitement vise plu- sieurs passages a` travers les diff´erents plans de bits, – soit d’un grand nombre de fenˆetres ´etroites (Fx petit), lorsque le traitement ne vise qu’un seul passage dans les plans de bits.

2. La vitesse de fonctionnement de la m´emoire des op´erandes est ´elev´ee, permettant d’im- portants d´ebits de pixels trait´es malgr´e une m´ethodologie d’impl´ementation privil´egiant le temps de calcul par rapport a` la qualit´e de circuit obtenue. Nous avons donc un syst`eme a` haut d´ebit de traitement, pour autant que les unit´es de traitement puissent suivre.

3. La diminution de la vitesse de fonctionnement due a` l’accroissement de la taille de la fenˆetre est faible, ce qui garanti des performances semblables lors d’une ´eventuelle parall´elisation plus massive.

143 Chapitre 4. Architecture reconfigurable

4.3 Unit´es de traitement

Les diff´erentes unit´es de traitement qui seront d´ecrites se basent sur deux algorithmes fonctionnant en mode bit-s´erie.

Le premier algorithme expos´e permet de trouver la valeur maximale, et avec tr`es peu de modifications la valeur minimale, dans un voisinage de NV pixels. Cet algorithme est ensuite adapt´e pour le filtre de rang g´en´eralis´e, calcul´e par ´elimination successive des maxima/minima locaux de voisinage.

Le deuxi`eme algorithme utilis´e est celui de Danielsson d´ej`a expos´e dans la Section 4.2.4.1. Mˆeme si cet algorithme est connu depuis 1981, son impl´ementation dans des architectures d´edicac´ees n’a vis´e que sa variante simplifi´ee pour le calcul de filtre m´edian sur un voisinage 3 3. Ici nous pr´esenterons son impl´ementation g´en´eralis´ee, pour les diff´erents voisinages × envisag´es et pour n’importe quelle valeur de rang r.

Nous commencerons par des explications d´etaill´ees d’algorithmes, avant de passer a` la concep- tion des unit´es de traitement correspondantes et leur impl´ementation.

4.3.1 Algorithmes

4.3.1.1 Algorithme Max

Consid´erons une fenˆetre F de l’image a` traiter I et un voisinage V au sein de cette fenˆetre, compos´e de NV pixels :

V = V [0], V [1], . . . , V [NV 1] (4.8) { − } Tous les pixels du voisinage sont cod´es sur b bits. La valeur de la couleur des pixels est exprim´ee en binaire : le bit de poids w, de pixel m de V sera not´e V [m, w]. Nous avons donc pour le voisinage :

V [0] = V [0, b 1], V [0, b 2], . . . , V [0, 0] { − − } V [1] = V [1, b 1], V [1, b 2], . . . , V [1, 0] { − − } . .

V [NV 1] = V [NV 1, b 1], V [NV 1, b 2], . . . , V [NV 1, 0] − { − − − − − } (4.9)

Le sous-ensemble des bits de voisinage V ayant le mˆeme poids w, le plan de bits, sera not´e w b 1 P BV . Examinons dans un premier temps le plan de bits de poids le plus fort P BV − :

b 1 P BV − = V [0, b 1], V [1, b 1], . . . , V [NV 1, b 1] (4.10) { − − − − } En comparant les valeurs des bits des diff´erents pixels pour ce mˆeme poids, deux situations diff´erentes peuvent apparaˆıtre :

144 4.3. Unit´es de traitement

b 1 1. Tous les bits de P BV − sont ´egaux :

0 V [0, b 1] = V [1, b 1] = . . . = V [NV 1, b 1] = − − − − 1  Dans ce cas, nous ne pouvons rien affirmer au sujet de la valeur maximale des pixels de voisinage V . Tous les pixels de V seront des candidats potentiels pour le maximum de l’ensemble. Le r´esultat aura pour le bit de ce poids la mˆeme valeur que tous les bits du b 1 plan P BV − , donc soit un ’0’ soit un ’1’. b 1 2. Les bits de P BV − sont diff´erents :

l, m : l, m 0, . . . , NV 1 l = m V [l, b 1] = V [m, b 1] (4.11) ∃ ∈ { − } ∧ 6 → − 6 − Dans ce cas, tous les pixels dont les bits pour ce poids valent ’0’ peuvent ˆetre ”exclus” b 2 du voisinage V pour le traitement du plan de bits suivant P BV − . Ces pixels seront certainement plus petits que la valeur maximale de V et ceci quelle que soit la valeur des bits de poids plus faible car nous avons toujours :

b 2 + b 1 − i b , 1 2 − > 1 2 (4.12) ∀ ∈ N ∗ ∗ i X=0 La valeur de bit du r´esultat pour ce poids (b 1) devrait alors valoir ’1’. −

Sur base de l’information des pixels a` exclure nous allons, dans l’it´eration suivante, construire b 2 un sous-ensemble de pixels de V et son plan de bits correspondant P BV − . Ce sous-ensemble de pixels sera compos´e uniquement des pixels de V dont le bit du poids pr´ec´edant, b 1 en − l’occurrence, valait ’1’.

Le mˆeme proc´ed´e de comparaison des bits est ensuite appliqu´e a` ce nouveau plan de bits P BV b 2 pour obtenir le bit de poids b 2 de r´esultat. − − L’algorithme est ex´ecut´e de fa¸con it´erative jusqu’`a obtention du dernier plan de bits P BV 0 et du bit de poids 0 de r´esultat.

Le pixel, ou les pixels (car il est possible que plusieurs pixels aient la mˆeme valeur de niveau de gris au sein d’un mˆeme voisinage), qui n’a (n’ont) pas ´et´e exclu(s) au bout de b it´erations sera le maximum du voisinage V .

L’algorithme ressemble a` l’algorithme de tri par classement d´ej`a mentionn´e (voir Section 2.2.1.7) en ce sens que les valeurs de voisinages sont distribu´ees dans des groupes. La principale diff´erence est qu’ici le nombre de groupes est limit´e a` deux : le groupe des candidats potentiels et le groupe des valeurs certainement plus petites que les candidats potentiels. Une autre diff´erence r´eside dans le fait qu’il n’existe pas de phase de recherche de la valeur apr`es le classement des pixels dans les groupes, la valeur est obtenue au fur et a` mesure que l’on avance dans le traitement des plans de bits successifs.

On pourrait ´egalement faire le rapprochement entre cet algorithme et celui de binary refi- nement utilis´e pour le calcul des filtres de piles (voir Section 3.2.5). Mˆeme si pour ces deux algorithmes nous avons le nombre de pas de calcul ´egal a` b, pour les filtres de piles il faut

145 Chapitre 4. Architecture reconfigurable

b 1 effectuer la threshold decomposition au pr´ealable et sauvegarder les 2 − bits pour chaque pixel de voisinage. De ce fait l’unit´e de traitement correspondante n´ecessitera une importante quantit´e de ressources logiques limitant ainsi sa performance de traitement.

La Figure 4.10 illustre les diff´erentes ´etapes du calcul de la valeur maximale pour un exemple concret de filtrage d’un voisinage 3 3. Le voisinage est d’abord transform´e en 8 plans de 9 × bits chacun, not´es P BV 7 a` P BV 0. Pour chaque plan des bits les cellules gris´ees repr´esentent les pixels a` exclure dans l’it´eration suivante et les cellules noires les pixels d´ej`a exclus dans les it´erations pr´ec´edentes. On montre ´egalement la construction du mot de r´esultat au fur et a` mesure que l’on avance dans le traitement des diff´erents plans de bits.

4.3.1.2 Algorithme Min

L’algorithme de calcul d’un filtre Max expos´e peut ˆetre adapt´e au calcul des filtres Min de plusieurs fa¸cons diff´erentes.

Tout d’abord on pourrait inverser le raisonnement pour le calcul de filtre Max et, au lieu d’exclure les valeurs des minima locaux d’un plan de bits a` l’autre, le faire cette fois pour les maxima locaux. Cette approche pr´esente n´eanmoins un petit inconv´enient : la description de l’unit´e de traitement change fortement, ce qui impliquerait d’importantes modifications de l’unit´e de traitement existante.

Une autre approche nous permet d’arriver au filtre Min, mais sans devoir passer par des modifications importantes de l’unit´e de traitement Max. Pour calculer le filtre Min on peut aussi tout simplement calculer un filtre Max sur les plans de bits invers´es car nous avons :

min(A, B) = max(A, B) (4.13) ou` A et B d´esignent les compl´ements de A et B (l’application d’un NON logique bit a` bit). En effet pour les deux mots A et B cod´es sur b bits nous avons :

b 1 b 1 − − si 2i A > 2i B (4.14) − − i i X=0 X=0 alors A < B et inversement.

Signalons que l’utilisation de cette m´ethode pour le calcul du filtre Min ne modifie en rien la quantit´e des ressources logiques n´ecessaires pour la r´ealisation d’une unit´e de traitement, comme nous allons le voir dans la Section 4.1.2.

4.3.1.3 Algorithme pour le filtre g´en´eralis´e

Algorithme d’´elimination successive des maxima/minima locaux L’algorithme expos´e pour le calcul d’un filtre Max/Min peut ˆetre utilis´e pour le calcul d’un filtre de rang g´en´eralis´e. En effet, en ´eliminant successivement NV r maxima (ou r minima) − 146 4.3. Unit´es de traitement

174 129 182 V={174,129,182,175,175,139,182,130,131} 175 175 139 V={~ 129,130,131,139,174,175,175,182,182} 182 130 131 MSB LSB

1 0 1 0 1 1 1 0 1 0 0 0 0 0 0 1 1 1 0 0 1 1 0 1 1 0 1 1 1 1 1 0 1 0 1 0 1 1 1 1 1 1 0 0 1 0 1 0 0 1 1 0 1 1 0 1 1 0 0 0 0 0 1 0 1 0 0 0 0 0 1 1

1 0 1 0 1 1 1 0 1 0 0 0 0 0 0 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 0 1 0 1 1 1 1 1 1 0 0 1 0 1 0 0 1 1 0 1 1 0 1 1 0 0 0 0 0 1 0 1 0 0 0 0 0 1 1 7 6 5 4 3 2 1 0

1 PB 1 0 1 0 1 1 0 1 1 1 0 1 1 0 1 0 1 1 0 1 1 0 1 1 0 1 1 1 0 1 1 0 1 1 0

Resultat Fig. 4.10: Recherche d’un maximum dans un voisinage 3 3 en mode × bit-s´erie.

147 Chapitre 4. Architecture reconfigurable locaux il est possible de calculer le filtre de n’importe quel rang r comme le maximum d’un voisinage V (mˆeme principe que pour l’algorithme utilis´e pour les architectures universelles, expos´e dans la Section 2.2.2). L’´elimination des diff´erents maxima locaux de V est faite en rempla¸cant sa valeur dans le voisinage par ’0’.

Pour illustrer ceci on peut prendre le mˆeme exemple de voisinage que celui utilis´e pour le calcul de filtre Max : V = 174, 129, 182, 175, 175, 139, 182, 130, 131 (voir Figure 4.10). Au bout de { } quatre maxima locaux ´elimin´es, respectivement 182, 182, 175 et 175 la valeur m´ediane (174) est trouv´ee, comme le Max de voisinage r´esultant : V = 174, 129, 0, 0, 0, 139, 0, 130, 131 . { } Lorsque dans le voisinage il existe plusieurs maxima locaux (dans l’exemple consid´er´e 182, 182 et 175, 175), il faut donc compter le nombre de pixels ´elimin´es.

Si une telle modification d’algorithme nous permet d’arriver rapidement a` une architecture qui calcule le filtre de rang g´en´eralis´e, sa performance d´ependra de la valeur du rang r et de la taille de voisinage consid´er´ee. C’est ici que le choix de la taille horizontale de la fenˆetre joue un rˆole important. En effet, comme nous avons pu le constater dans la Section 4.2, plus Fx est grand plus nous avons le temps d’effectuer le traitement tout en pr´eservant le d´ebit des pixels trait´es. Comme le syst`eme est reconfigurable et comme la m´emoire locale peut atteindre une taille importante, nous pouvons toujours nous arranger, en choisissant de fa¸con judicieuse la taille de Fx, pour traiter le mˆeme nombre de pixels quel que soit la valeur de rang recherch´ee (ceci sera abord´e de fa¸con plus d´etaill´ee dans la Section 4.4.).

Algorithme de Danielsson Si l’emploi de l’algorithme d’´elimination successive des maxima/minima locaux peut ˆetre 8 justifi´e lorsque NV est petit et r est petit ou grand , il n’en est pas de mˆeme pour des voisinages plus grands et des rangs proches du m´edian. En effet, la quantit´e de ressources logiques mobilis´ee pour pr´eserver le d´ebit de pixels trait´es devient trop importante.

Pour la conception de l’unit´e de traitement nous allons cependant modifier quelque peu l’al- gorithme expos´e. Pour rappel, la recherche de la valeur ayant un rang r par l’algorithme de Danielsson consiste a` compter le nombre d’occurrences des ’0’ et des ’1’ dans chaque plan de bits et a` comparer ce nombre avec la valeur de rang. Le r´esultat de la comparaison sera utilis´e pour choisir la valeur de bit de r´esultat pour ce poids, pour d´ecider s’il faudra additionner ou soustraire le nombre de ’0’ (ou de ’1’) lors de traitement de plan de bit suivant et quels pixels il faudra exclure de voisinage.

Dans l’algorithme que nous allons utiliser c’est le nombre des ’1’ qui est toujours calcul´e, mais dans un voisinage masqu´e, de la mˆeme fa¸con comme que pour les filtres Max/Min. Le nombre des ’0’ est alors calcul´e comme ´etant la diff´erence entre le nombre de pixels dans le voisinage qui n’ont pas encore ´et´e exclus et le nombre des ’1’ dans le voisinage masqu´e.

Consid´erons les diff´erents plans de bits d’un voisinage en partant du plan de bit de poids le plus significatif et en allant vers les plans de bit des poids plus faibles : P BV w, w b 1, . . . , 0 . ∈ { − } Pour chaque plan de bits nous allons effectuer les op´erations suivantes :

8En fonction de la valeur de rang recherch´ee on choisira l’´elimination des maxima ou des minima locaux. Ainsi si le rang est proche de NV on choisira d’´eliminer les maxima et si par contre il est proche de 1, alors on choisira d’´eliminer les minima.

148 4.3. Unit´es de traitement

1. Calculer le voisinage masqu´e, not´e P BV M comme un ET logique (not´e ) entre le · registre de masque a` l’it´eration w - M w et le plan de bits P BV :

P BV M w = M w P BV w (4.15) · Lorsque w = b 1, tous les bits de masque valent ’1’. − w w 2. Compter le nombre de pixels qui valent ’1’ dans P BV M , not´e n1 . w 3. Calculer le nombre de pixels qui valent ’0’, not´e n0 comme :

nw = np nw (4.16) 0 − 1 ou np d´esigne le nombre de pixels dans le voisinage n’ayant pas encore ´et´e exclus. Au d´ebut nous avons bien entendu np = NV . 4. Calculer la valeur de n :

w n = n + n1 , si la valeur de r´esultat valait ’0’ n = n nw, si la valeur de r´esultat valait ’1’ (4.17) − 0 Avant de calculer le premier plan de bits le r´esultat est mis a` ’0’ de fa¸con a` ce que dans w la premi`ere it´eration on calcule : n = n + n1 , avec n qui au d´epart vaut 0. 5. Comparer n avec la valeur de rang : si n r alors • ≥ – la sortie pour ce plan de bits sera mise a` ’1’, – les pixels qui valent ’0’ seront exclus lors de l’it´eration suivante, – mettre a` jour le nombre de pixels dans le voisinage masqu´e : np = np nw. − 0 si n < r alors • – la sortie pour ce plan de bit sera mise a` ’0’, – les pixels qui valent ’1’ seront exclus lors de l’it´eration suivante, – mettre a` jour le nombre de pixels dans le voisinage masqu´e : np = np nw. − 1 Pour le mˆeme exemple de voisinage utilis´e pour le filtre Max, le Tableau 4.3 indique les diff´erentes ´etapes du calcul d’un filtre m´edian sur un voisinage 3 3. ×

4.3.2 Description de l’unit´e de traitement pour les filtres Max/Min

La description de l’algorithme Max/Min met clairement en ´evidence trois parties distinctes de l’unit´e de traitement : 1. Construction des plans de bits masqu´es. 2. Calcul de la condition de mise a` z´ero du masque. 3. Calcul de la valeur filtr´ee.

Nous allons maintenant formaliser chacune de ces trois parties.

149 Chapitre 4. Architecture reconfigurable

w PBV M PBVM n1 n0 N N ≥ 5 Res. NP

7 7 7 111111111 111111111 111111111 9 0 N + n1 = 9 Oui 1 NP = 9 − n0 = 9 6 6 6 000000000 111111111 000000000 0 9 N − n0 = 0 Non 0 NP = 9 − n1 = 9 5 5 5 101110100 101110100 101110100 5 4 N + n1 = 5 Oui 1 NP = 9 − n0 = 5 4 4 4 001000100 100110000 001000100 2 3 N − n0 = 2 Non 0 NP = 5 − n1 = 3 3 3 3 100111000 100110000 100110000 3 0 N + n1 = 5 Oui 1 NP = 3 − n0 = 3 2 2 2 101110100 100110000 100110000 3 0 N − n0 = 5 Oui 1 NP = 3 − n0 = 3 1 1 1 101111111 100110000 100110000 3 0 N − n0 = 5 Oui 1 NP = 3 − n0 = 3 0 0 0 010111001 100110000 000110000 2 1 N − n0 = 4 Non 0 NP = 3 − n1 = 1

Tab. 4.3: Diff´erentes ´etapes de calcul, plan de bits par plans de bits, du filtre m´edian 3 3 avec l’algorithme de Danielsson. × 1. Construction des plans de bits masqu´e b 1 0 La construction des diff´erents plans de bits : P BV − , . . . , P BV , a` partir d’un voisinage V est faite a` l’aide de la m´emoire locale - la matrice des registres a` d´ecalage dont la description a ´et´e donn´ee dans la Section 4.2.

L’exclusion des mots dans le voisinage peut ˆetre faite a` l’aide d’un mot de ”masque“, not´e M, de NV bits, associ´e a` chaque voisinage V de la fenˆetre F en cours de traitement. Chaque bit de ce mot M est associ´e a` un pixel particulier de voisinage V . Ainsi, le bit marqu´e M[0] correspond au pixel V [0] et ainsi de suite, jusqu’au bit M[NV 1] qui correspond au pixel − V [NV 1]. − Nous allons noter le plan de bits de poids w d’un voisinage masqu´e : P BV M w le r´esultat w b w d’un ET logique, bit a` bit, entre le mot P BV et le mot M − , au moment de l’it´eration b w : − w w w w P BV M = P BV M [0], P BV M [1] . . . P BV M [NV 1] { w b w − } = P BV M − · b w b w = V [0, w] M − [0], . . . , V [NV 1, w] M − [NV 1] (4.18) · − · − w 0, . . . b 1 ∀ ∈ { − }

Lors de la phase d’initialisation tous les bits du mot M sont mis a` 1. De cette fa¸con le plan de bits a` masquer lors de la premi`ere it´eration b 1 : P BV b 1 contient tous les bits de poids − − le plus fort du voisinage V .

Au cours des it´erations suivantes (le traitement des plans de bits suivants), les bits du mot M correspondants aux pixels qu’il faut exclure seront mis a` 0. Les diff´erents ´etats de M seront not´e M 1, M 2, . . . M b avec l’´etat M 1 qui correspond a` l’´etat initial et l’´etat M b a` l’´etat de mot de masque apr`es le traitement de tous les plans de bits. Les bits de mots de masque apr`es le traitement, donc de mot M b qui valent ’1’ indiquent les pixels ayant la valeur maximale de V .

Signalons que le masque M peut avoir un autre rˆole. Lorsque la forme du voisinage change, pour ne plus ˆetre l’habituel carr´e, il suffit, lors de la phase d’initialisation, de placer dans le

150 4.3. Unit´es de traitement mot M les ’0’ et les ’1’ de fa¸con a` exclure les pixels n’appartenant pas a` la forme du voisinage d`es le d´epart.

2. Calcul de la condition de la mise a` z´ero du masque Les diff´erents ´etats de mot M, donc M 1, M 2, . . . , M b sont obtenus par une mise a` ’0’ des bits de M correspondants aux pixels de V dont les bits valent ’0’ et s’il y a une in´egalit´e entre les bits.

Pour d´eterminer s’il y a une in´egalit´e entre les bits il est plus simple de partir de la condition d’´egalit´e. Tous les bits d’un plan de bits masqu´e P BM w seront ´egaux s’ils valent tous ’1’ ou tous ’0’ :

w w w w Equ = P BV M [0] P BV M [1] . . . P BV M [NV 1] + · · · − w w w + P BV M [0] P BV M [1] . . . P BV M [NV 1] (4.19) · · · − L’in´egalit´e sera alors : NEquw = Equw (4.20)

La condition de la mise a` z´ero des registres de masque M est alors donn´ee par :

w w 1, si NEqu = 1 ET P BV M [m] = 0 ResetM [m] = , m 0, . . . , NV 1 (4.21) (0, si NEqu = 0 ∀ ∈ { − }

3. Calcul de la valeur filtr´ee Le bit de r´esultat pour le poids w peut ˆetre calcul´e comme un OU logique (not´e +) des diff´erents bits de plan de bits masqu´e courant :

w w w w Res = P BV M [0] + P BV M [1] + . . . + P BV M [Nv 1] (4.22) −

En comparant les ´equations logiques 4.19 et 4.22 on constate que pour calculer NEquw et Resw il suffit de calculer les deux fonctions logiques suivantes :

w w w F 1 = P BV M [0] + P BV M [1] + . . . + P BV M [NV 1] w w w − F 2 = P BV M [0] + P BV M [1] + . . . + P BV M [NV 1] (4.23) − et puis de calculer NEquw et Resw comme :

NEquw = F 1 F 2 (4.24) · Resw = F 2 (4.25)

La Figure 4.11 montre le sch´ema fonctionnel d’une unit´e de traitement pour les filtres Max/- Min. Elle est compos´ee de NV m´emoires d’un bit (marqu´ees M[0], . . . , M[NV 1]) et d’une − logique combinatoire permettant de calculer les fonctions d´ecrites : – Resultat - le r´esultat du filtrage, – NEqu - la non-´egalit´e, – ResetM - la mise a` z´ero des m´emoires.

151 Chapitre 4. Architecture reconfigurable

Le signal InitM sert a` initialiser le registre de masque M lors de la premi`ere it´eration. Dans le cas d’un voisinage carr´e, le mot M est tout entier constitu´e des ’1’.

Chaque plan de bits en provenance de la m´emoire source locale - la matrice de registre a` d´ecalage - apparaˆıt sur le bus P BV . Le plan de bits est ensuite masqu´e (le bus P BV M). Sur le plan de bits masqu´e on calcule ensuite les fonctions logiques F 1 et F 2 (l’´equation 4.23). En utilisant ces deux fonctions interm´ediaires on calcule : le r´esultat de filtrage pour le plan de bits w - Result, la variable NEqu et les conditions de mis a` z´ero pour chaque bit de registre de masque (ResetM[m]).

PBV PBVM

PBV[0] w PBVM[0] F2 Res

PBV[1] PBVM[1]

F1 NEqu PBV[NV-1] PBVM[NV-1]

S Mask[0] Q M[0] PBV[0] ResetM[0] R

S Mask[1] Q M[1] PBV[1] ResetM[1] R

S Mask[N -1] V Q M[N -1] PBV[N -1] V ResetM[N -1] V R V InitM PBV

Fig. 4.11: Sch´ema fonctionnel d’une unit´e de traitement pour le filtre Max en mode bit-s´erie.

Pour le filtre Min, les entr´ees des portes ET utilis´ees pour le calcul du plan de bits masqu´e du voisinage sont pr´ec´ed´ees par des inverseurs : on modifie l’´equation 4.18 utilis´ee pour le calcul du plan de bit masqu´e :

w 0, , b 1 (4.26) ∀ ∈ { · · · − w} b w b w P BV M = V [0, w] M − [0], . . . , V [NV 1, w] M − [NV 1] · − · − w et l’´equation 4.22, qui d´evient : Resw = Res .

Comme le calcul de ces deux fonctions sera fait a` l’aide des m´emoires des CLEs, par ailleurs d´ej`a utilis´ees pour le calcul d’un ET logique entre les bits du plan et le mot de masque, l’ajout

152 4.3. Unit´es de traitement de ces inverseurs ne changera donc rien quant a` la quantit´e de ressources logiques n´ecessaires a` la r´ealisation d’une unit´e de traitement 9.

4.3.3 Description de l’unit´e de traitement pour le filtre de rang g´en´eralis´e

4.3.3.1 Algorithme d’´elimination successives des maxima/minima locaux

Pour la r´ealisation d’une unit´e de traitement bas´ee sur l’algorithme d’´elimination suc- cessive des maxima/minima locaux on part de la mˆeme description donn´ee pour l’unit´e de traitement Max/Min. Selon l’algorithme d´ecrit (voir la Section 4.1.1.3) a` celle-ci il faut ajou- ter :

1. un nouveau mot de masque, de NV bits, permettant d’exclure du voisinage V les maxi- ma/minima locaux un par un, 2. un module permettant de s´electionner un seul maxima/minima local parmi ceux trouv´es, apr`es chaque cycle de b it´erations.

Le nouveau mot de masque sera not´e MM w. Comme pour le mot M, tous les bits du mot MM sont, au d´ebut de traitement mis a` ’1’ de fa¸con a` ce que tous les pixels du voisinage soient pris en compte (le signal not´e InitMM).

L’introduction de ce nouveau mot de masque implique quelques modifications des ´equations donn´ees pour l’unit´e de traitement Max/Min.

Ainsi, le plan de bits masqu´e (l’´equation 4.18 pour l’unit´e de traitement Max/Min) devient :

w w b w b w P BV M = P BV MM − M − (4.27) w · b w · = tmp M − (4.28) · La condition de la mise a` z´ero du mot de masque M (l’´equation 4.21 pour l’unit´e de traitement Min/Max) devient alors :

w w 1, si NEqu = 1 ET tmp [m] = 0 ResetM [m] = , m 0, . . . , NV 1 (4.29) (0, si NEqu = 0 ∀ ∈ { − }

En ce qui concerne la mise a` z´ero des bits de masque MM, elle n’aura lieu qu’apr`es le traitement de tous les plans de bits (ce qui sera marqu´e par un signal ResetMM) et pour une seule valeur de maxima/minima local.

Comme apr`es une it´eration compl`ete nous savons quelles sont les valeurs maximales de V (les bits de masque M ayant encore la valeur de ’1’), c’est dans le mot de masque que nous allons chercher le premier pixel dont le bit de masque M associ´e vaut ’1’. Pour ce faire, nous

9Comme le nombre de variables reste le mˆeme, c’est le mˆeme nombre de LUT s qui sera n´ecessaire pour le calcul de plan de bit masqu´e, dans les deux cas. La seule chose qui change est la table de v´erit´e, qui dans le cas d’un filtre Max est relative a` la fonction P BV [i] · M[i], tandis que pour le filtre Min elle corresponde a` la fonction P BV [i] · M[i].

153 Chapitre 4. Architecture reconfigurable utilisons un simple encodeur de priorit´e sur le mot M. Les sorties de cet encodeur, not´ees sous forme d’un vecteur P de NV bits, sont calcul´ees comme suit :

P [m] = 1 et P [k] = 0 k 0, . . . , m 1 si M[m] = 1 (4.30) ∀ ∈ { − } quelles que soient les valeurs M[m 1], . . . , M[0] − Le mot P sera ensuite utilis´e pour d´efinir la mise a` z´ero du mot de masque MM :

m 0, . . . , NV 1 (4.31) ∀ ∈ { − } 1, si P [m] = 1 ET ResetMM = 1 ResetMM w[m] = (0, si P [m] = 0

La Figure 4.12 montre le sch´ema fonctionnel de l’unit´e de traitement pour le filtre Max/Min, modifi´e pour le calcul du filtre de rang g´en´eralis´e. On remarquera l’ajout d’un nouveau mot de masque MM et de l’encodeur de priorit´e P .

PBVM PBV[0] tmp[0] w PBVM[0] F2 Res

PBV[1] tmp[1] PBVM[1]

F1 NEqu PBV[NV-1] tmp[NV-1] PBVM[NV-1]

S S Q MM[0] M[0] ResetMM[1] Q M[0] tmp[0] R ResetM[0] R S S Q MM[1] M[1] ResetMM[0] Q M[1] tmp[1] R ResetM[1] R EP

S S MM[N -1] M[N -1] Q V V M[N -1] tmp[N -1] ResetMM[NV-1] Q V V R ResetM[NV-1] InitMM R

ResetMM

P M

InitM PBV

Fig. 4.12: Sch´ema fonctionnel d’une unit´e de traitement pour le filtre g´en´eralis´e en mode bit-s´erie (l’algorithme d’´elimination des Maxima/- Minima locaux).

4.3.3.2 Algorithme de Danielsson

La description de l’algorithme de Danielsson met en ´evidence les diff´erentes parties d’une unit´e de traitement : 1. Calcul du voisinage masqu´e P BV M.

154 4.3. Unit´es de traitement

2. Compteur du nombre de ’1’ dans le voisinage masqu´e : n1.

3. Soustracteur pour le calcul du nombre de ’0’ : n0. 4. Additionneur - soustracteur pour le calcul de n. 5. Comparateur de n avec la valeur de rang r. 6. Soustracteur pour le calcul du nombre de pixels dans le voisinage np. 7. Calcul de la nouvelle valeur de masque M.

1. Calcul du voisinage masqu´e P BV M Le voisinage masqu´e est obtenu tout simplement en calculant un ET logique entre le plan de bits courant P BV et la valeur de masque M.

2. Compteur du nombre de ’1’ dans le voisinage masqu´e : n1 Pour calculer le nombre de ’1’ dans le voisinage masqu´e nous allons utiliser NVx circuits additionneurs de NVy op´erandes d’un seul bit. On calculera d’abord le nombre de ’1’ par colonnes, le r´esultat final ´etant obtenu en sommant le nombre de ’1’ des diff´erentes colonnes. De cette fa¸con et pour des voisinages successifs lors d’une parall´elisation on ´evitera de r´ep´eter inutilement le calcul du nombre de ’1’ par colonne. Le nombre de ’1’ est cod´e sur 4, 5 et 6 bits respectivement pour des voisinages de 3 3, 5 5 et 7 7 pixels. × × ×

3. Soustracteur pour le calcul du nombre de ’0’ : n0 Pour obtenir le nombre de ’0’ nous allons soustraire de nombre de pixels dans le voisinage n’ayant pas encore ´et´e exclus (np) le nombre de ’1’ pour ce plan de bits - n1. Initialement np = NV .

4. Additionneur - soustracteur pour le calcul de n Si la valeur du r´esultat obtenu pour le plan de bits pr´ec´edant valait ’0’ nous allons ajouter a` n le nombre de ’1’, sinon c’est le nombre de ’0’ qui sera soustrait. Initialement n vaut z´ero, b ainsi que le r´esultat de fa¸con a` avoir n = n1 lors de traitement de premier plan de bits. 5. Comparateur de n avec la valeur de rang r Le r´esultat de la comparaison de n avec le rang r donne la valeur du r´esultat pour ce plan de bits : si n r alors la sortie vaut ’1’, sinon elle vaut ’0’. ≥ 6. Soustracteur pour le calcul du nombre de pixels dans le voisinage np Si le r´esultat courant vaut ’1’ nous allons soustraire de nombre de pixels dans le voisinage np le nombre des ’0’, sinon le nombre de ’1’ calcul´e pour ce plan de bits.

7. Calcul de la nouvelle valeur de masque M Si le r´esultat courant vaut ’1’, alors la nouvelle valeur de masque vaut : – soit M = P BV M de fa¸con a` exclure les pixels qui ont un poids ’0’, · – sinon M = P BV M de fa¸con a` exclure les pixels qui ont un poids ’1’. · L’unit´e de traitement correspondante a` l’algorithme de Danielsson se montre plus complexe que les deux unit´es de traitement envisag´ees pr´ec´edemment, principalement a` cause de la pr´esence de plusieurs circuits arithm´etiques. Mais du fait des ressources logiques d´edicac´ees a` l’arithm´etique du FPGA et du faible nombre de bits codant les mots n0, n1, n et np on peut n´eanmoins esp´erer une impl´ementation efficace.

155 Chapitre 4. Architecture reconfigurable

La Figure 4.13 montre le sch´ema fonctionnel d’une unit´e de traitement pour le filtre de rang g´en´eralis´e selon l’algorithme de Danielsson.

n N + n+ PBV - PBVM Compteur n1 M des '1' n0 Resultat - Resultat+ np r n>r Resultat

np + - np

M+ M

Resultat np M n

Fig. 4.13: Sch´ema fonctionnel d’une unit´e de traitement pour le filtre g´en´eralis´e en mode bit-s´erie (algorithme de Danielsson).

4.3.4 Validation de la description

Les diff´erentes unit´es de traitement propos´ees ont ´et´e d´ecrites en langage VHDL pour une impl´ementation dans un circuit FPGA. Les diff´erentes configurations de l’unit´e de traitement sont obtenues a` partir d’une mˆeme description de circuit de fa¸con a` ce que : le nombre de bits utilis´es pour coder la couleur du pixel, le type de filtre (Min ou Max dans le cas d’une unit´e de traitement sp´ecifique et la valeur de rang dans le cas d’une unit´e de traitement g´en´eralis´e) ainsi que la taille de voisinage apparaissent comme des param`etres d’impl´ementation.

Dans un premier temps la description des unit´es de traitement a ´et´e valid´ee pour un exemple concret : le r´ealisation d’une unit´e de traitement permettant de calculer la valeur maximale, minimale et m´ediane d’un voisinage de 3 3, 5 5 et 7 7 pixels cod´es sur 8 bits. Nous × × × pr´esentons ici les r´esultats de la simulation pour le voisinage 3 3. Les r´esultats de la validation × pour des voisinages de 5 5 et 7 7 pixels peuvent ˆetre trouv´es dans la Section C.2 de l’Annexe × × C.

Le voisinage utilis´e pour la simulation est le mˆeme que celui utilis´e chaque fois jusqu’ici : V = 174, 129, 182, 175, 175, 139, 182, 130, 131 , a` quoi correspond le voisinage tri´e : V˜ = { } 129, 130, 131, 139, 174, 175, 175, 182, 182 . Les valeurs correspondantes aux rangs r = 1, r = 5 { } et r = 9, respectivement Min, Med et Max sont alors 129, 174 et 182.

156 4.3. Unit´es de traitement

Le Tableau 4.4 indique les valeurs des pixels du voisinage d´ecrit, exprim´ees en binaire. La valeur binaire de chaque pixel peut ˆetre lue verticalement (colonnes du Tableau 4.4) tandis que les valeurs de plan de bits sont lues horizontalement (lignes du Tableau 4.4). La derni`ere colonne indique la valeur d´ecimale de chaque plan de bits, avec le bit du pixel V [0] comme bit de poids le plus significatif.

Voisinage

Index V [0] V [1] V [2] V [3] V [4] V [5] V [6] V [7] V [8]

Valeur 174 129 182 175 175 139 182 130 131

Plan de bits Poids 256 128 64 32 16 8 4 2 1

P BV7 - MSB 128 1 1 1 1 1 1 1 1 1 511

P BV6 64 0 0 0 0 0 0 0 0 0 0

P BV5 32 1 0 1 1 1 0 1 0 0 372

P BV4 16 0 0 1 0 0 0 1 0 0 68

P BV3 8 1 0 0 1 1 1 0 0 0 312

P BV2 4 1 0 1 1 1 0 1 0 0 372

P BV1 2 1 0 1 1 1 1 1 1 1 383

P BV0 - LSB 1 0 1 0 1 1 1 0 0 1 185

Rang 5 1 8 6 7 4 9 2 3

↑ ↑ ↑ ↑

Med Min Max Max

Tab. 4.4: Voisinage 3 3 employ´e pour la simulation : valeurs des pixels × et des plans de bits correspondants (en binaire et en d´ecimal). La derni`ere ligne indique la valeur de rang pour chaque pixel.

157 Chapitre 4. Architecture reconfigurable

La Figure 4.14 montre le chronogramme de fonctionnement de l’unit´e de traitement Max et Min obtenu pour le voisinage d´ecrit. Apr`es la phase d’initialisation du registre de ”masque“, on peut voir l’´evolution du calcul du r´esultat suite au traitement des 8 plans de bits successifs. Les r´esultats obtenus par simulation correspondent aux valeurs de Max et de Min du voisinage consid´er´e.

V={174,129,182,175,175,139,182,130,131} V={129,130,131,139,174,175,175,182,182}~

clk initm pbv 511 0 372 68 312 372 383 185 (8) (7) (6) a) (5) (4) (3) (2) (1) (0) resultat 1 0 1 1 0 1 1 0

0 1 2 3 4 5 6 7

clk initm pbv 511 0 372 68 312 372 383 185 (8) (7) (6) b) (5) (4) (3) (2) (1) (0) resultat 1 0 0 0 0 0 0 1

0 1 2 3 4 5 6 7 Fig. 4.14: Chronogrammes de fonctionnement d’une seule unit´e de trai- tement calculant les filtres Max a) et Min b), pour un voisinage de 3 3 × pixels cod´es sur 8 bits.

La Figure 4.15 montre le chronogramme de fonctionnement de l’unit´e de traitement pour le filtre g´en´eralis´e. Le processus d’´elimination, ici des maxima locaux (c’est l’unit´e de traitement Max qui a ´et´e utilis´ee), a ´et´e arrˆet´e apr`es quatre it´erations de fa¸con a` ce que la valeur maximale repr´esente la m´ediane de V (la valeur 174). Signalons l’´evolution de l’´etat du registre de deuxi`eme masque (MM signal masquemm sur le chronogramme).

On remarquera ´egalement la mise a` z´ero des bits correspondants aux rangs 9, 8, 7, 6 et 5 ; leur indice dans le voisinage sont respectivement : 6, 2, 4, 3 et 0.

158 4.3. Unit´es de traitement

V={174,129,182,175,175,139,182,130,131} V={129,130,131,139,174,175,175,182,182}~

clk initm initmm iresetmm

pbv 511 0 372 68 312 372 383 185 511 0 372 68 312 372 383 185 511 0 372 68 312 372 383 185 511 0 372 68 312 372 383 185 511 0 372 68 312 372 383 185 maskmm 511 507 443 427 395 139 (0) (1) (2) (3) (4) (5) (6) (7) (8) resultat 1 0 1 1 0 1 1 0 1 0 1 1 0 1 1 0 1 0 1 0 1 1 1 1 1 0 1 0 1 1 1 1 1 0 1 0 1 1 1 0

182 182 175 175 174

0 8 16 24 32 40 Fig. 4.15: Chronogramme de fonctionnement d’une seule unit´e de trai- tement calculant le filtre m´edian par ´elimination, pour un voisinage de 3 3 pixels cod´es sur 8 bits. ×

La Figure 4.16 montre le chronogramme de fonctionnement de l’unit´e de traitement pour le filtre g´en´eralis´e bas´e sur l’algorithme de Danielsson. Mis a` part la valeur de r´esultat (signal Resultat) on montre ´egalement la valeur de masque (signal Mask) et le nombre de ’1’ (signal NOnes). Le tableau de la mˆeme figure indique les diff´erents calculs li´es au traitement des diff´erents plans de bits.

4.3.5 Impl´ementation

La description des circuits d´ecrits est valid´ee a` travers le processus de simulation pour un ensemble de vecteurs a` l’entr´ee diff´erents (en fait des voisinages), ce qui nous permet de passer au processus d’impl´ementation proprement dit. Apr`es l’impl´ementation nous serons en mesure de caract´eriser la performance du circuit r´ealis´e en termes de quantit´e des ressources logiques n´ecessaires et de vitesse du circuit obtenu. Signalons qu’`a ce stade les r´esultats pr´esent´es sont obtenus avec une m´ethodologie d’impl´ementation qui favorise un temps d’impl´ementation rapide plutˆot que la qualit´e du r´esultat obtenu. Pour plus de d´etails techniques concernant cette m´ethodologie voir Section C.1 de l’Annexe C.

Les r´esultats de l’impl´ementation concernent le mˆeme circuit FPGA que celui utilis´e pour l’impl´ementation de la m´emoire locale. Pour rappel il s’agit du circuit portant la r´ef´erence xc2v2000-6 dont les ressources logiques comptent 10752 tranches.

159 Chapitre 4. Architecture reconfigurable 8

0 00000000 1 0000 1

1 0 1 00 00 9 9 3 3 3 3 1 111 0 = = =5 = = = = = 1 7 0 6 1 5 0 4 1 3 0 2 0 1 0 0 1 0 6 n n n n n n n n ------

P 9 9 9 3 3 3 3 N = = = =5 = = = =

1 P P P P P P P P N N N N N N N N 1111111 } } 0 1 0 1 0 1 1 1 0 2 1 1 Res. 8 3 1 1 , , 2 0 n n n o o o 8 3 >=5 Oui Oui Oui Oui Oui N N N 1 1 1 N , , 00 1 5 2 0 7 8 9 0 2 4 1 1 111 , , = = =5 = =5 =5 =5 = 0 1 5 9 7 1 6 0 5 1 4 0 3 1 2 0 1 0 0 0 4 7 3 n n n n n n n n N 1 1 - - - - - , ,

+ + + 4 5 N N N N N N N N 7 7 0000 1 1 0 11 , , 0 11 000 0 9 4 3 0 0 0 1 00 n 9 5 1 00 3 7 111 1 1 1 , , 00 9 0 5 2 3 3 3 2 n 1 1 2 3 8 1 1 00 00 , , 1 1 00 M 0 0000 0000 0000 0000 0 9 1 0 3 2 11 000 11 11 11

111 1 1 1 1 0 00 PBV 0 00 00 00 , , 111 1 1 111111111 000000000 1 00 1 1 1 000 0 9 4 1 00 2 7 000 1 1 1 00 { { 00 1 2 0 0000 0000 0000 0000 0000 = = 11 11 11 11 11 M ~ 111 V V 0 00 00 00 00 00 111111111 111111111 1 1 1 1 1 1

0 1 00 0 1 1 1 0 00 00 00 0 1 000 00 1 1 0 0 111 0 000 111 111 1 111 1 111 1111111 0 PBV 0 00 0 0 1 111111111 000000000 1 00 1 1 1 0 w 7 6 5 4 3 2 1 0

1 0000 000000000 0 1 00 1 111111111 111111111 t m a es t clk l p n pbv u o m /i_init t n es r p m t Fig. 4.16: Chronogramme de fonctionnement d’une seule unit´e de trai- tement calculant le filtre m´edian par l’algorithme de Danielsson, pour un voisinage de 3 3 pixels cod´es sur 8 bits. × 160 4.3. Unit´es de traitement

4.3.5.1 Unit´e de traitement bas´ee sur l’algorithme Min/Max

Le Tableau 4.5 indique les r´esultats de l’impl´ementation, obtenus pour une unit´e de trai- tement d’un filtre Max. Les r´esultats sont les mˆemes pour une unit´e de traitement de type Min.

r Vx Vy NV Q [tranches] FClk [MHz] tpar [sec]

3 3 9 19 225 29 5 5 25 54 126 31 7 7 49 102 74 32

Tab. 4.5: R´esultats de l’impl´ementation pour une seule unit´e de trai- tement (filtre Max/Min) pour les trois voisinages envisag´es. Circuit FPGA : xc2v2000-6.

Le Tableau 4.6 montre les r´esultats de l’impl´ementation pour une unit´e de traitement calcu- lant le filtre de rang g´en´eralis´e par l’algorithme d’´elimination successive des maxima/minima locaux.

r Vx Vy NV Q [tranches] FClk [MHz] tpar [sec]

3 3 9 36 188 28 5 5 25 116 118 34 7 7 49 231 88 37

Tab. 4.6: R´esultats d’impl´ementation pour une seule unit´e de traitement (filtre g´en´eralis´e obtenu par ´elimination des maxima/minimas locaux) pour les trois voisinages envisag´es. Circuit FPGA : xc2v2000-6.

4.3.5.2 Unit´e de traitement bas´ee sur l’algorithme de Danielsson

Le Tableau 4.7 indique les r´esultats de l’impl´ementation obtenus pour une seule unit´e de traitement calculant le filtre de rang selon l’algorithme de Danielsson.

r Vx Vy NV Q [tranches] FClk [MHz] timpl [sec]

3 3 9 34 101 30 5 5 25 75 61 30 7 7 49 118 50 35

Tab. 4.7: R´esultats de l’impl´ementation pour une seule unit´e de trai- tement (filtre g´en´eralis´e par algorithme de Danielsson) pour les trois voisinages envisag´es. Circuit FPGA : xc2v2000-6.

161 Chapitre 4. Architecture reconfigurable

4.3.5.3 Discussion

La quantification de la performance des diff´erentes unit´es de traitement nous permet de faire des conclusions importantes suivantes :

– Ressources logiques Les unit´es de traitement, mˆeme lorsqu’elle calculent des filtres sur des voisinages de grande taille, n´ecessitent une faible quantit´e de ressources logiques par rapport a` la quantit´e des ressources logiques disponibles au sein d’un circuit FPGA. Nous pouvons donc compter sur un parall´elisme de grain tr`es fin, mˆeme pour des FPGAs de moyenne densit´e.

– Performance Mˆeme si la vitesse de fonctionnement des circuits est faible, compar´ee a` la vitesse des microprocesseurs actuels, le pipe-line de traitement et un grand nombre d’unit´es de traitement potentiellement r´ealisables au sein d’un mˆeme circuit FPGA annoncent la possibilit´e de traitement a` tr`es haut d´ebit.

– Optimisation En imposant des contraintes d’impl´ementation plus s´ev`eres et en for¸cant le logiciel de placement et de routage a` chercher une solution plus optimale, on peut esp´erer arriver a` des circuits plus rapides et donc a` des d´ebits de traitement plus importants.

Bien entendu lors de l’impl´ementation de plusieurs unit´es de traitement au sein d’un mˆeme FPGA, la quantit´e des ressources logiques utilis´ee et la performance d´ependront du nombre d’unit´es effectivement r´ealis´ees. Si l’augmentation du nombre d’unit´es de traitement a pour corollaire la diminution de la performance, une m´ethodologie d’impl´ementation qui vise la per- formance aura elle, la tendance inverse. La quantification des r´esultats de l’impl´ementation nous permettra dans ce cas de d´eduire le d´ebit r´eel des pixels trait´es par le syst`eme reconfi- gurable, pour diff´erents algorithmes et pour diff´erents voisinages envisag´es. Les aspects de la multiplication du nombre d’unit´es de traitement et leur impl´ementation sous fortes contraintes feront l’objet de la Section suivante.

162 4.4. Syst`eme reconfigurable complet

4.4 Syst`eme reconfigurable complet

4.4.1 Description du syst`eme complet

Les diff´erentes parties constitutives du syst`eme reconfigurable ´etant d´ecrites et leur fonc- tionnement v´erifi´e, nous pouvons a` pr´esent passer a` l’int´egration du syst`eme complet. Plu- sieurs configurations du syst`eme sont possibles quant a` la mani`ere d’´ecrire et de lire les donn´ees dans les m´emoires locales. Le choix d’une configuration particuli`ere est a` faire en fonction de l’architecture du mat´eriel utilis´e pour son impl´ementation. Signalons toutefois que du fait de sa description param´etrable, le changement de configuration du syst`eme reconfigurable d´ecrit n’implique que des modifications mineures par rapport a` la description existante. Ainsi, le syst`eme propos´e peut ˆetre adapt´e a` un mat´eriel autre que celui que nous allons pr´esenter ici.

Dans ce qui va suivre nous allons pr´esenter une configuration particuli`ere de notre syst`eme reconfigurable, adapt´ee a` une carte existante et destin´ee a` la conception des syst`emes recon- figurables en g´en´eral. Il s’agit de la carte Alpha Data ADP-WRC-II, d´ej`a mentionn´ee dans la Section 4.1. L’avantage de cette carte, outre le fait qu’elle peut accueillir un circuit FPGA de haute densit´e, est qu’elle dispose de deux m´emoires DDR-SDRAM, addressables de fa¸con ind´ependante et d’une largeur de 256 bits. Une telle architecture permet donc d’arriver a` de tr`es hauts d´ebits de transfert de donn´ees entre le circuit FPGA et les deux m´emoires.

Au sommet de la hi´erarchie du syst`eme reconfigurable complet on trouve n modules de traite- ment identiques. Chaque module poss`ede une m´emoire source locale permettant la sauvegarde d’une fenˆetre a` traiter de Fx Vy pixels. A cette m´emoire sont associ´es F˜x unit´es de traite- × ment et une m´emoire destination locale permettant la sauvegarde de F˜x pixels trait´es. Chaque module re¸coit un flux de donn´ees a` travers un bus de 8 bits (DataIn). Les donn´ees trait´ees apparaissent sur un autre bus, lui aussi d’une largeur de 8 bits (DataOut).

La m´emoire source locale, les unit´es de traitement et la m´emoire destination locale fonc- tionnent en pipe-line. Ainsi, pour chaque nouveau chargement d’une ligne de la fenˆetre a` traiter de Fx pixels, le syst`eme sort en mˆeme temps la fenˆetre trait´ee, en fait une ligne de F˜x pixels.

Le nombre de modules de traitement a` r´ealiser au sein d’un mˆeme circuit FPGA sera limit´e par la largeur du bus de donn´ees sur lequel est plac´e le syst`eme reconfigurable d’une part et par les ressources logiques n´ecessaires pour la r´ealisation de chaque module d’autre part.

Pour l’exemple de la carte consid´er´ee, les deux bus de donn´ees ´etant de 256 bits, nous pouvons donc r´ealiser au maximum 32 modules de traitement. En ce qui concerne la quantit´e exacte des ressources logiques n´ecessaires pour la r´ealisation d’un module complet, elle sera d´etermin´ee apr`es son impl´ementation. N´eanmoins sur base de l’information de la quantit´e des ressources logiques disponibles dans le FPGA, nous pouvons d´eduire la quantit´e des ressources qu’il serait possible d’allouer pour un seul module de traitement. En prenant le FPGA le plus dense, le circuit xc2v8000 (46.592 tranches) et une occupation de ressources de l’ordre de 80 %, on arrive a` un chiffre de 1200 tranches par module de traitement. Comme les unit´es de traitement bas´ees sur l’algorithme Max/Min et celui de Danielsson peuvent travailler

163 Chapitre 4. Architecture reconfigurable sur des fenˆetres de taille plus petite que celle bas´ee sur l’algorithme par ´elimination10, tout un pr´eservant le haut d´ebit de traitement, ce sont elles qui vont ˆetre retenues pour cette impl´ementation particuli`ere.

L’image a` traiter est sauvegard´ee dans la m´emoire source globale (une m´emoire physique de la carte) et d´ecoup´ee en 32 bandes de largeur fixe. A chaque bande est associ´e un module de traitement. Les bandes pr´esentent un recouvrement de Vx 1 pixels permettant de calculer − les pixels au bord de la bande. Une adresse de la m´emoire source correspond donc a` 32 pixels, chacun appartenant a` l’une de 32 bandes de l’image.

Chaque bande est a` son tour d´ecoup´ee en fenˆetres de traitement qui, elles aussi, repr´esentent un recouvrement de Vx 1 pixels. Pour l’image trait´ee nous avons une situation semblable, le − premier pixel de l’image r´esultat est sauv´e a` une distance de Vx1 pixels par rapport au bord 11 gauche de l’image et a` une distance de Vy1 pixels par rapport au bord sup´erieure de l’image .

La Figure 4.17 montre le principe de la sauvegarde de l’image a` traiter dans la m´emoire source globale (M´em.1), le d´ecoupage de l’image en bandes, l’association de diff´erents modules de traitement pour chaque bande et l’´ecriture des bandes trait´ees dans la m´emoire destination globale (M´em.2).

Une telle fa¸con de lire les donn´ees dans la m´emoire globale source peut ˆetre r´ealis´ee au stade de l’´ecriture de l’image a` traiter, ou lors de sa lecture pour le traitement. Signalons que d’autres sch´emas de lecture/´ecriture de donn´ees depuis la m´emoire globale sont ´egalement possibles, notre choix s’est port´e sur celui-ci car il permet de maximiser le nombre de pixels trait´es pour l’architecture adopt´ee du syst`eme reconfigurable complet (lecture pixel par pixel, et ligne par ligne d’une bande de l’image).

4.4.2 Impl´ementation d’un module de traitement

La description formelle d’un module de traitement est assez directe : il suffit de cr´eer un certain nombre d’instances des diff´erentes parties constitutives du syst`eme reconfigurable. Pour d´eterminer le nombre d’instances, a` savoir le nombre de registres de la m´emoire locale source, le nombre d’unit´es de traitement correspondant et le nombre de registres de la m´emoire locale destination, il faut fixer la taille de la fenˆetre de traitement.

Pour ce qui est de la taille verticale de la fenˆetre, lorsque la lecture des donn´ees de l’image (en fait de la bande) est faite pixel par pixel, et ligne par ligne, nous avons montr´e que le fonctionnement de pipe-line de traitement est optimal lorsque Fy = Vy (voir Section 4.2). Par

10Dans le cas d’une unit´e de traitement bas´ee sur l’algorithme par ´elimination, pour pr´eserver le d´ebit des pixels trait´es (`a chaque cycle d’horloge nous avons un pixel entrant et un pixel sortant du syst`eme) il faut avoir une fenˆetre de traitement suffisamment large. En effet, comme nous l’avons remarqu´e dans la Section 4.2, Fx = r ∗ n, ou r indique la valeur du rang et n le nombre de pas de calcul. Si la densit´e des FPGAs actuels nous permet d’imaginer une impl´ementation des modules de traitement bas´e sur l’algorithme par ´elimination travaillant sur des fenˆetres tr`es larges, c’est le nombre de modules qui sera fortement limit´e. 11En fait les pixels au bord de l’image ne sont pas calcul´es. L’image r´esultat pr´esente un bord d’une ´epaisseur de Vx1, Vx2, Vy1 et Vy2 pixels, ces derniers correspondant aux distances entre le pixel central de voisinage et le bord de celui-ci. Pour des voisinages envisag´es, ce bord a une ´epaisseur de 1, 2 et 3 pixels respectivement.

164 4.4. Syst`eme reconfigurable complet

Image à traiter Bande1 Bande 2 Bande 32

Mém.1

8 8 8 DataIn=32*8=256

Module 1 Module 2 Module 32

FPGA

8 8 8 DataOut=32*8=256 Vx1 Vy1

Mém.2 Image traitée

Fig. 4.17: Syst`eme reconfigurable complet : 32 modules de traitement. contre la taille horizontale de la fenˆetre sera d´etermin´ee de fa¸con a` maximiser le nombre de pixels trait´es.

La taille horizontale de la fenˆetre d´ependra du nombre de pas de calcul : il faut que le nombre de pixels charg´es soit au moins ´egal au nombre de pas de calcul a` effectuer. Lorsqu’il y a une ´egalit´e, nous avons alors un parfait ´equilibre entre le chargement des donn´ees a` traiter, le calcul sur ces donn´ees et la sauvegarde des r´esultats (il n’y aura pas d’attente ni du cˆot´e des unit´es de traitement ni du cˆot´e de la m´emoire).

Cependant le nombre de pas de calcul n’est pas l’unique facteur qui aura une influence sur le choix de la taille horizontale de la fenˆetre. Le deuxi`eme facteur qui jouera un rˆole important dans le choix de Fx est li´e a` l’effet de bord li´e au calcul dans une fenˆetre. En sachant que pour chaque nouvelle ligne de la fenˆetre, donc pour Fx pixels a` l’entr´ee, nous n’avons pas Fx pixels de r´esultat mais bien F˜x, car il existe une perte. En outre, pour d´eterminer le temps total de traitement, nous devons nous baser sur la quantit´e de pixels sortants (en fait ceux qui sont effectivement calcul´es) et non sur la quantit´e des pixels entrants, a` cause de l’effet de bord.

La perte de performance du syst`eme reconfigurable due a` l’effet de bord (redondance en lecture de donn´ees) peut ˆetre quantifi´ee a` travers un facteur de rendement du syst`eme reconfigurable,

165 Chapitre 4. Architecture reconfigurable not´e η. Nous allons d´efinir ce facteur comme un rapport entre le nombre de pixels effectivement calcul´es et le nombre de pixels qu’il faut charger dans la m´emoire locale. Dans le cas d’un d´eplacement ligne par ligne dans la bande et lorsque Fy = Vy nous avons :

F˜x Fx (Vx 1) η = = − − , Fx Vx (4.32) Fx Fx ≥

A partir de l’´equation 4.32, on voit que pour minimiser la perte due a` l’effet de bord (i.e. maximiser le rendement du syst`eme) nous avons int´erˆet de prendre Fx le plus grand possible. Pour se donner une id´ee de la valeur du rendement, la Figure 4.18 montre son ´evolution en fonction de la taille de la fenˆetre Fx et pour diff´erentes tailles envisag´ees de voisinages.

1

0.9

0.8

0.7 Vx=3 η Vx=5 0.6 Vx=7

0.5

0.4

0 5 10 15 20 25 30 35 Fx [pixels]

Fig. 4.18: Rendement d’un module de traitement caract´erisant la perte de performance li´ee au calcul dans une fenˆetre de taille proche de la taille de voisinage.

La taille horizontale de la fenˆetre sera fix´ee donc de fa¸con a` minimiser la perte due a` l’effet de bord d’une part et a` maximiser le nombre de modules de traitement r´ealisables au sein du FPGA d’autre part. En outre, on choisira Fx de fa¸con a` ce que 32 modules de traitement puissent ˆetre int´egr´es dans un seul FPGA de haute densit´e.

Ici il convient de pr´eciser que la diminution de la vitesse de fonctionnement d’un module de traitement due a` l’augmentation du nombre d’unit´es de traitement, pour les ordres de gran- deurs de Fx envisag´es, n’est pas significative. Ainsi l’impl´ementation d’un module Max/Min pour le traitement sur un voisinage de 3 3 pixels lorsque la taille horizontale de la fenˆetre × passe de 10 a` 20 pixels a montr´e une mˆeme vitesse de fonctionnement du module.

En fixant la taille de la fenˆetre nous pouvons ensuite d´eduire tous les param`etres de la des- cription du module n´ecessaires a` son impl´ementation.

Dans ce qui va suivre nous nous contenterons de montrer les r´esultats de la simulation pour un seul module de traitement, pour un voisinage de taille 3 3 pixels et pour une largeur de × fenˆetre de 10 pixels.

166 4.4. Syst`eme reconfigurable complet

Pour la simulation du fonctionnement des diff´erents modules nous utiliserons une fenˆetre dont les valeurs de pixels varient de 1 a` Fx Fy, apr`es quoi la derni`ere valeur est maintenue jusqu’`a ∗ la fin de la simulation. Un cycle de simulation comprendra le traitement de trois fenˆetres successives.

Le choix des valeurs de pixels a` traiter a ´et´e fait tout simplement pour la facilit´e que repr´esente la sp´ecification d’un tel stimulus a` l’entr´ee d’un module et la simplicit´e avec laquelle on peut interpr´eter les r´esultats obtenus (voir Figure 4.19). En effet, dans une premi`ere fenˆetre de 10 3 pixels, les valeurs maximales des 8 voisinages correspondront a` des valeurs allant de 23 × a` 30 (`a la Figure 4.19 les valeurs entour´ees d’un cercle de fond blanc), tandis que les valeurs m´edianes seront de 12 a` 19 (les valeurs entour´ees d’un carr´e de fond blanc). Pour le filtre Max, tous les pixels des deux fenˆetres suivantes trait´ees auront la valeur de 30 (les valeurs entour´ees d’un cercle gris clair et gris fonc´e). Pour le filtre m´edian, les valeurs de la deuxi`eme fenˆetre iront de 22 a` 29 (les valeurs entour´ees d’un carr´e de fond gris clair), tandis que pour la troisi`eme nous aurons 30 partout (les valeurs entour´ees d’un carr´e de fond gris fonc´e).

30 30 30 30 30 30 30 30 30 30

30 30 30 30 30 30 30 30 30 30 F3

30 29 28 27 26 25 24 23 22 21 F2

20 19 18 17 16 15 14 13 12 11 F1 10 9 8 7 6 5 4 3 2 1

Fig. 4.19: Les valeurs des pixels pour le traitement des trois fenˆetres successives et le valeurs Max et m´edianes pour les diff´erentes voisinages.

La Figure 4.20 a) montre le chronogramme de fonctionnement (g´en´er´e par le logiciel de simu- lation) d’un seul module dont l’unit´e de traitement est bas´ee sur l’algorithme Max/Min (en l’occurrence il s’agit d’un filtre Max). Apr`es la phase de chargement de la m´emoire source lo- cale avec les valeurs de la premi`ere fenˆetre a` traiter (mis en route du pipe-line de traitement), les 8 premiers pixels sortants ont bien la valeur maximale des diff´erents voisinages, ainsi que les pixels r´esultats pour les deux fenˆetres suivantes (F2 et F3).

La Figure 4.20 b) montre le chronogramme de fonctionnement d’un seul module fonctionnant selon l’algorithme de Danielsson, utilis´e pour la recherche de la valeur m´ediane. On remarque sur le bus de donn´ees de sortie que les 8 premi`eres valeurs sont effectivement les valeurs m´edianes pour les trois fenˆetres consid´er´ees.

Les r´esultats d’impl´ementation des deux modules de traitement, pour le circuit FPGA xc2v2000- 6 sont indiqu´es dans le Tableau 4.8. Le choix de la largeur de la fenˆetre Fx a ´et´e fait de fa¸con a` ce que un module de traitement ne d´epasse pas 1200 tranches de circuit FPGA12.

12Le choix de limiter un module a` 1200 tranches a ´et´e fait de fa¸con a` ce que les 32 modules r´ealis´es dans le FPGA le plus dense, le circuit xc2v8000-5, ne d´epasse pas 80% des ressources disponibles.

167 Chapitre 4. Architecture reconfigurable 0 0 2 2 1 1 0 0 6 6 3 3 F F ~ ~ 0 0 3 3 6 0 2 11 1 8 0 5 6 9 2 8 2 7 2 3 2 3 2 6 F F F 2 F ~ ~ 5 2 4 2 3 2 0 22 3 0 6 2 7 1 8 0 3 6 9 0 1 3 8 9 1 2 7 8 1 2 x 2 1 x 2 1 -1) -1) x F x F 6 7 F F 1 F 2 F ~ ~ 5 -(V 6 -(V 1 2 x x F F 4 5 1 2 3 4 1 2 2 3 1 2 0 0 3 3 9 9 2 2 8 8 2 2 7 7 2 2 6 6 2 2 1 1 5 5 2 2 F F 4 4 2 2 3 3 2 2 22 22 1 1 2 2 0 0 2 2 9 9 1 1 8 8 1 1 7 7 1 1 6 6 1 1 5 5 1 1 4 4 1 1 3 3 1 1 2 2 1 1 11 11 0 0 1 1 9 9 8 8 7 7 6 6 5 5 4 4 3 3 2 2 1 1 t t t x i in t t t u x clk ini in i u o Ou clk ini _ o i Ou ata _ i ata d ata d ftMatr ata d i d ftMatr i Sh CopyLineIn Sh CopyLineIn CopyLine CopyLine ) a) b Fig. 4.20: Chronogrammes de fonctionnement des trois modules de trai- tement obtenus par simulation pour un voisinage de taille 3 3 pixels. × 168 4.4. Syst`eme reconfigurable complet

Pour les diff´erents modules et les voisinages ce tableau indique : – la taille de la fenˆetre et le nombre d’unit´es de traitement correspondantes (Fx et NUT ), – la quantit´e de ressources logiques utilis´ees par module - Qr, exprim´ee en nombre de tranches, – la fr´equence maximale de fonctionnement du circuit - FClk, – le temps n´ecessaire pour le placement et le routage - tpar.

La deuxi`eme partie du tableau indique les r´esultats d’impl´ementation obtenus sous contraintes fortes.

r Module V Fx NUT Q FClk [MHz] tpar [sec] FClk [MHz] tpar [sec]

3 × 3 20 18 664 111 47 180 72 Max/Min 5 × 5 16 12 865 116 59 169 122 7 × 7 14 8 1000 87 65 141 101

3 × 3 20 18 864 89 60 101 116 Danielsson 5 × 5 16 14 1121 51 70 72 217 7 × 7 14 8 1164 50 109 56 341

Tab. 4.8: R´esultats de l’impl´ementation d’un seul module de traitement (algorithmes Max/Min et Danielsson) pour les trois tailles de voisi- nages envisag´ees. Circuit FPGA : xc2v2000-6.

Les r´esultats de l’impl´ementation d’un seul module de traitement nous permettent de faire les deux remarques suivantes : 1. La quantit´e des ressources logiques n´ecessaires a` la r´ealisation d’un module complet est telle que l’on peut envisager de travailler avec les fenˆetres suffisamment larges, permet- tant de minimiser le facteur de perte li´e au calcul dans le voisinage. 2. La vitesse de fonctionnement d’un module reste ´elev´ee, malgr´e la multiplication des unit´es de traitement n´ecessaires au calcul simultan´e dans une fenˆetre.

4.4.3 Etablissen´ t d’une correspondance entre ressources n´ecessaires et res- sources disponibles

La quantit´e de ressources logiques n´ecessaires a` la r´ealisation d’un seul module nous permet d’estimer la quantit´e de ressources logiques n´ecessaires a` un syst`eme reconfigurable complet compos´e de 32 modules de traitement. Ces chiffres peuvent ensuite ˆetre mis en correspondance avec la quantit´e de ressources logiques disponibles dans des circuits FPGAs de haute densit´e.

Le graphique de la Figure 4.21 indique la quantit´e estim´ee de ressources logiques n´ecessaires a` l’impl´ementation de 32 modules diff´erents, pour les deux types de modules et pour les trois tailles des voisinages envisag´es. En ordonn´ee, on indique ´egalement la quantit´e des res- sources logiques disponible pour les deux circuits FPGAs Xilinx de haute densit´e : xc2v6000 et xc2v8000 (respectivement 33.792 et 46.592 tranches).

169 Chapitre 4. Architecture reconfigurable

XC2V8000 45000

40000

35000 XC2V6000

30000

25000 Voisinage r Q 3x3 20000 5x5 7x7

15000

10000

5000

0 MaxMin Danielsson Module de traitement

Fig. 4.21: Estimation de la quantit´e de ressources logiques n´ecessaires a` l’impl´ementation de 32 modules de traitement.

Nous pouvons constater que pour la r´ealisation de 32 modules de traitement travaillant sur une fenˆetre dont la largeur permet de maximiser le nombre de pixels trait´es, l’impl´ementation du syst`eme reconfigurable complet peut ˆetre faite a` l’aide d’un circuit FPGA xc2v8000.

4.4.4 Impl´ementation du syst`eme complet

Partant de la description d’un seul module, la description du syst`eme complet revient a` l’instantiation de 32 modules de traitement identiques.

Le Tableau 4.9 indique les r´esultats de l’impl´ementation obtenus pour un syst`eme recon- figurable complet, pour les deux strat´egies d’impl´ementation diff´erentes et pour le circuit FPGA xc2v8000-5. Pour la quantit´e de ressources logiques utilis´ees (exprim´ee en nombre de tranches), le chiffre entre parenth`eses indique le pourcentage de l’occupation du FPGA, qui a ´et´e volontairement limit´e a` un maximum de 80 %.

De telles vitesses de fonctionnement du syst`eme reconfigurable complet impliquent la mˆeme performance pour la m´emoire globale source et pour la m´emoire globale destination. Comme cela a ´et´e montr´e dans [Gop04], une m´emoire DDRAM peut ˆetre contrˆol´ee avec un circuit FPGA a` une fr´equence de 200MHz, ce qui est largement au dessus de ce qui est requis par le syst`eme reconfigurable.

170 4.4. Syst`eme reconfigurable complet

r Syst`eme V Fx NUT Q FClk [MHz] tpar [min] FClk [MHz] tpar [min]

3 × 3 20 576 21.318 (45 %) 101 16 115 61 Max/Min 5 × 5 16 384 27.935 (59 %) 90 30 115 100 7 × 7 14 256 32.292 (69 %) 77 41 92 140 3 × 3 20 576 27.209 (58 %) 63.7 22 83 245 Danielsson 5 × 5 16 384 36.013 (77 %) 43.5 27 58 190 7 × 7 14 256 37.638 (80 %) 36 53 45 180

Tab. 4.9: R´esultats de l’impl´ementation du syst`eme reconfigurable com- plet pour les trois tailles de voisinages envisag´es. Circuit FPGA : xc2v8000. 4.4.5 D´ebit des pixels trait´es

Sur base de l’architecture adopt´ee pour le syst`eme reconfigurable complet, sur base de l’information de la vitesse de fonctionnement maximale (un pixel de r´esultat est calcul´e a` chaque cycle d’horloge) et du rendement du syst`eme reconfigurable complet, nous pouvons calculer le d´ebit que le syst`eme propos´e pourrait atteindre lors d’une impl´ementation physique selon l’expression suivante :

D = 32 η FClk [P x/sec] (4.33) × ×

Dans les deux cas extrˆemes de filtre de rang : le calcul d’un filtre Max/Min et le calcul d’un filtre m´edian, le Tableau 4.10 indique les d´ebits de traitement du syst`eme reconfigurable complet, exprim´es en millions de pixels trait´es par seconde, calcul´es selon l’expression 4.33 pour diff´erentes tailles envisag´ees des voisinages. Les r´esultats pr´esent´es sont bas´es sur des fr´equences de fonctionnement indiqu´ees dans le Tableau 4.9 et major´ees d’un facteur de s´ecurit´e de 80 %.

D´ebit de pixels trait´es [MPx/sec] Voisinage 3 3, η = 0.9 5 5, η = 0.8 7 7, η = 0.7 × × × Max/Min 2650 2355 1649 M´edian 1912 1188 806

Tab. 4.10: D´ebits de traitement pour un syst`eme reconfigurable complet compos´e de 32 modules de traitement.

171 Chapitre 4. Architecture reconfigurable

4.5 Conclusion

Dans ce chapitre nous avons d´ecrit une architecture d´edicac´ee reconfigurable bas´ee sur des circuits FPGAs de haute densit´e permettant de calculer diff´erents filtres de rang en mode bit-s´erie, pour des voisinages de taille et de forme param´etrables.

Dans un premier temps nous avons montr´e un algorithme simple, permettant de calculer les filtres Max/Min. L’impl´ementation d’une unit´e de traitement bas´ee sur cet algorithme s’av`ere particuli`erement int´eressante tant au niveau de la quantit´e des ressources logiques n´ecessaires a` sa r´ealisation qu’au niveau de sa grande vitesse de fonctionnement, mˆeme avec des voisinages de grande taille.

Nous avons ensuite montr´e qu’il est possible d’arriver a` un filtre de rang g´en´eralis´e, en partant de l’algorithme Max/Min et en ´eliminant successivement les maxima/minima locaux dans le voisinage. Cependant l’unit´e de traitement correspondante pr´esente un inconv´enient majeur : la grande quantit´e de ressources logiques n´ecessaires lorsque l’on souhaite pr´eserver un haut d´ebit de traitement. Si pour des voisinages de petite taille et pour des petites valeurs de rang cette m´ethode reste int´eressante, tr`es vite on arrive a` la limite des ressources logiques disponibles, mˆeme pour un FPGA de haute densit´e.

Afin d’am´eliorer la performance du syst`eme reconfigurable pour la recherche de la valeur du rang proche du m´edian et surtout lorsque la taille du voisinage augmente, nous avons utilis´e l’algorithme de Danielsson. Cet algorithme, connu depuis 1981, a ´et´e souvent utilis´e pour l’impl´ementation des filtres m´edians 2D. Cependant les impl´ementations propos´ees visaient principalement le voisinage de 3 3 pixels, pour lequel cet algorithme peut ˆetre fortement sim- × plifi´e. Ici, nous avons pr´esent´e l’impl´ementation de cet algorithme dans sa forme g´en´eralis´ee, permettant donc de calculer le filtre de n’importe quel rang pour n’importe quelle taille de voisinage. En introduisant un fonctionnement de type pipe-line entre une m´emoire sp´ecifique des op´erandes contenant les donn´ees a` traiter, une matrice (plutˆot un vecteur) d’unit´es de traitement et une m´emoire pour les r´esultats nous avons pu d´efinir la notion de module de traitement. Un tel module est capable de calculer pour chaque nouvelle nouvelle ligne de la fenˆetre a` l’entr´ee, une ligne des pixels filtr´es, au facteur de perte prˆet.

Du fait de la faible quantit´e de ressources logiques n´ecessaires a` l’impl´ementation d’un seul module de traitement au regard de la quantit´e de ressources logiques disponibles dans un circuit FPGA de haute densit´e, nous avons pu montrer qu’une parall´elisation massive est donc possible. En effet, le nombre d’unit´es de traitement travaillant en parall`ele est de l’ordre de la centaine.

Le syst`eme reconfigurable pr´esent´e peut ˆetre facilement int´egr´e dans une solution mat´erielle disponible actuellement et permettant la conception de syst`emes reconfigurables a` l’aide des FPGAs de haute densit´e. Pour un exemple concret d’une telle solution, la carte Alpha Data ADP-WRC-II, nous avons pu quantifier les d´ebits de traitement maximaux qu’il serait possible d’obtenir si l’on impl´ementait vraiment les circuits d´ecrits. Pour les deux cas extrˆemes de filtres de rang : le filtre Max/Min et le filtre m´edian et pour des voisinages de 3 3, 5 5 et 7 7 × × × pixels, nous avons montr´e que le d´ebit des pixels trait´es pourrait atteindre 2649, 2355 et 1380 [MPx/sec] pour un filtre Max/Min et 1450, 880 et 645 [MPx/sec] pour un filtre m´edian.

172 Chapitre 5

Discussion et conclusion

5.1 Probl`eme, motivation et int´erˆet

Dans le cadre de ce travail nous avons trait´e le probl`eme de l’acc´el´eration des filtres de rang, souvent utilis´es dans le traitement des images num´eriques. Ces filtres constituent un outil permettant d’effectuer des traitements sur des images avec des buts divers : l’´elimination de bruit impulsionnel, les transformations morphologiques etc.

Une chaˆıne de traitement des images num´eriques est constitu´ee de plusieurs traitements a` effectuer l’un apr`es l’autre. L’utilisation des filtres de rang est g´en´eralement li´ee a` la phase de pr´e-traitement, donc tout en amont de la chaˆıne, juste apr`es l’´etape de l’acquisition.

Le plus faible temps d’ex´ecution possible est donc souhaitable de fa¸con a` ce que d’autres traitements, ou une analyse d’image plus complexe, soient toujours r´ealisables en temps r´eel.

Ici, il convient de pr´eciser que la notion du temps r´eel d´ependra de l’application vis´ee. Dans l’imagerie num´erique par temps r´eel le plus souvent on sous entend une cadence de l’ordre de 25 images par seconde, li´ee traditionnellement par le cin´ema et la vid´eo a` la vision humaine.

Ce chiffre est cependant loin d’ˆetre le mˆeme pour toutes les applications possibles de l’imagerie num´erique. Ainsi, lorsque on parle du contrˆole de qualit´e en milieux industriels par exemple, le nombre d’images acquises par seconde sera d´etermin´e en fonction de la nature du processus a` contrˆoler et la vitesse maximale avec laquelle on peut acqu´erir des telles images.

Des cam´eras num´eriques actuelles sont capables d’acqu´erir des images a` tr`es haute r´esolution et a` une tr`es grande vitesse. Elles peuvent donc ˆetre utilis´ees dans des processus de traitement beaucoup plus rapides que ceux de 25 images par seconde. Dans ce cas une importante quantit´e de donn´ees est g´en´er´ee en tr`es peu de temps, imposant des tr`es courtes fenˆetres de temps, pour un traitement des images en continu.

Pour de telles applications, le temps d’ex´ecution de filtres de rang peut s’av´erer contraignant et ceci principalement a` cause de l’op´eration de tri.

Pour un filtre de rang, cette op´eration est a` faire :

173 Chapitre 5. Discussion et conclusion

1. Sur des vecteurs (voisinages) dont la taille est de l’ordre des quelques dizaines d’´el´ements (pixels). 2. Pour tout pixel de l’image a` traiter dont la taille est de l’ordre d’un million de pixels. Mˆeme si nous disposons aujourd’hui d’algorithmes de tri efficaces, le nombre d’op´erations a` effectuer par une architecture informatique classique est tellement grand que les temps de traitement deviennent inacceptables dans le cas des applications annonc´ees et surtout lorsque la taille de voisinage et/ou la taille de l’image augmentent.

L’acc´el´eration de ce type de traitement particulier voit alors tout son int´erˆet.

Par ce travail nous avons apport´e des solutions au probl`eme d’acc´el´eration de temps de calcul des filtres de rangs. Ces solutions visent l’impl´ementation de ces filtres sur deux architectures informatiques diff´erentes : l’architecture universelle et l’architecture d´edicac´ee reconfigurable.

5.2 Impl´ementation sur l’architecture universelle

Dans le Chapitre 2 nous avons pr´esent´e l’impl´ementation des filtres de rang sur un or- dinateur personnel d’une configuration actuelle, bas´e sur un micro-processeur d’architecture Pentium 4. Un tel choix est justifi´e par le fait que ces ordinateurs pr´esentent une importante puissance de calcul grˆace a` la haute vitesse de fonctionnement des micro-processeurs et de la m´emoire, aux diff´erentes manifestations de parall´elisme (notamment le parall´elisme d’ins- tructions, de donn´ees et dans certain cas le parall´elisme inter-processeur), sans parler d’une mise en ”grappe“ (cluster) de plusieurs ordinateurs.

De tels syst`emes sont de plus en plus utilis´es pour le calcul des probl`emes complexes dans des temps acceptables, mettant a` l’´ecart des solutions traditionnelles beaucoup plus on´ereuses telles que stations de travail ou encore super-ordinateurs.

Cependant l’exploitation de toutes les possibilit´es offertes par les ordinateurs personnels d’au- jourd’hui pr´esente un inconv´enient majeur : elle n’est pas automatique en ce sens que les compilateurs ne sont pas encore capables d’extraire le parall´elisme a` partir d’un code ´ecrit dans un langage de programmation ´evolu´e, tel que C ou C++.

Cette constatation implique que de telles architectures peuvent ˆetre abord´ees de deux fa¸con diff´erentes : 1. On ne consid`ere un probl`eme qu’`a travers le choix (et/ou la conception) d’algorithmes et de leur codage a` l’aide d’un langage de programmation ´evolu´e. Dans ce processus on fait l’abstraction compl`ete de l’architecture du processeur et du mat´eriel sous-jacent (c’est d’ailleurs la raison d’ˆetre des langages de programmation ´evolu´es).

2. La conception et l’impl´ementation des algorithmes tient compte de l’architecture du mat´eriel cible. Dans le cas d’un ordinateur personnel ce seront : (a) L’exploitation des diff´erents niveaux de parall´elisme, notamment celui de donn´ees (le fonctionnement en mode SIMD du micro-processeur).

174 5.3. Impl´ementation sur des architectures d´edicac´ees reconfigurables

(b) La conception d’algorithmes en fonction du couplage entre le micro-processeur et la m´emoire (les aspects li´es a` la lecture des donn´ees). (c) L’application des diff´erentes techniques de programmation avanc´ees, n´ecessaires pour une impl´ementation efficace des algorithmes d´ecrits (optimisation du codage d’algorithmes).

Avec les impl´ementations des filtres de rang dans une architecture universelle de deux fa¸con diff´erentes d´ecrites, nous avons montr´e que :

1. Lorsque l’impl´ementation des filtres de rang tient compte de l’architecture de l’ordinateur cibl´e, des facteurs d’acc´el´eration de l’ordre de 10 peuvent ˆetre obtenus par rapport a` une approche du probl`eme purement algorith- mique (le d´ebit des pixels trait´es passe de quelques m´ega pixels par seconde a` quelques dizaines de m´ega pixels par seconde).

2. Mˆeme si l’on tient compte de parall´elisme de l’architecture universelle, lorsque la taille de voisinage augmente et la valeur de rang recherch´e ap- proche la m´ediane, l’affaiblissement de la performance est in´evitable.

3. Dans une architecture universelle, quelque soit le type d’algorithme utilis´e, nous sommes toujours limit´e par : l’acc`es inad´equat aux donn´ees de l’image par le biais de la m´emoire centrale, le faible nombre de registres internes (m´emoire des op´erandes) et un faible degr´e de calcul concurrent (faible parall´elisation).

5.3 Impl´ementation sur des architectures d´edicac´ees reconfi- gurables

Si l’on veut encore acc´el´erer le temps de traitement, nous sommes oblig´es de faire appel a` des solutions mat´erielles d´edicac´ees, bas´ees sur des circuits ASIC ou FPGA.

Dans le Chapitre 3 nous avons fait un tour d’horizon des diff´erents algorithmes qui peuvent ˆetre utilis´es pour le calcul de filtres de rang avec des syst`emes d´edicac´es. Nous avons ´egalement pr´esent´e quelques impl´ementations des syst`emes de traitement correspondants.

Le parcours des syst`emes d´edicac´es existants a permis de d´egager deux conclusions impor- tantes : 1. La plupart des solutions propos´ees jusqu’`a pr´esent se limitent au calcul dans un voisinage de 3 3 pixels. × (a) Or dans les traitements des images num´eriques envisag´es habituellement il est sou- vent n´ecessaire (voire indispensable) de param´etrer la taille et la forme de voisinage de fa¸con a` adapter le filtre au mieux a` l’application vis´ee.

175 Chapitre 5. Discussion et conclusion

2. Les impl´ementations existantes se contentent de l’impl´ementation d’une seule unit´e de traitement. (b) Or, les avanc´es technologiques li´ees a` l’int´egration des circuits int´egr´es de plus en plus denses impliquent que les FPGAs actuels sont caract´eris´es par une importante quantit´e des ressources logiques, ce qui permet de traiter d’un grand nombre de variables.

En tenant compte des remarques (a) et (b), nous nous sommes fix´e pour objectif la conception d’un syst`eme d´edicac´e reconfigurable massivement parall`ele, bas´e sur des circuits FPGA et permettant de calculer les filtres de rang avec des voisinages dont la taille et la forme sont param´etrables.

Avec une impl´ementation originale des filtres de rang sur une architecture reconfigurable d´ecrite dans le Chapitre 4 nous avons montr´e que :

1. En utilisant les algorithmes fonctionnant en mode bit-s´erie on arrive a` des unit´es de traitement n´ecessitant une faible quantit´e des ressources logiques, caract´eris´ees par une grande vitesse de fonctionnement mˆeme lorsqu’il s’agit de travailler avec des voisinages de grande taille.

2. La faible quantit´e des ressources logiques n´ecessaire pour la r´ealisation d’une unit´e de traitement permet une parall´elisation massive au sein d’un FPGA de haute densit´e, tout en pr´eservant la haute vitesse de traitement.

3. La vitesse ´elev´ee de fonctionnement de l’unit´e de traitement et leur grande nombre, ainsi que le pipe-line de traitement : le chargement des pixels dans la m´emoire locale, la construction de plans de bits pour le traitement, le traitement mˆeme et la r´ecup´eration des r´esultats a` la sortie, r´esultent d’un d´ebit de traitement qui est de l’ordre de 1000 m´ega pixels par seconde.

Pour un exemple concret d’une carte existante permettant l’int´egration des syst`emes recon- figurables a` l’aide des FPGAs Xilinx de haute densit´e (la carte Alpha Data ADP-WRC-II), nous avons pu quantifier les d´ebits de traitement qu’il serait possible d’obtenir si le syst`eme d´ecrit avait vraiment impl´ement´e.

Le Tableau 5.1 mets en ´evidence la diff´erence de performance, exprim´e par le d´ebit des pixels trait´es (en MPx/sec) entre une architecture universelle bas´ee sur un processeur Pentium 4 et l’architecture reconfigurable propos´ee, pour les deux cas extrˆemes de filtre de rang : les filtres Max/Min et le filtre m´edian. Une telle diff´erence en performance s’explique :

1. Du fait d’un fonctionnement en mode bit-s´erie, le nombre de pas de calculs (BOPs) n´ecessaires au calcul de la valeur filtr´ee d’un voisinage est r´eduit au nombre de bits utilis´es pour coder la couleur du pixel, quelle que soit la taille du voisinage.

2. Dans le syst`eme reconfigurable d´ecrit nous disposons d’un acc`es aux donn´ees parfaite- ment adapt´e a` l’application envisag´ee. Tout d’abord l’acc`es a` la m´emoire centrale du

176 5.4. Am´eliorations possibles

D´ebit de pixels trait´es [MPx/sec]

V Universelle standard Universelle parall`ele Reconfigurable

D0 D1 D2

3 × 3 9 200 2650

Max/Min 5 × 5 5 154 2355

7 × 7 3.5 100 1649

3 × 3 3.3 125 1912

M´edian 5 × 5 2.3 42 1188

7 × 7 2.2 22 806

Tab. 5.1: Comparaison de performance d’un ordinateur personnel dot´e d’un processeur Pentium 4 (architecture universelle standard et pa- rall`ele) et de l’architecture d´edicac´ee reconfigurable propos´ee.

syst`eme via les bus de donn´ees larges et distincts pour l’image a` traiter et pour l’image trait´ee. Ensuite la grande taille de la m´emoire locale des op´erandes permet le calcul simultan´e des pixels successifs dans une fenˆetre de l’image quelque soit la taille du voi- sinage.

3. Du fait de la configuration de la m´emoire centrale et de la haute densit´e des circuits FPGAs, le syst`eme reconfigurable est massivement parall`ele et permet : (a) de minimiser la redondance en lecture des donn´ees n´ecessaires pour le calcul des fenˆetres successives dans un module de traitement d’une part, (b) et de maximiser le nombre de modules de traitement r´ealis´es dans un FPGA, d’autre part.

5.4 Am´eliorations possibles

Pour ce qui est de la performance des ordinateurs personnels bas´ees sur le micro-processeur Pentium 4, nous pensons que tr`es peu de place reste pour des am´eliorations significatives. A notre avis elles ne seront possibles qu’avec un changement substantiel de l’architecture actuelle de l’ordinateur personnel : aussi bien du cot´e de l’architecture du micro-processeur que de la m´emoire.

Nous pouvons ´egalement citer la voie alternative au calcul par le CPU qui est li´ee a` l’exploi- tation de la GPU (Graphics Processor Unit). Ces circuits, utilis´es pour le calcul et l’affichage rapide des images 3D, sont dot´es d’une importante puissance de calcul et sont de plus en plus utilis´es pour le calcul autre que la 3D, avec une performance d´efiant celle d’un processeur normal.

177 Chapitre 5. Discussion et conclusion

En ce qui concerne les am´eliorations du syst`eme reconfigurable elles serait possibles a` travers :

1. Optimisation de la description formelle des circuits pour chaque voisinage D`es le d´epart nous nous sommes efforc´e de faire une telle description formelle du syst`eme, que le changement de param`etres li´es a` la taille et la forme de voisinage soit ais´e (scala- bilit´e du probl`eme). Nous nous trouvons donc bien dans une logique qui met en opposi- tion : l’universalit´e de la description et sa performance. A notre avis, un important gain en performance pourrait ˆetre obtenu en consid´erant chaque voisinage s´epar´ement et en faisant une description formelle sp´ecifique a` chaque voisinage envisag´e. Dans ce cas et surtout lorsque la taille de voisinage augmente, une unit´e de traitement pourrait ˆetre d´ecoup´ee en un nombre plus important d’´etages de pipe-line, permettant d’augmenter le d´ebit de traitement.

2. Optimisation du processus d’impl´ementation Dans le processus d’impl´ementation nous nous sommes bas´e sur des r´esultats obte- nus par un processus d’impl´ementation automatis´e, mais n´eanmoins guid´e par des contraintes de performances impos´ees. Etan´ t donn´ee la simplicit´e des unit´es de trai- tement et la r´egularit´e avec laquelle elles se multiplient, ce sera int´eressant de r´ealiser le placement manuel pour une seule unit´e de traitement et ensuite utiliser ce motif de placement pour toutes les autres unit´es de traitement d’un syst`eme reconfigurable complet.

5.5 Conclusion finale

Les ordinateurs d’architecture universelle sont des machines polyvalentes permettant la r´esolution automatis´ee d’un grand nombre de probl`emes. Il s’agit de machines de structure complexe, pour lesquelles on souhaite pouvoir coder des algorithmes de fa¸con la plus simple possible. Pour y arriver, les ordinateurs d’aujourd’hui sont dot´e d’un grand nombre de couches superpos´ees permettent a` l’homme de faire l’abstraction de la complexit´e du mat´eriel et de ”communiquer“ avec elle dans un langage qui lui est proche.

Le prix a` payer, pour une universalit´e de l’application d’une mˆeme machine et pour une facilit´e de communication entre l’homme et cette machine, est li´e a` son rendement, variable en fonction de l’application qu’elle ex´ecute.

Dans le cas de traitement des images, ce rendement est particuli`erement faible, duˆ a` la quantit´e de donn´ees qui est en jeu et le calcul dans le voisinage qui lui est propre. Pour le calcul des filtres de rang (syst`eme a) de la Figure 5.1), le mauvais rendement se traduit par un d´ebit de pixels trait´es D0 de l’ordre de quelques m´ega pixels par seconde.

L’exploitation du parall´elisme des architectures universelles (syst`eme b) de la Figure 5.1) peut am´eliorer la performance du calcul des filtres non-lin´eaires. Dans ce cas le d´ebit des pixels trait´es D1 peut ˆetre augment´e d’un facteur de 10 par rapport au d´ebit D0.

Si une architecture universelle introduit la possibilit´e de calcul de probl`emes diff´erents sur une mˆeme machine, le paradigme de calcul reconfigurable grˆace aux circuits FPGAs introduit

178 5.5. Conclusion finale

Système Capteur de Utilisateur traitement

a) b) c)

Mém Mém Mém

UT UT

UAL UAL UAL

CPU CPU UT UT

FPGA Universelle standard Universelle parallèle Dédicacée reconfigurable D0 D1 D2

D2 ~- 10D1 ~- 100D0

Fig. 5.1: Impl´ementation des filtres de rang sur trois architectures diff´erentes. la notion de l’adaptation du mat´eriel au calcul du probl`eme. Cela se traduit par une grande libert´e des approches possibles et forcement le choix des meilleures.

Pour les applications en traitement des images num´eriques et plus particuli`erement pour le calcul des filtres de rang, l’approche reconfigurable en mode bit-s´erie permet de faire une parall´elisation plus ”naturelle“ du probl`eme pos´e. Un grand nombre d’unit´es de traitement qui op`erent sur des voisinages entiers, plutˆot que sur des pixels s´epar´ement, permet de minimiser le nombre d’op´erations a` effectuer pour chaque nouveau pixel a` calculer.

Dans le cadre de ce travail nous avons pu montrer qu’une telle approche (syst`eme c) de la Figure 5.1), ´etant donn´e la technologie actuelle, r´esulte en un meilleur rendement de la machine par rapport a` l’application donn´ee et une performance (d´ebit des pixels trait´es D2) 10 fois sup´erieure par rapport a` une architecture universelle parall`ele et 100 fois par rapport a` une architecture universelle standard.

179 Chapitre 5. Discussion et conclusion

180 Annexe A

Architecture universelle

A.1 Pr´esentation g´en´erale de l’application

Les diff´erents algorithmes d´ecrits dans le Chapitre 2 ont ´et´e cod´es et les proc´edures cor- respondantes int´egr´ees dans une application permettant d’´evaluer leur performance sur un ordinateur dot´e d’un processeur Intel - Pentium 4. L’interface graphique de l’application d´evelopp´ee (Figure A.1), hormis les fonctionnalit´es standards de manipulation des fichiers d’images accessibles depuis la barre d’outils classique, propose deux boites a` outils sous forme de deux fenˆetres ind´ependantes. Une premi`ere boite (fenˆetre S´equentiels, Figure A.1) est des- tin´ee a` l’ex´ecution des proc´edures bas´ees sur des algorithmes de filtre de rang g´en´eralis´e et des algorithmes d´edicac´es (cf. Section 2.2) qui exploitent l’architecture standard. Une autre boite a` outils (fenˆetre Extensions, Figure A.1) permet d’acc´eder aux proc´edures qui utilisent les diff´erentes extensions de l’architecture standard, i.e. le parall´elisme intra-processeur (cf. Section 2.3).

En ce qui concerne l’exploitation de parall´elisme inter-processeur, il est possible, grˆace au panneau de configuration (panneau Priorit´e, Figure A.1), d’ex´ecuter une proc´edure dans deux threads distincts. De plus, l’utilisateur peut affecter une valeur de priorit´e maximale pour le process et pour le thread ex´ecutant la proc´edure choisie (cf. Section A.3.2)1.

Pour l’ex´ecution d’une proc´edure l’utilisateur sp´ecifie un certain nombre de param`etres tels que la taille de voisinage, la valeur de rang recherch´e ou encore le nombre de fois que la mˆeme proc´edure sera appliqu´ee a` la mˆeme image (Filtre, Figure A.1). Les butons d´edicac´es permettent de choisir rapidement les valeurs des voisinages les plus couramment utilis´es : 3 3, 5 5, 7 7. De mˆeme, il est possible de sp´ecifier les valeurs typiques pour les rangs × × × (Min, Med, Max), dont la valeur num´erique est automatiquement calcul´ee en fonction de la taille de voisinage.

Une fenˆetre de texte est utilis´ee pour l’affichage des diverses informations concernant les ac- tions entreprises (panneau Info Figure A.1). Apr`es chaque traitement, les donn´ees li´ees a` la

1Par d´efaut tous les proc´edures sont ex´ecut´ees a` travers un seul thread et avec une priorit´e normale pour le process et le thread. Le changement de priorit´e n’affecte que le thread qui ex´ecutera la proc´edure choisi - les valeurs de priorit´e normale sont r´etablies d`es la fin d’ex´ecution de la proc´edure.

181 Annexe A. Architecture universelle proc´edure ex´ecut´ee sont affich´ees : le type de l’algorithme et la proc´edure correspondante, la taille de voisinage, la valeur de rang et le temps d’ex´ecution total. Egalemen´ t, lorsque une mˆeme proc´edure est ex´ecut´ee plusieurs fois les temps caract´eristiques : minimal, moyen et maximal sont affich´es ainsi que l’´ecart type des mesur´es effectu´ees. Les diff´erents informa- tions obtenues sont automatiquement sauvegard´ees dans un fichier texte pour une ´eventuelle utilisation post´erieure.

Afin d’automatiser le processus de test, l’utilisateur a la possibilit´e de choisir plusieurs proc´edures, voir toutes (panneau “Automation”, Figure A.1), et les ex´ecuter sur une mˆeme image, pour un ou tous les voisinages standard.

Dans la barre de menu classique on retrouve un menu suppl´ementaire (“Extras”) qui permet d’acc´eder aux fonctionnalit´es li´ees a` la comparaison des diff´erents niveaux de priorit´e(cf. Section A.3.2), les mesures de performance de la m´emoire et les proc´edures combin´ees (cf. Section A.4).

Fig. A.1: Interface de l’application

182 A.2. Mesure de temps d’ex´ecution d’une proc´edure

A.2 Mesure de temps d’ex´ecution d’une proc´edure

A.2.1 Diff´erentes m´ethodes de mesure de temps

La mesure de temps d’ex´ecution d’une proc´edure est habituellement faite a` l’aide de la fonction API WIN322 - GetTickCount(), qui renvoie le temps ´ecoul´e depuis la derni`ere mise en route de syst`eme d’exploitation. Deux appels a` cette fonction, avant et apr`es la proc´edure a` ´evaluer, nous donnent les temps dont la diff´erence repr´esente le temps d’ex´ecution. La r´esolution th´eorique de la fonction GetTickCount() est de l’ordre d’une milliseconde, mais en r´ealit´e une telle pr´ecision n’est jamais atteinte. Ainsi, pour les syst`emes d’exploitation Windows95 (ou 98) la pr´ecision r´eelle est de seulement 55ms et de 10 a` 15ms pour le Windows NT [Lou00]. Pour les temps d’ex´ecution des proc´edures envisag´ees, cette pr´ecision s’av`ere insuffisante.

Il est possible de mesurer des temps beaucoup plus petits en utilisant une autre fonction API - QueryPerformanceCounter(). Cette fonction permet d’acc´eder a` un compteur haute r´esolution3, incr´ement´e par une horloge sp´ecifique. La fr´equence d’incr´ementation de cette horloge varie d’un mat´eriel a` l’autre ; dans notre cas elle a ´et´e ´evalu´ee a` 3579545 Hz4, ce qui nous permet de mesurer des temps d’ex´ecution a` 0.3µs pr`es. Le coutˆ d’appel de cette fonction est cependant non n´egligeable : pour le syst`eme utilis´e il a ´et´e ´evalu´e a` 60µs.

Enfin signalons qu’il est possible d’effectuer des mesures de temps avec une pr´ecision en- core plus ´elev´ee, de l’ordre d’un cycle processeur. Ceci est possible grˆace a` un compteur des cycles effectifs ex´ecut´es par le processeur. L’acc`es a` ce compteur est assur´e par l’instruction assembleur RDTSC Read Time Stamp Counter dont l’utilisation est largement d´ecrite dans [Not97].

Mˆeme si l’emploi de l’instruction RDTSC offre des mesures de loin les plus pr´ecises, nous avons adopt´e le compteur haute r´esolution car sa pr´ecision est largement suffisante pour les mesures de temps des proc´edures envisag´ees.

A.2.2 Analyse des mesures pour les proc´edures types

Le temps d’ex´ecution d’une mˆeme proc´edure sur un mˆeme lot de donn´ees n’est pas constant et les variations de 10 a` 20 % entre les temps mesur´es sont courantes pour les syst`emes d’exploitation de famille Windows[Fom99]. Les origines de telles variations sont nombreuses et relatives a` la complexit´e du mat´eriel sous-jacent et de leur interaction avec le syst`eme d’exploitation. Tout d’abord nous nous trouvons dans un environnement multi-taches : le temps d’ex´ecution va donc d´ependre des autres taches en cours d’ex´ecution et de la politique

2Application Programming Interface - les fonctions de syst`eme d’exploitation accessibles par une application ext´erieure. 3Tous les ordinateurs personnels n’int`egrent pas ce compteur, un test de pr´esence avant son utilisation est donc indispensable. 4La valeur de la fr´equence d’incr´ementation de ce compteur est obtenue a` l’aide de la fonction API - QueryPerformanceFrequency().

183 Annexe A. Architecture universelle de leur ordonnancement5. Ensuite, l’ordonnancement des instructions se fait dans le d´esordre, donc il ne doit pas forcement ˆetre le mˆeme d’une ex´ecution a` l’autre.

Afin d’analyser le probl`eme de la mesure de temps d’ex´ecution quatre proc´edures type ont ´et´e retenues pour l’analyse : – deux exploitant l’architecture standard : tri a` bulle et tri rapide hybride not´ees Proc.1 et Proc.2 – deux exploitant le parall´elisme de donn´ees a` travers les extensions MMX et SSE2 not´ees Proc.3 et Proc.4 Ces quatre proc´edures ont ´et´e ex´ecut´ees 100 fois et les temps d’ex´ecution mesur´es ont ´et´e enregistr´es. Le choix de ces proc´edures particuli`eres a ´et´e guid´e par les diff´erents ordres de grandeurs de temps d’ex´ecution en jeu. Pour ´eviter l’influence d’autres threads en cours d’ex´ecution, la priorit´e de process et de thread ex´ecutant ces quatre proc´edures ont ´et´e fix´e a` leur plus grande valeur (le processeur ne change pas de contexte d’ex´ecution, il consacrera tout son temps a` l’ex´ecution de la proc´edure en question tant que celle-ci n’est termin´e).

Sur base des donn´ees enregistr´ees, pour chaque proc´edure type nous pr´esentons quatre gra- phiques suivantes : 1. Diagramme temporel des mesures - pour identifier des ´eventuelles anomalies des mesures (valeurs atypiques) 2. Diagramme de d´ecalage6 - pour v´erifier que les diff´erentes mesures de T ne sont pas autocorr´el´ees 3. Histogrammes7 - pour voir la distribution de T 4. Graphique des mesures ordonn´ees en fonction des quantiles de la distribution normale8 - pour v´erifier l’hypoth`ese sur la distribution, pr´esum´ee normale Egalemen´ t, chaque graphique est accompagn´e d’un tableau des valeurs de statistiques de position usuelles : le nombre de mesures n, les valeurs : minimum, m´edian, moyenne m, maximum et l’´ecart type s des mesures ainsi que l’intervalle de confiance calcul´e pour 95 %.

Pour les Proc. 1. et 2. (Figure A.2) les diagrammes temporels de mesures ne pr´esentent aucune d´erive importante de la s´erie. Le diagramme de d´ecalage ne pr´esente pas de motif r´egulier ni de valeurs atypiques - les donn´ees ne semblent pas ˆetre autocorr´el´ees. Les deux histogrammes sont sym´etriques et bien en forme de cloche. Le diagramme de quantiles est proche d’une droite et confirme l’hypoth`ese d’une distribution normale. Dans ce cas nous pouvons conclure que les mesures de temps d’ex´ecution peuvent ˆetre repr´esent´ees par un mod`ele de type univari´e : Ti = C + Ei ou Ti est la mesure r´eelle, C composante d´eterministe et Ei la composante 2s al´eatoire. Dans ce cas la moyenne des mesures, avec un intervalle de confiance de √n , est une bonne estimation de la moyenne de la population.

5Il est cependant possible de r´eduire l’influence sur le temps d’ex´ecution des autres process en cours d’ex´ecution en attribuant a` un thread sp´ecifique, la priorit´e la plus ´elev´e. Pour plus d’information voir Section A.3.2 de cet annexe. 6Il s’agit de T [i] en fonction de T [i + 1]. 7Les histogrammes sont construits avec des classes d’intervalle d’une largeur ´equivalente a` 0.3s, s ´etant l’´ecart type. 8Le graphique montre la fonction T [i] = m + sZ[i] avec T [i] les temps mesur´es ordonn´es, m valeur moyenne des mesures, s l’´ecart type et Z[i] les quantiles de la distribution normale standard µ = 0, σ = 1.

184 A.2. Mesure de temps d’ex´ecution d’une proc´edure

1 2 3 4 0.6 Proc. 1. 0.6 Proc. 1. 20 Proc. 1. 0.6 Proc. 1.

X 0.55 0.55 15 0.55

X X X

XX X F 0.5 0.5 X 10 0.5

T[i] T[i] X T[i] XX XX X X XXX X X XX X X XX XXX X X X XXX X XX XXXXXXXX XX X X XXX X X XX X X X X X XX XXXX X X 0.45 0.45 X X XX X 5 0.45 XX X X X X X X

0.4 0.4 0 0.4 0 10 20 30 40 50 60 70 80 90 100 0.4 0.45 0.5 0.55 0.6 0.3 0.35 0.4 0.45 0.5 0.55 0.6 -3 -2 -1 0 1 2 3 i T[i+1] Classe Q-N[0,1]

0.52 Proc. 2. 0.52 Proc. 2. 20 Proc. 2. 0.52 Proc. 2. X 0.51 0.51 15 0.51 X X X X X X XX X X X X X X X XX XX X XX X X X X X XX XX X X F 0.5 0.5 X XX X 10 0.5 T[i] T[i] X XX X X X X X T[i] X X XXXXX X XX X X X XX X X X XX X XX X X X X X XX X X X X X X X XX X X X 0.49 0.49 X X 5 0.49 X X X X 0.48 0.48 0 0.48 0 10 20 30 40 50 60 70 80 90 100 0.48 0.485 0.49 0.495 0.5 0.505 0.51 0.46 0.47 0.48 0.49 0.5 0.51 0.52 0.53 -3 -2 -1 0 1 2 3 i T[i+1] Classe Q-N[0,1]

2s n Tmin Tmed Tmoy Tmax σ Tmoy  √n [ms] Proc. 1. 100 0.4323 0.4673 0.4678 0.5566 0.0194 467.8  3.8 Proc. 2. 100 0.4844 0.4972 0.4970 0.5147 0.0049 497.0  0.9

Fig. A.2: Proc. 1. et 2.

Pour les Proc. 3. et 4. (Figure A.3) la situation est quelque peu diff´erente. Les diagrammes temporelles rel`event quelques valeurs atypiques, tout au d´ebut de la s´equence de mesures. Les diagrammes de d´ecalage mettent ces points encore plus en ´evidence. Si l’histogramme pour la Proc. 3. se montre plus ou mois sym´etrique et proche d’une cloche, celui de la Proc. 4. ne l’est pas. Le diagramme des quantiles confirme que dans ce cas on ne peut pas vraiment parler d’une distribution normale. Signalons cependant la tr`es faible valeur de l’´ecart type.

Nous avons proc´ed´e a` l’´elimination des quelques valeurs atypiques (2 pour le Proc. 3. et 7 pour le Proc. 4), les nouveaux diagrammes sont pr´esent´es a` la Figure A.4. Sans les valeurs atypiques les mesures approchent une distribution normale.

Enfin en utilisant l’´ecart type obtenu, nous pouvons calculer le nombre minimal de mesures n´ecessaires a` effectuer pour que la moyenne des mesures soit a` d unit´es prˆet de la moyenne de population en utilisant l’expression suivante :

Z( α )σ 2 n = 2 (A.1) d   α α avec Z( 2 ) la quantile de l’orde ( 2 ) de la loi Normale. α Pour un intervalle de confiance 95 % nous avons Z( 2 ) = 1.96 et en fixant la pr´ecision a` 10% de la valeur moyenne de temps d’ex´ecution il est possible de calculer n. Pour la Proc. 4. n est le plus grand : 16 mesures, c’est pour quoi le nombre des mesures a` ´et´e fix´e a` 25.

185 Annexe A. Architecture universelle

1 2 3 4 0.018 0.018 40 0.018 Proc. 3. Proc. 3. X Proc. 3. Proc. 3.

0.0175 0.0175 30 0.0175

0.017 0.017 X XX X F 20 0.017 X XX XXXXX XXXX X X X X T[i] T[i] X XXXX XXXXXXXXX XXXXXXXXX T[i] X X XXXXXXXXXX X XXX XX X X X XX X X XXXX XX X 0.0165 0.0165 10 0.0165

0.016 0.016 0 0.016 0 10 20 30 40 50 60 70 80 90 100 0.0167 0.0168 0.0169 0.017 0.0171 0.016 0.0165 0.017 0.0175 0.018 -3 -2 -1 0 1 2 3 i T[i+1] Classe Q-N[0,1]

0.007 Proc. 4. 0.007 Proc. 4. 50 Proc. 4. 0.007 Proc. 4.

0.0065 0.0065 40 0.0065 X 0.006 0.006 0.006 X 30

0.0055 0.0055 F 0.0055 T[i] T[i] T[i] 20 X X 0.005 0.005 X X 0.005 XXX XXXXXXX X 0.0045 0.0045 10 0.0045

0.004 0.004 0 0.004 0 10 20 30 40 50 60 70 80 90 100 0.004 0.0045 0.005 0.0055 0.006 0.0065 0.007 0.003 0.00375 0.0045 0.00525 0.006 -3 -2 -1 0 1 2 3 i T[i+1] Classe Q-N[0,1]

2s n Tmin Tmed Tmoy Tmax σ Tmoy  √n [ms] Proc. 3. 100 0.0167 0.0169 0.0169 0.0178 0.0001 16.9  0.02 Proc. 4. 100 0.0047 0.0048 0.0048 0.0061 0.0002 4.8  0.04

Fig. A.3: Proc. 3. et 4.

1 2 3 4 0.017 Proc. 3. 0.017 Proc. 3. X 20 Proc. 3. 0.017 Proc. 3. X X X 0.01695 0.01695 X X X 0.01695 X X X X X XX XX X X X X 15 X X X X X X X X X 0.0169 0.0169 X X X X X 0.0169 X X X X X XX XXX X XX X XX X X X X XX X X X X X X XXX X 0.01685 0.01685 X X X X X F 10 0.01685 X X XXX X T[i] T[i] X X T[i] X X X X X X X X X X X X 0.0168 0.0168 X 0.0168 X X 5 0.01675 0.01675 0.01675

0.0167 0.0167 X 0 0.0167 0 10 20 30 40 50 60 70 80 90 100 0.01670.016750.01680.016850.01690.01695 0.017 0.0165 0.016675 0.01685 0.017026 0.0172 -3 -2 -1 0 1 2 3 i T[i+1] Classe Q-N[0,1]

0.0049 0.0049 30 0.0049 Proc. 4. Proc. 4. X Proc. 4. Proc. 4. X X X XX 25 X X 0.00485 0.00485 XXX 0.00485 X X X X XX X 20 XXXXXX XX XX X XXXX XX X X X X X X X X 0.0048 0.0048 X F 15 0.0048

T[i] T[i] X T[i] XXXXX XX XXXXX X XXXX X X XXXXXX X X X X X X X X X XX 10 0.00475 0.00475 0.00475 5

0.0047 0.0047 0 0.0047 0 10 20 30 40 50 60 70 80 90 100 0.0047 0.00475 0.0048 0.00485 0.0049 0.0046 0.0047 0.0048 0.0049 0.005 -3 -2 -1 0 1 2 3 i T[i+1] Classe Q-N[0,1]

Tmin Tmed Tmoy Tmax σ Proc. 3. 0.0167 0.0168 0.0168 0.0169 0.00005 Proc. 4. 0.0047 0.0048 0.0048 0.0049 0.00003

Fig. A.4: Proc. 3. et 4. sans valeurs atypiques

186 A.3. Fonctionnement en mode multithread

A.3 Fonctionnement en mode multithread

A.3.1 M´ecanisme

Si on travaille avec les librairies MFC9 l’initiation de chaque thread peut ˆetre effectu´e par un appel a` la fonction haut niveau AfxBeginThread(). Cette fonction a comme argument le nom de la fonction a` ex´ecuter ainsi que quelques param`etres de configuration notamment ceux de la priorit´e. Deux appels successifs a` cette fonction cr´eeront donc deux threads qui, dans le cas d’une machine multi-processeur, pourraient ˆetre ex´ecut´es de fa¸con concurrentielle.

Dans le cas d’une ex´ecution sur un syst`eme multi-processeur, le nombre de processeurs peut ˆetre obtenu avec la fonction GetSystemInfo(), il est possible d’explicitement sp´ecifier quel thread sera ex´ecut´e sur quel processeur a` l’aide de la fonction SetThreadAffinityMask().

A.3.2 Influence de la priorit´e des threads sur le temps d’ex´ecution

Dans le syst`eme d’exploitation utilis´e, le temps de processeur est partag´e entre les diff´erents threads en cours d’ex´ecution. A chaque thread est associ´e un des 32 niveaux possibles de priorit´e. L’attribution d’un niveau de priorit´e particulier est faite en respectant la hi´erarchie existante entre le process et le thread. Ainsi, chaque process poss`ede son propre attribut de priorit´e. Chaque thread cr´e´e par ce process h´erite la priorit´e de base du process qui l’a cr´e´ee, mais peut encore raffiner cette valeur dans la plage fix´e par la priorit´e du process de base 10.

A chaque niveau de priorit´e est attribu´e une file d’atteinte sp´ecifique. Les files d’atteinte de niveau de priorit´e sup´erieur sont servis d’abord avec un ordonnancement qui se d´eroule selon le sch´ema round robin : chaque thread re¸coit une quantit´e fixe de temps processeur appel´e time slice quantum11. Apr`es avoir consomm´e un quanta de temps, le thread en cours d’ex´ecution est mis a` la fin de la file d’atteinte et le thread suivant peut ˆetre servi.

Un m´ecanisme de changement dynamique de la priorit´e permets au threads d’une priorit´e basse de recevoir le temps processeur malgr´e la pr´esence des threads d’une priorit´e ´elev´ee. Egalemen´ t le syst`eme d’exploitation d´efini un intervalle de temps (de l’ordre d’une seconde) dans lequel chaque thread doit ˆetre ex´ecut´e au moins une fois.

Par d´efaut, le process et le thread ont une priorit´e qualifi´e de “normale”, ´equivalente a` la valeur 9 de l’´echelle de priorit´e. Les valeurs de priorit´e plus basses correspondent aux process et aux threads que l’on souhaite ex´ecuter en arri`ere plan (les process dits idle), tandis que la valeur la plus ´elev´ee correspond aux threads dont l’ex´ecution est dite critique - les threads dont l’ex´ecution est dite “temps r´eel”. Lorsque un thread est lanc´e avec la priorit´e maximale, le processeur consacrera tout son temps a` son ex´ecution jusqu’`a ce que celui-ci ne se termine. Si l’on souhaite qu’un thread particulier prenne tout le temps processeur rien que pour lui,

9Il s’agit de la librairie Microsoft Foundation Class fourni avec le compilateur Visual C++. 10La valeur de priorit´e d’un thread apparaˆıt donc comme un ”offset” de la priorit´e de process. 11Ce temps varie d’un syst`eme d’exploitation a` l’autre. Il est g´en´eralement admis que les quantas plus longs permettent a` une application de calcul intensif d’ˆetre plus performante, tandis que les quantas plus courts conviennent mieux lorsque plusieurs applications demandent une certaine interactivit´e avec l’utilisateur.

187 Annexe A. Architecture universelle il est donc n´ecessaire de lui attribuer le plus haut niveau de priorit´e possible, une pratique courante dans le domaine de traitement des images temps r´eel (voir p.e. [CD99, Fom99]). Signalons cependant que le changement de priorit´e n’apporte aucun gain suppl´ementaire sur le temps d’ex´ecution global si l’application consid´er´ee est la seule en cours d’ex´ecution. Le temps processeur consomm´e par ces services de base du syst`eme d’exploitation est n´egligeable.

Afin d’´eviter toute interf´erence possible avec d’autres process en cours d’ex´ecution, les priorit´es de process et de thread d’ex´ecution ont ´et´e fix´ees a` la plus haute valeur possible pour toutes les mesures effectu´ees.

A.4 Mesure de performance de la m´emoire

La performance de la m´emoire joue un rˆole important dans le temps d’ex´ecution d’une proc´edure de traitement des images ´etant donn´ee la quantit´e de donn´ees en jeu. La bande passante th´eorique est de l’ordre de 3.2 GB pour la m´emoire centrale, et de 48 et de 96 GB/s ([Int99b, Int99e]) pour les deux niveaux de la m´emoire cache (le niveaux L1 - m´emoire cache hors-processeur et L2 - m´emoire cache dans le processeur mˆeme). En r´ealit´e les d´ebits effectifs vont d´ependre non seulement de la performance individuelle des composants (de la m´emoire, de la vitesse de bus etc.) mais aussi d’une configuration mat´erielle a` l’autre (le taux d’occupation de bus qui est partag´e p.e.) et il conviens donc de le quantifier pour l’ordinateur utilis´e.

Pour ´etablir la bande passante r´eelle de la m´emoire de l’ordinateur utilis´e, plusieurs m´ethodes de d´eplacement d’une quantit´e fixe de donn´ees (un bloc contigu¨e de 8 MB) ont ´et´e ´evalu´ees. Ainsi, avec la fonction C standard de copie : memcpy le taux de transfert obtenu est de l’ordre de 270MB/s, ce qui est tr`es loin des 3.2 GB th´eoriques ´enonc´e. Une proc´edure sp´ecifique, bas´ee sur l’exploitation des extensions a` l’architecture standard 12 arrive a` des d´ebits qui sont de l’ordre de 405 MB/s. Les tests de lecture/´ecriture depuis la m´emoire, mais impliquant le passage par le processeur a` travers les registres de l’extensions, affichent une performance de 980 MB/s pour l’´ecriture et pour la lecture. L’utilisation de ces mˆemes fonctions mais cette fois-ci en exploitant le chargement explicite des donn´ees dans la m´emoire cache (prefetch) permettent d’arriver a` d´ebits de l’ordre de 5.6 GB/s.

Nous constatons donc une importante diff´erence de performance en fonction de m´ethode utilis´ee pour r´ealiser le transfert de donn´ees. La bande passante de la m´emoire n’est donc pas uniquement fonction du mat´eriel mais aussi de la fa¸con comment il a ´et´e programm´e.

A.5 Code auto-modifiable pour le calcul d’adresses

Nous avons vu dans la Section 2.3 tout l’int´erˆet de chargement des lignes de l’image depuis la m´emoire centrale dans les registres de l’extension a` l’aide d’un mode d’adressage dit explicite. Une instruction de chargement, telle que movdqu xmm1 , [esi+1024] ; fait r´ef´erence a` une adresse sauvegard´ee dans le registre esi et une constante (1024) d´efinie au moment de

12Il s’agit des fonctions intrinsic mm stream ps et mm load ps.

188 A.5. Code auto-modifiable pour le calcul d’adresses l’´ecriture de programme - au moment de la compilation. Si le changement de la valeur de esi permet d’acc´eder au diff´erentes lignes de l’image, la valeur de l’offset permet d’acc´eder aux lignes de l’image, en faite de la fenˆetre n´ecessaire pour le calcul des pixels courants.

Le d´esavantage d’un tel mode d’adressage r´eside dans le fait que la taille de l’image, i.e. offset de d´eplacement, est sp´ecifi´e au moment de compilation. Donc tout changement de la taille horizontale de l’image implique la re-compilation du programme. Le code auto-modifiable va permettre d’effectuer ce mˆeme adressage explicite, mais aussi pour des valeurs qui pourraient ˆetre d´efinies au moment de l’ex´ecution du programme.

Afin de permettre au programme de se modifier par lui-mˆeme, il faut dans un premier temps demander au syst`eme d’exploitation les droits permettant d’y effectuer une op´eration d’´ecriture. Sans ses droits, l’´ecriture dans la m´emoire de programme provoque une faute de protection g´en´erale ce qui, en d’autres termes, signifie l’arrˆet d’ex´ecution de programme im- pos´e par le syst`eme d’exploitation. Le changement de droits est effectu´e par une fonction API (b.] dans le listing A.1) juste le temps d’effectuer l’´ecriture n´ecessaire. La zone m´emoire qui va subir le changement des droits d´etermin´ee par les balises start et end.

Les droits attribu´es par d´efauts sont restaur´es apr`es l’op´eration de l’´ecriture (c.] dans le listing).

Le programme effectue ensuite une op´eration d’´ecriture a` l’endroit d´etermine par la balise l1.

1 2 int s i z e x = 2 0 4 8 ; 3 unsigned char image = new unsigned char [ 2 0 4 8 2 0 4 8 ] ; ∗ ∗ 4 unsigned long o l d p r o t e c t ; 5 LPVOID c o d e s t a r t , code end ; 6 LPVOID c o d e m o d i f y ; 7 8 // A d r e s s e s d e s b a l i s e s e t l a l o n g u e u r de l a zone a` m o d i f i e r a . ] 9 asm mov c o d e s t a r t , o f f s e t [ s t a r t ] ; 10 asm mov code end , o f f s e t [ end ] ; 11 DWORD c o d e l e n g h t = (DWORD) ( (BYTE ) code end (BYTE ) c o d e s t a r t ) ; 12 ∗ − ∗ 13 // P e r m i s s i o n pour l a m o d i f i c a t i o n de l a zone e n t r e s t a r t e t end b . ] 14 BOOL r e s u l t = V i r t u a l P r o t e c t ( c o d e s t a r t , c o d e l e n g h t ,PAGE WRITECOPY,& o l d p r o t e c t ) ; 15 16 // E f f e c t u e r l e s m o d i f i c a t i o n s d e s l i g n e s d . ] e t e . ] du code a` m o d i f i e r 17 asm 18 19 m{ ov c o d e m o d i f y , o f f s e t [ l 1 ] ; // p r e n d r e l ’ a d r e s s e 20 mov ebx , c o d e m o d i f y ; 21 add ebx , 8 ; 22 mov eax , s i z e x ; // p r e n d r e l a n o u v e l l e v a l e u r de l ’ o f f s e t 23 mov [ ebx ] , eax ; // m e t t r e l a v a l e u r 24 add ebx , 8 ; // a l l e r s u r l a l i g n e s u i v a n t e 25 s a l eax , 1 ; // 2 26 mov [ ebx ] , eax ; // ∗p u t i n p l a c e 27 28 } 29 // O b t e n i r l a p e r m i s s i o n pour l a m o d i f i c a t i o n de l a zone e n t r e s t a r t e t end c . ] 30 r e s u l t = V i r t u a l P r o t e c t ( c o d e s t a r t , c o d e l e n g h t ,PAGE EXECUTE,& o l d p r o t e c t ) ; 31 32 // Code a` m o d i f i e r 33 asm 34 s t a r t : mov e s i , image ; // p o i n t e u r s u r l ’ image 35 { l 1 : 36 movdqu xmm0 , [ e s i ] ; // 37 movdqu xmm1 , [ e s i + 1 0 2 4 ] ; // changement de 1024 d . ] 38 end : movdqu xmm2 , [ e s i + 2 0 4 8 ] ; // changement de 2048 e . ] 39 } Listing A.1: Code auto-modifiable

189 Annexe A. Architecture universelle

190 Annexe B

Circuits FPGAs Xilinx

La soci´et´e Xilinx est l’un des principaux producteurs sp´ecialis´es dans le domaine de la conception et de la fabrication des circuits logiques programmables, en particulier des circuits FPGA. Depuis 1984, date d’apparition des premiers circuits FPGA, diff´erentes familles de FPGAs se sont succ´ed´ees : 2000, 3000, 4000, Spartan, Virtex, Virtex II, Virtex II-Pro.

Au premier abord l’architecture des diff´erentes familles de FPGA est fort semblable et proche de la description g´en´erale pr´esent´ee dans la Section 3.1. Cependant, l’´evolution des FPGAs Xilinx montre d’importantes avanc´ees notamment au niveau de l’architecture de la cellule logique ´el´ementaire, de la topologie du r´eseau d’interconnexions, ainsi que dans l’introduction des ressources suppl´ementaires telles que la logique n´ecessaire a` la construction des addition- neurs et des multiplicateurs performants, la m´emoire RAM etc.

Bien entendu, les familles les plus r´ecentes telles que Virtex II ou encore Virtex II-Pro b´en´eficient des derni`eres technologies employ´ees pour la fabrication des circuits int´egr´es. Ces technologies combinent r´ealisation des circuits en plusieurs couches avec un λ de l’ordre du dixi`eme de microns (8 couches de 0.15 µ pour la famille Virtex II et 9 couches de 0.13 µ pour Virtes II-Pro) et possibilit´e d’impl´ementation d’un nombre important d’entr´ees/sorties. Les FPGAs fabriqu´es avec une telle technologie sont donc des circuits de tr`es haute densit´e, ils impliquent une grand quantit´e de ressources logiques et offrent la possibilit´e de traitement d’un grand nombre de variables.

Comme tout circuit FPGA, les FPGAs de la famille Virtex II de Xilinx sont construits au- tour de trois ´el´ements essentiels d´ej`a mentionn´es : les cellules logiques ´el´ementaires, le r´eseau d’interconnexion et les bornes d’´entr´ees/sorties. En plus de ces ressources, les FPGAs de cette famille poss`edent un certain nombre de m´emoires RAMs et des circuits multiplica- teurs d´edicac´es. Les circuits FPGAs de la famille Virtex II-Pro sont mˆeme dot´es de micro- processeurs embarqu´es : l’unit´e FPGA la plus dense de cette famille 2VP125 poss`ede pas moins de 4 processeurs PowerPC-405.

Nous proposons ici un bref descriptif de l’architecture des circuits FPGAs Xilinx de la famille Virtex II.

191 Annexe B. Circuits FPGAs Xilinx

B.1 Architecture des FPGAs Virtex

B.1.1 Cellule logique ´el´ementaire

Dans la terminologie Xilinx une cellule logique ´el´ementaire est appel´ee Configurable Logic Block - CLB. Bien que ce nom soit rest´e identique tout au long de l’´evolution des diff´erentes familles des FPGAs, l’architecture qu’il d´esigne a fortement chang´e depuis l’introduction des circuits de la famille Virtex.

A partir de la premi`ere g´en´eration de la famille Virtex, un CLB est compos´e de quatre sous- cellules identiques appel´ees tranches (slices) repr´esent´ees sch´ematiquement a` la Figure B.1.

ShiftIN COUT COUT COUT Y

F1 Din F2 X1Y1 YQ F3 F D R1 F4 FR FW D 15 Matrice X1Y0 4 CY Voisins de Shift directes Shift connexions Tranche G1 Din Y G2 X0Y1 XQ 3 G D R2 G4 FR GW D15 4 CY X0Y0

ShiftOUT CIN ShiftOUT CIN CIN Tranche CLB

Fig. B.1: Architecture d’un CLB des circuits FPGA de la famille Virtex II : 4 tranches de 2 m´emoires de 16 bits (d’apr`es Xilinx [Xil03e]).

Chacune des tranches d’un CLB poss`ede un certain nombre de ressources logiques. Nous d´ecrivons les plus importantes d’entre elles : – M´emoires F et G - Il s’agit des m´emoires de 16 bits que l’on peut adresser avec deux bus d’entr´ee ind´ependants de quatre bits chacun. Ces m´emoires poss`edent deux sorties : une sortie D qui donne le contenu de la m´emoire selon l’adresse pr´esente sur le bus F R (ou GR) et une sortie D15, le dernier bit adress´e par la m´emoire. Chaque m´emoire poss`ede ´egalement une entr´ee suppl´ementaire Din. Cette entr´ee, combin´ee avec la sortie D15, est utilis´ee pour la construction des registres a` d´ecalage a` plus grand nombre de bits a` partir de plusieurs m´emoires F (ou G) mis en s´erie (connexion Shift sur la Figure B.1).

– Logique d´edicac´ee d’addition CY - La logique suppl´ementaire (not´ee CY sur la Figure B.1 par tranche permet d’effectuer efficacement l’op´eration d’addition (ou de soustraction). A cette logique est associ´ee une connexion sp´ecifique permettant de te- nir compte d’un ´eventuel report de l’´etage pr´ec´edant et de propager le report calcul´e

192 B.1. Architecture des FPGAs Virtex

aux tranches situ´ees imm´ediatement au dessus de la tranche consid´er´ee (connexions Cin et Cout). Il est ainsi possible de construire des additionneurs de mots d’un plus grand nombre de bits.

– Bi-stables programmables R1 et R2 - La sortie D de la m´emoire F (ou G) peut ˆetre dirig´ee vers deux bi-stables programmables R1 et R2. Ces bi-stables peuvent ˆetre utilis´es pour la r´ealisation des latch ou des flip-flops habituels lors de r´ealisation des circuits synchrones.

– Multiplexeurs - L’ensemble des multiplexeurs (non repr´esent´es a` la Figure B.1) per- mettent la r´ealisation de multiplexeurs a` grand nombre de canaux.

Dans chaque tranche, les sorties D des m´emoires F et G peuvent ˆetre : soit dirig´ees directement vers d’autres circuits combinatoires et/ou s´equentiels (sorties X, Y ) ; soit m´emoris´ees dans les deux ´el´ements m´emoire R1 et R2 dans le cas de la r´ealisation d’un circuit synchrone (sorties XQ, Y Q). Dans les deux cas, la connexion des sorties avec d’autres CLBs se fait soit via des connexions d´edicac´ees pour des tranches adjacentes au CLB consid´er´e, soit via la matrice des connexions a` des CLBs situ´es plus loin dans le FPGA (voir Section A.1.6).

B.1.2 Modes de fonctionnement d’un CLB

Un CLB se pr´esente donc comme une ressource logique polyvalente. En fonction de la configuration attribu´ee, il peut adopter l’un de plusieurs modes de fonctionnement distincts, dont nous pr´esentons les plus importants :

G´en´erateur des fonctions logiques Les m´emoires des CLBs (en fait les m´emoires des tranches) contiennent des tables de v´erit´e permettant le calcul des fonctions logiques. Un CLB peut donc r´ealiser au maximum 8 fonc- tions logiques diff´erentes, chacune sur 4 variables d’entr´ees diff´erentes.

Registres Chaque m´emoire (F ou G) peut fonctionner comme un registre a` d´ecalage de 16 bits a` ´ecriture synchrone mais a` lecture asynchrone. Les deux ´el´ements m´emoire peuvent cependant ˆetre utilis´es pour une lecture synchrone depuis F et G. La lecture d’un poids particulier d’un registre fait a` l’aide des m´emoires est effectu´ee par l’interm´ediaire des variables d’entr´ee, en fait les 4 bits d’adresses des m´emoires F ou G. Ind´ependamment de ce registre a` d´ecalage, et donc des m´emoires F et G, les R1 et R2 peuvent ˆetre utilis´es pour la r´ealisation de diff´erents types de registres a` lecture parall`ele. Un registre de 8 bits n´ecessitera donc pour sa r´ealisation un seul CLB.

M´emoire Comme chaque CLB poss`ede 8 m´emoires de 16 bits, chacune des m´emoires peut ˆetre organis´ee pour contenir des mots de 1, 2, 4 et 8 bits a` simple acc`es, ou en des m´emoires de mots de 1, 2, 4 bits en double acc`es. L’adressage double, dans le cas d’un cycle d’´ecriture/lecture simultan´ees aux adresses diff´erentes, est fait a` l’aide des deux bus suppl´ementaires W F et W G de m´emoires F et G.

193 Annexe B. Circuits FPGAs Xilinx

Multiplexeurs Les m´emoires F et G ainsi que les diff´erents multiplexeurs associ´es au CLB permettent la r´ealisation des multiplexeurs de 4, 8, 16 et 32 canaux a` l’aide de 1, 2, 4 et 8 tranches respec- tivement.

Logique d´edicac´ee pour l’arithm´etique Chaque CLB ayant des ressources logiques sp´ecifiques pour le calcul et la propagation du report (le bloc CY a` la Figure B.1) permet une impl´ementation tr`es efficace des circuits arithm´etiques tels qu’additionneurs ou soustracteurs. Il est ainsi possible de r´ealiser un addi- tionneur ou un soustracteur complet sur deux mots d’un bit en tenant compte d’un ´eventuel report de l’´etage pr´ec´edent (Cin) a` l’aide de seulement une tranche de CLB. Le report g´en´er´e est directement transmis a` la tranche sup´erieure Cout pour la construction des additionneurs ou des soustracteurs de mots cod´es sur plusieurs bits.

Calcul de SdP Chaque tranche poss`ede une porte logique OU g´en´eralis´ee (not´ee ORCY ) ayant comme entr´ee le signal Cout de la tranche consid´er´ee et le mˆeme signal provenant de la tranche situ´ee imm´ediatement a` sa gauche (voir Figure B.2). Les sorties des diff´erentes portes ORCY pro- venant des tranches adjacentes peuvent ˆetre mises en s´erie. Il est ainsi possible de calculer ais´ement des expressions logiques de type somme des produits - SdP, sans pour autant consom- mer de CLBs suppl´ementaires pour calculer la somme apr`es avoir calcul´e les produits.

ORCY ORCY ORCY ORCY COUT COUT COUT COUT

4 X0Y1 4 X1Y1 4 X2Y1 4 X3Y1

CIN CIN CIN CIN

Fig. B.2: Porte OU g´en´eralis´ee par tranche du CLB.

B.1.3 Bloc de m´emoire RAM

Il s’agit de m´emoires RAM d’une capacit´e de 18Kbits qui peuvent ˆetre exploit´ees en simple ou en double acc`es (cycles ´ecriture/lecture simultan´ees sur des adresses diff´erentes). Ces m´emoires sont configurables et peuvent ˆetre organis´ees en m´emoires de 0.5K, 1K, 2K, 4K, 8K et 16K mots de 36, 18, 9, 4, 2 et 1 bits respectivement.

B.1.4 Multiplicateur

A chaque bloc de m´emoire RAM est associ´e un circuit multiplicateur de deux mots de 18 bits. Plusieurs de ces circuits peuvent calculer de fa¸con simultan´ee la multiplication sur des donn´ees sauvegard´ees ailleurs dans le FPGA, mais sont optimis´es pour les op´erations sur des op´erandes provenant des blocs de m´emoire RAM. L’utilisation des circuits de multiplication s’av`ere particuli`erement utile lors de l’impl´ementation des applications de traitement de signal,

194 B.1. Architecture des FPGAs Virtex caract´eris´ees par un nombre important de cycles lecture - multiplication - accumulation de r´esultats.

Le nombre de circuits multiplicateurs (´egalement des blocs de m´emoire RAM) d´epend de la taille et de la densit´e du circuit FPGA consid´er´e. Ainsi nous disposons d’un multiplicateur et d’un bloc de m´emoire RAM toutes les 4 lignes de CLBs et ceci toutes les 2, 4 ou 6 colonnes, en fonction de la densit´e du FPGA (6 colonnes pour les FPGAs les plus denses).

B.1.5 Digital Clock Manager - DCM

L’architecture des circuits FPGAs Virtex II offre une ressource particuli`ere permettant une gestion efficace des diff´erents signaux d’horloge (Digital Clock Manager - DCMs) n´ecessaires au fonctionnement optimal d’un circuit logique r´ealis´e dans un FPGA. Le rˆole principale de cette ressource consiste a` g´en´erer des signaux d’horloge internes au FPGA mais parfaitement en phase avec les horloges sources venant de l’ext´erieur. Ainsi les d´elais de distribution du signal d’horloge dans les endroits ´eloign´es de la source seront compl`etement ´elimin´es. Grˆace a` ces unit´es il est ´egalement possible de g´en´erer un grand nombre de fr´equences d’horloge diff´erentes, a` travers un ensemble des diviseurs/multiplicateurs de fr´equence.

Comme pour les bloc de m´emoire RAM et le multiplicateurs, le nombre de DCMs varie en fonction de la taille de FPGA. On compte deux ressources DCM toutes les 2, 4 ou 6 colonnes des CLBs, pour les FPGAs les plus denses.

B.1.6 Blocs d’entr´ee/sortie

Le rˆole principal des blocs d’entr´ee/sortie (Input/Output Block - IOB) est d’assurer la communication entre la logique interne au FPGA et le monde ext´erieur au circuit et ceci pour l’ensemble des standards ´electriques les plus r´epandus.

Chaque IOB peut ˆetre programm´e de fa¸con a` ce que la patte de circuit qui lui est associ´ee puisse ˆetre utilis´ee soit comme une entr´ee, soit comme une sortie, soit les deux (une patte bidirectionnelle). Chaque IOB dispose ´egalement de 6 ´el´ements m´emoires configurables en tant que bascule D ou en tant que latch. Pour un mode de fonctionnement particulier de l’IOB (entr´ee, sortie ou bidirectionnelle) les deux ´el´ements de m´emoire permettent de doubler le d´ebits de donn´ees entrantes/sortantes puisque leur synchronisation peut (en fait doit) ˆetre faite avec deux signaux d’horloge de mˆeme p´eriode mais d´ephas´es de 180˚. Un tel signal d’horloge peut facilement ˆetre construit a` l’aide d’un DCM d´ecrit plus haut.

B.1.7 R´eseau d’interconnexions

Le r´eseau d’interconnexions permet la r´ealisation des connexions (i.e. le routage) entre les diff´erentes tranches au sein d’un mˆeme CLB, entre les diff´erents CLBs, les DCMs, les multiplicateurs, la m´emoire RAM et les IOBs utilis´es pour la construction d’un circuit donn´e.

195 Annexe B. Circuits FPGAs Xilinx

Au sein d’un mˆeme CLB, les diff´erentes tranches peuvent communiquer via des connexions rapides. Une matrice des connexions programmables (Programmable Switch Matrix - PSM) est associ´ee a` chaque CLB, IOB, DCM, a` la m´emoire RAM et au circuit multiplicateur. Le rˆole de cette matrice est de r´ealiser une connexion programm´ee entre les conducteurs “entrants” et “sortants”. La programmation de la connexion est ´etablie a` l’aide d’un mot de m´emoire d´efini par la configuration. Grˆace aux PSMs toute ressource peut donc acc´eder a` toute autre ressource, quelque soit l’endroit ou` elle se trouve dans le circuit FPGA.

Les conducteurs “entrants” et “sortants” d’une matrice PSM sont dispos´es entre les lignes et le colonnes des CLBs. Il en existe diff´erents types : – 48 conducteurs longs qui parcourent toute la surface du circuit – 240 conducteurs directs par ensemble de 3 et 6 CLBs – 80 conducteurs pour les CLBs adjacents – 16 conducteurs directs dans les 8 directions – 8 conducteurs rapides, internes au CLBs A ces ressources de routage s’ajoutent ´egalement les connexions sp´ecifiques de propagation du report d´ej`a mentionn´ees et celles de distribution du signal d’horloge.

B.1.8 Architecture

Plusieurs CLBs, en fait des matrices de 2 4 CLBs au bord du circuit et 4 4 partout × × ailleurs, sont regroup´es en clusters. A chaque cluster de CLB est associ´e un bloc de m´emoire RAM et un circuit multiplicateur.

La Figure B.3 montre le cluster de CLBs du coin sup´erieur gauche d’un circuit FPGA. On peut y voir les IOBs associ´es, un cluster de 2 4 CLBs, la m´emoire RAM et le multiplicateur × associ´e, le DCM et les matrices des connexions programmables PSM associ´ees.

B.2 Circuits FPGAs de la famille Virtex II

Le Tableau B.1 indique la quantit´e des ressources d´ecrites pour des FPGAs Xilinx de la famille Virtex II disponibles en 2004.

B.3 Performance des FPGAs

La performance globale d’un circuit r´ealis´e au sein d’un FPGA d´ependra : – des performances respectives de tous les ´el´ements individuels du FPGA ; ce que nous d´esignerons comme la performance brute du circuit – des ressources effectivement utilis´ees pour la construction du circuit d´efinitif.

En ce qui concerne la performance brute des FPGAs, la famille Virtex II propose pour chaque circuit particulier trois classes de performance not´ees : -4, -5, -6 ; -6 ´etant l’indice qui d´esigne les circuits les plus performants.

196 B.3. Performance des FPGAs

IOB IOB IOB DCM PSM PSM PSM PSM

IOB CLB CLB PSM PSM PSM PSM

IOB CLB CLB PSM PSM PSM PSM ultiplicateur é M IOB CLB CLB M PSM PSM PSM PSM

IOB CLB CLB PSM PSM PSM PSM

Fig. B.3: Disposition des diff´erents ´el´ements d’un FPGA Virtex II (d’apr`es Xilinx [Xil03e]).

Circuits CLBs Tranches Multiplic. M´em. RAM DCMs Max E/S

XC2V40 8 x 8 256 4 72 4 88 XC2V80 16 x 8 512 8 144 4 120 XC2V250 24 x 16 1.536 24 432 8 200 XC2V500 32 x 24 3.072 32 576 8 264 XC2V1000 40 x 32 5.120 40 720 8 432 XC2V1500 48 x 40 7.200 48 864 8 528 XC2V2000 56 x 48 10.752 56 1,008 8 624 XC2V3000 64 x 56 14.336 96 1,728 12 720 XC2V4000 80 x 72 23.040 120 2,160 12 912 XC2V6000 96 x 88 33.792 144 2,592 12 1,104 XC2V8000 112 x 104 46.592 168 3,024 12 1,108

Tab. B.1: Circuits FPGAs Xilinx - Virtex II : le nombre de CLBs et de tranches, le nombre de circuits multiplicateurs, la capacit´e totale des diff´erentes m´emoires RAM en Kbits, le nombre de DCMs, le nombre maximal de bornes d’entr´ee/sortie.

197 Annexe B. Circuits FPGAs Xilinx

Pour se faire une id´ee de cette performance, voici quelques donn´ees caract´eristiques pour un circuit d’indice -6 : – le temps d’acc`es a` une m´emoire F ou G est de 0.35ns lorsqu’elle fonctionne comme un g´en´erateur de fonctions logiques et de 1.63ns lorsque elle travaille en mode m´emoire

– les deux bi-stables par tranche peuvent fonctionner avec un signal d’horloge dont la p´eriode maximale est de 1.2ns.

Pour une information plus compl`ete concernant la performance brute des diff´erents ´el´ements on peut se rapporter a` [Xil03d].

Pour un circuit donn´e, la performance va d´ependre de sa complexit´e : le nombre et la position des blocs IOB, le temps de transmission des signaux depuis les entr´ees jusqu’`a la logique combinatoire et/ou s´equentielle, la vitesse avec laquelle celle-ci calculera les fonctions logiques r´ealis´ees a` l’aide d’un ensemble des m´emoires et le temps de transmission des signaux vers les sorties.

Pour illustrer l’ordre de grandeur de vitesse, voici les performances obtenues a` l’aide de FPGA XC2V1000-5 pour quelques circuits logiques type : – un d´ecodage d’adresses de 16 et 64 bits est fait en 6.3 et 9.3ns,

– un additionneur de 8 et 64 bits peut fonctionner a` 292 et 114 MHz respectivement,

– une m´emoire a` simple acc`es de 4096 mots de 4 bits fonctionne a` une fr´equence d’horloge de 278MHz.

198 Annexe C

Architecture reconfigurable

C.1 Impl´ementation des circuits propos´ees

L’impl´ementation du syst`eme reconfigurable d´ecrit dans le Chapitre 4 a ´et´e faite a` l’aide de la plate-forme de d´eveloppement des FPGAs Xilinx : Integrated Software Environment 6.2. - (ISE). Cette plate-forme regroupe un ensemble d’outils permettant de faire la descrip- tion et la synth`ese, la v´erification, l’impl´ementation et la v´erification apr`es l’impl´ementation (validation) des circuits destin´es a` l’int´egration dans des FPGA.

La Figure C.1 montre l’organigramme du flot de conception et les diff´erents outils associ´es utilis´es. Une telle approche a` l’impl´ementation est largement inspir´ee de la diverse documen- tation propos´ee par Xilinx (voir [Xil03h, Xil03a, Xil03c, Xil03b]), permettant de maximiser la performance des circuits r´ealis´es, tout en minimisant le temps de d´eveloppement, un facteur important lorsqu’il s’agit de construire des circuits a` la carte.

Description et synth`ese Un circuit est d’abord d´ecrit en langage VHDL et sa description v´erifi´ee a` l’aide d’un simu- lateur, en l’occurrence le logiciel ModelSim XE II, version 5.7. A la description de circuit sont associ´es les diff´erents stimuli (en fait les vecteurs de donn´ees a` l’entr´ee) sous forme des bancs d’essai, d´ecrits ´egalement en langage VHDL. La description de circuit et le fichier de stimulus sont ensuite pass´es au logiciel de simulation, permettant d’effectuer une v´erification fonctionnelle de la description.

Apr`es la v´erification de la description, la synth`ese du circuit peut ˆetre effectu´ee a` l’aide de programme XST - Xilinx Synthesis Technology. Outre la possibilit´e de visualiser le circuit sous forme d’un sch´ema RTL, nous pouvons disposer d’une premi`ere estimation de la performance pour le circuit d´ecrit. Bien entendu la performance donn´ee ne sera qu’une indication, car la performance r´eelle ne pourra ˆetre obtenue qu’apr`es le placement et le routage d´efinitifs.

Impl´ementation L’´etape de synth`ese fourni au processus d’impl´ementation un fichier contenant la description physique de circuit, sous forme d’un ensemble de primitives (briques de base) des circuits

199 Annexe C. Architecture reconfigurable

Description et Synthèse

Stimulus VHDL

Simulation Fichier VHDL Fonctionnelle

Synthèse ModelSim XST

*.NGD Implémentation Paramètres

Translate

ISE Analyse de Contraintes Map délais

Timing Analyser Place&Route Constraints editor PACE

Validation

Stimulus

Modèle Simulation PostPAR Fichier VHDL après PAR

ModelSim Fig. C.1: Flot de conception et les outils utilis´es pour une impl´ementation physique des circuits d´ecrits.

FPGAs Xilinx (il s’agit d’un fichier portant une extension NGD, pour Native Generic Da- tabase). Mis a` part la description du circuit, le processus d’impl´ementation proprement dit, en fait les trois sous-´etapes : translate, map et place and route, n´ecessitent la d´efinition d’un ensemble de param`etres permettant de contrˆoler leur d´eroulement. Ces param`etres peuvent ˆetre class´es en deux groupes distincts : les param`etres des programmes d’impl´ementation et les contraintes de la performance. 1. Param`etres des programmes d’impl´ementation Les param`etres li´es aux diff´erents programmes d’impl´ementation sont introduits via l’interface graphique de la plate-forme de d´eveloppement ISE. Il s’agit principalement : de l’effort que le programme de placement et de routage va ”fournir“ afin de rencon- trer la performance de circuit souhait´e et le choix d’une des 100 diff´erentes tables de coutsˆ utilis´ee pour le placement. L’influence de choix d’une table de coutˆ sur la per- formance de circuit d´efinitif peut ˆetre significative car chaque table produira un place- ment particulier. Les exp´eriences ont montr´e qu’une diff´erence en performance de 30 % est possible, pour une mˆeme description de circuit mais pour les diff´erentes tables de cout[Wha02ˆ ]. Lorsque l’on souhaite pousser la performance d’un circuit au maximum, alors l’impl´ementation peut ˆetre faite pour un certain nombre de tables de coutsˆ (ou toutes) dans une impl´ementation dite Multi-Pass Place and Route - MPR. La table de coutˆ offrant la meilleure performance serait alors retenue pour le placement et le rou- tage d´efinitifs. Pour les circuits d´ecrits, l’impl´ementation d’un module de calcul avec les diff´erentes tables de coutˆ n’a pas relev´ee des diff´erences aussi significatives, la raison

200 C.1. Impl´ementation des circuits propos´ees

pour laquelle nous nous sommes limit´e a` la table des coutsˆ utilis´ee par d´efaut.

2. Les contraintes sur la performance de circuit que l’on souhaite obtenir sont introduites dans le processus d’impl´ementation a` l’aide des applications graphiques Constraint Edi- tor et/ou PACE, ou tout simplement a` la main, a` l’aide d’un fichier texte contenant les descriptions des contraintes avec une syntaxe particuli`ere. Pour les circuits synchrones, la sp´ecification des contraintes peut ˆetre faite de mani`ere globale (de telles contraintes sont valables pour le circuit eniter) a` l’aide de trois types de contraintes diff´erentes : (a) P´eriode minimale (fr´equence maximale) - Cette contrainte agit sur le d´elai maxi- mal qui peut y avoir entre tout ´el´ement synchrone source et tout ´el´ement synchrone destination. C’est donc la fr´equence maximale avec laquelle le circuit synchrone peut fonctionner dans le FPGA. (b) Contrainte sur les entr´ees (Pad to setup time) - Comme le circuit FPGA re¸coit les donn´ees du monde ext´erieur, il faut ´egalement tenir compte de d´elais li´es au transit de donn´ees depuis la fronti`ere physique du FPGA (les pattes d’entr´ees) jusqu’au premier ´el´ement synchrone. Mˆeme si le premier ´el´ement synchrone se trouve dans un IOB du FPGA, ces d´elais sont n´eanmoins a` prendre en compte. (c) Contrainte sur les sorties (Clock to Pad) - Le mˆeme raisonnement est d’appli- cation pour les sorties du FPGA. La sp´ecification des contraintes est faite en fonction de la complexit´e du circuit, de la performance brute du FPGA cible et des performances que l’on souhaite obtenir. Afin de fixer une performance r´ealiste pour le circuit, g´en´eralement apr`es l’´etape de mapping et avant le placement et le routage, on effectue une analyse des d´elais a` l’aide de l’outil Timing Analyser. A ce stade, une telle analyse nous donne l’information sur les d´elais introduits par la logique pure (en fait les d´elais introduit par des LUT s) et peut servir d’une premi`ere estimation de la performance du circuit final. G´en´eralement on consid`ere que le temps pass´e pour le calcul des fonctions logiques et le routage doit ˆetre partag´e avec un rapport de 50-50 %. Une estimation correcte de la performance du circuit avant le placement et le routage ´evitera donc une perte de temps li´e a` la tentative de l’impl´ementation d’un circuit avec des performances tout simplement impossibles d’atteindre. Les param`etres des programmes d’impl´ementation et les contraintes de la performance du circuit ´etant d´efinis, le circuit peut ˆetre plac´e et rout´e dans le FPGA cible. Apr`es le processus d’impl´ementation on peut ais´ement v´erifier si les contraintes impos´ees ont ´et´e rencontr´ees oui ou non. Si ce n’est pas le cas, il faut alors affaiblir des contraintes impos´ees et refaire le processus d’impl´ementation. Nous sommes donc bien dans un cycle it´eratif des ´etapes : la d´efinition des contraintes - l’impl´ementation - la v´erification des r´esultats d’impl´ementation.

Validation Lorsque le circuit obtenu a rencontr´es les contraintes impos´ees, le processus d’impl´ementation est termin´e. La derni`ere ´etape consiste alors a` effectuer la validation de fonctionnement du cir- cuit r´ealis´e dans des conditions esp´er´ees. Cette v´erification peut ˆetre faite de fa¸con mat´erielle, avec le circuit FPGA dans lequel on aurait charg´e la configuration et qui on placerait dans un banc d’essai mat´eriel. Mais cette v´erification peut ˆetre ´egalement faite de fa¸con logicielle. Afin de r´eduire les coutsˆ (le temps) li´e au d´eveloppement des circuits int´egr´es en g´en´eral, on

201 Annexe C. Architecture reconfigurable utilise de plus en plus des solutions logiciels permettant une v´erification par simulation. Dans ce cas, un mod`ele physique de circuit, g´en´er´e automatiquement sur base de l’information du circuit r´ealis´e, est utilis´e pour une simulation r´ealiste.

Comme nous n’avons pas dispos´e d’un circuit FPGA suffisamment dense pour effectuer une v´erification mat´erielle, c’est la m´ethode de v´erification par simulation qui a ´et´e utilis´ee.

Strat´egies d’impl´ementation La description du flot de l’impl´ementation met en ´evidence deux objectifs oppos´es : un temps d’impl´ementation court et la performance maximale de circuit. En effet, lorsque les contraintes sont faibles, ”l’effort“ que le programme de placement et de routage doit fournir pour trouver une solution qui les satisfait l’est aussi. Par contre lorsque l’on exige que le circuit r´esultant pr´esente une performance particuli`ere, l’effort d’impl´ementation (le temps) doit ˆetre plus important. C’est pour cette raison que nous avons adopt´e deux strat´egies d’impl´ementation diff´erentes : l’impl´ementation sous contraintes faibles et l’impl´ementation sous contraintes fortes.

1. Impl´ementation sous contraintes faibles Dans cette strat´egie d’impl´ementation nous allons privil´egier un temps d’impl´ementation court par rapport a` la performance du circuit. Elle sera utilis´ee syst´ematiquement pour chaque circuit d´ecrit, de fa¸con a` ´etablir la quantit´e des ressources logiques n´ecessaires et une performance de circuit que l’on pourrait qualifier de minimale. Pour cette strat´egie d’impl´ementation les param`etres des diff´erents programmes utilis´es pour l’impl´ementation sont tout simplement ceux par d´efaut, car ils garantissent le meilleur rapport entre le temps d’impl´ementation et la qualit´e des r´esultats obtenus. Nous avons donc un effort normal pour le placement et le routage et une seule table de coutˆ pour le placement. En ce qui concerne les contraintes sur la performance elles sont fix´ees a` des valeurs largement au dessous d’une performance maximale. Ces valeurs ont ´et´e d´etermin´ees de fa¸con empirique, en estimant grossi`erement la complexit´e du circuit et en connaissant la performance brute de FPGA cible. En l’occurrence, quelque soit le type de circuit pr´esent´e nous avons toujours 20ns pour la p´eriode minimale et 10ns pour les contraintes sur les entr´ees et les sorties.

2. Impl´ementation sous contraintes fortes Dans cette strat´egie d’impl´ementation l’objectif est de maximiser la performance de circuit final, et ceci au d´etriment d’un temps d’impl´ementation plus long, comme en t´emoignent les r´esultats pour le syst`eme reconfigurable complet, expos´es a` la fin du Chapitre 4. Pour une impl´ementation sous contraintes fortes nous avons utilis´e un effort maximal pour le processus de placement et de routage. En ce qui concerne les contraintes, elles sont dans un premier temps fix´ees a` des valeurs proches de celles obtenus par le processus de synth`ese. Ensuite, elles sont progressivement affaiblies, jusqu’`a ce qu’elle ne soit pas rencontr´ees par le processus d’impl´ementation.

202 C.2. Validation des unit´es de traitement pour des voisinages de 5 5 et 7 7 pixels × ×

C.2 Validation des unit´es de traitement pour des voisinages de 5 5 et 7 7 pixels × ×

On consid`ere un voisinage V de 5 5 pixels et le voisinage correspondant tri´e V˜ : ×

174 129 182 175 175 1 2 3 4 6 139 182 130 131 23 7 8 9 10 11 V = 21 2 80 12 191 V˜ = 12 21 23 80 111 11 1 6 7 8 129 130 131 139 174 9 3 4 10 111 175 175 182 182 191

Pour ce voisinage on donne les valeurs des pixels pour quelques valeurs de rang :

r = 25 (Max) r = 13 (Med) r = 1 (Min) r = 20

191 = (10111111)2 23 = (00010111)2 1 = (00000001)2 174 = (10101110)2

On consid`ere le voisinage V de 7 7 pixels suivant et le voisinage correspondant tri´e V˜ : ×

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 2 3 4 5 6 7 8 2 3 4 5 6 7 8 V = 9 10 11 12 13 14 15 V˜ = 9 10 11 12 13 14 15 16 17 18 170 20 21 22 16 17 18 20 21 22 23 23 24 25 26 27 28 29 24 25 26 27 28 29 30 30 31 32 33 34 35 36 31 32 33 34 35 36 170

Les valeurs des pixels pour quelques valeurs de rang sont :

r = 49 (Max) r = 25 Med r = 1 (Min) r = 39

170 = (10101010)2 12 = (00001100)2 0 = (00000000)2 27 = (00011011)2

Aux voisinages d´ecrites correspondent deux plans de bits suivants, cod´es en d´ecimal :

P BV = 33489920, 4097, 24380417, 4510720, 20450867, 24431813, 25142987, 12175193 { } P BV = 131072, 0, 131103, 1966048, 534912992, 8084644321, 27487790694, 45812853418 { } Les Figures C.2 a), b), c) et d) montrent les chronogrammes de calcul des filtres Max et Min pour les voisinages d´ecrits. La Figure C.3 montre le chronogramme de fonctionnement d’une unit´e de traitement calculant le filtre de rang (la valeur m´ediane pour le 5 5 et r = 36 pour × le 7 7) a` l’aide de l’algorithme par ´elimination. La Figure C.4 montre le chronogramme de × calcul de filtre m´edian pour les deux voisinages d´ecrits en utilisant l’unit´e de traitement bas´ee sur l’algorithme de Danielsson.

203 Annexe C. Architecture reconfigurable

1 1 0 0 7 8 8 1 1 34 1 0 1 34 0 5 5 93 93 1 1 5 28 28 5 7 1 1 7 1 8 8 1 2 5 5 2 1 4 4 1 6 94 94 6 6 7 7 1 0 0 0 90 90 77 77 4298 4298 1 48 48 1 5 7 7 5 2 2 2 2 5 1 1 3 3 1 0 1 0 1 1 4432 8 4432 8 6 1 6 1 8084 2443 8084 2443 4 7 7 1 0 0 0 6 6 2992 2992 08 08 1 1 5 5 349 349 204 204 5 5 3

1 0 1 0 20 20 048 7 048 7 0 0 66 1 66 1 9 5 9 5 1 4 1 4 2 7 7 0 0 0 0 1 1 03 03 11 11 3 3 1 243804 1 243804 1

1 0 1 0 7 7 409 409 0 0 0 2 2 7 7 0 0 1 1 3 3 33489920 1 1 33489920 t t t t a a a a t t t t clk clk clk clk l l l l pbv pbv pbv pbv initm initm initm initm resu resu resu resu ) ) ) a) b c d Fig. C.2: Chronogrammes de fonctionnement d’une unit´e de traitement calculant les filtres Max et Min pour les voisinages de 5 5 et de 7 7 × × pixels.

204 C.2. Validation des unit´es de traitement pour des voisinages de 5 5 et 7 7 pixels × ×

1

1 0

1 0

1 7 1 3

0 3 5 1 2 1 2 r= 0 Med.

0 0

0 0

0

0

0

1

0

4 0

0 8 1

0 1 6 3 0 8 2 1 r=

1 r= 0

0

0

1

0

0

1

1

1

1

5 0

1 9 1

1 7 1 3 111 2 1 r= 0 r= 0

1

0

1

0

0

0

1

0

0

1 6

0 9 0 1 1 2

0 4

1 1 28

0 r=

0 r=

0

0

0

0

1

1 0

0 1

7 1 0 0 1 1

3 1

0 9 4 1 2 0

0 r= r= 0 0

0 0

0 1

0 1

1 1

1 0 8 1 2

1 1 0 3 0 4

0 1

0 3 r=

0 r= 0

0 0

0 1

1 1

1 1

1 0 9 9 3

1 1 1 3 4 1

1 0 1 3 r=

0 r= 0

0 0

0 1

0 0

0 1

0 1 0 4 0 1 7 44 2

0

0 1 3 r=2

1 r= 1

0 0

0 1

1 1

1 0

1 0 1 5 1 0 75 4

0 0 1 33 r=2

1 1 r=

0 0

1 0

1 0

1 1

1 0

1 0 6 75 4 4 0 0 1 3 r=22

1 1 r=

0 0

1 0

0 1

1 1

1 0 3

0 0 7 82 4 1 0 5 1 3 r=2 1 1 r=

0 0

1 0

0 0

1 0

1 1 4 0 0 8 82 4

1 0 6 1 3

1 r=2 1 r=

0 0

1 0

1 0

1 1

1 0

1 1 9 0

1 4

0 7 191 1

1 r=25 1 r=

0 0

1 1 t t a a t t clk clk l l pbv pbv u u tmm tmm initm initm initmm initmm res res rese rese i i ) a) b Fig. C.3: Chronogrammes de fonctionnement d’une unit´e de traitement calculant le filtre de rang g´en´eralis´e (l’algorithme par ´elimination) pour les voisinages de 5 5 et de 7 7 pixels. × ×

205 Annexe C. Architecture reconfigurable

1 0 7 8 1 4 3 5 1 0 3 8 9 2 1 1 5 8 7 5 1 4 2 1 6 4 9 6 0 1 1 7 9 77 98 8 2 4 4 7 1 2 5 2 5 1 2 3

0 1 3 44 1 6 8 4 1 8 3 0 8 44 2 4 2

1 0 99 7 2 6 1 8 9 0 4 5 3 4 5 0 2 3

0 0 8 0 4 2 0 7 0 66 1 9 5 1 4 2

0 0 7 1 3 4 0 0 8 11 3 3 4 1 2 1

0 0 7 9 0 0 4 0 0 2 2 7 899 0 4 1 3 33 1 t t a a t t clk clk l l pbv pbv i_init i_init resu resu ) a) b Fig. C.4: Chronogrammes de fonctionnement d’une unit´e de traitement calculant le filtre m´edian (l’algorithme de Danielsson) pour les voisi- nages de 5 5 et de 7 7 pixels. × ×

206 C.3. Validation des modules de traitement apr`es placement et routage

C.3 Validation des modules de traitement apr`es placement et routage

Dans la Section C.1 nous avons indiqu´e qu’il est possible de r´ealiser apr`es le processus de placement et de routage une simulation r´ealiste du circuit r´ealis´e dans le FPGA. En effet, en utilisant le programme NetGen (ce programme fait partie de la suite ISE 6.2 de Xilinx) on peut, et de fa¸con enti`erement automatique, g´en´erer un mod`ele de circuit qui tient compte des d´elais r´eels introduits par une impl´ementation physique.

Le mod`ele g´en´er´e, ainsi que le fichier de banc d’essais propre a` une simulation physique sont pass´es au logiciel de simulation, le mˆeme que celui utilis´e pour la simulation fonctionnelle (ModelSim). Pour le mod`ele g´en´er´e et le banc d’essai fourni, le simulateur v´erifie qu’aucune violation des temps requis pour un fonctionnement correcte de circuit ne s’est produit au cours de la simulation (des ´eventuels erreurs sont communiqu´ees a` l’utilisateur).

Nous pr´esentons ici les r´esultats de la simulation des mod`eles de deux modules de traitement, calculant le filtre Max et le filtre m´edian (l’algorithme de Danielsson) dans un voisinage de 3 3 pixels. La taille de la fenˆetre du module de traitement (Fx) a ´et´e fix´e a` 10 pixels. × Pour les deux simulations, la vitesse d’horloge a ´et´e fix´e a` 67 MHz, permettant un d´ebit de 54 MPx/sec.

Le fichier de banc d’essai (le mˆeme pour les deux modules), ´ecrit en VHDL, permet d’effectuer la lecture de fichier d’une image a` traiter (le fichier binaire contenant les valeurs de la couleur des pixels cod´ees sur 8 bits), de mettre les donn´ees aux format n´ecessaire pour le traitement (lecture pixel par pixel, ligne par ligne), de passer les donn´ees a` traiter au mod`ele du module de calcul et effectuer la simulation.

Les pixels calcul´es (l’image trait´e) sont ensuite ´ecrits dans un fichier de r´esultat, de mˆeme format que l’image a` traiter. En utilisant un logiciel de manipulation et de traitement des images, il est ensuite possible de v´erifier le r´esultat obtenu.

Les Figures C.5 et C.6 illustrent les r´esultats de la simulation obtenus pour les deux modules de traitement. Sur chaque figure on montre : – L’image a` traiter, une bande de cette image et un agrandissement sur quelques lignes successives de la bande permettant le traitement de plusieurs fenˆetre successives.

– La bande de r´esultat, obtenue apr`es le traitement, l’agrandissement sur les lignes cor- respondantes des fenˆetres trait´ees.

– La partie du chronogramme de fonctionnement d’un module de traitement correspon- dant au traitement des fenˆetres successives indiqu´ees.

Pour les deux mod`eles de circuit et les bancs d’essai fourni, le processus de simulation n’as rapport´e aucune erreur de simulation. Les fichiers des images de r´esultat montrent bien l’effet du filtrage.

207 Annexe C. Architecture reconfigurable 1 2 3 F F F ~ ~ ~ 1 22 8 é 1 0 1 7 x x x x x 0 4 1 5 x x x x x 0 3 5 5 5 5 4 7 5 10 10 10 5 99 4 0 5 ns 7 9 4 8 8 110 110 110 00 3 8 1 2 2 2 6 5 0 6 e 7 9 4 1 3 11 11 11 é 2 3 3 3 4 8 9 3 it 3 8 11 11 11 10 a 88 3 3 3 4 88 37 tr 11 11 11 10 6 5 7 3 3 3 4 3 9 8 Bord de la bande non trait 1 11 11 11 10 7 7 4 5 5 5 88 1 6 10 10 10 101 5 9 1 Image 5 7 6 99 9 5 1 101 101 101 7 4 0 8 9 8 6 9 9 7 3 4 7 4 0 1 9 ns 5 00 1 8 0 4 66 1 7 0 6 4 1 4 11 5 2 5 0 0 1 0 5 3 3 1 8 5 4 4 8 9 3 33 2 5 11 10 8 2 3 4 4 5 7 3 0 11 1 7 2 100 10 3 0 4 5 5 7 5 9 6 2 33 4 7 F 10 10 ~ 3 0 2 0 0 0 8 9 9 2 3 3 3 10 110 33 11 6 7 2 6 1 7 5 6 9 9 3 1 37 0 3 10 11 1 3 4 9 1 2 0 4 33 1 37 89 1 100 11 10 7 0 5 7 8 5 1 6 3 9 1 1 33 9 99 1 10 5 11 2 5 7 7 3 7 6 ns 2 8 9 99 6 8 2 3 5 3 00 8 3 7 1 2 0 2 4 1 7 9 9 88 4 4 6 101 0 33 5 1 0 11 73 89 99 9 6 3 100 2 0 3 r 11 e 7 1 2 it F 9 a ~ 1 tr 3 5

1 11 à 5 7 0 2 1 1 1 0 4 1 7 1 6 6 1 Image 11 33 2 5 0 7 1 0 7 2 11 2 20 11 ns 1 3 1 200 F 6 ~ 33 3 8 1 11 5 3 0 8 1 88 99 t t i x n e i i u n n clk i o _ i ata d ata ftMatr d i CopyLi Sh Fig. C.5: R´esultats de la simulation du mod`ele de circuit obtenu apr`es le placement et le routage. Module de calcul de filtre Max pour un voisinage de 3 3 pixels. ×

208 C.3. Validation des modules de traitement apr`es placement et routage 8 0 8 0 1 1 22 1 4 5 7 1 2 3 0 1 F F F ~ ~ ~ 0 é 3 7 2 x x x x x 99 x x x x x 7 8 00 ns 5 7 8 6 33 2 1 0 6 100 100 1 1 2 2 5 0 7 3 7 3 2 2 e 9 10 10 é 33 4 4 0 1 1 9 3 3 88 it 10 10 6 3 a 2 4 6 1 1 6 7 9 3 3 2 10 10 tr 4 1 4 7 1 1 7 2 9 3 3 3 1 100 10 6 9 7 99 99 9 33 33 66 Bord de la bande non trait 7 6 1 7 7 7 7 6 33 Image 9 9 9 6 3 4 8 0 3 7 7 3 2 3 8 9 9 9 8 4 9 7 3 4 7 1 3 33 9 5 7 6 8 4 6600 ns 3 8 0 4 4 4 5 0 3 1 0 5 6 5 4 5 7 8 3 0 9 3 3 1 8 5 4 8 9 3 33 2 5 6 3 10 9 7 3 F 4 4 5 7 3 0 ~ 1 7 2 100 10 33 0 4 5 5 7 5 9 6 2 33 4 10 10 6 3 0 0 0 8 0 2 9 2 3 3 9 2 10 110 4 7 6 7 2 6 1 7 9 9 9 3 1 37 0 3 10 11 44 1 3 4 9 5 33 1 37 89 2 100 11 10 200 3 00 ns 5 7 8 5 1 2 9 1 1 33 9 99 4 00 10 6 1 33 5 7 7 3 7 6 8 9 99 6 8 2 3 02 1 0 1 2 8 3 7 3 88 4 4 7 9 9 101 7 1 5 1 0 73 89 99 9 6 3 2 100 9 1 F r ~ 4 0 1 e 5 1 it 99 a 7 2 tr 1 4

7 à 9 1 6 44 1 33 200 7 00 1 Image 7 2 02 1 20 4 0 1 1 3 1 02 1 6200 ns 33 F ~ 00 1 8 1 99 3 8 7 9 88 3 9 t t i x n n i i u n clk i eI o _ n i ata d ata ftMatr d i Sh CopyLi

Fig. C.6: R´esultats de la simulation du mod`ele de circuit obtenu apr`es le placement et le routage. Module de calcul de filtre m´edian (l’algorithme de Danielsson) pour un voisinage de 3 3 pixels. ×

209 Annexe C. Architecture reconfigurable

210 Glossaire

API Application Programming Interface ASIC Application Specific Integrated Circuit Bit-s´erie voir p.101 Bit-parall`ele voir p.101 CCD Charge Coupled Device CISC Complex Instruction Set Computer CLB Configurable Logic Bloc CLE Cellule logique ´el´ementaire CPU Central Processing Unit DDR-SDRAM Double Data Rate - Synchronous Dynamic RAM DSP Digital Signal Processor DPGA Dynamically Programmable Gate Array EPROM Erasable Programmable Read Only Memory Fenˆetre voir p.10 FPGA Field Programmable Gate Array GPU Graphics Processor Unit ILP Instruction Level Parallelism IOB Input Output Bloc LUT Look Up Table M´emoire cache voir p.57 MFC Microsoft Foundation Classes MISD voir p.27 MIMD voir p.27 MMX Multi Media Extensions PBF Plan de bits de la fenˆetre PBV Plan de bits du voisinage Process voir p.49 RAM Random Access Memory RISC Reduced Instruction Set Computer R´eseau de tri voir p.106 SISD voir p.27 SIMD voir p.27 SSE Streaming SIMD Extensions Thread voir p.49 UAL Unit´e arithm´etique logique VHDL VHSIC Hardware Description Language VHSIC Very High Speed Integrated Circuits Voisinage voir p.10

211 212 Bibliographie

[Ack02] S. Ackerman. Video Pre-Compression Processing. Technical report, Teranex Inc., 2002. [Act03] Actel. Axcelerator Family FPGAs. Actel Product Specification, 2003. [AFSS00] R. Andraka, P. Friedin, S. Singh, and T. Southgate. The John Henry Syndrome : Humans vs. Machines as FPGA Designers. ACM/SIGDA Eight International Symposium on Field Programmable Gate Arrays, Monterey, California, 2000. [AIP97] A.Gasteratos, I.Andreadis, and Ph.Tsalides. Realization of Rank-Order Filters Based on Majority Gate. Pattern Recognition, 30(9) :1571–1576, septembre 1997. [AIP00] A.Gasteratos, I.Andreadis, and Ph.Tsalides. Non-linear Image Processing in Hardware. Pattern Recognition, 33(6) :1013–1021, septembre 2000. [AK97] J. Astola and P. Kuosmanen. Fundamentals of Nonlinear Digital Filtering. CRC Press, 1997. [Alp04a] AlphaData. ADP-WRC-II Hardware Overview, Version 1.2, 2004. [Alp04b] AlphaData. ADP-WRC-II, Product Specifications, 2004. [Alt03a] Altera. Product selection guide, 2003. [Alt03b] Altera. Stratix Device Handbook. Altera Product Specification, 2003. [BAK96] D. A. Buell, J. M. Arnold, and W. J. Kleinfelder. Splash 2 - FPGAs in a Custom Computing Machine. IEEE Computer Society, 1996. [Bat68] K. E. Batcher. Sorting Networks and their Applications. In AFIPS Spring Joint Com- puter Conference, volume 32, pages 307–314, 1968. [BCB02] K. Benkrid, D. Crookes, and A. Benkrid. Design and Implementation of a Novel Al- gorithm for General Purpose Median Filtering on FPGAs. In Proceedings of the IEEE International Symposium on Circuits and Systems (ISCAS2002), volume 4, pages 425– 428, 2002. [BCCM91] A. Biancardi, V. Cantoni, U. Cei, and M. Mosconi. Morphological Operators on a Mas- sively Parallel Fine Grained Architecture. In Springer Verlag, editor, Computer vision : Specialized processors for Real Time Image Analysis, Workshop Proceedings Barcelona, Spain, pages 33–47, 1991. [Bit82] J. R. Bitner. An asymptotically optimal algorithm for the dutch national flag problem. SIAM Journal on Computing, 11(2) :243–262, May 1982. [BM85] R. S. Boyer and J. S. Moore. Program Verification. Journal of Automated Reasoning, 1(1) :17–23, 1985. [BMM97] R. Bernstein, M. Moore, and S. Mitra. Adjustable quadratic filters for image enhance- ment. International Conference on Image Processing (ICIP ’97), 3, 1997. [BOI93a] R. S. Bajwa, R. M. Owens, and M. J. Irwin. A Massively Parallel Micro-Grained VLSI Architecture. In International Conference on VLSI Design’93, 1993.

213 Bibliographie

[BOI93b] R. S. Bajwa, R. M. Owens, and M. J. Irwin. Image Processing with the MGAP : A Cost Effective Solution. In International Parallel Processing Symposium, 1993. [Bov87] A. C. Bovik. Streaking in median filters. IEEE Transactions on Acous. Speech Signal Processing, 35(4), 1987. [BR96] S. Brown and J. Rose. FPGA and CPLD Architectures : A Tutorial. IEEE Design and Test of Computers, 1996. [BW00] J. Birnbaum and R. S. Williams. Physics and the Information Revolution. Physics Today, pages 38–42, January 2000. [CC89] M. Coster and J. L. Chermant. Pr´ecis d’Analyse d’Images. Presse du CRNS, 1989. [CD99] R. Cutler and L. Davis. Developing Real-Time Vision Application for Intel Pentium III based Windows NT Workstations. FRAME-RATE : Frame-rate Applications, Methods and Experiences with Regularly Available Technology and Equipment in conjunction with IEEE International Conference on Computer Vision (ICCV), September 1999. [CDF+86] W. S. Carter, K. Duong, R. H. Freeman, H. C. Hseih, J. U. Ya, J. E. Mahoney, L. T Ngo, and S. L. Sze. A User Programmable Reconfigurable Logic Array. Proceedings of the Custom Integrated Circuits Conference, pages 233–235, 1986. [CG02] L. Cai and D. Gajski. Introduction of Designed-Oriented Profiler of Spec-C Language, March 2002. [CH84] E. Cloud and W. Holsztynski. Higher efficiency for parallel processors. In Proceedings IEEE Southcon 84, pages 416–422, 1984. [Cha93a] C. Chakrabarti. Sorting Networks Based Architectures for Median Filters. In IEEE Transactions on Circuits and Systems, pages 723–727, 1993. [Cha93b] F. Charot. Architectures paralleles specialisees pour le traitement d’image. Technical Report 1978, INRIA- Rennes, France, 1993. [Cha94] C. Chakrabarti. High Sample Rate Array Architectures. In IEEE Transactions on Signal Processing, pages 707–712, 1994. [Che89] K.w Chen. Bit-Serial Realizations of a Class of Nonlinear Filters Based on Positive Boolean Functions. In IEEE Transactions on Circuits and Systems, volume 36, pages 785–794, 1989. [Chu96] K. L. Chung. A fast pipelined median filter network. Signal Processing, 51(2) :133–136, 1996. [CL92] L. Chang and J. Lin. A bit-level systolic array for median filter. In IEEE Trans. Signal Process., volume 40, pages 2079–2083, 1992. [CL98] C. Chakrabarti and L. E. Lucke. VLSI Architectures for Weighted Order Statistic (WOS) Filters. In Proceedings of the IEEE Int. Symposium on Circuits and Systems, Monterey, California, volume 2, pages 320–324, 1998. [Clo88] E. Cloud. The geometric arithmetic parallel processor. In Proceedings Frontiers of Massively Parallel Processing, 1988. [Clo91] E. Cloud. Geometric arithmetic parallel processor : Architecture and implementation. In Parallel Architectures and Algorithms for Image Understanding, 1991. [CME93] C. Chou, S. Mohanakrishnan, and J. B. Evans. FPGA implementation of digital filters. In Proceedings of the Fourth International Conference on Signal Processing Applications and Technology, pages 80–88, Santa Clara, CA, 1993. [CN01] P. Cassou-Nogu`es. Hilbert. Les Belles Lettres, 2001. [CR93] S.A. Cucacaro and C.F. Reese. The cm-2x : A hybrid cm-2/xilinx prototype. Proc. IEEE of Workshop on FPGAs for Custom Computing Machines, 1993. [CS92] C. Chakrabarti and S.Dhanani. Median Filter Architectures based on Sorting Networks. In Proceedings of IEEE International Conference on Circuits and Systems, 1992.

214 Bibliographie

[CSC96] H. M. Chang, M. H. Sunwoo, and T. H. Cho. Implementation of a SliM Array Processor. In 10th International Parallel Processing Symposium (IPPS ’96), 1996. [CW96] E. M. Clarke and J. M. Wing. Formal methods : state of the art and future directions. ACM Computing Surveys, 28(4) :626–643, 1996. [Dan81] P. E. Danielsson. Getting the median faster. Computer Graph. Image Proc. 17, pages 71–78, 1981. [DBH+00] B. A. Draper, A. P. Willem B¨ohm, J. Hammes, W. Najjar, J. R. Beveridge, C. Ross, M. Chawathe, M. Desai, and J. Bins. Compiling SA-C Programs to FPGAs : Performance Results. International Conference on Vision Systems, Vancouver, pages 220–235, 2000. [Dij76] E. W. Dijkstra. A Discipline of Programming. Prentice-Hall, 1976. [Duf83] M. J. B. Duff. Computing Structures for Image Processing. Academic Press, Inc., 1983. [Dun90] R. Duncan. A Survey of Parallel Computer Architectures. IEEE Computer Society Press, pages 5–16, 1990. [ELS00] S. Elzinga, J. Lin, and V. Singhal. Design tips for HDL implementation of arithmetic functions. Xilinx Application Note XAPP215, 2000. [FE63] R.H. Fuller and G. Estrin. Some applications for content addressable memories. In AFIPS Confer. Proc. 1963 EJCC, volume 24, pages 495–508, 1963. [Fet95] Y. Fet. Parallel Processing in Cellular Arrays. Research Study Press Ltd., 1995. [Flo67] R. Floyd. Assigning meaning to programs. In J. T. Schwartz, editor, Mathematical Aspects of Computer Science, number 19 in Proceedings of Symposia in Applied Mathe- matics, pages 19–32. American Mathematical Society, 1967. [Fly72] M.J Flynn. Some Computer Organizations and their Effectiveness. IEEE Trans. Com- puters C-21, 9 :948–960, 1972. [Fom99] M. I. Fomitchev. MMX technology code optimization. Dr.Dobb’s Journal, 1999. [Fra97] R. Fraer. Analyse de programmes annot´es par des assertions. PhD thesis, L’Universit´e de Nice - Sophia Antipolis U.F.R. Facult´e des Sciences, 1997. [Fru92] M.A. Frumkin. Systolic computations. Kluwer Academic Publishers, 1992. [Ful99] R. Fulton. Creating most efficient comparators. XCell Journal, 1999. [Ger00] J. Gerlach. SystemC : A C++ Based Modeling Platform for System Level Design. In Workshop on Synthesis and System Integration of Mixed Technologies (SASIMI 2000), Kyoto, Japan, April, 2000. [GHC+92] M. Gokhale, W. Holmes, A. Copser, S. Lucas, R.Minnich, D.Sweely, and D.Loprest. Building and Using a Highly Programmable Logic Array. IEEE Computer, 24 :81–89, 1992. [Gop04] L. Gopalakrishnan. Synthesizable 400 Mb/s DDR SDRAM Controller, Xilinx Application Note 253, v2.3, Juin 2004. [GR00] J. Gerlach and W. Rosenstiel. System Level Design Using SystemC Modeling Platform. In Workshop on System Design Automation (SDA 2000), pages 185–189, Rathen, Germany, March, 2000. [Gro00] S. Grossman. Digital Camera Chip Set Delivers High Quality Images at 50Mpixels/sec. Electronic Design, 2000. [Guc00] S. Guccione. List of FPGA-based Computing Machines. http ://www.io.com/ guccione/, 2000. [HA28] D. Hilbert and W. Ackermann. Grundzuge der Theoretischen Logik. Berlin : Julius Springer, 1928. [HAIG99] A.A. Hiasat, M.M. Al-Ibrahim, and K.M. Gharaibeh. Design and implementation of a new efficient median filtering algorithm. VISP, 146(5) :273–285, October 1999.

215 Bibliographie

[Hew00] Hewlett Packard. PA-RISC 8x00 Family of With Focus on PA-8700, April 2000. [Hil02] D. Hilbert. Sur les probl`emes futurs des math´ematiques : les 23 questions. Gauthier- Vilars r´eimpr.Sceaux, Gabay, 1902. Comptes rendus du II`eme Congr`es International de math´ematiques tenu a` Paris du 6 au 12 aoutˆ 1900. [HJ90] J.N. Hwang and J.M. Jong. Systolic architecture for 2-D rank order filtering. In Pro- ceedings of the International Conference on Application Specific Array Processors, pages 90–99, 1990. [Hoa69] C. A. R. Hoare. An axiomatic basis for computer programming. Commun. ACM, 12(10) :576–580, 1969. [Hon96] A. De Hon. Reconfigurable Architectures for General-Purpose Computing. Technical Report 1586, Massachusetts Institute of Technology, Octobre 1996. [HSB84] W. Hannaway, G. Shea, and W. R. Bishop. Handling real-time images comes naturally to systolic array chip. In Electronic Design, November 1984. [HSU+01] G. Hinton, D. Sager, M. Upton, D. Boggs, D. Carmean, A. Kyker, and P. Roussel. The microarchitecture of the pentium 4 processor. Intel Technology Journal, 2001. [HT03] A. Habibi and S. Tahar. A Survey on System-On-a-Chip Design Languages. In Proc. IEEE 3rd International Workshop on System-on-Chip (IWSOC’03)), June 2003. [HZ98] K. Hwang and Z.Xu. Scalable Parallel Computing Technology, Architecture, Program- ming. McGraw-Hill, 1998. [ICL+94] G.B. Adams III, E.J. Coyle, L.C. Lin, L. Lucke, and K.K. Parhi. Input Compression and Efficient VLSI Architectures for Rank Order and Stack Filters. In Signal Processing, Special Issue on Nonlinear Signal Processing, 1994. [IEE00] IEEE. IEEE Standard VHDL Language Reference Manual. IEEE Std 1076, 2000 Edition, 2000. [Int97a] Intel Corporation. Intel Architecture Optimization Manual, 1997. [Int97b] Intel Corporation. Pentium II Processor Developer’s Manual, 1997. [Int99a] Intel Corporation. Image Processing Library - Reference Manual, 1999. [Int99b] Intel Corporation. Intel Architecture Software Developer’s Manual - Basic Architecture, 1999. [Int99c] Intel Corporation. Intel Architecture Software Developer’s Manual - Instruction Set Re- ference, 1999. [Int99d] Intel Corporation. Intel Architecture Software Developer’s Manual - System Programming Guide, 1999. [Int99e] Intel Corporation. Intel Pentium 4 Processor Optimisation, 1999. [Int01] Intel Corporation. Introduction to Hyper-threading Technology, 2001. Document number : 250008-002. [Int02] Intel Corporation. Intel C++ Compiler - User’s Guide, 2002. [JBH95] K. S. Joo, T. Bose, and J. W. Hall. 2D Nonlinear Adaptive Filtering for Image Restora- tion. IEEE Workshop On Nonlinear Signal and Image Processing, 1995. [JPJ96] E. Juliussen and K. Petska-Juliussen. The 8th Annual Computer Industry Almanac. Technical report, Computer Industry Almanac, 1996. [JW89] N. P. Jouppi and D. W. Wall. Available instruction-level parallelism for superscalar and superpipelined machines. In Proceedings of the 3rd International Conference on Architectural Support for Programming Languages and Operating System (ASPLOS), volume 24, pages 272–282, New York, NY, 1989. ACM Press.

216 Bibliographie

[KA95] P. Kuosmanen and J. Astola. Soft Morphological Filtering. J. Mathematical Imaging and Vision, 5 :231–262, 1995. [KL78] H.T. Kung and C.E. Leiserson. Algorithms for VLSI processors arrays. Sparse Matrix Proceedings, SIAM press, pages 256–282, 1978. [Knu73] D. E. Knuth. The Art of Computer Programming : Sorting and Searching, volume 3. Addison Wesley, 1973. [KOA90] M. Karaman, L. Onural, and A. Atalar. Design and Implementation of a General-Purpose Median Filter Unit in CMOS VLSI. In IEEE Journal of Solid-Sate Circuits, volume 25, pages 505–513, 1990. [Kun80] H.T. Kung. The Structure of Parallel Algorithms. Adv. in Computing, SIAM press, 9 :65–112, 1980. [Kup95] R. K. Kupta. Co-Synthesis of Hardware and Software for Digital Embedded Systems. Kluwer Academic Publishers, Boston, USA, 1995. [Lec99] J.E. Lecky. Turbochanged algorithms. Image Processing, pages 16–20, March 1999. [LLC03] T.W. Lee, J. H. Lee, and S.B. Cho. FPGA implementation of a 3x3 window median filter based on a new efficient bit-serial sorting algorithm. In Proceedings of the 7th Korea-Russia International Symposium - KORUS 2003, pages 237–242, 2003. [Lou00] S. Loughran. Win32 programming faq, revision 3.2, 2000. [LP92] L.E. Lucke and K.K. Parhi. A new VLSI architecture for rank order and stack filters. In Proc.of the IEEE International Symposium on Circuits and Systems, San Diego, May 1992. [Mar94] J. Marguin. Histoire des instruments et machines a` calculer. Trois ci`ecles de m´ecanique pansante. Paris, Hermann, 1994. [Mat74] G. Matheron. Random Sets and Integral Geometry. New York : Wiley, 1974. [MBH+02] D. T. Marr, F. Binns, D. L. Hill, G. Hinton, D. A. Koufaty, J. A. Miller, and M. Upton. Hyper-threading technology and microarchitecture. Intel Technology Journal, 2002. [McC01] S. McCartney. Eniac : The Triumphs and Tragedies of the World’s First Computer. Penguin Putnam, 2001. [McF93] M. C. McFarland. ”formal verification of sequential hardware : A tutorial”. ”IEEE Transactions on computer-Aided Design of Integrated Circuits and Systems”, 12(5) :633– 654, 1993. [McM78] C. L. McMaster. An analysis of algorithms for the dutch national flag problem. CACM, 21(10) :842–846, October 1978. [Mic99] G. De Micheli. Hardware Synthesis From C/C++ Models. In Proceedings of the Confe- rence on Design, Automation and Test in Europe, page 80, 1999. [Moo65] G. E. Moore. Cramming More Components Onto Integrated Circuits. Electronics, 38 :114–117, 1965. [MS00] G. Matheron and J. Serra. The Birth of Mathematical Morphology. 5`eme Congr`es de la Soci´et´e Internationale de Morphologie Math´ematique, 2000. [Not97] Intel Pentium 2 Processor Application Notes. Using the rdtsc instruction for performance monitoring, 1997. [Ofl83] K. Oflazer. Design and implementation of a single chip 1-D median filter. In IEEE Trans on Acoust., Speech, and Signal Processing, volume ASSP-30, pages 1164–1168, 1983. [OINB93] R. M. Owens, M. J. Irwin, C. Nagendra, and R. S. Bajwa. Computer Vision on the MGAP. In Computer Architectures For Machine Perception, pages 337–341, 1993. [PS04] Photo-Sonics. Photo-Sonics Phantom V4.0 High Speed Color Digital Camera, 2004.

217 Bibliographie

[PTVF02] W. H. Press, S. A. Teukolsky, W. T. Vetterling, and B. P. Flannery. Numerical Recipes in C++. Cambridge University Press, 2002. [Ram95] G. Ramponi. A Simple Cubic Operator for Sharpening an Image. IEEE Workshop On Nonlinear Signal and Image Processing, 1995. [RP93] G. Ravi and E. Paraskevas. Design and Implementation of an Efficient General-Purpose Median Filter Network. In Digital Signal Processing, volume 3(1), pages 64–72, January 1993. [RS95] G. Ramponi and G. L. Sicuranza. Quadratic Filters for Image Processing. IEEE Tran- sactions on Acous, 1995. [Sec93] Second History of Programming Languages Conference. The developement of the C language, Cambridge, April 1993. [Sed98] R. Sedgewick. Algorithms in C++ : Fundamentals, Data structures, Sorting and Sear- ching. Addison Wesley, 1998. [Ser82] J. Serra. Image Analysis and Mathematical Morphology. London : Academic, 1982. [Shi96] S. G. Shiva. Pipelined and Parallel Computer Architectures. Harper Collins College Publishers, 1996. [Sin00] S. Singh. Death of RLOC ? Proceedings of the 2000 IEEE Symposium on Field Progam- mable Custom Computing Machines, 2000. [Ski85] D.B. Skililcorn. A Taxonomy for Computer Architectures. IEEE Computer 21, 11 :46–57, 1985. [SM56] A.E. Slade and H.C. McMahon. A Cryotron Catalog Memory. In AFIPS Conference Proceedings 1956 EJCC, volume 10, pages 115–120, 1956. [Smi96] J. Smith. Implementing Median Filters in XC4000E FPGAs. XCELL, Q4(23), 1996. [Soi99] P. Soille. Morphological Image Analysis. Springer-Verlag, 1999. [Swa01] S. Swan. An Introduction to System-Level Modeling in SystemC 2.0, 2001. [TEL95] D. M. Tullsen, S. J. Eggers, and H. M. Levy. Simultaneous Multithreading : Maximizing On Chip Parallelism. In 22nd Annual International Symposium on Computer Architec- ture, Santa Margherita Ligurez, Italy, Juin 1995. [Tho61] J. E. Thornton. Parallel operation in the control data 6600. Fall Joint Computers Conference, 26 :33–40, 1961. [TT01] E. Trichina and A. Tiountchik. Scalable Algorithm for Montgomery Multiplication and Its Implementation on the Coarse-Grain Reconfigurable Chip. In D. Naccache, editor, Topics in Cryptology - CT-RSA 2001, The Cryptographer’s Task Track at RSA Confe- rence 2001, San Francisco, CA, USA, April 8-12, 2001, Proceedings, volume 2020, Kyoto, Japan, 2001. Springer. [VBD+96] J. Vuillemin, P. Bertin, D.Roncin, M. Shand, H. Touati, and P. Boucard. Programmable Active Memories : Reconfigurable Systems Come of Age. IEEE Transactions on VLSI systems, 4(1), 1996. [VL96] S. Vanderwiel and D. J. Lilja. A Survey of Data Prefetching Techniques. University of Minnesota, octobre 1996. [VSS99] D. Mac Vicar, S. Singh, and R. Slous. B´ezier Curve Rendering on Virtex. In Procee- dings of Field Programmable Custom Computing Machines (FCCM 1999), Los Alamitos, California, USA, 1999. IEEE Computer Society Press. [Vui94] J. Vuillemin. On Computing Power. Technical report, Digital Equipment Corporation - Paris Research Laboratory, Juin 1994. PRL Research Report 39. [WCN86] P. Wendt, E. Coyle, and N.Gallagher. Stack filters. IEEE Transactions on Acoustics, Speech and Signal Processing, ASSP-34(6) :898–911, 1986.

218 Bibliographie

[Wha02] R. Whatcott. Timing Closure. Xilinx support, 2002. [WLM+98a] N. Woolfries, P. Lysaght, S. Marshall, G. McGregor, and D. Robinson. Fast Adaptive Image Processing in FPGAs Using Stack Filters. In Reiner W. Hartenstein and Andres Keevallik, editors, Field-Programmable Logic : From FPGAs to Computing Paradigm, pages 406–410. Springer-Verlag, Berlin, 1998. [WLM+98b] N. Woolfries, P. Lysaght, S. Marshall, G. McGregor, and D. Robinson. Fast Implemen- tation of Non Linear Filters Using FPGAs. In IEE Colloquium on Non-Linear Signal and Image Processing, Mai 1998. [WLM+98c] N. Woolfries, P. Lysaght, S. Marshall, G. McGregor, and D. Robinson. Non Linear Image Processing on Field Programmable Gate Arrays. In NOBLESSE Workshop on Non-linear Model Based Image Analysis, Glasgow, Proc. NMBIA’98, pages 301–307, 1998. [Wol99] J. H. Wolf. Programming methods for the pentium iii processor’s streaming ex- tensions using the vtune tm performance enhancement environment. Intel Technology Journal, 1999. [Xil97] Xilinx. Gate Count Capacity Metrics for FPGAs. Xilinx application note, 1997. [Xil02] Xilinx. Virtex-II Platform FPGAs : Introduction and Overview. Advanced Product Specification, 2002. [Xil03a] Xilinx. ISE 5.1i Development System Reference Guide, Aout 2003. [Xil03b] Xilinx. ISE 6.1i Constraints Guide, Septembre 2003. [Xil03c] Xilinx. Synthesis and Verification Design Guide, version 4.0, Juin 2003. [Xil03d] Xilinx. Virtex II Platform FPGAs : DC and Switching Characteristics. Xilinx Product Specification, 2003. [Xil03e] Xilinx. Virtex II Platform FPGAs : Detailed Descriptions. Xilinx Product Specification, 2003. [Xil03f] Xilinx. Virtex II Platform FPGAs : Introduction and Overview. Xilinx Product Specifi- cation, 2003. [Xil03g] Xilinx. Virtex II-Pro Platform FPGAs : Introduction and Overview. Xilinx Product Specification, 2003. [Xil03h] Xilinx. XST User Guide, version 4.0, Juin 2003.

219