Université Libre De Bruxelles

Université Libre de Bruxelles Faculté de Sciences appliquées Service des Systèmes Logiques et Numériques

Implémentation des filtres non-linéaires de rang sur des architectures universelles et reconfigurables Dragomir Milojevic

Promoteur : Prof. Philippe Van Ham

Travail présenté en vue de l’obtention du titre de Docteur en Sciences Appliquées Année Académique 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 également au Prof. Nadine Warzée, pour son soutien, son efficacité et pour sa grande disponibilité.

Je remercie également : Le Prof. Marc Acheroy et les membres du SIC de l’Ecole´ Royale Militaire avec lesquels j’ai eu l’opportunité de faire de la recherche appliquée dans un but huma- nitaire et de réaliser des expériences 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’équipe du laboratoire des Systèmes Logiques et Numériques avec qui j’ai partagé beaucoup plus que le quotidien : prof. Jean Florine, Christophe De Hauwer (¸ca va être vite fait), Olivier Debeir (on va mettre encore une couje), Serge Joris (ma biche), Don Patrick Bischop (vive la Westmalle), Xavier Baele (le thé vert au jasmin est dans mon tiroir), Claude Verbeek (Led Zep a` 7h du matin annoncent une belle journée), Constant Hubert (il n’y a qu’un ampli a` lampes qui sonne bien), Denis Haumont, Laurent Mundeleer, Cédric Laugerotte, Thierry Leloup et tous les autres ... Merci a` Bill, Ella, Sarah, Billie, Isao, Eva, Patricia, et les autres de m’avoir accompagné a` tout moment.

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

Table des mati`eres

R´esum´e 1

Abstract 1

1 Introduction 5 1.1 Présentation générale ...... 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éaires ...... 13 1.3.2.1 Classification ...... 13 1.3.2.2 Filtres non-linéaires de Classe I ...... 14 1.3.2.3 Filtres non-linéaires de Classe II ...... 18 1.3.2.4 Exemples d’application des filtres non-linéaires ...... 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édicacées ...... 31 1.4.2.3 Taxinomies des architectures selon la configurabilité . . . . . 32 1.5 Performance ...... 33 1.5.1 Performance du matériel ...... 33 1.5.1.1 Paramètres classiques ...... 34 1.5.1.2 Paramètre commun ...... 35 1.5.2 Performance d’une application ...... 37 1.5.2.1 Temps d’exécution ...... 37 1.5.2.2 Accélération ...... 37 1.5.2.3 Mesure spécifique pour le traitement d’images ...... 38

i Table des mati`eres

2 Architecture universelle 39 2.1 Parallélisme des architectures universelles ...... 40 2.1.1 Parallélisme intra-processeur ...... 40 2.1.1.1 Parallélisme des instructions ...... 40 2.1.1.2 Problèmes liés a` l’exploitation du parallélisme des instructions 45 2.1.1.3 Parallélisme des données ...... 48 2.1.2 Parallélisme inter-processeur ...... 49 2.1.2.1 Parallélisme des systèmes a` mémoire partagée ...... 49 2.1.2.2 Parallélisme des systèmes a` mémoire repartie ...... 52 2.1.3 Processeurs actuels ...... 52 2.1.4 Architectures universelles ciblées ...... 53 2.1.4.1 Architecture standard ...... 53 2.1.4.2 Extensions ...... 55 2.1.4.3 Différences entre Pentium 2 et Pentium 4 ...... 57 2.1.4.4 Performance de la mémoire ...... 57 2.1.5 Exploitation des différents niveaux de parallélisme ...... 58 2.1.5.1 Accès au parallélisme intra-processeur ...... 58 2.1.5.2 Accès au parallélisme inter-processeur ...... 60 2.2 Exploitation de l’architecture standard ...... 62 2.2.1 Implémentation de filtre de rang généralisé ...... 63 2.2.1.1 Tri a` bulle (Bubble sort) ...... 63 2.2.1.2 Tri par sélection (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émentation des filtres spécifiques ...... 70 2.2.3 Conclusion ...... 70 2.3 Exploitation de parallélisme intra-processeur ...... 73 2.3.1 Librairie de traitement des images Intel ...... 74 2.3.2 Programmation des extensions : filtres spécifiques Min/Max ...... 74 2.3.2.1 Description générale 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édian ...... 85 2.3.4 Programmation des extensions : filtre d’un rang quelconque ...... 86 2.3.5 Filtres dérivés et/ou la chaˆıne de traitement ...... 86 2.3.6 Filtre de rang généralisé ...... 86 2.4 Exploitation du parallélisme inter-processeur ...... 88 2.4.1 Exécution sur deux processeurs ...... 88 2.5 Conclusion ...... 90 ii Table des matières

3 Architectures dédicacées 91 3.1 Circuits FPGAs ...... 92 3.1.1 Architecture ...... 92 3.1.1.1 Description générale ...... 92 3.1.1.2 Ressources typiques des FPGAs actuels ...... 93 3.1.2 Implémentation des circuits logiques dans les FPGA ...... 95 3.1.2.1 Processus d’implémentation ...... 95 3.1.2.2 Perspectives de la description des circuits ...... 97 3.1.2.3 Efficacité des outils actuels d’implémentation ...... 98 3.1.3 Applications des FPGAs ...... 100 3.2 Parallélisation du calcul des filtres non-linéaires ...... 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érie ...... 104 3.2.2.2 Mode bit-parallèle ...... 105 3.2.3 Réseaux de tri ...... 106 3.2.4 Architectures bit-série ...... 109 3.2.4.1 Algorithme pour le filtre de rang ...... 109 3.2.4.2 Cas particulier de filtre médian ...... 111 3.2.4.3 Généralisation de l’algorithme pour les filtres Min/Max . . . 114 3.2.4.4 Généralisation pour les autres filtres non-linéaires ...... 115 3.2.5 Architectures dédiées aux filtres de piles ...... 116 3.3 Conclusion ...... 118 3.3.1 Performance des systèmes dédicacés existants ...... 118 3.3.2 Remarques ...... 119 3.3.2.1 Remarques générales ...... 119 3.3.2.2 Remarques spécifiques a` l’architecture ...... 120 3.3.3 Objectifs ...... 122

4 Architecture reconfigurable 123 4.1 Description globale du système dédicacé 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émoire globale ...... 129 4.1.2.3 Unité de contrôle ...... 131 4.1.3 Hypothèses de travail ...... 132 4.2 Mémoire locale des unités de traitement ...... 133 4.2.1 Description de la mémoire locale source ...... 133 4.2.2 Description de la mémoire locale destination ...... 138 4.2.3 Validation de la description ...... 139 4.2.4 Implémentation ...... 141 4.2.5 Discussion ...... 143 4.3 Unités 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énéralisé ...... 146 4.3.2 Description de l’unité de traitement pour les filtres Max/Min . . . . . 149 4.3.3 Description de l’unité de traitement pour le filtre de rang généralisé . 153 4.3.3.1 Algorithme d’élimination successives des maxima/minima locaux ...... 153 4.3.3.2 Algorithme de Danielsson ...... 154 4.3.4 Validation de la description ...... 156 4.3.5 Implémentation ...... 159 4.3.5.1 Unité de traitement basée sur l’algorithme Min/Max . . . . . 161 4.3.5.2 Unité de traitement basée sur l’algorithme de Danielsson . . 161 4.3.5.3 Discussion ...... 162 4.4 Système reconfigurable complet ...... 163 4.4.1 Description du système complet ...... 163 4.4.2 Implémentation d’un module de traitement ...... 164 4.4.3 Etablissen´ t d’une correspondance entre ressources nécessaires et ressources disponibles ...... 169 4.4.4 Implémentation du système complet ...... 170 4.4.5 Débit des pixels traités ...... 171 4.5 Conclusion ...... 172

5 Discussion et conclusion 173 5.1 Problème, motivation et intérêt ...... 173 5.2 Implémentation sur l’architecture universelle ...... 174 5.3 Implémentation sur des architectures dédicacées reconfigurables ...... 175 5.4 Améliorations possibles ...... 177 5.5 Conclusion finale ...... 178

A Architecture universelle 181 A.1 Présentation générale de l’application ...... 181 A.2 Mesure de temps d’exécution d’une procédure ...... 183 A.2.1 Différentes méthodes de mesure de temps ...... 183 A.2.2 Analyse des mesures pour les procédures types ...... 183 A.3 Fonctionnement en mode multithread ...... 187 A.3.1 Mécanisme ...... 187 A.3.2 Influence de la priorité des threads sur le temps d’exécution ...... 187 A.4 Mesure de performance de la mémoire ...... 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 élémentaire ...... 192 B.1.2 Modes de fonctionnement d’un CLB ...... 193 B.1.3 Bloc de mémoire RAM ...... 194 B.1.4 Multiplicateur ...... 194 B.1.5 Digital Clock Manager - DCM ...... 195 B.1.6 Blocs d’entrée/sortie ...... 195 B.1.7 Réseau d’interconnexions ...... 195 iv Table des matières

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émentation des circuits proposées ...... 199 C.2 Validation des unités de traitement pour des voisinages de 5 5 et 7 7 pixels 203 × × C.3 Validation des modules de traitement après placement et routage ...... 207

Glossaire 211

Bibliographie 213

v Table des mati`eres

vi R´esum´e

Les filtres non-linéaires de rang sont souvent utilisés dans le but de rehausser la qualité d’une image numérique. Leur application permet de faciliter l’interprétation visuelle et la compréhension du contenu des images que ce soit pour un opérateur humain ou pour un traitement automatique ultérieur. Dans le pipeline d’une chaˆıne habituelle de traitement des images, ces filtres sont appliqués généralement dans la phase de pré traitement, juste après l’acquisition et avant le traitement et l’analyse d’image proprement dit.

Les filtres de rang sont considérés comme un important goulot d’étranglement 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éré et lorsque le rang approche la médiane.

Cette thèse propose deux solutions a` l’accélération du temps de traitement des filtres de rang.

La première solution vise l’exploitation des différents niveaux de parallélisme des ordinateurs personnels d’aujourd’hui, notamment le parallélisme de données et le parallélisme inter- processeurs. Une telle approche présente un facteur d’accélération de l’ordre de 10 par rapport a` une approche classique qui fait abstraction du matériel grâce aux compilateurs des langages évolués. Si le débit résultant des pixels traités, de l’ordre d’une dizaine de millions de pixels par seconde, permet de travailler en temps réel avec des applications vidéo, peu de temps reste pour d’autres traitements dans la chaˆıne.

La deuxième solution proposée est basée sur le concept de calcul reconfigurable et réalisée a` l’aide des circuits FPGA (Field Programmable Gate Array). Le système décrit combine les algorithmes de type bit-série et la haute densité des circuits FPGA actuels. Il en résulte un système de traitement hautement parallèle, impliquant des centaines d’unités de traitement par circuit FPGA et permet d’arriver a` un facteur d’accélération supplémentaire de l’ordre de 10 par rapport a` la première solution présentée. Un tel système, inséré entre une source d’image numérique et un système hôte, effectue le calcul des filtres de rang avec un débit de l’ordre de centaine de millions de pixels par seconde.

Mots-clefs Traitement des images, filtres non-linéaires, filtres de rangs, calcul parallèle, calcul reconfigurable, algorithmes bit-série, 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 ﬁlters 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 signiﬁcant 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 ﬁlter computing time acceleration.

The ﬁrst solution aims the exploitation of the various levels of parallelism of personal computers 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ésentation générale

La discipline de traitement des images numériques est souvent représentée comme une chaˆıne composée de trois maillons : l’acquisition de l’image, le traitement et/ou l’analyse suivis de l’exploitation des données obtenues. L’image, au départ représentée par un signal analogique, est transformée dans le domaine discret lors de l’acquisition. Le passage du monde analogique vers le monde numérique est souvent accompagné par une dégradation de l’information, dueˆ principalement aux imperfections du processus d’acquisition, de conversion et de transmission. Lors du traitement, l’aspect visuel de l’image numérique acquise peut être amélioré en effectuant diverses opérations de filtrage. Dans la phase d’analyse, une ou plusieurs caractéristiques significatives sont extraites de l’information numérique d’une seule ou d’une série d’images. Les paramètres ainsi obtenus sont ensuite utilisés par un opérateur humain ou par un système doté d’une intelligence artificielle afin de mieux saisir l’information visuelle, de prendre une décision particulière, ou encore d’automatiser entièrement une activité.

Actuellement, le processus d’acquisition des images numériques peut se faire avec une très grande précision1 et vitesse2 ce qui a pour conséquence un débit de données qui peut facilement atteindre plusieurs dizaines de mégaoctets par seconde, auquel le système de traitement et d’analyse3 doit pouvoir faire face. Si a` une aussi grande quantité de données on ajoute la complexité sans cesse croissante des traitements, le système qui automatise le processus de traitement doit pouvoir présenter 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és d’une résolution de l’ordre de plusieurs megapixels, chaque pixel étant quantifié sur 8 a` 12 bits, par composante couleur acquise. Une seule image est donc représentée par une quantité d’information de l’ordre de quelques mégaoctets. 2Pour les caméras numériques rapides, la fréquence 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é de données acquises. Dans la phase d’analyse on peut imaginer travailler sur une quantité d’information plus réduite : passage a` la représentation par objets, régions d’intérêt, codage des contours etc.

5 Chapitre 1. Introduction

2. distribuer le calcul entre plusieurs systèmes de traitement existants : la parallélisation, 3. ou créer des systèmes dédicacés, éventuellement parallèles.

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

L’augmentation de la vitesse des systèmes informatiques suit la prédiction de Gordon Moore annoncée déjà en 1965 [Moo65]. Cette prédiction, 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érifié depuis4. Cependant la raison nous suggère que le respect de cette loi ne pourra pas continuer indéfiniment car une limite, imposée par des lois physiques, doit exister. En 2000, les prévisions sur le développement de la technologie fixent cette limite dans deux décennies [BW00].

Des facteurs d’accélération beaucoup plus importants peuvent être obtenus en distribuant le calcul entre plusieurs systèmes de traitement. Le parallélisme et le traitement d’images ont une longue histoire dont les débuts remontent aux années ’80 [Duf83]. Depuis, d’importantes avancées technologiques dans la fabrication des composantes électroniques ont permis la réalisation de systèmes d’un parallélisme de plus en plus important, pour un prix de plus en plus faible.

La naissance de la nouvelle génération des circuits logiques programmables - les FPGA5 en 1986 [CDF+86], introduit un important changement du paradigme de calcul automatisé, celui du calcul reconfigurable. Grâce a` ces circuits il est possible de concevoir les systèmes de traitement ou` le matériel “s’adapte” a` un problème particulier de calcul, d’ou leur appellation. Le haut degré d’intégration des FPGAs implique la possibilité de parallélisation du traitement au sein d’un même circuit, dont le degré dépendra, bien entendu, de la complexité du traitement souhaité. Enfin le prix des FPGA n’est pas prohibitif, il s’agit de circuits commerciaux, destinés a` l’industrie électronique de faible volume de production ou l’usage des ASIC 6 ne serait pas rentable.

Les deux dernières solutions au problème du traitement des images numériques méritent donc d’être étudiées de plus près et représentent le principal fil conducteur de cette thèse.

Cette brève présentation générale a permis de mettre en évidence trois pôles : 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ève description du contenu de cette thèse ainsi que sa contribution dans le domaine de l’accélération du temps de calcul d’un type de traitement particulier.

Section 3 - Donne une introduction au problème particulier du traitement des images numériques qui nous intéresse : les filtres non-linéaires. Par leur nature, ces traitements s’avèrent particulièrement inadaptés aux architectures classiques et représentent souvent le goulot d’étranglement dans la chaˆıne de traitement.

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

6 1.1. Présentation générale

Section 4 - Propose un parcours des différentes architectures informatiques. Plusieurs taxinomies présentées permettrons de se familiariser avec les notions générales liées au calcul parallèle et nécessaires pour le développement de la suite.

Section 5 - Nous nous intéressons a` la performance de calcul et cette section a pour but de montrer comment elle peut être mesurée. A la même occasion, une comparaison de la puissance brute de calcul des processeurs et des FPGAs permettra de justifier l’emploi de ces derniers au problème posé.

7 Chapitre 1. Introduction

1.2 Contenu et contributions

1.2.1 Contenu

Cette thèse traite du problème de l’accélération du temps de calcul d’une classe particulière des filtres non-linéaires a` l’aide des architectures universelles et des architectures dédicacées reconfigurables, massivement parallèles.

De tous les filtres non-linéaires utilisés dans le traitement des images numériques nous allons nous limiter uniquement aux filtres de rang, car ces filtres représentent la brique de base pour la construction de la plupart des filtres non-linéaires. Ce choix est encore justifié 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émentations proposées mettent en opposition deux approches distinctes des architectures informatiques : 1. Approche des unités de traitement très rapides mais d’un parallélisme faible. 2. Approche d’un parallélisme d’unités 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éponse est fortement liée a` un tout indissociable : le problème - l’algorithme - le programme - le matériel. Ce dernier maillon est fortement lié a` un moment précis des technologies déployées pour sa fabrication et aura une influence directe sur la performance du traitement.

Mis a` part ce Chapitre d’introduction, cette thèse en propose quatre autres : Chapitre 2 - Architecture universelle Ici nous allons traiter de l’implémentation des filtres de rangs sur des ordinateurs personnels en tant qu’exemple type d’une architecture universelle, dotée d’un faible nombre d’unités de traitement fonctionnant a` grande vitesse. Nous allons montrer les limitations de tels systèmes surtout lorsqu’il s’agit de calculer les filtres considérés pour des voisinages de grande taille. Chapitre 3 - Architectures dédicacées Dans ce Chapitre on trouvera la description d’un ensemble d’algorithmes et de systèmes dédicacés existants permettant de calculer les filtres de rangs. Ce parcours nous aidera a` mettre en évidence les désavantages des systèmes proposés jusqu’à présent et justifier la nécessité d’une approche alternative. Chapitre 4 - Architecture reconfigurable Ce Chapitre contient la description d’un système reconfigurable de traitement original, caractérisé par un grand nombre d’unités de traitement d’une vitesse faible de fonctionnement. Néanmoins nous allons montrer qu’un tel système permet d’arriver a` un débit de traitement beaucoup plus important que celui d’une architecture universelle et des architectures dédicacées existantes. Chapitre 5 - Discussion et conclusion Enfin dans ce dernier Chapitre nous allons comparer les différents résultats obtenus, ce qui nous permettra de conclure.

8 1.2. Contenu et contributions

1.2.2 Contributions

Architecture universelle L’opération de tri constitue la tâche la plus récurrente dans le monde de l’informatique. De ce fait un grand nombre d’algorithmes de tri a été proposé, surtout pour des architectures universelles de type SISD. Malheureusement ces algorithmes ne sont pas vraiment adaptés au parallélisme de type SIMD et MIMD (ici on fait référence aux stations multi-processeurs a` mémoire partagée) intégrés dans la plupart d’architectures universelles d’aujourd’hui.

1. La contribution principale de cette thèse dans l’étude des architectures universelles se situe dans la conception d’algorithmes et de programmes ori- ginaux, permettant une exploitation optimale des différents niveaux de pa- rallélisme pour le calcul des filtres de rang. La démarche, celle d’une étude du matériel sous-jacent, de la conception d’algorithmes et de leur codage en fonction du matériel, démontre que pour ces applications particulières il est possible d’obtenir d’importants facteurs d’accélération par rapport a` une démarche classique ou` la seule étude algorithmique fait abstraction complète du matériel.

Architecture reconfigurable Les différentes implémentations des filtres de rang dans les architectures dédicacées proposées jusqu’à présent ne concernent que des voisinages de petite taille et des valeurs de rang pour lesquelles les algorithmes peuvent être considérablement simplifiés. De plus, les implémentations existantes n’envisagent pas la parallélisation du traitement, actuellement possible a` une grande échelle grâce au haut degré d’intégration des circuits intégrés.

2. Le principal apport de cette thèse dans l’accélération du calcul des filtres de rang a` l’aide des architectures reconfigurables est lié au développement d’un système de traitement original, ayant les caractéristiques suivantes :

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

(b) Le système permet de calculer les filtres de n’importe quelle valeur de rang, ce qui donne l’accès a` une multitude des filtres différents, utilisés a` des fins différentes.

(c) L’emploi des algorithmes en bit-série permet de maximiser le nombre d’unités de traitements pour un circuit FPGA de haute densité ainsi que leur vitesse de fonctionnement. Ces deux points ont pour corollaire la possibilité d’un haut débit des pixels traités, 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 human visual system indicates that it possesses nonlinear characteristics. This should be taken into account in image ﬁlte- ring. Fundamentals of non linear digital ﬁltering. Jakko Astola, Pauli Kuosmannen. Performance

1.3.1 Images et transformations

1.3.1.1 Notations

Une image numérique monochromatique est un signal de luminosité bidimensionnel, discret, présenté sous forme d’une matrice notée I[i, j] avec 0 i < Ix et 0 j < Iy. Pour ≤ ≤ des raisons de simplicité d’écriture, nous allons noter l’image sous forme d’un vecteur I[i], ou` chaque pixel est identifié par un seul indice i avec 0 i < NI et ou` NI = Ix Iy. ≤ ∗ On définit 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éfini par les distances Vx1, Vx2, Vy1 et Vy2 dans les quatre principales directions en partant du pixel considéré (voir Figure 1.1). Comme pour l’image, le voisinage d’un pixel est présenté sous forme d’une matrice notée V [m, n]. Pour des raisons de simplicité d’écriture nous utiliserons un seul indice pour désigner un élément 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 éléments 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éfinir un voisinage V , noté 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’équation 1.1 appartiennent au bord de l’image.

10 1.3. Traitement

On définit une fenêtre de l’image I comme une partie de cette image, de forme rectangulaire, notée sous forme d’une matrice F [k, l] avec 0 k < Fx, 0 l < Fy et ou` Fx, Fy désignent ≤ ≤ respectivement la taille horizontale et verticale de la fenêtre. Pour une fenêtre F et une image I nous avons toujours Fx Ix et Fy Iy. Tout comme pour l’image et le voisinage, une ≤ ≤ fenêtre sera notée sous forme d’un vecteur F [k], avec 0 k < NF . ≤ L’image I est découpée en un ensemble de fenêtres F qui présentent un recouvrement de Vx1 + Vx2 et Vy1 + Vy2 pixels (voir Figure 1.1). Cet ensemble de fenêtres permet d’accéder a` tous les voisinages Vi définis par l’équation 1.1.

La Figure 1.1 montre une image et deux fenêtres successives de cette image (en trait pointillé et en trait plein). Pour chaque fenêtre on peut définir (Fx Vx Vx ) (Fy Vy Vy ) − 1 − 2 ∗ − 1 − 2 voisinages : les pixels appartenant aux deux rectangles grisés. Pour la première fenêtre il s’agit du rectangle gris clair et pour la deuxième fenêtre du rectangle gris foncé. Un agrandissement de la première fenêtre illustre deux voisinages successifs des pixels i (en trait plein) et i + 1 (en trait pointillé).

Inx

V V x1 Fi x2 Fi+1

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ère toutes les fenêtres F d’une image I permettant de couvrir tous les pixels définis par l’équation 1.1. Comme en toute généralité nous avons :

Ix mod(Fx Vx ) = 0 − 2 6 Iy mod(Fy Vy ) = 0 (1.3) − 2 6 un certain recouvrement des fenêtres aux extrémités de l’image est nécessaire afin de couvrir tous les pixels indiqués.

11 Chapitre 1. Introduction

Dans le domaine spatial, le filtrage d’une image numérique consiste a` appliquer un opérateur de transformation de chaque pixel de l’image initiale I[i] en fonction des valeurs des pixels définis dans le voisinage Vi. D’une manière tout a` fait générale cette transformation est notée :

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ées sont alors dites ponctuelles (les opérateurs de pixel). L’exemple type d’un tel traitement est le seuillage, couramment utilisé pour séparer les objets de leur arrière plan. Un autre exemple sont les modifications linéaires ou non-linéaires de l’histogramme qui peuvent être utilisées pour améliorer le contraste de l’image. De telles opérations peuvent être réalisées a` l’aide de tables pré-calculées avant le traitement, afin de limiter le temps de calcul exclusivement au temps d’accès a` la mémoire.

1.3.1.3 Transformations spatiales

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

Filtres linéaires et non-linéaires Il existe une analogie entre les transformations spatiales et la notion de filtrage défini par la théorie du traitement des signaux analogiques, unidimensionnels. Le filtrage y est défini comme une transformation du signal a` l’entrée par un système linéaire, invariant dans le temps7 : le filtre.

La notion de filtrage d’un signal unidimensionnel et continu peut être étendue aux signaux discrets, bi-dimensionnels, telles qu’une image numérique. Dans ce cas l’opération de filtrage consiste a` calculer le produit de convolution entre l’image et la réponse 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ème est linéaire si la transformation du signal a` l’entrée est linéaire : T (af1[t] + bf2[t]) = aT (f1[t])+ bT (f2[t]). Le système est invariant dans le temps si une translation dans le temps du signal a` l’entrée se traduira par une même translation dans le temps du signal de sortie.

12 1.3. Traitement

En fonction du type de filtre choisi, les différents effets peuvent être obtenus : suppression des fortes transitions des niveaux de luminosité et apparition de flou ; ou justement le contraire : suppression de la composante continue dans l’image et mise en évidence des variations rapides.

Par opposition aux filtres linéaires ou` la valeur filtrée de l’image est obtenue par une combinaison linéaire des pixels du voisinage, dans le filtrage non-linéaire cette valeur est obtenue sur base de l’information statistique de pixels voisins. Ainsi, chaque voisinage Vi est trié au préalable, et la valeur filtrée est choisie sur base d’une fonction de rang.

Dans le cadre de cette thèse nous allons nous limiter aux filtres non-linéaires pour des raisons suivantes : 1. La parallélisation des filtres linéaires est un problème déjà largement étudié et leur implémentation dans les FPGAs est devenu une pratique courante (voir par exemple [CME93]). 2. La diversité des filtres non-linéaires est très importante et leur application fréquente pour un grand nombre des problèmes en traitement des images, comme nous allons le voir par la suite. Pour certains d’entre eux ils se montrent extrêmement efficaces, beaucoup plus efficaces que les filtres linéaires. 3. L’opération de tri est couteuseˆ malgré l’existence d’algorithmes rapides et la grande vitesse des architectures actuelles. En effet, le tri dans le voisinage, même d’une petite taille, doit être effectué 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 Classiﬁcation

Astola et Kuosmanen décrivent dans [AK97], un grand nombre de filtres non-linéaires appliqués au traitement des images numériques et proposent deux taxinomies de ces filtres. La première introduit les classes suivantes : les filtres linéaires généralisés, les filtres basés sur le tri, les filtres morphologiques et une classe “autre”. La deuxième taxinomie est faite sur base de l’interprétation de filtre en tant qu’estimateur ou en tant que filtre géométrique (filtres morphologiques). Les deux auteurs soulignant qu’aucune des deux taxinomies ne prétend être complète. En outre, ils émettent une réserve quant a` l’existence d’une taxinomie parfaite permettant de classer tous les filtres non-linéaires existants.

Comme nous nous intéressons aux aspects de calcul de ces filtres, nous proposons ici une classification basée sur la complexité des opérations impliquées. Nous définissons alors deux classes des filtres non-linéaires : la Classe I et la Classe II.

Les filtres de la Classe I nécessitent toujours une opération de tri, sur un voisinage complet ou sur un ensemble de sous-voisinages. D’autres opérations telles que la pondération, la sélection, le calcul de la valeur moyenne peuvent précéder ou suivre l’opération de tri.

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

13 Chapitre 1. Introduction

La Table 1.1 montre l’appartenance des différents filtres non-linéaires décrits dans [AK97] aux deux classes introduites.

Filtres non-linéaires Classe I Classe II Filtres de rang Médians hybrides Filtres de rang sélectif Moyens tronqués Médians a` multi-étages Moyens non-linéaires Morphologiques Filtres L et C Filtres de piles Polynômiaux

Tab. 1.1: Classification des filtres non-linéaires

1.3.2.2 Filtres non-lin´eaires de Classe I

Filtres de rang et filtres pondérés de rang8 t Pour le calcul des filtres de rang on considère un voisinage Vi , correspondant au voisinage Vi, trié par l’ordre croissant. Le pixel de l’image résultante 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èrement intéressants sont ceux déterminés par les rangs : r = 1, r = NV et r = NV /2. Il s’agit des filtres minimum, maximum et médian notés respectivement : min I , { } max I et med I . Les deux premiers filtres sont des opérateurs de base permettant la { } { } construction des filtres morphologiques tandis que le filtre médian est le plus souvent utilisé pour supprimer le bruit impulsionnel dans une image.

Les filtres pondérés de rang introduisent la possibilité de favoriser et/ou défavoriser certains pixels de voisinage Vi et ainsi palier au problème des filtres médians classiques ayant tendance a` supprimer les petits détails de l’image. Le calcul de ces filtres implique la recherche de la valeur médiane d’un voisinage initial Vi transformé : tous les éléments de Vi ont été répétés un certain nombre de fois. Le nombre de répétition de chaque élément de Vi est défini par le vecteur de poids P et l’opérateur de répétition, noté . ♦ 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éré peut| alors{z être }écrit comme| : {z }

I˜[i] = med P Vi , 0 i < NI (1.8) { ♦ } ≤ Filtre de rang sélectif Dans les filtres de rang classiques, le rang choisi est le même 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édians a` plusieurs étages Ces filtres impliquent le calcul de la valeur médiane de plusieurs filtres médians réalisés sur q sous-voisinages différents, 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ée, on définit habituellement quatre sous-voisinages élémentaires typiques : V1, V2, V3 et V4 (Figure 1.2) ainsi que leurs différentes 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

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

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

Fig. 1.2: Sous-voisinages types pour le calcul de filtre médian multi-étage

Filtres moyens tronqués Les valeurs extrêmes d’un voisinage trié peuvent jouer un rôle important sur le résultat final du filtrage. Afin de défavoriser les pixels trop éloignés de la valeur médiane, que l’on peut supposer moins significatifs, un filtre moyen tronqué calcule la moyenne d’un certain nombre t d’éléments du vecteur de voisinage trié Vi . Les différentes fa¸cons de choisir ces éléments vont donner naissance aux diverses variantes de ce filtre. Ainsi, le filtre (r,s) fold trimmed mean t filter fait exclusion des r premières et s dernières 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ères et s dernières 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 également possible de spécifier un intervalle, borné par des valeurs q1 et q2. Le filtre t t est alors calculé comme une moyenne de Vi uniquement pour des valeurs Vi [m] telles que t q1 < Vi [m] < q2 (filtre tronqué modifié). Une autre variante de ce filtre consiste a` calculer la moyenne des K éléments les plus proches de l’élément central de la suite Vi (filtre de K plus proches voisins).

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

15 Chapitre 1. Introduction

Filtres morphologiques Les filtres morphologiques dérivent de la morphologie mathématique introduite par Mathe- ron et Serra en 1964[MS00] et dont l’application au traitement des images est décrite dans deux ouvrages clés [Mat74, Ser82]. Initialement, la morphologie mathématique était destinée aux images binaires, mais son extension aux images en niveaux de gris futˆ rendue possible, grâce a` l’équivalence entre les notions ensemblistes et les fonctions (pour plus de détails voir [CC89] ou encore [Soi99]).

Les opérateurs de base de la morphologie mathématique sont dus a` Minkowski qui en 1903 définit des opérations ensemblistes d’addition (dilatation) et de soustraction (l’érosion). On considère une image binaire I comme un ensemble occupé partiellement par un ensemble d’objets9 noté X. On définit alors les deux opérateurs de base par la question : pour toute position p de l’espace de l’image I, est-ce que le voisinage10 V est entièrement inclu dans l’ensemble X ou est-ce qu’il touche l’ensemble X ? L’ensemble de p des réponses positives forme l’image érodée/dilatée. 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érateurs de base il est possible de définir d’autres opérateurs, 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érateurs morphologiques de base aux images en niveau de gris est définie par la plus grande valeur de I dans le voisinage Vi et la plus petite valeur pour l’érosion :

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érateurs ne sont donc rien d’autre que les deux filtres caractéristiques de rang, mentionnés plus haut. Nous avons donc : ERO V = min V = t t { } { } V [0] pour l’érosion et DIL V = max V = V [NV 1] pour la dilatation. { } { } − 9Dans une image binaire, une valeur est attribuée au fond de l’image et l’autre aux objets qui s’y trouvent. 10En morphologie mathématique le voisinage est appelé l’élément structurant. Comme nous définissons les opérateurs morphologiques comme une classe des filtres non-linéaires, définis avec la notion de voisinage, nous avons préféré, par souci de clarté, de garder l’appellation de voisinage. 10Le voisinage V d’un voisinage V est transposé 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érents filtres morphologiques classiques ne peuvent pas être utilisés pour le filtrage du bruit dans une image. Cependant, les filtres morphologiques mous (Soft Morphological Filters), introduits par Kuosmanen dans [KA95] sont utilisés pour une élimination très efficace du bruit impulsionnel. Pour les opérateurs mous de base, la notion de voisinage (de l’élément structurant), est étendue au système structurant composé d’un voisinage V , d’un centre C d’une certaine forme et taille11 et d’un rang r. Les opérateurs de base sont alors définis 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érateur de répétition défini a` l’équation 1.7.

A partir des opérateurs de base on peut définir les mêmes opérateurs dérivés de la morphologie mathématique classique tels que l ’ouverture, la fermeture et autres.

Filtres de piles Il est possible de définir toute une nouvelle classe des filtres non-linéaires grâce a` un codage des images particulier. Ce codage, désigné dans la littérature 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ésente le nombre de bits utilisés pour coder la couleur. Les éléments de ce vecteur sont déterminés 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é, noté V¨ , nous avons donc 2 plans de bits de NV bits chacun, notés 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ésentation de la même information.

Le filtre généralisé de piles consiste a` appliquer a` chaque plan de bits une fonction Booléenne positive12dans la littérature anglo-saxonne Positive Boolean Function ou PBF qui satisfait la propriété 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ébrique de 2b bits ainsi obtenus donne la valeur du voisinage filtré.

Les filtres minimum et maximum possèdent la propriété des piles et il est possible de les calculer en employant les fonctions logiques ET et OU sur le V¨ [o]. Le filtre médian possède également cette propriété, avec comme fonction Booléenne la médiane 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ême. 12Une fonction Booléenne positive est une fonction qui peut être écrite sous forme d’une expression composée de variables non-compleméntées. 13Une fonction Booléenne binaire qui renvoie la valeur médiane d’un vecteur trié des éléments 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é des valeurs 1, 5, 3, 7, 3, 9, 5, 9, 1 . Le voisinage trié et décomposé V¨ t est alors présenté 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édian hybride Il est possible de combiner les avantages des filtres linéaires et non-linéaires dans un seul filtre qui s’attaquera a` la fois au bruit impulsionnel et au bruit Gaussien d’une image. Un filtre médian hybride implique le calcul de q filtres linéaires fil sur le voisinage Vi avant l’application d’un filtre médian :

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

Si le nombre q de filtres linéaires appliqués est faible devant la taille du voisinage NV , l’implémentation d’un tel filtre peut se faire de manière efficace puisque la recherche de la valeur médiane n’implique pas le tri du voisinage complet.

Filtres moyens non-linéaires La forme générale d’un filtre moyen non-linéaire est donnée 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étique log x , moyenne géométrique g(x) = (1.22)  1  x , moyenne harmonique  p x R 1, 0, 1 , filtre moyen Lp.  ∈ \{− }  Les moyennes arithmétiqueet géométrique sont largement utilisées pour combattre le bruit Gaussien, tandis que la moyenne harmonique et le filtre moyen Lp sont plutôt utilisés pour le filtrage du bruit impulsionnel.

Filtres polynômiaux La forme générale d’un filtre polynômial d’ordre M est donnée 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ômiaux sont caractérisés par un important accroissement du temps de calcul pour les ordres supérieurs, la raison pour laquelle ils ne sont employés que très rarement dans le traitement des images. Néanmoins signalons que les filtres d’ordres inférieurs ont été utilisés avec succès pour la réduction du bruit des images faiblement contrastées [RS95], l’amélioration de la netteté [Ram95], la restauration [JBH95] et l’amélioration d’images numériques [BMM97].

Filtres L L’un des principaux inconvénients des filtres médians classiques concerne le déplacement des bords et l’apparition des artefacts [Bov87]. Les filtres L permettent de palier ce problème en combinant les effets d’un filtrage linéaire et non-linéaire. Ils consistent a` calculer la moyenne t des éléments du vecteur trié Vi , pondérés 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ètement différents peuvent avoir le même vecteur de voisinage trié et par conséquence le même résultat de filtrage. L’exclusion de l’information spatiale se traduit par une perte de l’information visuelle des petits détails de l’image. Les filtres C peuvent être considérés comme des filtres L mais a` la place d’un simple vecteur des poids, on dispose d’une matrice. Le choix des poids utilisés pour la pondération de chaque pixel de V est fonction du rang et de sa position spatiale au sein du voisinage. On peut alors écrire :

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 ﬁltres non-lin´eaires

La Figure 1.4 montre le résultat suite a` l’application d’un filtre linéaire et un filtre non- linéaire sur une image présentant un bruit impulsionnel. A l’image bruitée de la Figure 1.4.a ont été appliqués : – un filtre linéaire classique : la moyenne d’un voisinage de 5 5 pixels - Figure 1.4.b, × – suivi d’un filtre médian de même taille - Figure 1.4.c La Figure 1.4.d montre une zone d’intérêt agrandie et riche en détails : on peut remarquer sur les deux images filtrées une perte de détails (la texture de tissu), plus importante dans le cas d’un filtre médian.

a) b)

c) d)

Fig. 1.4: Elimination´ de bruit impulsionnel : filtre linéaire (moyenne) et filtre médian 20 1.3. Traitement

La Figure 1.5 montre qu’il est possible d’arriver a` un résultat de filtrage semblable avec des filtres morphologiques mous. La même image de l’exemple précédant - Figure 1.5.a, a été 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éro et le rang r = 5 - Figure 1.5.c L’agrandissement d’une zone d’intérêt - la Figure 1.5.d, montre une plus mauvaise conserva- tion de détails par rapport au filtrage médian.

a) b)

c) d)

Fig. 1.5: Elimination´ de bruit impulsionnel : ﬁltres morphologiques mous

21 Chapitre 1. Introduction

La Figure 1.6 montre l’application a` l’image initiale - Figure 1.6.a d’un gradient morphologique - Figure 1.6.b. Les opérations morphologiques : la dilatation et l’érosion ont été calculées avec des voisinages de taille 5 5 pixels. ×

a) b)

Fig. 1.6: Gradient morphologique

22 1.4. Machine

1.4 Machine

Ordinateur - Calculateur électronique doté de mémoires a` grande capacité, de moyens de traitement des informations a` grande vitesse, capable de résoudre des problèmes Traitement Machine arithmétiques et logiques complexes grâce a` l’exploitation automatique des programmes enregistrés. 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 ﬂows 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éaliser le calcul de fa¸con automatisée peut être divisée en trois périodes remarquables. Les premières machines a` calculer mécaniques capables de réaliser des opérations arithmétiques simples, ont été développées lors la première période remarquable, située entre le début de XVI-ème et la fin de XIX-ème siècle. Dans la deuxième période, qui couvre la première moitié du XX-ème siècle, les grandes découvertes liées aux mathématiques et a` la logique ont permis de poser les bases théoriques de l’informatique. Dès les années quarante, plusieurs machines construites, dites de la première génération des ordinateurs, marquent le début de la troisième période remarquable qui s’étend jusqu’à nos jours.

La première machine mécanique a` calculer14 futˆ construite par John Napier, mathématicien écossais qui au début de XVI-ème siècle (probablement vers 1610) construit les règles (dites de Napier), permettant d’effectuer les opérations arithmétiques de multiplication, de division et de racine carrée. En 1623, indépendamment de Napier, un autre “calculateur numérique” mécanique futˆ introduit par Wilhelm Schickard, dont la connaissance nous est parvenue uniquement par ces écrits avec Kepler. Le seul exemplaire de cette machine a` été brulˆ é en 1624, dans un incendie, probablement volontaire, afin de protéger son auteur des accusations d’actes de sorcellerie.

Indépendamment de Napier et de Schickard, Blaise Pascal construit en 1643 la Pas- caline, un autre calculateur numérique capable d’additionner et de soustraire les nombres a` plusieurs chiffres avec un report automatique. Quelques années plus tard, en 1673, Gott- fried Leibniz con¸coit une machine qui effectue les quatre opérations arithmétiques de base a` l’aide des engrenages. Sa machine réalise pour la première fois la multiplication comme l’addition successive dans un accumulateur. Leibniz soulève également l’idée de l’existence d’un procédé universel permettant de trouver une solution a` tout problème de fa¸con mécanique, par le calcul et sans “réfléchir”.

14Quoique en Chine, depuis 1300, on utilise couramment l’abacus pour eﬀectuer 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ées contenant l’information du motif. Plus tard, en 1822, Charles Bab- bage travaille sur la réalisation de la “Machine Différentielle” et de la “Machine Analy- tique”, mais aucune de ces machines ne fonctionna correctement. A cette même époque on constate la première commercialisation d’un calculateur numérique - l’arithmomètre 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-ème et le passage au XX-ème siècle marquent le début de la deuxième période remarquable et la reprise des idées de Leibniz sur la recherche des procédés permettant une automatisation de calcul. La reprise de ces idées trouve ses racines dans la volonté des mathématiciens de formaliser les mathématiques de fa¸con a` éviter tout paradoxe qu’elles pourraient engendrer, notamment ceux relevés par Cesare Burali-Forti (1899) et Bertrand Russell (1901) de la théorie des ensembles, formulée par Georg Ferdinand Cantor15 dès 1874.

L’idée d’une formalisation complète des mathématiques culmine avec le mathématicien David Hilbert qui est a` l’origine d’un programme dans lequel toute démonstration serait purement syntaxique, dépourvu de son sens sémantique. En outre, toute démonstration peut être ramené a` un procédé, une procédure effective i.e. un algorithme16, qui décrit seulement l’ordre de manipulation des symboles.

Le programme de Hilbert17 vise la recherche d’un système formel18 ainsi qu’une théorie de démonstration tels qu’il serait possible de : 1. Prouver la consistance19 2. Répondre aux questions de complétude20 3. Résoudre le problème de décision (Entscheidungsproblem)21. Le théorème de complétude, démontré par Kurt Godel¨ en 1928, répond positivement aux deux premières questions pour la logique du premier ordre. Au sein de ce système formel, il est donc possible de mécaniser toute démonstration.

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éponse positive. Selon Cantor la taille d’un ensemble composé de tous les sous-ensembles d’un ensemble donné est toujours plus grande que la taille de l’ensemble même. Or, ceci ne peut être appliquer sur l’ensemble universel car il contient déjà tout ! 16En 820 AD, Muhammed idn Musa Al-Khwarizmi, écrit une encyclopédie des procédés de calcul connus de son temps. A l’époque médiévale cet ouvrage futˆ diffusé dans le monde entier et son nom futˆ latinisé en algorithmus, pour être repris au XIX-ème siècle par Lady Ada Lovelace pour designer l’ensemble des règles opératoires 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ègles d’inférences. 19La question de la consistance a été soulevé par Hilbert pour la première fois en 1900, lors de son dis- cours au Congrès International des Mathématiciens a` Paris[Hil02] et peut être énoncé comme suit : Certains raisonnements valides peuvent-ils conduire vers des absurdités ? 20Tout énoncé peut-il être soit prouvé soit réfuté ? 21Le problème de décision a été formulé par Hilbert et Ackermann dans [HA28] et peut être énoncé comme suit : Existe-il une procédure effective (i.e. algorithme), qui, en un nombre fini d’opérations, permet de dire si un énoncé mathématique est vrai ou faux ?

24 1.4. Machine

Mais en 1931 avec le célèbre théorème d’incomplétude, Godel¨ démontre que dès que l’on fait intervenir dans un système formel l’arithmétique, même élémentaire, il existe des propositions indécidables : on ne peut donc pas trouver une procédure effective permettant de dire si ces propositions sont vraies ou fausses. Ce résultat réfute définitivement le programme d’ Hilbert et l’idée mécaniste des mathématiques.

Quant a` la question du problème de décision, une réponse négative a été donnée par les modèles abstraits de calcul développées dans les années ’30 - les fonctions récursives et le λ- calcul. En 1936, Alan Turing apporte également une réponse négative a` ce problème avec le célèbre article “On computable numbers, with an application to the Entscheidungsproblem”. Dans cet article il décrit les concepts d’une machine universelle - la machine de Turing et il démontre qu’une telle machine ne peut résoudre le problème d’arrêt (Halting Problem)22.

A cette époque des importantes avancées théoriques, on constate également la réalisation des premiers circuits élémentaires nécessaires pour une matérialisation des concepts théoriques. Ainsi le premier additionneur d’un bit a` été 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èrement électronique (à tubes) et en 1941 achève la construction d’une machine permettant de résoudre un système de 29 équations.

Le début de la troisième période remarquable, celle qui va donner naissance aux ordinateurs de la première génération, est lié a` la construction de deux calculateurs universelles (calculateurs contrôlés 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é de Harvard en collaboration avec IBM. Ce calculateur, basé sur des technologies mixtes : électriques et mécaniques, pouvait réaliser des opérations arithmétiques et calculer des fonctions logarithmiques et trigonométriques. Le deuxième, Colossus, a été construit en Angleterre par Turing dans le but d’automatiser le décryptage des messages codés par les Allemands dans la deuxième guerre mondiale.

Trois ans plus tard, la construction d’un autre calculateur universel, nomé Electronic Numeri- cal Integrator and Computer - ENIAC futˆ achevée a` la Moore School of Electrical Engineering par John Mauchly et Presper Eckert. Dès 1944, le nouveau collaborateur de cette équipe est John Von Neumann, qui en 1945 décrit, dans un rapport intitulé ”The first draft of a Report on the Electronic Discrete Variable Automatic Computer - EDVAC”, une machine algorithmique universelle a` programme enregistré, donc un ordinateur, et les principes de son exploitation23. Dans cette description un ordinateur est composé : d’une unité de traitement (UT) et d’une unité de contrôle (UC)24, de la mémoire (M) et des unités d’entrée et de sortie. L’unité de traitement exécute les instructions (i.e. le programme), émises par l’unité de contrôle, sur les données élémentaires. Les instructions ainsi que les données sur lesquelles elles agissent se trouvent dans la même mémoire. L’exécution de chaque instruction passe par plusieurs étapes : recherche de l’instruction, le décodage et l’exécution proprement dit (le cycle fetch-decode-execute). Les descriptions matérielle et logicielle définissent ce que l’on

22Est-il possible de prévoir l’arrêt d’un algorithme particulier. 23Même si ce rapport porte la signature exclusive de Von Neumann, les principaux résultats décrits sont dus également a` Eckert et Mauchly. Par ailleurs, l’idée du programme enregistré dans la mémoire du système a déjà été élaborée 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éalisé seulement en 1952, bien après quelques autres machines qui se disputent le titre de premier ordinateur réalisé. Ainsi, en janvier 1948, le Selective Sequence Electronic Calculator - SSEC est achevé par Wallace Eckert (IBM). Cette machine pouvait lire des instructions sur une bande en papier (Machine de Turing !) voire même en mémoire, réalisée a` l’aide des relais. Quelque mois plus tard, en juin 1948, le Small Scale Experimental Machine - SSEM futˆ construite a` l’université de Manchester. Elle était capable d’exécuter un programme chargé en mémoire, construite au tour des écrans a` tubes cathodiques dont un point allumé représentait un bit d’information sauvegardée. Enfin le troisième : Electronic Delay Storage Automatic Computer - EDSAC, fortement inspiré de l’EDVAC, a été réalisé en 1949 par Maurice Wilkes de l’Université de Cambridge.

En 1953, on compte dans le monde entier une centaine d’ordinateurs de première génération. Ce chiffre va atteindre en 1995 [JPJ96] plus de 257 millions. Il est généralement admis que dans cet intervalle de temps l’évolution des ordinateurs a traversé cinq générations distinctes.

La deuxième génération des ordinateurs (1956-1967)25 est caractérisé par un important changement technologique. Les tubes électroniques et les relais électro-mécaniques utilisés dans la première génération ont été remplacés par des transistors, beaucoup plus fiables et d’un temps de commutation plus faible. Les systèmes deviennent de plus en plus robustes et rapides. Le calcul en virgule flottante n’est plus réalisé par des sous-routines mais par des unités matérielles spécifiques. Dans cette époque on remarque également l’apparition des premiers langages de programmation : Fortran en 1956, Algol en 1958 et Cobol en 1959.

La génération suivante (1967-1978) est marquée par un nouveau changement technologique : l’introduction des circuits intégrés a` faible et moyen degré d’intégration de quelque dizaines voir des centaines des transistors par circuit. La réalisation des circuits intégrés de plus en plus denses a permis la réalisation de premier processeur26, Intel 4004, en 1971. La notion de pipeline est introduite pour les différentes étapes d’exécution des instructions et l’unité de contrôle n’est plus câblée mais micro-programmée. Entre 1969 et 1973, nous avons le développement du langage C [Sec93] et de système d’exploitation UNIX.

La quatrième génération(1978-1988) des architectures informatiques est basée sur des circuits intégrés de type LSI et VLSI (Large et Very Large Scale of Integration) ayant entre 1.000 et 100.000 transistors. Dans cette génération on voit apparaˆıtre les premiers ordinateurs personnels, d’un prix abordable et destinés donc aux grand public.

Les ordinateurs de la cinquième génération (1988-1995) sont caractérisés par l’emploi des circuits ULSI (Ultra Large Scale of Integration) a` plus d’un million de transistors par puce. On constate également l’apparition des systèmes parallèles d’une centaine de processeurs et le développement des ordinateurs permettant un parallélisme extensible. Un autre aspect du développement des architectures informatiques est lié au développement des réseaux informatiques, de plus en plus performants en terme de débit de transmission, permettant un calcul distribué. 25On ne peut pas parler des dates précises de début et de fin de chaque génération. Les dates, repris de [HZ98], sont citées dans le but de mieux situer les différentes générations dans le temps. 26Le terme processeur sera utilisé pour designer un circuit intégré complexe doté de plusieurs unités de contrôle, d’une ou plusieurs unité(s) de traitement et éventuellement de la mémoire.

26 1.4. Machine

Aujourd’hui, nous sommes a` la sixième génération des ordinateurs dont les caractéristiques essentiels sont liées a` la conception et a` l’exploitation des systèmes informatiques massivement parallèles. La quantité des opérations exécutées par une seule machine sont actuellement mesurés par des teraflops (1012 opérations en virgule flottante par seconde).

1.4.2 Classiﬁcation des architectures

La description des différentes générations d’ordinateurs introduit déjà une première classification des architectures se basant sur le critère des grandes changements technologiques. Ce critère est cependant insuffisant lorsqu’il s’agit d’étudier toutes les architectures d’ordinateurs possibles. Plusieurs taxinomies tentent a` systématiser la classification des différentes architectures existantes et étudier les architectures possibles indépendamment de la technologie. Signalons toutefois qu’aucune de ces taxinomies n’est parfaite, car il est très difficile d’isoler des critères pertinents permettant une classification complète.

1.4.2.1 Taxinomies des architectures universelles

Taxinomie selon Flynn La classification des architectures la plus couramment utilisée, celle de Flynn présentée dans [Fly72], est basée sur le nombre d’occurrences d’instructions et de données élémentaires (mots d’information) a` chaque pas d’exécution. Il est alors possible d’introduire quatre classes d’architectures différentes :

SISD (Single Instruction Single Data) est caractérisée par une seule unité de traitement et un seul espace mémoire. Une unité de contrôle unique (un générateur d’instructions) émet un flux d’instructions qui est appliqué a` un flux de données. Une instruction élémentaire est exécutée sur une donnée élémentaire a` la fois. Si l’on admet l’analogie entre le couple instruction - donnée et le couple fonction - argument, pour une architecture SISD on peut alors écrire : y = f(x).

SIMD (Single Instruction Multiple Data) sont des architectures a` multiples unités de traitement qui appliquent le même flux d’instructions aux différents flux de données : →−y = f(→−x ). MISD (Multiple Instruction Single Data) implique également l’existence de plusieurs unités de traitement, mais chaque unité dispose de son propre générateur d’instructions qui agit sur le même flux de données :→−y = →−f (x). MIMD (Multiple Instruction Multiple Data) permet l’exécution simultanée de différents flux d’instructions sur différents flux de données : →−y = →−f (→−x ). Taxonomie selon Skillicorn L’approche de Skillicorn a` la taxinomie des différentes architectures informatiques [Ski85] se base plutôt sur le critère matériel et le nombre d’occurrences des différentes unités fonctionnelles : – le nombre d’unités de contrôle, des mémoires associées et de connexions, – le nombre d’unités de traitement, des mémoires associées et de connexions

27 Chapitre 1. Introduction ainsi que sur le type de connexions entre les unités de contrôle et les unités de traitement et les unités de traitement mêmes. Le nombre d’occurrences peut être nul, unitaire ou égale a` n.

En considérant les différentes unités fonctionnelles et leur nombre d’occurrences, il est possible d’énoncer toutes les architectures possibles de fa¸con purement combinatoire. Il existe cependant des combinaisons non permises car certaines unités fonctionnelles doivent exister pour qu’une architecture ait un sens. Ainsi il faut qu’il y ait au moins une unité de traitement, une mémoire et une connexion entre les deux. En éliminant toutes les combinaisons non-permises, Skillicorn parvient a` définir 28 architectures différentes possibles.

Taxonomie selon Duncan La classification selon Duncan proposée dans [Dun90] ne se concentre que sur des architectures parallèles27 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écrites précédemment.

Architectures parall`eles

Synchrone MIMD Paradigme MIMD

Vecteur SIMD Systolique Mémoire partagée Mémoire distribuée MIMD/SIMD Data Flow Reduction

Processor Array M´emoires associatives

Fig. 1.7: Classiﬁcation selon Duncan

Architectures vectorielles On appelle les architectures vectorielles des ordinateurs qui exploitent les processeurs vectoriels. Un processeur vectoriel possède plusieurs unités de traitement disposées en série. Une donnée élémentaire (une opérande) n’est plus un simple mot d’information mais bien un vecteur composé d’un nombre fixe d’éléments.

Array des processeur Ce type d’architecture correspond au concept SIMD de calcul au sens de Flynn : le même flux d’instructions est exécuté par un ensemble d’unités de traitement sur des données différentes. L’architecture de l’unité de traitement peut être a` plusieurs ou a` un seul bit, comme par exemple la Connection Machine dotée de pas moins de 65536 processeurs d’un bit [Shi96].

27Cette taxinomie fait distinction entre les machines qui utilisent le parallélisme de bas niveau : pipeline des instructions, multiples unités arithmétiques logiques au sein d’un même unité de traitement etc. et les architectures proprement dites en tant que machines autonomes.

28 1.4. Machine

Mémoires/processeurs associatifs La composante principale d’un processeur associatif est une mémoire associative inventée par Slade and McMahon en 1956 [SM56]. Par opposition a` une mémoire conventionnelle ou chaque mot d’information est accédé par le biais d’une adresse unique, dans une mémoire associative l’accès parallèle a` un ensemble de mots est fait par le contenu. Un mot d’information que l’on souhaite retrouvé dans une mémoire associative est comparé avec le contenu de la mémoire entière, ou seulement d’une partie, définie par un masque de recherche. Les adresses qui contiennent le mot de l’information recherché, ou éventuellement une portion de ce mot si l’on travaille avec un registre de masque du mot recherché, seront validées et lues. En ajoutant a` chaque mot d’une telle mémoire une unité de traitement, on obtient alors une architecture de type SIMD capable de réaliser des calculs d’un parallélisme massif.

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

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és a` ce type d’architectures peuvent être trouvés dans [FE63] et [Fet95]. Malheureusement de telles architectures ne sont pas beaucoup ex- ploitées, principalement a` cause de la quantité des ressources matérielles nécessaires pour leur réalisation. Il faut cependant noter que le concept de la mémoire associative est couramment utilisé dans la réalisation des mémoires caches.

Architectures systoliques La architectures systoliques, introduites par Kung et Leiserson dans [KL78] sont des réseaux d’unités de traitement (processeurs) identiques qui re¸coivent, calculent et échangent des données de fa¸con synchrone a` travers un réseau d’interconnexions régulier. Elles doivent leur

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

Le grand avantage des réseaux systoliques réside dans le fait qu’elles minimisent les goulots d’étranglement liés aux accès a` la mémoire, en rempla¸cant les opérations d’écriture et de lecture des résultats intermédiaires par le calcul organisé de fa¸con similaire au pipeline. Dans [Kun80] un ensemble d’algorithmes permettant d’effectuer des opérations vectorielles et matricielles est proposé et une librairie des algorithmes systoliques peut être trouvée dans [Fru92]. Le exemple type d’une telle architecture est le système Intel iWarp ainsi que le processeur GAPP - Geometry Arithmetical Parallel Processor développé dans les années ’80.

Architectures a` mémoire distribuée Dans une architecture a` mémoire distribuée chaque unité de traitement (processeur) possède sa propre mémoire locale qui ne peut être accédée directement par d’autres processeurs. Cependant les différents couples processeur-mémoire peuvent échanger les données via un réseau de connexions. En fonction de type de connexion établie entre un certain nombre de couples processeur-mémoire, i.e. la topologie du réseau, on peut obtenir des architectures différentes. On parle alors des topologies fixes (l’anneau, le mesh, l’arbre, l’hypercube,...) ou encore programmables lorsque les connexions sont définies par l’utilisateur ou encore par le programme.

Architectures a` mémoire partagée Les architectures a` mémoire partagée sont construites autour d’un même espace mémoire uti- lisé par plusieurs unités de traitement (processeurs) : chaque processeur peut accéder a` chaque mémoire. Cet espace mémoire peut être constitué d’une seule mémoire physique (exemple : les ordinateurs personnels multi-processeur) ou de plusieurs mémoires accessibles par chaque processeur. Lorsque une architecture a` mémoire partagée possède plusieurs mémoires physiques, l’accès des différents processeurs aux différentes mémoires peut être assuré par : – le bus - un seul processeur accède a` une seule mémoire a` la fois, – le crossbar - chaque processeur peut accéder directement a` chaque mémoire via une connexion programmable, – le réseau d’interconnexion multi-étage - réduisent le nombre de connexions d’un crossbar en introduisant plusieurs étages de connexions programmables.

Architectures MIMD/SIMD Il est rare qu’en pratique l’algorithme d’un problème a` résoudre soit parfaitement adapté a` une architecture particulière : SIMD ou MIMD. Les architectures hybrides MIMD/SIMD permettent de faire face aux problèmes “mixtes” en exploitant les avantages de chaque architecture. Ainsi un ou plusieurs systèmes SIMD seront utilisés pour contrôler 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ées Dans une architecture flot de données l’exécution d’une instruction est possible dès que les opérandes nécessaires sont prêtes (approche du “bas vers le haut”). Pour une telle architecture le programme est défini sous forme d’un graphe. Chaque noeud est une tâche asynchrone (une expression a` calculer - une instruction) a` laquelle on pourrait associer une unité de

30 1.4. Machine traitement. Plusieurs noeuds (unités de traitement) peuvent donc fonctionner en parallèle. Les arcs représentent les communications nécessaires pour les instructions suivantes a` exécuter. Le calcul de l’expression : a = d + e f g, nécessite les opérandes d, e, f, g. Lorsque les − ∗ opérandes sont prêtes, 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 évaluées, un dernier noeud peut calculer le résultat final.

Architectures réduites Contrairement aux architectures flot de données, l’exécution d’une instruction dans une architecture réduite a lieu lorsque son résultat est nécessaire pour l’exécution de l’instruction déjà en cours d’exécution (approche du “haut vers le bas”). L’exécution d’un programme consiste donc a` calculer une expression imbriquée complexe. Ainsi, le calcul de la même expression a = d + (e (f g)) est décomposée 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érandes particulier : − ∗ d’abord g et f puis e et enfin d.

Architectures wavefront L’efficacité d’un réseau systolique dépend de la régularité des tâches distribuées entre les différentes unités de traitement. Dans un réseau systolique, traitant des problèmes réels, l’équilibre de charge de calcul entre les différentes unités de traitement n’est pas toujours assurée : les unités ayant terminé une partie de calcul seront obligées d’atteindre. Les architectures wavefront apportent aux architectures systoliques la possibilité de fonctionner en monde asynchrone grâce a` un système de requête-accusé de réception entre les différentes unités de traitement.

1.4.2.2 Taxinomies des architectures d´edicac´ees

Les différentes taxinomies abordées concernent les machines universelles, capables de résoudre n’importe quel problème calculable (thèse de Church-Turing28). De telles architectures traitent des problèmes avec une certaine efficacité qui est, on peut s’en douter intuitivement, inversement proportionnelle a` son universalité. En d’autres termes, plus une machine est universelle moins elle sera efficace [BAK96].

Afin d’améliorer l’efficacité d’un calcul automatique des problèmes particuliers et complexes, des architectures “moins universelles” et plus dédicacées apparaissent comme solution idéale. Le principal avantage d’un système dédicacé est lié au caractère dual de l’approche a` la résolution du problème : celui de l’algorithme et celui de la machine qui exécutera l’algorithme en question.

Comme les architectures universelles, les architectures dédicacées peuvent faire l’objet d’une classification. Ainsi, Buell et al. introduisent dans [BAK96] une répartition des architectures dédicacées en trois classes distinctes : 1. Les unités dédicacées - il s’agit de systèmes autonomes qui ne visent aucune universalité si ce n’ést pour des applications semblables.

28La forme la plus courante de cette thèse est : “Tous ce qui est calculable, peut être calculé par une machine de Turing”.

31 Chapitre 1. Introduction

2. Les co-processeurs - qui se présentent sous forme de systèmes destinés a` un système hôte particulier et permettent de réaliser certaines fonctionnalités de fa¸con plus efficace29. 3. Les processeurs attachés - qui ont un rôle fort semblable de celui des co-processeurs, mais ne se limitent pas a` un système hôte particulier et visent une plus grande universalité.

1.4.2.3 Taxinomies des architectures selon la conﬁgurabilit´e

Une classification qui impliquerait a` la fois des architectures universelles et des architectures dédicacés peut être faite selon la relation entre le support physique - le matériel et l’information concernant la description fonctionnelle du système - la configuration. Nous pouvons alors parler de quatre classes d’architectures différentes : I. Architectures universelles (programmables) II. Architectures configurables III. Architectures reconfigurables IV. Architectures dynamiquement reconfigurables

Architectures universelles (programmables) La configuration des architectures programmables est établie 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és définies au préalable par la configuration. L’exécution en séquence de plusieurs de ces fonctionnalités permet la réalisation des fonctionnalités plus complexes : la machine universelle - le programme.

Architectures configurables En utilisant un matériel spécifique, tel que les circuits ASIC ou FPGA, il est possible de réaliser n’importe quelle fonctionnalité désirée. La limitation de la complexité d’une ou plusieurs fonctionnalités a` réaliser réside dans la taille du support qui re¸coit la configuration. La configuration du support établie une fois ne change pas en cours d’utilisation.

Architectures reconfigurables Elles différent des architectures configurables par le fait que la configuration du support peut changer selon la volonté du concepteur/utilisateur ou du programme/application. Ceci est possible grâce aux certaines supports physiques : les circuits FPGA a` mémoire statique par exemple. Le processus de changement de la configuration comprends la destruction complète au préalable de la configuration actuelle et implique une interruption du fonctionnement normal du système.

Architectures dynamiquement reconfigurables Dans les architectures dynamiquement reconfigurables une partie de la configuration, i.e. une partie du support physique qui définit une ou plusieurs fonctionnalités, peut être changée a` n’importe quel instant, sans compromettre le fonctionnement du reste de la configuration. Le support physique permettant la réalisation de telles architectures reconfigurables sont des circuits DPGA (Dynamicaly Programmable Gatte Arrays).

29Exemple : la CM2-X de Thinking Machines Corp. utilise les unités de calcul en virgule flottante sous forme des co-processeurs réalisés 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 universe 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ème particulier a` résoudre commence par le choix (ou l’élaboration) d’un ou plusieurs algorithmes. A ce stade-ci il est possible d’évaluer la complexité théorique des algorithmes choisis en termes de nombre de pas de calcul d’une machine hypothétique et/ou d’espace mémoire nécessaire. Cette complexité est exprimée sous forme d’une fonction, notée O, le plus souvent : linéaire, logarithmique, quadratique, cubique ou exponentielle, de la taille du problème n.

L’évaluation de la complexité algorithmique nous permet de classer les algorithmes et de se rendre compte de la faisabilité du calcul que l’on souhaite automatiser. Ainsi pour certains problèmes, la complexité algorithmique est tellement grande que le temps d’exécution est très long, quelque soit la technologie employée. Parfois même ce temps est suffisamment long pour que nous n’ayons aucun espoir de les résoudre dans un temps raisonnable.

Les problèmes qui nous intéressent ont typiquement une complexité algorithmique linéaire, logarithmique ou quadratique, avec des tailles n de l’ordre de quelque millions. Les algorithmes, les programmes qui les codent et le matériel utilisé pour l’exécution de ces programmes sont caractérisés par des temps de calcul relativement faible : entre quelque millisecondes et quelque dizaines de secondes. Pour de tels problèmes la performance du matériel devient alors importante d’ou` l’intérêt de pouvoir la quantifier a` priori.

1.5.1 Performance du mat´eriel

La performance d’un système informatique est le plus souvent exprimée a` travers la performance de ses deux parties clefs : la mémoire et l’unité de traitement. Pour la mémoire, la bande passante est un très bon indicateur de sa performance. Pour les unités de traitement, le paramètre le plus courant est le nombre d’instructions que celui-ci peut exécuter par unité de temps. Malheureusement ce dernier ne peut être utilisé pour un circuit FPGA, pour lequel on quantifie le plus souvent la quantité de ressources logiques. Dès lors une comparaison entre les deux sur base des données caractéristiques de constructeur devient impossible.

Avant de passer a` la description d’un paramètre commun qui nous permettra de faire cette comparaison, examinons d’un peu plus près les paramètres classiques de la puissance de calcul du matériel.

33 Chapitre 1. Introduction

1.5.1.1 Param`etres classiques

Processeurs Le nombre d’instructions qu’un processeur peut exécuter par unité de temps est souvent mise en valeur par le fabricant afin de favoriser son produit et n’est pas toujours représentative de la performance réelle. Dans le but d’offrir une information plus précise et en tenant compte de la difficulté de réduire la performance du matériel a` seulement quelques paramètres, il est d’usage courant de considérer la performance d’un processeur ou d’un système informatique a` travers sa performance réelle. Cette performance est établie pour un certain nombre d’applications types. Différents bancs d’essais existent, les plus connus étant ceux proposés par Standard Performance Evaluation Corporation - SPEC. Si l’évaluation des performances des différents processeurs et des systèmes informatiques est couramment faite sur base de ces bancs d’essais, leur utilisation pour les architectures dédicacées s’avère très difficile, voir impossible. En effet, pour chaque application d’un banc d’essai il faudrait réaliser un système dédicacé pour pouvoir effectuer la comparaison.

FPGA La plupart des constructeurs des FPGA expriment la performance de leurs circuits a` travers un paramètre lié a` la quantité des ressources logiques disponibles, la conséquence directe de la densité d’intégration. Un autre paramètre important est lié au temps de commutation des différentes parties du FPGA. La quantité des ressources logiques disponible est souvent exprimée par le nombre équivalent de portes logiques Npl, calculé selon un protocole généralement propre a` chaque constructeur.

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

Ce même protocole défini ensuite comment évaluer le nombre équivalant de portes logiques pour la logique et pour la mémoire : – Nombre maximal de portes pour la logique Le nombre maximal des portes logiques est calculé pour une cellule élémentaire, dans les FPGAs Xilinx une mémoire de 16 bits (une Look Up Table - LUT) et d’un flip-flop. Une mémoire de 16 bits a son équivalent en portes logiques qui varie entre 2 et 18 portes. Ce nombre est déduit a` partir des circuits logiques complexes que l’on peut réaliser a` l’aide d’une mémoire 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émoire La mémoire de chaque bloc logique de FPGA peut fonctionner non seulement comme un générateur de fonctions logiques - lorsqu’il contient la table de vérité programmée lors de la configuration - mais aussi comme une mémoire conventionnelle, avec son contenu qui peut être modifié en cours de fonctionnement. On considère que la sauvegarde d’un bit d’information nécessite 4 portes logiques. En suivant le protocole exposé, il est possible de procéder a` l’estimation de Npl pour un FPGA donné, doté d’un certain nombre de blocs logiques.

34 1.5. Performance

La comparaison entre les différents circuits FPGA sur base de nombre équivalent des portes logiques présente certains désavantages. Les approximations et les hypothèses admises dans le protocole exposé laissent beaucoup de marge et peuvent conduire a` d’importantes différences. Si en suivant le même protocole on peut parler d’une comparaison entre les différents FPGAs au sein d’une même famille et d’un même producteur, la comparaison entre les FPGAs des producteurs différents devient très difficile.

Prenons un exemple concret. En 2002 le circuit le plus dense de chez Xilinx (Virtex-II XC2V8000) affiche un nombre équivalent de portes logiques de 8 millions [Xil02]. Chez Altera, le circuit le plus dense (Apex - HC2A70), selon les données constructeur [Alt03a], possède un équivalant 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êmes procédés de fabrication (dans les deux cas la taille du plus petit objet intégré dans le circuit est de l’ordre de 0.12µm), sur une même surface de silicium et doivent par conséquence avoir une puissance de calcul semblable.

S’il s’avère difficile de comparer les FPGAs entre les différents producteurs ou familles, la situation est pire si l’on souhaite réaliser une comparaison entre les FPGA et les processeurs en tant qu’unités 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és de traitement il est nécessaire d’introduire un autre critère de comparaison. Vuillemin propose dans [Vui94] une évaluation de la puissance de calcul basée sur la notion d’un bit actif programmable (Programmable Active Bit - PAB) défini comme un circuit séquentiel a` deux entrées et une fonction de rétroaction (un bit de mémoire). La notion de PAB permet d’introduire la puissance virtuelle de calcul30 - P V qui est alors définie comme le nombre de PABs n qui fonctionnt a` la fréquence f : P V = n f (1.26) × La dimension de P V est exprimée en unités appelées BOPs, l’acronyme de Binary Operations Per Second.

Pour un processeur quelconque n représente la taille des opérandes des unités arithmétiques et logiques. Pour un FPGA quelconque, n représente le nombre de LUTs qui peuvent être lues simultanément. Sur base de ces informations, nous pouvons déduire la puissance virtuelle de calcul d’un processeur grande série 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ément puisqu’il possède deux unités de traitement (des entiers) de 64 bits chaque qui fonctionnent a` la fréquence de 3.0GHz. Dès lors sa puissance virtuelle de calcul s’élève a` 384 GBOPs.

Pour un circuit FPGA, un Xilinx - XC2V8000 par exemple, le nombre de PABs passe a` 93184, le nombre déduit a` partir des données constructeur. Ainsi le circuit XC2V8000 possède 46,592

30La puissance virtuelle de calcul est vu comme la puissance maximale théorique qu’un circuit peut présenter. Pour plusieurs raisons, dont on peut s’en douter les origines, cette puissance n’est jamais atteint en réalité.

35 Chapitre 1. Introduction tranches - slices et chaque tranche possède 2 mémoires de 16 bits et deux éléments de mémoire. L’accès a` cette mémoire peut se faire a` une fréquence de 420 MHz. La puissance virtuelle de calcul de ce FPGA est donc 38220 GBOPs, ce qui représente une puissance virtuelle de calcul environ 100 fois plus grande que celle de processeur envisagé.

Si la puissance virtuelle de calcul représente un moyen simple et efficace de comparaison, elle ne tiens pas compte d’un fait important, l’universalité de l’unité de traitement. Intuitivement, on peut s’imaginer que les processeurs apparaissent comme des unités 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é fonctionnelle Cf - une métrique qui vise a` quantifier le nombre de fonctions réalisables par circuit. Cette métrique est basé sur la notion de nombre équivalent de portes logiques, normalisé par la fréquence f et la technologie λ31 :

N C = pl (1.27) f fλ

– Diversité fonctionnelle FD - une métrique basée sur le nombre des fonctions différentes Ni qu’il est possible de définir par une configuration donnée et pour une surface de circuit A :

N F = i (1.28) D A

Dans une évaluation exhaustive des différentes moyens techniques permettant la réalisation des unités de traitement32, De Hon montre que les FPGA montrent une capacité de calcul de 15 a` 75 fois supérieure par rapport aux processeurs standards avec une diversité fonctionnelle nettement moindre.

En théorie, les FPGAs et les systèmes informatiques qui les utilisent présentent donc une puissance de calcul par circuit nettement plus importante que celle des processeurs conventionnels. Ils représentent donc un moyen très intéressant d’accélération.

En pratique, plusieurs systèmes d’architecture (re)configurables basées sur des FPGAs ont pu montrer une performance supérieure aux architectures programmables. On peut citer Pro-

31Par λ on désigne la taille du plus petit objet intégré dans un circuit intégré et qui dépend de stade actuel de technologie de fabrication. 32Mémoires en tant qu’unités de traitement fonctionnant en mode LUT, les systèmes SIMD a` plus de 1024 unités 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’existence d’une liste assez exhaustive des différentes machines reconfigurables construites jusqu’à nos jours proposée par Guccione dans [Guc00].

1.5.2 Performance d’une application

1.5.2.1 Temps d’ex´ecution

La complexité algorithmique d’un problème et les paramètres classiques d’évaluation de la puissance de calcul d’un système informatique ne peuvent conduire qu’à une approximation très grossière de temps de calcul. Ces paramètres sont insuffisants pour modéliser le temps d’exécution d’un programme. Un grand nombre de facteurs vont jouer un rôle important dans la performance définitive et la seule mesure pertinente de l’efficacité d’un programme exécuté sur une machine est le temps de calcul effectif.

1.5.2.2 Acc´el´eration

La notion d’accélération exprime habituellement le gain en temps d’exécution obtenu par une architecture parallèle a` N unités de traitement (le temps d’exécution t2) par rapport a` une architecture a` une seule unité de traitement (le temps d’exécution t1) :

t A = 1 (1.29) t2

Si A = N, nous parlons d’une accélération idéale : la charge de calcul peut être divisée entre N unités de traitement identiques et le temps d’exécution est donc réduit d’un facteur N.

33DECPeRLe-1 Ce système a été réalisée dans le Laboratoire de recherche de Digital Equipment Corporation-DEC a` Paris en 1992. Il est composé de 23 circuits FPGA Xilinx 3090-100 dont 16 ont été utilisés pour la réalisation du noyau purement computationnel, le reste étant utilisée pour la gestion de 8MB de mémoire statique et l’aiguillage de données vers le noyau computationel. Une douzaine d’applications : la multiplication de grands nombres, comparaisons des chaˆınes de caractères, la convolution binaire etc. ont pu démontrer que l’approche PAM et sa réalisation matérielle sous forme d’un système co-processeur offre des résultats supérieures en termes de performance-prix que n’importe quelle autre système : super ordinateur, ordinateur massivement parallèle et le matériel dédicacés inclus[VBD+96]. 34SPLASH Développé dans le laboratoire Supercomputing Research Center - SRC le système SPLASH2 est construit au tour de 32 unités Xilinx XC3090. D’après [GHC+92] la performance de ce système présente une accélération 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éalité, une telle accélération ne se produit jamais et pour diverses raisons35 nous avons toujours : t1/t2 < N.

Dans ce qui va suivre la notion d’accélération ne sera pas utilisée uniquement pour la comparaison entre une architecture parallèle et une architecture séquentielle mais aussi pour les éventuels gains obtenus entre les différents algorithmes exécutées sur une même machine ou les différentes implémentations d’un même algorithme.

1.5.2.3 Mesure sp´eciﬁque pour le traitement d’images

La mesure du temps d’exécution nous permet de dire si un problème peut être calculé dans un temps t. Cette réponse est valide pour un algorithme particulier, son programme correspondant, une taille du problème n, un niveau de technologique particulier et une architecture informatique précise. Afin d’exclure l’influence de la taille du problème et le rôle de la technologie nous préférons travailler avec un paramètre qui en est indépendant : le nombre d’opérations élémentaires nécessaires pour calculer un pixel de l’image résultante, noté BOP s.

Pour une architecture programmable universelle le BOP s peut être calculé a` partir du temps d’exécution t mesuré, comme suit : t f BOP s = × (1.30) NI ou` f désigne la fréquence de fonctionnement du processeur utilisé et NI la taille de l’image (le nombre de pixels calculés).

Pour des architectures dédicacées, le nombre de BOP s est déduit de fa¸con triviale a` partir du nombre de pas de calcul de la nouvelle architecture.

Afin de caractériser la performance d’une architecture nous allons également utiliser la notion du débit des pixels traités, défini comme le nombre de pixels calculés par unité de temps. Duˆ a` la taille des images habituellement rencontrées, ce débit sera exprimé en millions de pixels par seconde (Mpx/sec).

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

CP A = α CP +(1 α) (CP /N) ∗ − ∗ et la loi d’Amdahl pour un grand nombre d’unités de traitement est énoncée comme suit :

lim A = N = 1 N 1+(N 1) α α →∞ − ∗ l’accélération d’un système parallèle est inversement proportionnelle a` la partie séquentielle d’un programme.

38 Chapitre 2

Architecture universelle

La première approche de l’implémentation des différents filtres de rang vise les architectures universelles et en particulier l’architecture universelle la plus répandue de nos jours - l’ordinateur personnel. Ce chapitre propose une étude détaillée de la performance de tels systèmes pour les applications envisagées et comprend 5 sections :

Section 1 - Propose une introduction générale sur les notions du parallélisme des architectures universelles actuelles et offre une description détaillée du matériel qui sera utilisé pour l’évaluation des performances de différents algorithmes envisagés.

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

Section 3 - Les ordinateurs personnels peuvent se montrer nettement plus performants en exploitant les différents niveaux de parallélisme du processeur employé. Dans cette section on peut trouver la description de plusieurs algorithmes et les procédures correspondantes, optimisées pour l’architecture de l’ordinateur cible. Ces réalisations permettent de quantifier le facteur d’accélération d’une telle approche par rapport a` l’approche dite de ”boite noire”.

Section 4 - Les meilleurs algorithmes (procédures) développés précédemment peuvent être encore accélérés en faisant intervenir le parallélisme des stations multi-processeurs. De tels ordinateurs personnels, doté de deux, voir quatre processeurs sont de plus en plus courants de nos jours. Cette section décrit les méthodes et les procédés permettant de quantifier le facteur d’accélération qu’il est possible d’obtenir avec un ordinateur ayant deux processeurs identiques.

Section 5 - Les différents résultats obtenus des trois approches d’implémentation nous permettrons de conclure sur l’implémentation des filtres non-linéaires sur des architectures universelles.

39 Chapitre 2. Architecture universelle

2.1 Parall´elisme des architectures universelles

Un regard superficiel sur les systèmes informatiques universels d’aujourd’hui peut nous mener a` la conclusion hâtive que leur architecture est la même que celle introduite par John Von Neumann dans le célèbre article de 1945 ”The fist draft of a Report on the Electronic Discrete Variable Automatic Computer - EDVAC”. En effet, le matériel est dans la plupart des cas encore con¸cu autour d’un seul processeur et d’une mémoire centrale. La conception des programmes consiste en codage d’algorithmes a` l’aide des langages de programmation évolués (typiquement C, C++) et de leur traduction en langage machine a` l’aide des compilateurs appropriés. Le programme exécutable généré est composé d’une suite d’instructions, supposées être exécutées de fa¸con séquentielle.

En réalité, les systèmes informatiques d’aujourd’hui sont très loin de cette vision simplifiée et cachent dans leurs couches sous-jacentes les différentes manifestations de parallélisme que l’on pourra situer a` deux niveaux : 1. Parallélisme intra-processeur - le parallélisme propre au processeur en tant qu’unité fonctionnelle et matérielle (un circuit intégré). 2. Parallélisme inter-processeur - le parallélisme au sein d’un même système informatique composé de plusieurs processeurs.

2.1.1 Parall´elisme intra-processeur

Les processeurs actuels intègrent deux types de parallélisme interne : le parallélisme des instructions, dans la littérature anglo-saxonne Instruction Level Parallelism - ILP, lié a` la possibilité d’exécution de plusieurs instructions dans un seul cycle machine et le parallélisme de données, 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écomposé en plusieurs étapes : la recherche de l’instruction (FI), le décodage de l’instruction (DI), l’exécution de l’instruction proprement dit (EX) et l’écriture des opérandes (WO). Chacune de ces étapes peut être réalisée par une unité matérielle câblée ou par une suite des micro-instructions : un micro- programme.

Le parallélisme des instructions est étroitement lié a` la fa¸con dont les différentes étapes d’exécution sont réalisées par le processeur. On admet généralement l’existence de 7 grandes classes d’architectures.

Architectures scalaires Un processeur scalaire exécutera les différentes étapes d’exécution d’une instruction de fa¸con séquentielle, une étape après l’autre avant de procéder a` l’exécution 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ède aucun parallélisme si ce n’est éventuellement au niveau des bits d’un même mot.

Par souci de simplification nous supposons que toutes les instructions sont composées d’un même nombre k d’étapes d’exécution et que chaque étape nécessite le même temps d’exécution τ.

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

T = N k τ (2.1) ∗ ∗ Architectures pipeline L’exécution de chaque étape peut être faite par une unité fonctionnelle indépendante, dont le résultat est sauvegardé localement. L’ensemble des ces unités, mises en série, 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 émettre et terminer une instruction par chaque cycle machine, a` partir du moment ou le pipeline est rempli. D’une manière tout a` fait générale, le nombre d’instructions émises par cycle sera noté m et le nombre d’instruction terminées sera noté n.

Le temps d’exécution, noté T (m, n), nécessaire pour réaliser N instructions1 a` l’aide d’une architecture pipeline est alors donné par l’expression suivante :

T (m, n) = T (1, 1) = (k + N 1) τ (2.2) − ∗ 1L’exécution de la première instruction a nécessité un temps : k ∗ τ. Les N − 1 instructions qui restent vont chacune nécessiter un temps τ.

41 Chapitre 2. Architecture universelle

L’accélération théorique d’une telle architecture par rapport a` une architecture scalaire peut être calculé comme : T N k A = = ∗ (2.3) cc T (1, 1) k + N 1 − et pour un grand2 nombre d’instructions N, l’accélération deviens alors : N k Acc = lim ∗ = k (2.4) N k + N 1 →∞ − L’accélération est donc proportionnelle au nombre d’étages de pipeline, pour autant qu’il y ait peu de ruptures de séquences.

La première application d’une architecture pipeline dans un processeur commercial date des années 60 [Tho61]. Aujourd’hui cette architecture est devenue une norme3 et en général sert de référence lorsqu’il s’agit de comparer les différentes architectures [JW89].

Architectures super-pipeline Chaque étape d’exécution peut être associée a` un micro-programme particulier composé de plusieurs micro-instructions a` exécuter. Une étape n’est donc plus une opération atomique mais elle même constitué de plusieurs étapes. Si au sein d’une même étape d’exécution, associée a` un étage du pipeline de processeur, les micro-opérations qui composent cette étape sont exécutées dans un pipeline (un étage de pipeline est lui même 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écution de N instructions deviens alors : N 1 T (1, n) = (k + − ) τ (2.5) n ∗ ou` n représente le nombre d’étages du pipeline (on dit que l’architecture est pipeline d’ordre n).

L’accélération obtenue par rapport a` une architecture pipeline de référence 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’étapes k. 3Un tel système informatique est souvent appelée Single Issue Base Machine.

42 2.1. Parall´elisme des architectures universelles

Architectures super-scalaire Si un microprocesseur possède plusieurs unités d’exécution permettant la réalisation simul- tanée de plusieurs étapes EX, on parle alors d’une architecture super-scalaire. Notons que chaque unité d’exécution 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és d’exécution avec deux pipelines d’étapes d’exécution).

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écution de N instructions est : N m T (m, 1) = (k + − ) τ (2.7) m ∗ Le nombre d’instructions émise par cycle machine m (i.e. le nombre d’instructions qui peuvent être exécutées simultanément) correspond au nombre d’unités de traitement d’un processeur super-scalaire.

A partir des équations 2.2 et 2.7 il est possible de calculer l’accélération d’une architecture super-scalaire par rapport a` l’architecture pipeline de référence : 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élération 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ême facteur d’accélération si elles sont de même ordre : le nombre d’unités d’exécution est le même que celui d’étages de pipeline (n = m).

Architectures super-scalaire/super-pipeline Les deux architectures décrites précédemment peuvent être combinées afin d’offrir le meilleur facteur d’accélération 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écution de N instructions pour une architecture super-scalaire/super-pipeline est : N m T (m, n) = k + − τ (2.9) n m ∗ ∗ et l’accélération par rapport a` l’architecture de référence 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ède plusieurs unités de traitement mais un seul pipeline des différentes étapes d’exécution. L’exploitation de multiples unités de traitement est assurée par l’existence de plusieurs étapes d’exécution (EX) codées aux sein d’une même 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élération d’une architecture VLIW par rapport a` l’architecture de référence est la même que celle d’une architecture super-scalaire. L’avantage de ces architectures réside surtout dans le fait que le décodage des instructions VLIW semble plus simple que dans le cas d’une architecture super-scalaire. On bénéficie également d’une économie des ressources en matériel, puisque le nombre de décodeurs des instructions ne se voit pas multiplié par le nombre d’unités d’exécution en jeu.

Un autre avantage des architectures VLIW est lié a` l’exploitation de parallélisme des instructions, faite lors de la compilation et non plus lors de l’exécution. En effet, le temps que l’on peut consacrer a` la recherche automatique (par le biais de compilateur) d’un éventuel parallélisme d’instructions est beaucoup plus important permettant, a` priori, d’obtenir un code exécutable plus performant.

Architectures vectorielles Dans une architecture vectorielle (Figure 2.7) lorsque une instruction est décodée, l’étape d’exécution (EX) travaille sur un vecteur de données, d’une taille quelconque, plutôt que sur un nombre fixe et généralement faible d’opérandes.

Les architectures vectorielles présentent deux avantages. Tout d’abord une opération sur deux vecteurs nécessite seulement une opération de décodage d’instruction a` exécuter qui sera ap- pliquée au vecteur entier. Le deuxième avantage réside dans le fait qu’une opération vectorielle

4Acronyme de Very Large Instruction Word.

44 2.1. Parallélisme des architectures universelles une fois lancée permet de prédire les données qui vont être accédées et les acheminer de fa¸con a` exploiter le pipeline au maximum (minimiser les arrêts du pipeline pour cause d’atteintes de données).

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èmes liés a` l’exploitation du parallélisme des instructions

Architectures pipeline Si une architecture pipeline apporte un gain théorique considérable par rapport a` une architecture purement scalaire, en réalité un tel gain n’est jamais atteint. Les principales raisons pour lesquelles l’accélération réelle diffère de l’accélération théorique sont liées aux trois types d’aléas différents : 1. Aléas structurels - Il s’agit de conflits liés a` l’exploitation des ressources matérielles, lorsque plusieurs instructions doivent accéder aux mêmes ressources matérielles en même temps. L’exemple typique de tels aléas est le conflit entre deux instructions, issues l’une après l’autre, destinées a` la même unité d’exécution, et de longueur différente pour que les étapes d’exécution arrivent en même temps5. 2. Aléas des données - Ces aléas font référence aux conflits d’accès aux données (collision d’opérandes) et on en distingue trois cas particuliers : RAW (Read After Write) - lorsque une instruction en cours d’exécution lit la donnée issue de l’instruction précédente n’ayant pas encore terminée sa phase d’écriture (l’instruction en cours obtient l’ancienne valeur qui n’a pas encore été modifiée par l’instruction précédente). WAW (Write After Write) - lorsque une instruction en cours écrit avant que l’instruction précédente ait terminé (écriture faite dans le mauvais ordre). WAR (Write After Read) - lorsque une instruction en cours écrit la donnée avant que celle-ci soit lue par l’instruction précédente. Ce dernier aléas n’intervient jamais lorsque la lecture et l’écriture se passent toujours a` des mêmes moments, mais cela ne doit pas forcement être toujours le cas.

5Dans un ordinateur de type CISC - (Complex Instruction Set Computer) les instructions sont composées 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ême nombre de micro-instructions. Aujourd’hui, même si le combat entre les défenseurs des deux approches continue, les processeurs commerciaux ne sont plus ni purement RISC, ni purement CISC, mais bien un mélange des deux.

45 Chapitre 2. Architecture universelle

3. Aléas de contrôle - Ce type d’aléas est lié a` la présence des sauts conditionnels qui impliquent le branchement du code en deux chemins d’exécution exclusifs.

Afin d’éviter les aléas et assurer un fonctionnement correct, le pipeline doit être suspendu ou vidé. Ces deux actions ont pour conséquence une perte de cycles machine, ce qui conduit inévitablement a` un abaissement des performances globales.

Les deux premiers types d’aléas impliquent que l’ordre d’exécution des instructions a de l’importance sur la performance d’exécution d’un programme. Il existe donc un ordre préférentiel d’exécution des instructions permettant de minimiser le temps d’exécution total. La recherche de l’ordre optimal d’exécution constitue le problème de l’ordonnancement6, un problème NP - complet7.

Afin de maximiser leur performances, la plupart des processeurs d’aujourd’hui emploient des méthodes heuristiques permettant de réaliser le meilleur ordonnancement possible des instructions en cours d’exécution. Mais étant donné la difficulté du problème d’ordonnancement et le temps qui lui est attribué (surtout lorsqu’il s’agit d’ordonnancement en cours d’exécution), les résultats sont fort variables. Les meilleurs performances dépendent encore et toujours de l’intervention de programmeur [Lec99].

Architectures super-scalaires Si l’ordonnancement des instructions est important pour une bonne performance des architectures pipeline, il est d’une importance capitale pour les architectures super-scalaires en raison de la présence de multiples unités d’exécution. La performance d’une application va donc dépendre de la qualité du code assembleur généré par le compilateur ainsi que des unités matérielles qui réalisent 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 être générés par deux compilateurs (ou programmeurs) différents et dans le but de calculer la même chose : a = b + c + d + e.

Si les deux codes en question sont exécutés par une même machine super-scalaire d’ordre 2, le code avec une optimisation de l’ordonnancement sera plus performant même si l’on compte

6Etan´ t donné un programme p, trouver l’ordre optimal des instructions, tel que le temps d’exécution de ce programme p pour une machine M soit minimal. 7Tout problème formalisable et décidable peut être calculé par une machine de Turing (thèse de Church). Afin d’exprimer la faisabilité de calcul d’un problème par un algorithme, on parle de sa complexité en temps et la complexité en espace qui dans le cas d’une machine de Turing peut être vu comme le nombre de déplacement de la tête de lecture/écriture et la taille de ruban nécessaires. Si pour un problème donné la complexité de l’algorithme permettant son calcul est une fonction polynomiale (ou exponentielle) de la taille du problème (n) on dit alors que le problème appartient a` la classe P (ou la classe E) des problèmes. Il existe cependant des problèmes pour lesquels on ne connaˆıt pas d’algorithme de complexité polynomiale, mais on peut toujours vérifier une solution proposée dans un temps polynomial (machine de Turing non-déterministe). De tels problèmes appartiennent a` la classe dite NP (non-deterministic polynomial) des problèmes. Un problème NP -complet est un problème NP particulièrement difficile (au moins tout aussi difficile que toute autre problème NP ) mais avec la propriété que si l’on trouve un algorithme polynomial pour un des problèmes NP -complet on aurait trouvé un algorithme polynomial pour tous les problèmes de la classe NP (réduction 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é et les trois instructions d’addition ne peuvent pas être exécutées de fa¸con concurrentielle. De plus, la deuxième et la troisième addition, doivent attendre la terminaison de l’instruction précédente provoquant ainsi un arrêt de pipeline (les aléas de données).

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écution de programme non-optimisé et optimisé

Le deuxième code, cette fois-ci avec une autre affectation de registres et un meilleur ordonnancement permet une exécution simultanée des deux chargements (load) et des deux additions.

A l’heure actuelle, les unités d’ordonnancement sont capables d’altérer l’ordre des instructions imposé par l’utilisateur (ou par le compilateur) afin d’exploiter au mieux les ressources disponibles. De plus, elles peuvent changer l’affectation des différents opérandes a` des registres différents de ceux imposés par le programme afin d’éviter les aléas de données (Register rena- ming). Mais de telles techniques se montrent efficaces dans des cas particuliers et ne peuvent donc pas être considérées comme universelles.

En général, on distingue deux types d’ordonnancements différents : l’ordonnancement dynamique lorsque l’ordre des instructions est établi a` l’exécution du programme par une unité matérielle dédicacée et l’ordonnancement statique lorsque celui-ci est établi par un programme, lors de la compilation (les architectures VLIW p.e.).

Pour l’ordonnancement dynamique on distingue trois stratégies différentes selon l’ordre dans lequel sont réalisées 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é 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égie d’ordonnancement, jamais employée même pour les processeurs émettant qu’une seule instruction par cycle. 2. Lancement selon l’ordre, terminaison dans le désordre9 Les instructions sont lancées dans l’ordre, mais peuvent être terminées a` des moments différents de celui imposé par le programme. 3. Lancement et terminaison des instructions dans le désordre10 Les instructions sont décodées dans l’ordre dans lequel elles apparaissent dans le programme et placées dans une fenêtre d’exécution. Depuis cette fenêtre d’exécution elles peuvent être retirées pour l’exécution dans un ordre déterminé par l’unité d’ordonnancement et qui ne doit pas forcement respecter l’ordre imposé par le programme. Architectures VLIW L’exploitation du parallélisme au niveau des instructions pour les architectures VLIW est directement lié a` la capacité du compilateur d’extraire le parallélisme a` partir d’un code écrit en langage de programmation évolué et de réaliser un bon ordonnancement statique des instructions (ce qui n’a rien d’immédiat). Un autre désavantage réside dans la dépendance des applications du matériel sous-jacent. Tout changement a` l’architecture implique l’incompati- bilité des applications réalisées sur des architectures ultérieures et par conséquent nécessite une re-compilation pour la nouvelle architecture cible.

2.1.1.3 Parall´elisme des donn´ees

Dans tous les processeurs actuels, les unités d’exécution sont spécialisées pour le type de données a` traiter (les entiers et les réels). Pour le calcul des entiers la taille maximale des opérandes est fixé a` 32, 64, voir 128 bits. Les unités d’exécution permettent de réaliser en une seule étape d’exécution (EX) une quelconque opération arithmétique ou logique pour la taille maximale des opérandes.

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

Les extensions a` une architecture standard ont pour but de permettre le meilleur emploi des unités d’exécution lorsque la taille de la donnée élémentaire (l’opérande) est plus petite que la taille maximale de l’opérande pour laquelle cette unité a été initialement prévue. En s’inspirant des processeurs vectoriels et du modèle 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élisme des architectures universelles un parallélisme des données a` l’aide du matériel existant et avec un minimum des ressources matériels supplémentaires.

L’intérêt 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élération se voit alors multiplié par le nombre d’unités d’exécution intégrées.

En général, les extensions de l’architecture standard se présentent sous forme d’un mode de fonctionnement particulier qui nous permet d’accéder a` un jeu d’instructions supplémentaire, spécifique a` l’extension en question. Ce jeu d’instructions supplémentaire intègre les instructions classiques : de transfert de données, des opérations arithmétiques/logiques, de décalage et de conversion de format, mais qui s’appliquent a` des vecteurs dont la taille dépend de la taille des opérandes de l’unité d’exécution et de la taille des données avec lesquelles on travaille.

Certaines de ces instructions sont particulièrement intéressantes pour des applications mul- timédia et les jeux vidéo, la raison pour laquelle ces extensions portent les noms qui font souvent référence a` ce type d’applications.

2.1.2 Parall´elisme inter-processeur

Mis a` part la classification des systèmes a` plusieurs processeurs en architectures SIMD et MIMD 12, le parallélisme inter-processeur peut être classé de fa¸con très grossière selon la manière d’exploiter la mémoire centrale. Ainsi, on distingue les systèmes a` mémoire partagée et les systèmes a` mémoire repartie.

Les systèmes a` mémoire partagée sont construit autour d’une seule mémoire centrale partagée entre plusieurs processeurs de nombre généralement faible (de l’ordre de quelques dizaines de processeurs identiques au plus).

Pour les systèmes a` mémoire repartie, chaque processeur possède son propre espace mémoire, mais peut communiquer avec les autres via un réseau de communication de topologie et de technologie quelconque. Il s’agit en général des systèmes composés d’un grand nombre de processeurs et engendre une certaine redondance de données.

2.1.2.1 Parallélisme des systèmes a` mémoire partagée

Au courant de la dernière décennie sont apparus les premiers ordinateurs personnels dotés de plusieurs processeurs qui partagent une même mémoire centrale. L’exploitation de pa- rallélisme inter-processeur est assurée a` haut niveau, par le système d’exploitation qui présente la caractéristique de fonctionnement dit en multi-tâche. De tels systèmes d’exploitation partagent en effet le temps d’un processeur entre différentes applications en cours, de fa¸con que leur exécution apparaˆıt simultanée a` l’utilisateur.

12Multiple Instruction Multiple Data

49 Chapitre 2. Architecture universelle

Le fonctionnement avec des processeurs multiples ne fait qu’étendre la notion de partage des tâches entre plusieurs processeurs. Le fonctionnement multi-tâche d’un système d’exploitation est étroitement lié aux deux notions fondamentales liées a` l’exécution d’un programme : le process et le thread.

Process Un process est défini comme un programme chargé en mémoire centrale du système, par le système d’exploitation ou par l’utilisateur, et en cours d’exécution. Chaque process est défini et identifié au sein du système d’exploitation par un ensemble de variables13. Cet ensemble de variables, appelé le contexte d’exécution, défini de fa¸con univoque l’état du process. Le système d’exploitation est le propriétaire de chaque process et de chaque contexte d’exécution correspondant. Le changement de contexte d’exécution, i.e. partage de temps d’un processeur entre différentes process (tâches), comprend la sauvegarde du contexte d’exécution en cours et le chargement du contexte d’exécution du process qui a obtenu le temps processeur.

Le changement de contexte d’exécution peut être inconditionnel pour des tâches qui doivent impérativement être exécutées au moment ou elles sont initiées : par exemple lors d’une interruption système. Pour toute autre tâche, le système d’exploitation sur base d’un certain critère décide de leur attribuer le temps processeur. L’établissement de critère pour la prise de décision de changement de contexte d’exécution (l’ordonnancement des tâches) peut se faire sur base de stratégies différentes, établies au préalable et qui résultent d’un compromis entre le temps passé au calcul pur, la rapidité de réponse du système a` l’utilisateur et l’effi- cacité de gestion des entrées/sorties. Comme l’ordonnancement des instructions, le problème d’ordonnancement des tâches n’a pas de solution optimale.

Il est important de savoir que le changement de contexte d’exécution entre les différents process (tâches) n’est pas une opération gratuite en termes de temps processeur, bien au contraire. Afin de minimiser le temps perdu lors de changement de contexte et permettre l’exécution d’un plus grand nombre de flots d’instructions indépendantes, la plupart des systèmes d’exploitation actuels intègrent la notion des threads.

Thread Un thread représente une partie de programme déjà en cours d’exécution, donc un process, mais exécutée de fa¸con tout a` fait indépendante de ce même process. Chaque process en cours d’exécution peut démarrer un ou plusieurs threads relatives a` la même ou les différentes parties d’un même programme. Tous les threads initiés par un même process partagent le même contexte d’exécution, celui de process qui les a crées. Le partage de même contexte d’exécution implique que les différents threads initiés par ce même process partagent un même espace mémoire, a` savoir le code et les données d’un programme.

Chaque thread, tout comme process, est défini de fa¸con univoque au moment de sa création par un ensemble des variables (l’état du thread). La quantité d’information nécessaire pour décrire un thread est nettement inférieure comparée a` celle nécessaire pour décrire un process. De ce fait le passage de l’exécution d’un thread a` l’exécution d’un autre peut se faire avec un moindre coutˆ en temps processeur, d’ou leur intérêt.

13Les états des registres du (ou des) processeur(s), les données associées au process tels que : l’identificateur de process, la priorité etc.

50 2.1. Parall´elisme des architectures universelles

D’une manière tout a` fait générale, la technologie des threads présente les avantages suivantes :

1. Meilleur usage des ressources matérielles Aujourd’hui les systèmes informatiques sont composés d’un grand nombre d’unités périphériques dont les constantes de temps varient fortement. Ecrire´ une application a` travers plusieurs threads permet d’exploiter les différentes ressources matérielles a` leur rythme sans pour autant ”bloquer” l’exécution d’autre tâches en cours. L’exemple typique est l’attente de données depuis une unité de sauvegarde, généralement lente, qui n’empêche pas l’exécution d’autres tâches en cours.

2. Fonctionnement par événement Il est souvent nécessaire de réaliser un traitement particulier pour un événement donné. La technique traditionnelle implique la réalisation d’une boucle qui effectue un polling sur l’événement en question. Si cette boucle est réalisé au sein d’un thread, celui-ci sera traité comme tout autre thread et le temps processeurs lui sera attribué. Pour éviter cette dépense inutile de temps processeur, les threads intègrent la possibilité d’être pi- lotés par des événements - les objets indépendants qui ne subissent pas les mécanismes habituels d’attente et de gestion propres aux threads. Lorsque un événement a lieu, c’est l’objet événement qui enverra des messages dès son activation a` tous les threads qui y sont attachés. En attendant l’événement, les threads concernés peuvent être mis dans un état bloqué et ne plus devoir être servis par le processeur.

3. Exploitation de parallélisme inter-processeur Dans le cas d’une machine multi-processeurs, nous disposons d’autant de files d’attentes pour l’exécution des threads que des processeurs. De ce fait autant de threads que des processeurs peuvent être exécutés simultanément. Une application multi-thread peut donc bénéficier d’une accélération lorsqu’elle est exécutée sur un système multi- processeur tout en préservant la compatibilité avec un système mono-processeur.

Dans les deux premiers cas, les threads peuvent améliorer le temps d’exécution d’une application au sein même d’un système informatique mono-processeur. Mais le principal avantage des threads réside, en ce qui nous concerne, dans la simplicité avec laquelle ils permettent d’exploiter le parallélisme inter-processeur d’un système multi-processeurs.

Multi threading simultané La technologie de multi threading simultané permet a` plusieurs threads indépendants d’exploiter de fa¸con concurrentielle les différents ressources physiques d’un processeur d’architecture super-scalaire. En outre, plusieurs threads indépendants peuvent demander l’exécution simultanée de plusieurs instructions par chaque cycle machine, a` condition que ces instructions n’utilisent pas les même ressources physique14. Les ressources matérielles du processeur

14Considérons par exemple le cas d’un processeur doté d’une unité de traitement spécialisée pour le calcul des entiers et d’une unité de traitement spécialisée pour le calcul des nombres codés en virgule flottante. Deux threads, un composé des instructions de calcul uniquement sur les entiers et un deuxième composé des instructions de calcul en virgule flottante, peuvent être exécutés en même temps puisque ils ne demandent pas les mêmes ressources physiques. Dans la technologie traditionnelle des threads, un thread en exécution immobilise toutes les ressources de calcul quelque soit les ressources réellement nécessaires pour son exécution.

51 Chapitre 2. Architecture universelle peuvent être donc partagées entre plusieurs threads mais en même temps. L’exploitation de cette technologie permet d’obtenir, pour un ensemble d’applications standards (SPEC), un gain allant jusqu’à quatre fois plus d’instructions exécutées par rapport au même processeur ne permettant pas ce partage de ressources matérielles [TEL95].

L’exemple commercial d’une telle technologie, appelé hyper-threads [Int01], est disponible sur les processeurs Xeon de chez Intel. Un tel processeur physique apparaˆıt au système d’exploitation comme deux processeurs logiques. Pour un coutˆ faible des ressources matérielles, 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élisme des systèmes a` mémoire repartie

Les systèmes informatiques a` mémoire repartie ont dans le passé représenté la classe des super-ordinateurs. Il s’agissait de systèmes couteux,ˆ difficilement accessibles et destinés a` l’emploi d’un ensemble d’utilisateurs plutôt qu’à l’utilisation d’une seule application.

Actuellement on voit de plus en plus apparaˆıtre des solutions de calcul massivement pa- rallèles impliquant de réseaux des ordinateurs personnels ou de stations de travail, appelés 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és et de réseaux très performants permettant la communication de données a` haut débit.

2.1.3 Processeurs actuels

Aujourd’hui l’architecture de la plupart des processeurs employés dans les systèmes informatiques universels est de type super-scalaire/super-pipeline. Le degré de scalarité varie entre 2 et 8 et le pipeline comporte entre 6 a` 20 étages15.

Tous les processeurs actuels intègrent des extensions a` l’architecture standard et exploitent le parallélisme de données. Ainsi, Intel intègre deux extensions différentes : l’une destiné uniquement pour le traitement des entiers - Multi Media Enhancement - MMX et l’autre pour le traitement et des entiers et des réels - Streaming SIMD Extension - SSE et SSE2 plus récamment16. 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 également le nombre d’unités de traitement dédicacées au calcul des entiers (E) et au calcul en virgule flottante (VF).

15Le nombre d’étages de pipeline peut varier fortement d’un producteur a` l’autre selon la stratégie d’implémentation adoptée. Ainsi les concepteurs des microprocesseurs UltraSPARC optent pour un plus faible nombre d’étages de pipeline avec l’argument que l’emploi d’un plus grand nombre d’étages ne sert qu’à augmenter de fa¸con artificielle la vitesse des processeurs bon marché. 16Pour le concurrent direct d’Intel, AMD, cette extension fort semblable porte le nom 3DNow ! est destinée plutôt 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 étude, le choix de l’architecture cible a été portée sur le matériel commun, basé sur les processeurs actuels de grande série, pour des raisons de leur accessibilité, de leur prix et de leur usage universel. L’implémentation des différents algorithmes qui seront pro- posés et la mesure de leur efficacité ont été effectués sur un ordinateur personnel doté d’un processeur Pentium 4 fonctionnant a` 1.5 GHz. Ce processeur intègre les différents niveaux de parallélisme intra-processeur décrits précédemment. Le système d’exploitation utilisé est Win- dows 2000, permettant la programmation des threads et donc l’exploitation de parallélisme inter-processeur.

En ce qui concerne les résultats de l’exploitation de parallélisme inter-processeur, une station doté de deux processeurs Pentium 2 fonctionnant a` 450MHz a été utilisé. Etan´ t donnée l’âge certain de ces processeurs, les résultats sont données a` titre indicatif et ont pour but de montrer le facteur d’accélération relatif lors d’utilisation d’un système informatique multi-processeur a` mémoire partagée.

Dans ce qui va suivre nous nous contentons de donner une description un peu plus détaillée du processeur Pentium 4 et seulement souligner les différences majeures par rapport a` l’architecture de Pentium 2.

2.1.4.1 Architecture standard

La base de l’architecture de processeur Pentium 4 (une description très détaillé peut être trouvée dans ([Int99b], [Int99c], [Int99d]) est le noyau IA-3217 introduit déjà depuis la génération 386 de la famille x86. Les différentes générations qui ont suivi le 386 ont apporté des modifications majeures a` ce noyau, mais toujours en assurant la compatibilité avec des processeurs des générations précédentes. Le Pentium 4 n’est pas une exception, tout en intégrant les différents niveaux de parallélisme dont nous avons parlé dans la section précédente.

Pentium 4 est un processeur : – Super-scalaire d’ordre 3 : trois instructions peuvent être décodées, exécutées et retirées par chaque cycle machine ; – Super-pipeline : le pipeline d’exécution est composé de 20 étages ; – 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és d’exécutions sont séparées pour les nombres entiers et les nombres réels. Le noyau de calcul des entiers possède 2 unités arithmétiques/logiques proprement dites, plus une unité dédiée uniquement aux opérations de décalage (indiquées ALU1, ALU2 et Integer op. sur la Figure 2.10). Les deux ALUs fonctionnent a` une vitesse deux fois plus élevée que l’horloge principale, permettant ainsi la réalisation jusqu’à quatre opérations arithmétiques/logiques par un cycle machine.

Le noyau de calcul en virgule flottante est composé d’une unité arithmétique/logique proprement dite (FP2 de la Figure 2.10) et une unité de mouvement des données entre les registres locaux (FP1). Ces mêmes unités d’exécution sont utilisées par les trois extensions a` l’architecture standard. Le choix de spécialisation pour chaque unité de calcul en virgule flottante a été dirigé par le compromis entre le coutˆ matériel et la performance obtenue. Pour des applications multimédia standards, le gain de deux unités identiques serait trop faible étant donné que les déplacements entre les différents registres ont autant d’importance que le calcul même [HSU+01].

Aux différentes unités d’exécution sont associé deux ports d’exécution distincts : le Port 0 regroupe une unité d’exécution pour les entiers et l’unité de déplacement des registres en virgule flottante ; le Port 1 comprends l’autre unité d’exécution pour les entiers, l’unité de calcul en virgule flottante proprement dit et l’unité de décalage des entiers (voir Figure 2.10).

Deux ports d’exécution supplémentaires (Port 2 et Port 3) se chargent des accès a` la mémoire :

18Disponible déjà sur certains processeurs Pentium. 19Streaming SIMD Extension, disponible a` partir de la génération Pentium 3. 20SSE2 est la deuxième génération de l’extension SSE disponible a` partir de la génération Pentium 4.

54 2.1. Parallélisme des architectures universelles l’un pour le chargement des données vers le processeur et l’autre pour la sauvegarde vers la mémoire. Une telle architecture permet donc d’émettre jusqu’à 6 instructions d’exécution par cycle machine21.

Le processeur Pentium 4 intègre deux niveaux de la mémoire cache (L1, L2) dans le même circuit intégré. La mémoire cache de niveau 2 est une mémoire de 256 kB avec une bande passante de 48GB/s22. Une unité matérielle est dédié a` l’exploitation dynamique (en cours d’exécution) de cette mémoire en prévoyant les accès allant jusqu’au 256 octets en amont de l’adresse en cours de lecture. En ce qui concerne la mémoire cache de niveau 1, elle est séparée pour les instructions (12 Ko) (Trace Cache) de celle pour les données (8 Ko). La mémoire cache de niveau 1 est plus petite que d’habitude, Pentium 3 intègre deux mémoires de 32KB séparées pour les données et les instructions par exemple, mais ces mémoires ont l’avantage d’avoir une latence extrêmement faible.

Le décodage des instructions se fait dans l’ordre imposé par le programme. Par contre l’exécution des instructions est faite dans le désordre (Out-Of-Order-Execution - OOOE). L’unité de retrait se charge de respecter l’intégrité de programme initial en réorganisant, dans l’ordre imposé par le programme, les instructions exécutées et en gérant les cas exceptionnels.

Afin de combattre les aléas structurels23, le Pentium 4 intègre une unité de prédiction de branchement permettant, sur base d’un historique et de fa¸con spéculative, de décoder les instructions a` exécuter, avant même que le chemin d’exécution soit réellement calculé.

2.1.4.2 Extensions

Extension MMX L’extension MMX possède son propre espace mémoire pour les opérandes, composé de huit registres de 64 bits, appelés MM0 a` MM7, permettant la sauvegarde de quatre types de données différents : les entiers codés sur 8 (byte), 16 (word), 32 (doubleword) et 64 bits (quadword). Ces registres sont considérés comme des vecteurs de 64 bits, l’interprétation de type de données est résolue par l’instruction utilisée. La gestion des entrées/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ées entre l’espace mémoire global (mémoire centrale du système) et ces registres se fait par une adresse sauvegardée dans un des registres GPR pointant vers un bloc contigu de mémoire de 4 ou 8 octets.

La Figure 2.11 montre le mécanisme d’adressage de la mémoire centrale, le transfert vers l’espace mémoire pour les opérandes et la résolution de type d’opérande selon l’instruction utilisée. Deux registres GPR edx et ebx pointent vers deux tableaux de données (huit octets en tout) de la mémoire centrale. Une seule instruction (movq) effectue le transfert du tableau vers un des registres (mm0 et mm1). Les instructions paddb, paddw, paddq réalisent 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émoire centrale, les registres MMX et résolution de type d’opérande. Avec les quatre types de données différents, l’extension MMX permet l’utilisation des unités d’exécution en mode vectoriel, la taille de vecteur étant variable en fonction du type de données employé. Remarquons que le parallélisme est maximal pour les données de type octet, ce qui s’avère particulièrement intéressant pour les applications envisagées.

Le jeu d’instructions comprends 6 classes d’instructions différentes : 1. Instructions de transfert entre la mémoire centrale et les registres et inversement. 2. Instructions arithmétiques d’addition, de soustraction, de multiplication et de multiplication/addition24 sur les données de type byte, word et doubleword. Ces instructions apparaissent sous deux formes différentes : – Wrap around : le report généré par une addition (soustraction) est ignoré, le résultat est tronqué25. – Signé (ou Non - signé) avec saturation : Le résultat d’une addition (soustraction) dépassant la limite permise par la définition du type de donnée va saturer le résultat a` cette limite permise26. 3. Instructions de comparaison d’égalité et en ”plus grand que” pour tous les types de données. 4. Instruction de conversion permettant le passage entre les différents types d’entiers. 5. Instructions logiques AND, NAND, OR et XOR. 6. Instructions de décalage a` gauche et a` droite. Extension SSE L’objectif de l’extension SSE est d’apporter le même modèle de calcul SIMD introduit pour

24Réalise le produit de deux vecteurs et la somme des éléments du vecteur en une seule instruction. 25Par exemple : 11111111 + 00000010 = 00000001 26Par exemple : 11111111 + 00000001 = 11111111

56 2.1. Parallélisme des architectures universelles les entiers, pour les nombres réels. L’espace mémoire des opérandes est composé de nouveau de huit registres, mais de 128 bits (notés XMM0 - XMM7), permettant d’utiliser les unités d’exécution en mode vectoriel avec quatre éléments27 par vecteur.

Le jeu d’instructions associé propose non seulement les instructions de calcul sur des nombres réels, mais également les nouvelles instructions pour le calcul sur des entiers, mais exécutables exclusivement sur les registres de l’extension MMX.

L’extension SSE introduit également des instructions de contrôle explicite de la mémoire cache, permettant d’agir de fa¸con logicielle sur cette mémoire (chargement des données depuis la mémoire centrale, dans la mémoire cache d’un certain niveaux) et non plus uniquement a` travers l’unité matérielle de contrôle.

Extension SSE2 L’apport de l’extension SSE2 est double car les données qu’elle peut traiter peuvent être aussi bien les réels (cette fois-ci en mode double précision) que les entiers. Pour les réels on retrouve un jeu d’instructions semblable a` l’extension SSE. Pour les entiers, cette extension intègre toutes les instructions introduites par les extensions MMX et SSE mais sur des registres XMM de 128 bits. Pour les entiers, les unités d’exécution apparaissent alors comme des unités vectorielles qui doublent le parallélisme de données par rapport a` l’extension MMX.

2.1.4.3 Diﬀ´erences entre Pentium 2 et Pentium 4

Etan´ t donné que le matériel utilisé pour explorer le parallélisme inter-processeur est basé sur les processeurs Pentium 2, il est important de constater la différence entre ces deux processeurs. Même si ces deux architectures partagent le même noyau IA-32 compatible, les différences entre leurs architectures standard respectives sont significatives. Nous n’allons pas entrer dans les détailles des différences de l’architecture standard, l’architecture de Pentium 2 étant décrite dans [Int97b]. L’important c’est de souligner qu’au point de vue des extensions le processeur Pentium 2 intègre uniquement la technologie MMX, avec un jeu d’instructions réduit par rapport a` celui de Pentium 4. Les instructions manquantes, hélas fort utiles dans les applications envisagées, seront donc réalisées a` l’aide des instructions disponibles réduisant ainsi la performance globale, comme nous allons le voir par la suite.

2.1.4.4 Performance de la m´emoire

L’évolution rapide des processeurs au courant des deux dernières décennies n’a pas été suivie par les mémoires. En effet, les comparaisons (p.e. dans [VL96]) montrent une évolution des mémoires plutôt linéaire et beaucoup plus faible que celle des processeurs. Ainsi, en 1996, les mémoires présentent une performance 75 fois inférieure par rapport a` celle des processeurs. Ce déséquilibre a été comblé par l’introduction des mémoires caches28, nettement plus rapides que les mémoires conventionnelles29. De ce fait la mémoire d’une architecture universelle doit

27Les nombres réels codés en virgule flottante en simple précision nécessitent 32 bits de mémoire. 28Il s’agit des mémoires statiques de faible temps d’accès, mais couteuses.ˆ 29Mémoires dynamiques nécessitant le rafraˆıchissement a` des intervalles de temps réguliers.

57 Chapitre 2. Architecture universelle

être considérée comme un système complexe composé de plusieurs maillons ou sous systèmes dont les caractéristiques propres vont influencer la performance globale d’une application.

Le sous système mémoire-bus de données d’un système informatique va jouer un rôle très important dans la performance définitive d’une application et en particulier dans les applications de traitement des images étant donné la quantité de données qui est en jeu. Si nous pouvons calculer la bande passante théorique en tenant compte de la vitesse et la largeur de bus30, en réalité de tels taux de transfert ne seront jamais atteints.

Le Tableau 2.2 montre la performance théorique des différents mémoires du système considéré.

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/écriture de données (pour plus de détails 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ébit réel de l’ordre de 1GB/s.

Les temps d’accès a` la mémoire centrale constituent la borne inférieure de temps d’exécution, car quelque soit l’algorithme employé ce temps sera nécessaire pour acheminer les données de l’image jusqu’au processeur et réaliser la sauvegarde de l’image résultante.

2.1.5 Exploitation des différents niveaux de parallélisme

Aux cours des sections précédentes nous avons exploré les différents niveaux de parallélisme des architectures universelles actuelles et en particulier celles des ordinateurs personnels. Nous avons également donné une description plus précise des éléments essentiels, a` savoir le processeur et la mémoire du matériel qui sera utilisé. Il reste a` déterminer dans quelle mesure et comment, un utilisateur peut réellement bénéficier de tout le potentiel offert par ces systèmes, car contrairement a` ce que l’on pourrait croire, leur exploitation n’a rien d’immédiat.

2.1.5.1 Acc`es au parall´elisme intra-processeur

Le parallélisme au niveau des instructions (ILP) est résolu lors de l’exécution du programme et reste en dehors de contrôle explicite de l’utilisateur, surtout si celui-ci écrit un programme a` l’aide d’un langage de programmation évolué. L’emploi (ou non) de parallélisme des ce type dépend exclusivement du code généré (qualité de compilateur) et de la qualité de l’ordonnancement dynamique des instructions. Comme le problème d’ordonnancement n’a

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

58 2.1. Parallélisme des architectures universelles pas de solution optimale, l’utilisateur peut seulement espérer que toutes les ressources disponibles au sein d’une architecture super-scalaire / super-pipeline seront effectivement utilisées au mieux et que la performance obtenue sera la meilleure possible.

Si une telle approche de l’exploitation de parallélisme ILP peut offrir des résultats satisfaisants dans plupart de cas, les performances obtenues ne seront certainement pas les meilleures. Afin d’améliorer le temps d’exécution d’un programme écrit en langage évolué, il est possible de procéder a` l’optimisation du code en suivant les directives connues, issues d’une profonde connaissance du matériel et du comportement du compilateur employé. Certaines de ces directives sont édictées par le fabricant même (pour les processeurs Intel on peut consulter [Int97a] et [Int99e] p.e.). D’autres, basées sur des expériences personnelles de gens travaillant dans le domaine peuvent provenir de sources moins officielles telles que différents groupes de discussion créés autour de ce sujet.

Il faut cependant souligner que de telles optimisations sont souvent étroitement liées a` une architecture bien précise et peuvent ne pas être applicables sur d’autres processeurs, même s’il s’agit des processeurs d’une même famille mais de générations différentes. Ainsi, certaines recommandations valables pour le processeur Pentium 3 ne sont plus d’actualité et ne doivent plus être prises en compte étant donné les changements apportés sur l’architecture de processeur Pentium 4[Int99e].

Une approche moins empirique a` l’optimisation du codé généré consiste en l’emploi des outils spécifiques de simulation et d’analyse des programmes exécutables. Pour les processeurs Intel, il s’agit de l’outil VTune [Wol99] permettant de simuler l’exécution du programme et offrir a` l’utilisateur les informations précises sur son fonctionnement étant donné un processeur particulier.

A l’aide de logiciel VTune il est possible d’envisager l’analyse d’un programme a` deux niveaux différents : – Analyse au niveau de programme : l’identification des goulots d’étranglements au sein d’un programme volumineux faisant appel a` beaucoup de fonctions différentes. 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âce a` ce deuxième niveau d’analyse, particulièrement intéressant dans notre cas, un programmeur peut étudier non seulement l’exploitation du parallélisme des instructions : usage des pipelines (leur suspensions et/ou attentes), l’ordonnancement des instructions et l’usage des différents unités d’exécution, mais également l’exploitation de la mémoire 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énicher au sein d’un code écrit en langage évolué, le parallélisme de données et le traduire en langage machine spécifique pour ces extensions. Si l’utilisateur veut être surˆ que son application bénéficie pleinement de ces extensions il est obligé de les programmer de manière explicite.

Pour ce faire nous avons le choix entre :

59 Chapitre 2. Architecture universelle

1. La programmation en assembleur, possible même au sein d’un langage de programmation évolué grâce a` la capacité de certains compilateurs de traiter le code assembleur en ligne (“in-line assembly”).

2. L’emploi des fonctions intrinsics (développées par Intel) qui codent les instructions assembleur des extensions avec une syntaxe de langage C. L’avantage des fonctions intrinsics est dans une programmation plus claire : on peut travailler avec les variables plutôt que des registres, et plus universelle car tous les compilateurs n’intègrent pas la possibilité de traiter le code assembleur en ligne.

Dans le cadre de cette étude j’ai opté pour la première approche, afin d’être le plus près possible de la machine et minimiser l’influence de la qualité des différents outils sur le résultat final. Le compilateur utilisé pour le développement de l’application est le Microsoft Visual C++ 6.031, quoique son rôle est réduit au minium lorsqu’il s’agit de traiter le code assembleur en ligne. Tout programme est analysé et optimisé au niveau microscopique a` l’aide de logiciel VTune32.

2.1.5.2 Acc`es au parall´elisme inter-processeur

Les systèmes d’exploitation WindowsNT et Windows2000 utilisés intègrent tous les deux les notions du process et du thread exposé dans la section 2.1.2.1. Pour ces systèmes d’exploitation une application en cours d’exécution est appelée un module. Un module est composé du code (le programme même), des données et des éventuelles ressources supplémentaires nécessaires pour l’exécution (les librairies dynamiques p.e.). A chaque module créé, le système d’exploitation attache automatiquement un process, c’est a` dire un contexte d’exécution et un thread initial a` travers qui l’exécution du programme a effectivement lieu.

Si le matériel sous-jacent possède plusieurs processeurs, a` chaque processeur disponible, le système d’exploitation associe une file d’attente des threads a` exécuter. Lorsque l’exécution d’un thread est demandé, le système d’exploitation va l’attribuer a` la première file d’attente la moins chargée. Sur une machine multi-processeur, plusieurs threads émis l’un après l’autre, peuvent donc être exécutés par différents processeurs de fa¸con concurrentielle. L’attribution des différents threads aux différents processeurs est faite de fa¸con automatique et apparaˆıt transparente a` l’utilisateur.

Les systèmes d’exploitation envisagés permettent a` l’utilisateur d’accéder aux différents services concernant les threads a` travers des fonctions spécifiques, de haut niveau, regroupées au sein de l’interface API - Application Programming Interface, appelé Win32. Mis a` part des fonctions évidentes de création, de suspension et de destruction d’un thread, il est possible de prendre contrôle explicite d’un processeur spécifique. Attribuer un thread précis a` un processeur précis33 peut apporter un facteur d’accélération proche de 3 pour les applications en traitement des images[CD99]. Il est donc préférable 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(), SetThreadAﬃnityMask()

60 2.1. Parallélisme des architectures universelles différents processeurs de fa¸con manuelle, plutôt que de se fier aux automatismes proposés par le système d’exploitation même.

Les différentes fonctions API ont été intégrées au sein d’une classe spécifique de la librairie Microsoft Foundation Classes - MFC, fourni avec le compilateur Visual C++. L’exploitation de parallélisme inter-processeur apparaˆıt alors triviale si son exploitation consiste a` exécuter le même code, c’est a` dire la même fonction (le même filtre) a` travers plusieurs threads différents avec les données provenant de la même image ou des images différentes.

61 Chapitre 2. Architecture universelle

2.2 Exploitation de l’architecture standard

Le premier objectif de l’implémentation des filtres non-linéaires sur des architectures universelles vise l’emploi de l’architecture standard d’un ordinateur personnel. Pour réaliser les différents filtres, nous allons nous baser sur des algorithmes de tri bien connus, codés avec un langage de programmation évolué, C++ en l’occurrence, tout en faisant l’abstraction du matériel utilisé. C’est une approche qualifiée de ”boite noire”, car les connaissances nécessaires pour une telle réalisation se limitent uniquement a` la description de l’algorithme employé et aux règles de codage imposées par le langage de programmation choisi.

Dans cette approche nous faisons distinction entre deux types de réalisations différentes : 1. Implémentation de filtre de rang généralisé Il s’agit d’une seule procédure (d’un seul algorithme) qui permet le calcul d’une multitude de filtres. En fait, le rang recherché 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émentation des filtres spécifiques Si l’implémentation d’un filtre de rang généralisé est très intéressante, principalement a` cause de son caractère universel, la réalisation des filtres spécifiques est a priori plus avantageuse puisque la connaissance du rang recherché conduit a` des algorithmes (procédures) plus performantes. Les deux approches d’implémentation envisagées vont faire appel a` des algorithmes de tri fortement développés dans les années ’70, lors de la percée des premiers ordinateurs, machines parfaitement adaptées a` ce genre de tâches.

Actuellement on compte des dizaines d’algorithmes de tri différents, chaque algorithme ayant de nombreuses variantes permettant d’améliorer la performance dans des cas particuliers. Le choix d’un algorithme a` employer va dépendre de nombreux facteurs tels que le nombre d’éléments a` trier, la distribution initiale des éléments au sein de la suite (si la suite est complètement ou partiellement désordonnée ou si la suite est déjà triée), la différence de coutˆ entre la comparaison et le déplacement des éléments (les facteurs liés au matériel) etc.

Notre objectif n’est pas de comparer tous les algorithmes de tri existants, mais de déduire l’effi- cacité réelle, celle de l’implémentation, de ceux les plus couramment utilisés. Les algorithmes employés sont largement décrits dans la littérature spécialisée (on peut voir par exemple [Knu73, Sed98, PTVF02]), mais les implémentations proposées permettant de quantifier de fa¸con précise le temps de calcul obtenu lorsqu’il s’agit de les appliquer au problème des filtres non-linéaires et ceci pour quelques tailles de voisinages les plus couramment utilisées.

Le traitement a été effectué sur l’image de référence, une image en niveaux de gris de 1024x1024 pixels codés sur 8 bits, et ceci pour les tailles de voisinages les plus couramment utilisés : 3 3 (9 valeurs), 5 5 (25 valeurs), 7 7 (49 valeurs). × × × Les temps d’exécution donnés représentent une moyenne de 25 temps d’exécution (cf. Annexe A.2) obtenus pour le traitement de la même image lorsque celle-ci se trouve dans la mémoire centrale du système (le temps de chargement de l’image dans la mémoire 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écution obtenus et la vitesse de processeur nous pouvons déduire le nombre d’instructions élémentaires a` exécuter : les BOPs (cf. Section 1.5.2.3), nécessaire pour produire un pixel de l’image résultante.

La priorité de process et de thread exécutant ces procédures a été fixée a` la plus haute valeur possible (cf. Annexe A.3.2), afin d’éviter l’interference avec d’autres threads en cours d’exécution.

2.2.1 Implémentation de filtre de rang généralisé

2.2.1.1 Tri a` bulle (Bubble sort)

Le tri a` bulle consiste a` comparer un a` un tous les éléments adjacents de la suite (Vi) a` trier, en les permutant s’ils ne respectent pas l’ordre de tri souhaité. Les permutations auront lieu tant que la suite entière n’est pas complètement triée. La complexité de cet algorithme est de O(n2), ou` n représente le nombre d’éléments a` trier, mais peut approcher O(n) dans les meilleurs des cas, lorsque la suite est déjà triée.

Malgré la complexité élevée de cet algorithme et de sa très mauvaise réputation, son utilisation peut être justifiée lorsque n est petit, principalement a` cause d’une extrême simplicité de code correspondant. Les diverses techniques, notamment concernant la condition d’arrêt peuvent améliorer le temps d’exécution d’une procédure basée 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ésultats de la procédure basée 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 élément pour une position par- t ticulière de la future suite triée Vi . Ainsi, pour le premier élément d’une suite croissante on cherchera le minimum (ou le maximum dans le cas d’une suite décroissante) de la suite entière a` trier. Lorsqu’un tel élément a été trouvé, il est permuté avec le premier élément. La recherche de l’élément de la position suivante peut ensuite avoir lieu, avec le parcours qui se fait uniquement sur la partie de la suite non triée. Le même procédé est répété tant que la dernière position de la suite triée n’ait pas trouvée.

Cette méthode ne convient pas pour des tableaux partiellement trié, car la recherche d’une position particulière implique le parcours complet du tableau. La complexité théorique de

63 Chapitre 2. Architecture universelle cet algorithme est O(n2), même d’ailleurs comme pour le tri a` bulle, mais la performance d’une procédure peut s’avérer meilleure principalement a` cause d’un plus petit nombre de permutations a` réaliser.

En effet, les résultats du Tableau 2.4 montrent une amélioration 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éthode de tri pas insertion, pour chaque élément Vi de la suite a` trier on cherche un index m de la suite triée 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 éléments de la suite triée a` partir de l’index m doivent être décalés d’une place pour permettre l’insertion de ce nouvel élément. L’algorithme est ensuite répété tant qu’il existe des éléments a` insérer.

Nous constatons l’existence des deux boucles : une pour la recherche de l’index m et la deuxième pour le déplacement des éléments. Nous en déduisons que dans le meilleur des cas (la suite est déjà triée) la complexité algorithmique est de O(n), tandis que dans le pire des cas (la suite est triée mais dans l’ordre inverse) la deuxième boucle sera toujours exécutée et la complexité 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 élément de la suite non triée est choisi arbitrairement - le pivot. On construit ensuite deux suites : une, dont tous les éléments sont plus petits de pivot choisi et une autre avec des éléments plus grands (la phase de partition). Les éléments de ces deux suites sont ensuite triés récursivement (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é moyenne est O(nlogn). Dans le pire des cas, lorsque le choix de pivot produit des sous tableaux complètement désordonnées, la complexité passe a` O(n2). Le grand avantage de tri rapide est lié a` l’efficacité de l’implémentation qui approche réellement la complexité théorique. Les programmes de tri rapide se montrent plus performants comparés aux programmes basés sur des algorithmes dont la complexité théorique dans le pire des cas est O(nlogn). Le seul in- convénient de cette méthode réside dans son caractère récursif, car une importante partie de temps est consommée dans la sauvegarde et la récupération de l’état du processeur lors d’appels récursif. Il est possible de se débarrasser complètement de la récursivité mais au détriment d’une importante complexité 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 équilibré (Balanced quicksort algorithm) concerne le choix de pivot en introduisant la recherche et la sélection du pivot de tel fa¸con pour que a` chaque fois il approche au mieux la valeur médiane. Ainsi on évite le cas de la performance théorique la plus basse ou les sous-tableaux sont complètement désordonnés.

Une autre amélioration mais concernant cette fois-ci la phase de la partition est directement inspiré 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érents (bleue, blanc et rouge), mélangées au départ, en une suite qui rappelle le drapeau national hollandais. Au début, la suite des balles est divisée en quatre zones (il s’agit bien des indexes différents de la même suite) rouge, blanc, gris et bleue marquées par des pointeurs r, w, g et b. La méthode consiste a` choisir arbitrairement une balle non classée (une balle de la zone grise) et de s’interroger sur sa couleur. Si elle est bleue elle sera échangée avec la dernière balle grise ; si elle est blanche elle sera échangée avec la première balle grise ; si elle est rouge elle sera échangé avec la première blanche puis cette blanche sera échangée avec la première rouge. A la fin de chaque opération les pointeurs sur des zones différents sont mis a` jour.

Il est possible d’appliquer le même principe pour réaliser le tri d’une suite de nombres. Le critère permettant de diviser la suite en trois zones n’est plus la couleur mais bien la valeur du pivot. Si un élément non trié est égal a` la valeur de pivot nous faisons grandir la zone blanche ; si cette valeur est plus petite nous échangeons les éléments en cours de la zone blanche et bleue (les zones bleu et blanc grandissent) ; si cette valeur est plus grande nous l’échangeons 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écursivité sur le temps d’exécution, il est conseillé, lorsque la taille de la suite est de l’ordre d’une dizaine d’éléments, de faire le tri a` l’aide d’autres

65 Chapitre 2. Architecture universelle méthodes plus adaptées a` un tel type de tri. Pour la réalisation d’un tel algorithme hybride, le tri a` bulle a été utilisé.

L’algorithme de base, l’algorithme avec l’amélioration de la phase de partition (Dutch natinal Flag) et l’algorithme hybride ont été réalisé et leur performance évaluée (Tableau 2.6). Les procédures améliorées montrent un gain non négligeable par rapport aux algorithmes décrits précédemment.

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: Diﬀ´erentes versions du tri rapide.

2.2.1.5 Tri par fusion (Merge sort)

Le tri par fusion est un algorithme basée sur le principe diviser pour régner, tout comme le tri rapide. Le déroulement de l’algorithme comprends également trois phases. Dans la phase initiale la suite est divisée en deux parties, qui sont ensuite triées récursivement. Dans la dernière phase les deux suites triées sont fusionnées.

La complexité théorique de cet algorithme est O(nlogn) dans tous les cas. Pour effectuer le tri, l’algorithme nécessite un espace mémoire supplémentaire, proportionnel a` la taille de la suite. Lors d’utilisation de cet algorithme dans la réalisation d’un filtre de rang généralisé, même pour des voisinages très grands, ceci n’est pas vraiment un inconvénient étant donné la taille actuelle des mémoires centrales.

Comme pour le tri rapide il est possible d’utiliser des méthodes moins efficaces lorsque la taille de la suite devienne petite, mais ceci n’est intéressant que pour des suites composées de plusieurs milliers d’éléments.

Les résultats obtenus (Tableau 2.7) sont de loin les plus mauvais par rapport aux algorithmes décrits précédemment, 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éalisé avec le tri a` bulle lorsque la taille de tableau est inférieure a` 10.

66 2.2. Exploitation de l’architecture standard

2.2.1.6 Tri par tas (Heap Sort)

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

La méthode de tri consiste donc a` construire le ”heap” dans un premier temps et d’y effectuer la recherche d’un élément pour un rang r précis par la suite. La complexité de cet algorithme est O(nlogn) dans tous les cas.

Le principal inconvénient de cette méthode réside dans la lourdeur de son implémentation, qui en moyenne ne présente pas des aussi bons résultats que le tri rapide, comme le montre les résultats 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 éléments a` trier ayant la même valeur qu’un certain attribut, par exemple le premier chiffre d’une suite des nombres, dans des groupes (classes) indépendants. Après cette première phase de groupement, les différentes classes sont ensuite triées individuellement35. La concaténation des différents groupes permet d’aboutir au résultat final : la suite triée.

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

Dans sa version adaptée au filtre de rang généralisé, 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é est trouvée en sommant (en comptant) le nombre de pixels pour chaque valeur de niveau de gris tant que cette somme soit inférieure 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écessaire, notamment lorsque le nombre d’éléments différents correspond au nombre de classes choisies. 36Pour cette raison, le tri par classement est également appelé le tri par histogramme ou encore le tri par comptage.

67 Chapitre 2. Architecture universelle ligne) de l’histogramme calculé précédemment et en y ”rajoutant” la colonne (ou la ligne) suivante de l’image. Ainsi, le calcul de la valeur filtrée de voisinage suivant n’implique que très peu d’opération supplémentaires.

La Figure 2.13 montre le principe de déplacement de la fenêtre, nécessaire 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éside dans la complexité algorithmique théorique qui n’est plus fonction de taille de voisinage mais de nombre de classes, des groupes, déterminé par le nombre de bits utilisés pour la quantification d’un pixel de l’image. De ce fait, un tel algorithme devrait présenter une très bonne performance même pour des voisinages de très grande taille.

Il faut cependant noter que la performance réelle d’une procédure basée sur cet algorithme et réalisée en pratique est influencée 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 également appelé l’algorithme de la fenêtre glissante.~~

~~68 2.2. Exploitation de l’architecture standard~~

Le temps d’exécution définitif va dépendre également de la valeur de rang recherchée, 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 élément dans l’histogramme en faisant NV son parcours dans le sens qui conviens le mieux. Le cas d’un filtre médian, lorsque r = 2 , est le cas le plus défavorable car il faut réaliser la somme des valeurs de l’histogramme pour arriver a` la valeur de rang r. Signalons enfin que le temps d’exécution dépendra du contenu de l’image38.

~~La Table 2.9 indique la performance de cet algorithme pour des voisinages habituels et montre la différence entre les deux cas extrêmes : le filtre Min/Max et le filtre Médian.~~

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 - ﬁltres Min/Max, M´edian.~~

Pour illustrer l’efficacité de cet algorithme lorsqu’il s’agit de calculer les filtres de rang pour des voisinages de très 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écution ainsi que le nombre de BOPs correspondant au tri rapide hybride. Rappelons ici que dans le cas de cette algorithme les temps d’exécution sont les mêmes quelque soit la valeur de rang r recherché (i.e. quelque soit le filtre choisi).

La colonne Classement montre les résultats de l’algorithme de tri par classement pour les deux cas limites : filtres Min/Max et le filtre médian, ainsi que le facteur d’accélération 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émentation des filtres spécifiques~~

Les algorithmes employés pour la réalisation d’un filtre de rang généralisé effectuent le tri complet du voisinage donnée. Or ceci n’est pas vraiment nécessaire si la valeur de rang est connue avant le traitement même. Pour certains algorithmes, tel que l’algorithme de tri par sélection, il est possible d’arrêter le tri avant, dès que le rang recherché a été trouvé et ainsi diminuer le nombre d’opérations a` effectuer.

Comme dans le cas de tri par classement, la performance d’un tel algorithme dépend de la valeur du rang recherché. En effet, plus le rang recherché est grand, plus on doit avancer dans l’opération du tri et a` nouveau deux cas extrêmes se présentent :

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édiane - c’est le cas le plus défavorable puisqu’il faut parcourir NV NV 2 fois le voisinage pour en enlever systématiquement les 2 minima (ou des maxima) pour arriver a` la valeur médiane

~~Le Tableau 2.11 montre la performance de l’algorithme de tri par sélection modifié pour les deux cas extrêmes a` savoir les filtres Min/Max et Médian.~~

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´eciﬁques.~~

~~2.2.3 Conclusion~~

~~Le graphique de la Figure 2.14 permet de comparer la performance des différentes procédures pour le filtre de rang généralisé, basées sur des algorithmes classiques de tri.~~

Nous pouvons constater la très mauvaise performance des procédures de tri par fusion et par tas (Pr-7, Pr-8). Les procédures basées sur des algorithmes de tri les plus connus, tels que le tri a` bulle, par sélection ou par insertion (Pr-1, Pr-2 et Pr-3), présentent des performances intéressantes lorsqu’il s’agit de travailler avec le plus petit des voisinages : un 3 3. Malheu- × reusement ces procédures ne présentent pas d’intérêt lorsque la taille de voisinage devient plus importante. Les procédures basées sur les différentes variantes de l’algorithme de tri rapide (Pr-4, Pr-5 et Pr-6) se montrent cependant plus avantageux dès que la taille de voisinage dépasse 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~~

~~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élection Pr-4 - Tri rapide de base Pr-6 - Tri rapide hybride Pr-8 - Tri par tas Fig. 2.14: Performance des différentes procédures de filtre de rang généralisé basées sur des algorithmes de tri classiques.

Les meilleurs temps obtenus par les procédures de filtre de rang généralisé (la procédure Pr-3 pour le voisinage 3 3 et la procédure Pr-6 pour les voisinages 5 5 et 7 7) sont ensuite × × × comparés avec la procédure qui réalise l’algorithme de tri par classement pour le Min/Max (Pr-9a) et médian (Pr-9b) et avec ceux des filtres spécifiques Min/Max (Pr-10) et Médian (Pr-11). La Figure 2.15 montre la comparaison pour les filtres Min/Max, ou` on constate une meilleure performance des algorithmes spécifiques. Il faut cependant noter que par rapport a` l’algorithme de tri par classement le facteur d’accélération 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élection Pr-6 - Tri rapide hybride Pr-9 a - Tri par classement Pr-10 - Spécifique pour Min/Max~~

Fig. 2.15: Performance de l’algorithme le plus rapide pour le filtre généralisé, l’algorithme de tri par classement et la procédure de filtre spécifique utilisés pour le calcul d’un filtre Min/Max.

~~71 Chapitre 2. Architecture universelle~~

La Figure 2.16 montre la comparaison des performances des procédures qui correspondent au filtre médian cette fois-ci. Ici, seulement pour le voisinage 3 3 il est plus intéressant de × travailler avec un algorithme spécifique. 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élection Pr-6 - Tri rapide hybride Pr-9 b - Tri par classement Pr-11 - Spécifique pour médian~~

Fig. 2.16: Performance de l’algorithme le plus rapide pour le filtre généralisé, l’algorithme de tri par classement et la procédure de filtre spécifique utilisé pour le calcul d’un filtre Médian.

Cette comparaison nous permet de déduire les meilleures procédures pour les filtres et voisinages envisagées 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édures qui calculent les différents filtres non-linéaires peut être sensiblement améliorée en exploitant les deux niveaux de parallélisme des architectures Pen- tium : le parallélisme de données et le parallélisme des instructions.

L’exploitation de parallélisme des données des extensions a` l’architecture standard n’est pas automatique. Cette partie de matériel ne sera donc pas utilisée lorsqu’il s’agit de compiler les programmes écrits en langages de programmation évolués39. Un utilisateur souhaitant que son application bénéficie réellement des ces extensions a le choix entre : employer les librairies commerciales ou programmer les extensions lui même.

L’emploi des librairies commerciales représente la manière la plus simple et la plus directe d’accéder au parallélisme de données. Dans ce cas, aucune connaissance préalable du matériel sous-jacent et des extensions en question n’est a` priori nécessaire, si ce n’est le format de données utilisées et la syntaxe d’appel des fonctions proposées. Une telle librairie, développée par Intel et spécifique aux applications de traitement des images a été utilisée dans un premier temps pour évaluer le gain en performance des extensions par rapport a` l’architecture standard.

L’emploi de librairies existantes offre l’avantage d’être immédiat. Par contre la programmation des extensions demande un temps considérable de développement et une bonne connaissance de l’architecture du processeur et de son jeu d’instructions. En contre partie les performances de telles procédures justifient l’effort déployé car il est possible d’améliorer considérablement les résultats obtenus par rapport aux libraires. De plus, la maˆıtrise des extensions permets a` l’utilisateur de réaliser ses propres fonctions et de les optimiser pour des cas particuliers souvent rencontrés dans la conception des programmes destinés au traitement des images.

L’exploitation de parallélisme des instructions est entièrement automatisée et ne laisse pas beaucoup de place a` l’intervention de l’opérateur. Cependant les résultats obtenus ne sont pas forcement les meilleurs duˆ a` la nature complexe du problème d’ordonnancement des instructions et le temps qui lui est consacré. En effet, l’ordonnancement est fait pendant l’exécution et donc doit être le plus rapide possible. L’optimisation des programmes a` ce niveau est résumée par le suivi de quelques règles de bonne pratique p.e. [Lec99], en général propres a` la programmation en assembleur et qui visent a` minimiser les différents aléas propres au fonctionnement en pipeline (aléas structurels et de données en particulier). Enfin, un outil d’analyse de programme en exécution : VTune, offre la possibilité de vérifier si l’ordre des instructions imposé par le programme est efficace ou pas et permet a` l’utilisateur d’agir en conséquence.

39Dans le compilateur de langage C/C++ d’Intel, il existe une option qui force le compilateur d’explorer le code est déterminer un éventuel parallélisme exploitable par les extensions, mais nous n’avons aucune garantie que cela aura effectivement lieu. La réussite, donc le passage entre un langage évolué et un code machine qui exploite réellement ces extensions, n’arrive que dans des situations bien précises, fort dépendantes du style d’écriture 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élisme de données ont fait leur apparition dès la première génération des processeurs Pentium. Au début, ces extensions n’ont pas été fort exploitées, probablement a` cause d’un usage de plus en plus fréquent des langages de programmation évolués. Comme le seul moyen possible de profiter des nouveautés dans l’architecture des processeurs Pentium implique la programmation en assembleur, marginalisée depuis un certain temps, cette partie de matériel est restée longuement sous-exploitée.

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

Ici nous nous intéressons plus particulièrement a` la librairie IPL, destinée au traitement des images. Cette librairie41, largement décrite dans [Int99a], a été évaluée pour la même image de test utilisée dans l’évaluation de la performance de l’architecture standard 42. Les performances des différents filtres sont représentées 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écifiques Min/Max~~

~~2.3.2.1 Description g´en´erale de l’algorithme~~

Considérons un pixel i de l’image I et un voisinage Vi correspondant a` ce pixel, de forme carrée, de taille Vx Vx, noté sous forme d’une matrice Vi[m, n]. Le calcul d’un filtre de rang ∗ spécifique (le filtre Min ou Max) pour ce pixel peut être réalisé en deux temps. Tout d’abord on calcule Vx valeurs intermédiaires : les maxima (ou les minima) locaux des éléments de m vecteurs colonnes de Vi, notés 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ée du pixel i de voisinage Vi donné 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~~

~~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ême principe peut être appliqué pour le calcul d’un ensemble des voisinages d’une fenêtre de l’image. Considérons une fenêtre Fi de taille Fx Fy, avec Fy = Vy = Vx : la fenêtre Fi est ∗ de la même hauteur que le voisinage. Comme précédemment, nous allons d’abord chercher les k maxima (ou les minima) locaux des différents vecteurs colonnes de la fenêtre Fi, notés 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être filtrée il suffit de calculer le maxima (ou les minima) des maxima/minima locaux des vecteurs colonnes qui correspondent aux différents 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être filtrée produit seulement Fx (Vx 1) et pas Fx éléments − − a` cause de l’effet de bord.

~~L’algorithme présenté convient parfaitement bien a` l’architecture SIMD des extensions a` l’architecture standard. En effet, la fenêtre Fi entière est sauvegardée dans le mémoire des~~

75 Chapitre 2. Architecture universelle registres. Le calcul des maxima (ou des minima) locaux des différents vecteurs colonnes de la fenêtre Fi est alors immédiat. Un registre particulier contient les valeurs des maxima locaux 0 des vecteurs colonnes de Fi, le vecteur ligne noté 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émentaires sont ensuite obtenus en appliquant au vecteur ligne tl − 43 l’opérateur de décalage a` droite, noté . 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érents vecteurs colonnes, obtenus a` partir des Fy vecteurs lignes (Equation´ 2.16), nous permet de calculer les valeurs de la fenêtre filtrée, le vecteur F˜i, dont les Fx (Vx 1) derniers valeurs représentent les valeurs filtrées : − −

~~˜ 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être Fi de 0 l’image et la formation du vecteur ligne tl correspondant. La Figure 2.18 b) montre le décalage 0 de vecteur tl et la formation des Fy vecteurs des maxima (des minima) locaux permettant le calcul des valeurs filtrées.

43L’opérateur de décalage réalise le déplacement a` droite (l’opérateur a` gauche étant noté ) des éléments du vecteur d’une place. Dans le cas d’un décalage a` droite, le dernier élément du vecteur est perdu et le premier élément 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être filtrée.~~

Pour le calcul des valeurs d’une nouvelle fenêtre F , nous avons le choix pour le déplacement de la fenêtre F dans l’image I entre : – déplacement horizontal - selon l’axe des indices i (Figure 2.19 a)) – déplacement 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éthodes présentent des avantages et des inconvénients qui peuvent jouer un rôle important sur le temps d’exécution final. Pour s’en rendre compte il est nécessaire de prendre en considération certains aspects

77 Chapitre 2. Architecture universelle matériels de l’architecture ciblée. Dans l’architecture de l’ordinateur visé les processus de lecture/écriture des données et le calcul sont des taches gérées par des unités matérielles indépendantes et peuvent donc être exécutées de fa¸con concurrentielle. Dans un cas idéal les deux sont dans un équilibre : on réalise un pipeline entre la lecture, le calcul et l’écriture. 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ébit de données, soit parce que la mémoire ne parviens pas a` délivrer la quantité de données nécessaire au calcul. Pour combler la faible latence de la mémoire centrale une mémoire cache est placée entre la mémoire centrale et le processeur, et son emploi sera tout a` fait différent dans les deux cas envisagés.

Si le déplacement de la fenêtre est “horizontal”, pour chaque fenêtre F de l’image I il faut réaliser le chargement de Fy lignes de l’image depuis la mémoire centrale (NF Fy chargements × au total avec NF le nombre de fenêtres total dans l’image). Dans ce cas, les données déjà présentes dans les registres internes de processeur et utilisées pour le calcul d’une fenêtre Fi ne sont pas réutilisées pour le calcul de la fenêtre Fi+1 suivante.

Même si cet algorithme peut paraˆıtre a` priori désavantageux, a` cause d’une évidente redondance en lecture, l’implémentation peut s’avérer intéressante. En effet, lorsque la fenêtre F est chargée dans les registres de processeur, une zone mémoire plus large, située immédiatement après la zone lue, est automatiquement placée dans la mémoire cache de niveau 2. Lorsque le calcul exige les données de la fenêtre suivante, la lecture ne devra pas se faire dans la mémoire centrale, mais bien dans la cache. En sachant que le temps d’accès a` cette mémoire est nettement plus faible que celui de la mémoire centrale (en théorie 48GB/s contre 3.2GB/s) on peut néanmoins espérer obtenir un bon résultat.

~~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éplacement “vertical” de la fenêtre F , le nombre de chargements des vecteurs lignes depuis la mémoire peut être réduit a` un seul chargement par fenêtre F a` calculer. Le nombre de chargements total des lignes de l’image est alors réduit a` NF , puisque on peut bénéficier des chargements déjà effectués.

~~78 2.3. Exploitation de parall´elisme intra-processeur~~

Si le nombre de chargement est ici inférieur a` celui de parcours horizontal, l’implémentation d’un tel algorithme présente a` priori un inconvénient majeur. Pour les tailles des images et des mémoires caches habituellement rencontrées44, la lecture de la ligne suivante de l’image nécessaire pour la construction de la fenêtre suivante se passera certainement dans la zone de la mémoire centrale qui n’a pas encore été copiée dans la mémoire cache. Si le processeur effectue le calcul suffisamment vite, il sera amené a` attendre le transfert.

~~Le pseudo-code de l’algorithme décrit et pour un élément structurant de taille 3 3 est donné × 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émentation des deux algorithmes exposés dépend fortement de l’extension utilisée 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être de 8 pixels de large. Pour des voisinages de taille inférieure a` 8 8 les mêmes instructions calculent alors 8 (Vx 1) × − − pixels de résultat avec un seul accès a` la mémoire pour la fenêtre 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 eﬃcace, comme nous allons le voir par la suite.

44Dans plupart des cas l’image est codé sur une quantité d’information beaucoup plus importante que celle de la mémoire cache. Dans notre cas l’image de référence fait un mégaoctets et la mémoire 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être. Par conséquence nous avons 16 (Vx 1) de pixels calculés par fenêtre F de l’image. − − Signalons que les mêmes algorithmes peuvent être utilisés pour des voisinages plus grands que ceux envisagés mais avec une implémentation plus particulière due, principalement, a` la gestion des résultats temporaires.

~~2.3.2.2 Parcours horizontal~~

L’implementation des algorithmes pour le parcours horizontal a été réalisée a` l’aide des extensions MMX, SSE et finalement SSE2 propre au processeur Pentium 4. Plusieurs techniques d’optimisation, décrites par la suite, sont utilisées avec succès pour améliorer le temps d’exécution final.

Implémentation a` l’aide des extension MMX et SSE L’étape clé de l’algorithme décrit est le calcul des valeurs de minima/maxima locaux entre les différents vecteurs lignes de la fenêtre F (pseudo-instruction compare du Listing 2.2). La réalisation de cette opération dépend fortement de l’extension utilisée.

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ênèrent dans le registre dst un vecteur masque, qui dans le cas de l’instruction pcmpgtb dst,src place la valeur 1 là 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ère 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écution moyen de cette procédure calculé sur 25 passes sur l’image de référence est de 16.62 ms (Procédure MMXProc1. de Tableau 2.14).~~

Pour l’extension SSE, les instructions spécifiques de recherche de minimum/maximum entre deux registres46 permet de remplacer le code décrit (Listing 2.4) par une seule instruction. Dans le cas d’une procédure travaillant sur un voisinage de 3 3, l’introduction de ces instruc- × tions permet d’obtenir un facteur d’accélération de 1.8 par rapport a` la procédure précédente (Procédure 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ès 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és. Le résultat est placé dans le registre dst.

~~80 2.3. Exploitation de parall´elisme intra-processeur~~

Pour les deux procédures en question, le parcours de l’image est fait de la même manière, a` l’aide de deux boucles écrites en langage C. Ces deux boucles peuvent être remplacées par une seule boucle, écrite en assembleur (SSEProc2. de Tableau 2.14). L’avantage en est double : – la gestion d’une deuxième boucle imbriquée est supprimée, – le calcul des adresses est réduit au strict minimum.

Une optimisation supplémentaire (SSEProc3. de Tableau 2.14), qui consiste en emploi de mode d’adressage dit de déplacement afin d’accéder aux différents vecteur lignes de la fenêtre F d’image I, permet d’obtenir un facteur d’accélération de 1.2, toujours par rapport a` la procédure précédente. Au lieu de travailler avec des pointeurs (registres) différents vers les différentes lignes de l’image, on peut utiliser un seul pointeur (en seul registre) et spécifier explicitement le déplacement entre deux lignes de l’image I (Listing 2.5).

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

~~Listing 2.5: Adressage de d´eplacement~~

On pourrait reprocher a` la spécification explicite de déplacement un certain manque d’uni- versalité car le programme compilé impose une constante pour la dimension horizontale de l’image. Le traitement d’une image de taille horizontale différente impliquerait la re- compilation du programme. Il est possible de rendre la valeur d’offset de déplacement variable en utilisant la technique de code auto-modifiable. Avant l’exécution de la procédure en question, le programme va modifier la valeur de l’offset de déplacement en écrivant la valeur désirée dans la zone mémoire correspondante. L’adressage reste bien celui de déplacement mais il est résolu lors de l’exécution du programme et plus lors de compilation 47.

La dernière optimisation consiste en emploi de la technique dite de déroulement des boucles. Cette méthode présente l’avantage de diminuer la charge de calcul des boucles et éventuellement permettre un meilleur ordonnancement des instructions. Elle consiste a` tout simplement répliquer le même code : il s’agit d’un simple ”copier-coller” du code a` l’intérieur de la boucle et d’adaptation des offsets de lecture des données et d’écriture des résultats. Le code ajouté va donc effectuer le calcul sur un autre set de données, dans notre cas typiquement la fenêtre Fi+1 suivante de l’image I. L’utilisation de déroulement des boucles (SSEProc4. de Tableau 2.14) permet d’observer une accélération de 1.3 par rapport a` l’exécution sur une seule fenêtre, toujours pour un voisinage 3 3. × Un déroulement supplémentaire de boucle n’apporte pas de gain majeur, le temps d’exécution ne change pratiquement pas pour l’élément structurant 3 3 (SSEProc5. de Tableau 2.14). × Seules les trois dernières procédures ont été adaptées pour les voisinages 5 5 et 7 7. On × × constate que pour les voisinages 5 5 et 7 7 le deuxième déroulement de boucle n’apporte × × pas de gain, au contraire la performance est pire que dans le cas d’un déroulement simple.

~~47Pour des explications plus détaillées concernant l’implémentation 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émentation 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être F de 16 pixels de large. Les instructions spécifiques pour le calcul des entiers, celles de comparaison et de décalage en mode octet48 peuvent être également utilisées sur ces registres.

La procédure la plus performante décrite pour l’extension SSE (SSEProc5.), a été adaptée pour l’extension SSE2, le Tableau 2.15 résume les résultats obtenus pour les différentes voisinages 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écution n’a pas été divisé par deux, malgré les 14 pixels calculés avec le même nombre d’instructions exécutées (contre 6 pour l’extension MMX). Nous sommes donc limité par la lecture de données qui ne parviennent plus a` suivre la vitesse de calcul de processeur.

~~Pour des voisinages 3 3 et 5 5 le facteur d’accélération non-négligeable obtenu est de 1.6 × × et de 2.9 par rapport a` la procédure la plus performante utilisant l’extension SSE.~~

~~2.3.2.3 Parcours vertical~~

~~L’algorithme de parcours vertical a été codé pour l’extension SSE2 avec les mêmes as- tuces de programmation mentionnées 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élisme intra-processeur l’adressage explicite mais sans déroulement de boucle. Pour la même image de référence et un voisinage de taille 3 3, le temps d’exécution 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é par la meilleure procédure de parcours horizontal. La lecture redondante49 des données s’avère donc plus avantageuse duˆ a` la meilleure exploitation de la mémoire cache. Nous sommes bien dans le cas d’un fort déséquilibre de pipeline entre la lecture, le calcul et l’écriture des résultats, car la latence de la mémoire centrale n’est pas couverte par la mémoire caché.

~~2.3.2.4 Analyse a` l’aide de VTune~~

L’implémentation des deux algorithmes proposés nous laisse supposer que si une éventuelle accélération est possible, elle devrait se faire de côté de la lecture de données. Une analyse des deux procédures a` l’aide de logiciel VTune a permis de confirmer cette hypothèse et d’isoler deux problèmes distincts quant a` l’emploi de la mémoire : le problème des accès en dehors de la mémoire cache soup¸conné dès le départ et le problème d’alignement de données50.

Mémoire cache Une meilleure exploitation de la mémoire cache peut être obtenue a` l’aide de deux solutions différentes. Une première solution consiste a` découper l’image a` traiter en sous-images de fa¸con a` ce que chaque sous-image tienne en entièreté dans la mémoire cache de niveau 2. Les différentes sous-images seront traitées séparément et les résultats assemblés a` posteriori. L’exécution de la procédure 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èreté de l’image de référence en seulement 2.3 ms. En réalité l’exécution sur l’image de référence ne se fait qu’en 5 ms si l’on tiens compte des temps de découpe et d’assemblage de l’image. Même si le facteur d’accélération obtenu est de 4 par rapport a` la procédure de parcours vertical normal, on constate aucune accélération par rapport a` la procédure de parcours horizontal.

La deuxième solution concernant une meilleure exploitation de la mémoire cache consiste a` utiliser l’instruction prefetch déjà mentionnée. La technique de prefetching logicielle consiste a` réaliser des chargements explicites d’une ligne de données de 128 octets dans la mémoire cache d’un certain niveau52. Les tests effectués ne montrent aucune différence significative

49Pour l’image de référence et pour un parcours vertical, la quantité de données a` lire est d’environs 2 mégaoctets quelque soit la taille de voisinage. Pour cette même image et pour un parcours horizontal cette quantité de données passe a` 4, 6 et 7 mégaoctets pour des voisinages 3 × 3, 5 × 5, 7 × 7. 50Le logiciel VTune compte le nombre d’accès réalisés en dehors de la mémoire cache. Sur base de nombre des cycles effectifs passés a` l’exécution il est dans la mesure de indiquer les endroits dans le code qui sont des potentielles source de ralentissement. 51La taille de la mémoire cache nous permet de travailler avec des sous-images plus grandes. Cependant [Int99e] préconise de travailler avec des vecteurs dont la taille correspond a` la moitié de la mémoire cache. 52Le processeur Pentium 4 intègre deux modes de prefetching : un matériel et un logiciel. Pour le prefetching matériel - automatique, une unité dédicacée réalise ce pré-chargement. Dans sa stratégie de base, cette unité copié systématiquement dans la mémoire cache de niveau 2 les 256 octets en amont de l’adresse lu. Dans [Int99e] on précise que l’unité matérielle de prefetch est capable de ”comprendre” des patterns d’accès simples et de modifier la stratégie de base. Etan´ t donnée le temps d’exécution des procédures envisagées, nous déduisons que le processeur n’arrive pas a` comprendre le pattern imposé par le parcours vertical, pourtant très simple. Pour le prefetching logiciel c’est l’utilisateur qui détermine la partie de la mémoire centrale qui sera copiée dans la mémoire cache.

83 Chapitre 2. Architecture universelle par rapport a` la version de la procédure sans pré-chargement. L’absence de gain peut être expliquée par le coutˆ d’appel de l’instruction prefetch non-négligeable mais surtout par la rapidité de calcul de processeur : le temps de calcul est ici nettement plus faible que le temps nécessaire pour réaliser le transfert.

Alignement des données Le deuxième problème d’accès a` la mémoire est lié a` l’alignement des données. Dans toutes les procédures considérées la lecture depuis la mémoire vers des registres internes du processeur est faite a` l’aide des instructions permettant de charger un vecteur de 16 octets depuis n’importe quelle adresse de la mémoire centrale. On appelle un tel accès non-aligné (instruction movdqu xmm, mem). Cette instruction de lecture est caractérisé par un grand nombre des cycles processeur effectifs nécessaires pour son exécution. Par opposition a` un accès non-aligné, un accès aligné (instruction movdqa xmm, mem) sur des adresses multiples de 16 est nettement plus efficace [Int99e]. Malheureusement le calcul des filtres dans le voisinage implique les effets de bords : pour certains pixels nous sommes obligés d’effectuer des lectures/écriture non-alignés. La Figure 2.20 montre :

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

~~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ès aligné (14/16 dans le cas d’un voisinage 3 3) justifierait la découpe de problème en deux : un calcul sur des adresses × alignées et un calcul sur des adresses non-alignées. Le temps de calcul sur des pixels qui se trouvent sur des adresses alignées est de 3.83ms. Malheureusement l’inclusion de calcul sur des pixels des adresses non-alignées fait monter le temps d’exécution a` 8.1ms car nous avons pour le restant de 2/16 des pixels le même nombre d’instructions a` exécuter puisque nous travaillons avec une unité de traitement vectorielle.

L’analyse des différentes possibilités d’amélioration de temps d’exécution a` travers l’action sur des accès mémoire nous permet de dire qu’il serait très difficile d’aller plus loin avec les algorithmes présentés. Nous avons donc des temps d’exécution de référence pour des filtres spécifiques Min/Max exploitant le parallélisme de données.

~~84 2.3. Exploitation de parall´elisme intra-processeur~~

~~2.3.3 Programmation des extensions : ﬁltre M´edian~~

Pour le calcul d’un filtre médian sur un voisinage 3 3 on peut utiliser un arbre de × comparateurs, représenté schématiquement a` la Figure 2.21. Chaque nœud de l’arbre est un comparateur de deux valeurs a et b a` l’entrée et permet de calculer : max a, b et min a, b . { } { } Trois nœuds sont ensuite utilisés pour complètement trier un vecteur de trois éléments : – 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 ﬁltre m´edian sur un voisinage de 3 3 pixels. ×~~

L’arbre décrit peut être facilement codé a` l’aide de l’extension SSE2. Pour des voisinages plus grandes la conception des arbres similaires s’avère particulièrement difficile a` cause d’un nombre fort limité de registres internes (8 en tout). Dans ce cas la gestion des résultats intermédiaires implique des accès fréquents a` la mémoire, ce qui se traduit par un abaissement de la performance.

L’implémentation de cet algorithme fait appel a` la procédure la plus performante des filtres Min/Max : une boucle de parcours de l’image en assembleur, un adressage explicite et un seul déroulement de boucle. La performance obtenue de cette procédure pour les voisinages typiques est indiquée 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 : ﬁltre d’un rang quelconque~~

A l’aide de la méthode exposée dans la section précédente il est possible de calculer les filtres de n’importe quel rang r. Etan´ t donnée que la recherche de la valeur médiane est le cas le plus défavorable et la recherche des Min/Max le cas le plus favorable, le temps d’exécution 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érivés et représentent souvent juste une étape dans la chaˆıne de traitement des images. La réalisation d’une séquence d’algorithmes implique alors plusieurs parcours de l’image et le calcul des résultats intermédiaires qui doivent faire au moins un aller-retour entre le processeur et la mémoire. Or comme nous l’avons montré c’est précisément les transferts qui représentent le goulot d’étranglement.

~~Pour illustrer l’inﬂuence 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ération arithmétique sur les deux résultats intermédiaires de filtrage.

Les meilleurs procédures pour les filtres morphologiques de dilatation/érosion sur un voisinage de 3 3 nécessitent environ 5 ms et nous avons besoin de ce même temps pour la soustraction × des deux images. De ce fait, l’exécution des trois procédures mis “en série” prends environs 15 ms.

Une autre fa¸con de faire la même chose serait de créer une procédure spécifique qui implique une seule lecture de la fenêtre F et d’effectuer le calcul complet. Dans ce cas les résultats intermédiaires restent dans la mémoire des registres minimisant ainsi les accès a` la mémoire. Le temps d’exécution d’une telle procédure est de seulement 7 ms, avec un facteur d’accélération de 2.4 par rapport a` la procédure avec des appels séquentiels des procédures.

~~2.3.6 Filtre de rang généralisé~~

Lors de l’exploitation de l’architecture standard un algorithme très performant pour le filtre généralisé a été présenté - l’algorithme de tri par classement. Cet algorithme, mis a` part sa très bonne performance pour des très grandes tailles de voisinage a l’avantage de produire le vecteur du voisinage trié complet : la réalisation de n’importe quel filtre de rang comprend alors tout simplement un accès différent au vecteur trié et donc un même temps d’exécution quel que soit le rang recherché.

~~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éponse 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ésente le calcul de l’histogramme fait pour chaque voisinage Vi, réalisé NV fois pour une image complète. En effet, avec une unité de traitement vectorielle, la manipulation de l’histogramme (l’enlèvement et l’ajout des colonnes de l’image) est possible mais au détriment d’une importante lourdeur de l’implémentation. Avec une unité de traitement vectorielle nous ne sommes plus dans la mesure de réaliser un adressage de la mémoire par le contenu et donc une implémentation efficace de calcul de l’histogramme.

~~87 Chapitre 2. Architecture universelle~~

~~2.4 Exploitation du parall´elisme inter-processeur~~

Pour explorer le parallélisme inter-processeur, un système a` mémoire partagée doté de deux processeurs d’architecture Pentium 2 a été utilisé. Un tel système permet l’exécution simultanée des deux threads avec deux flots d’instructions indépendants sur deux flots de données indépendants provenant d’une même mémoire centrale53. Si une application souhaite bénéficier de ce type de parallélisme elle doit initier deux threads au sein du thread principal d’exécution. Comme il s’agit d’un ordinateur équipé des processeurs Pentium 2, seules les procédures développées pour l’architecture standard et celles qui exploitant l’extension MMX peuvent donc être exécutées.

~~2.4.1 Ex´ecution sur deux processeurs~~

Etan´ t donné le nombre de processeurs disponibles, l’image a` traiter est divisée en deux parties, les deux sous-images appelé ”haut” et ”bas” (Figure 2.22). Afin d’éviter les effets de bord et permettre la reconstruction de l’image résultante après le calcul, les deux sous- images présentent un recouvrement de l’image initiale de Vy lignes. En toute généralité, la sous-image ”haut” couvre Vy1 lignes supplémentaires 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 processeurs.~~

Le choix de sens de la coupure de l’image, horizontal plutôt que vertical, a été dicté par la fa¸con dont l’image est sauvegardée dans la mémoire centrale et vise une meilleure exploitation de la mémoire cache.

Les parties ”haut” et ”bas” de l’image seront traitées par la même procédure, exécutée a` travers deux threads distincts (cf. Section A.3 de l’Annexe A). Les deux threads en question vont

~~53Signalons qu’à la taille de la mémoire cache prêt, nous pouvons considérer un tel système comme une architecture MIMD a` mémoire partagée.~~

~~88 2.4. Exploitation du parall´elisme inter-processeur~~

écrire leur résultats respectifs dans deux zones mémoires distinctes mais faisant partie d’un même bloc de mémoire contiguë de l’image résultante. Signalons qu’aucune synchronisation entre deux threads ne pas nécessaire car il n’existe aucun risque d’écriture concurrentielle.

En ce qui concerne l’ordonnancement des threads, deux situations différentes peuvent être envisagées : 1. Affectation des deux threads aux processeurs est laissée libre au système d’exploitation - l’ordonnancement automatique 2. Chaque thread est explicitement associé a` un processeur particulier grâce a` la fonction API SetThreadAffinityMask() - l’ordonnancement manuel. Aucune différence significative n’a pas été relevée entre les deux modes d’ordonnancement malgré un facteur d’accélération proche de 3 énoncé par Cutler et Davis dans [CD99]. Afin d’assurer une exécution concurrentielle la stratégie de l’ordonnancement manuel a été utilisé systématiquement.

Le Tableau 2.17 montre les résultats obtenus en termes de temps de calcul et de BOPs par pixel correspondant pour les deux procédures envisagées : l’algorithme rapide DNF et celui basé sur l’extension MMX. La première colonne (T1) donne les résultats lorsqu’un seul 54 thread a été initié, ce qui équivaut a` la performance d’un seul processeur . La colonne T2 montre les résultats obtenus lorsqu’il s’agit de travailler avec deux threads selon le schéma 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élération proche de 2, observé lors de l’exploitation des procédures pour l’architecture standard et lors de l’exploitation des procédures utilisant l’extension MMX.

Une remarque est cependant nécessaire. Si le facteur d’accélération observé est proche du facteur d’accélération théorique d’une machine parallèle il ne doit pas forcement le rester pour une machine bi-processeur basée sur des processeurs Pentium-4. En effet, comme nous l’avons montré dans la Section 2.3 le goulot d’étranglement se situe au niveau de la mémoire, même pour une machine doté d’un seul processeur. Dans ce cas, la multiplication des processeurs dans une architecture de type mémoire partagée ne pourrait en aucun cas apporter ce même facteur d’accélération.

~~54Ceci est nécessaire puisque les résultats obtenus précédemment sont relatifs a` l’emploi d’une architecture Pentium 4.~~

~~89 Chapitre 2. Architecture universelle~~

~~2.5 Conclusion~~

L’implémentation des filtres non-linéaires sur des architectures universelles a été abordée de trois fa¸cons différentes : 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ète de matériel, possible grâce aux compilateurs de langages de programmation évolué. 2. L’approche du parallélisme intra-processeur, principalement basé sur l’exploitation de parallélisme de données (le mode SIMD de fonctionnement). Ce type de parallélisme a été exploité a` travers les libraires commerciales et avec des programmes spécifiques con¸cus pour les extensions en question. Lors de ce dernier, le choix d’algorithmes et la conception des procédures correspondants ont été dirigés par le matériel sous-jacent. 3. Les meilleurs algorithmes et leur procédures correspondantes ont été évalué sur une machine bi-processeur, l’exemple type de parallélisme inter-processeurs des architectures universelles. La performance d’un ordinateur personnel tout a` fait standard a été établie pour chaque approche envisagé. Le Tableau 2.18 résume les performances obtenus : les temps de traitement pour une image de 1024*1024 pixels, le nombre de BOPs nécessaire pour le traitement d’un seul pixel et les débits correspondants : D0 pour l’architecture universelle standard et D1 pour l’architecture universelle parallèle.

~~Débit des pixels traités [Mpx/sec] Universelle standard Universelle parallèle 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ésultats montrent que les systèmes informatiques universels d’aujourd’hui, même ceux appartenant a` la classe des ordinateurs de bas de gamme (les ordinateurs personnels) présentent une importante puissance de calcul lorsqu’il s’agit de les utiliser pour le calcul de filtres non- linéaires. La condition étant bien entendu d’exploiter “manuellement” les différents niveaux de parallélisme existant.

~~Si l’on souhaite améliorer d’avantage la performance de tels traitements, l’implication d’un plus grand nombre d’unités de traitement apparaˆıt nécessaire.~~

~~90 Chapitre 3~~

~~Architectures d´edicac´ees~~

Dans le chapitre précédant nous avons établi la performance des architectures universelles utilisées pour le calcul des différents filtres non-linéaires employés dans le traitement des images numériques. Les ordinateurs de bureau, en tant qu’exemple le plus représentatif de ces architectures, ont été abordés a` l’aide de deux approches différentes : l’une purement algorithmique faisant abstraction du matériel sous-jacent et l’autre qui tient compte de l’architecture du processeur utilisé. Nous avons montré que la deuxième approche présente un important facteur d’accélération par rapport a` la première et c’est elle qui a été retenue en tant que performance significative de tels systèmes.

Dans ce chapitre nous allons examiner les différents algorithmes et systèmes dédicacés existants utilisés pour le calcul de filtres non-linéaires. Il est organisé autour de 3 sections, dont voici un bref aper¸cu :

Section 1 - Dans cette première section nous retrouvons une courte description des circuits FPGAs, l’élément clef utilisé pour la construction des systèmes dédicacés et des systèmes reconfigurables. Nous nous intéressons aux aspects matériels des circuits FPGA ainsi qu’aux logiciels utilisés pour l’implémentation des circuits logiques complexes. Un autre point abordé est lié a` la problématique de la qualité du processus d’implémentation automatisée, car son influence sur la performance finale du système est d’une importance capitale.

Section 2 - Nous enchaˆınerons par un aper¸cu des différents algorithmes et des systèmes dédicacés existants utilisés pour le calcul des filtres non-linéaires. La performance des différents algorithmes et architectures présentés est quantifiée a` l’aide des deux paramètres décrits dans le Chapitre 1 : le nombre de BOPs par pixel et le débit des pixels traités lorsque l’architecture proposée a été effectivement réalisée.

Section 3 - Enfin la dernière section propose un résumé des résultats, une discussion concernant les limites des algorithmes et des architectures décrits et pointe sur la difficulté de comparaison de ces résultats. La motivation et la raison d’être d’une autre approche pour l’implémentation des filtres non-linéaires, objet du Chapitre 4, apparaˆıtra déjà 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égrés qui permettent la réalisation de circuits logiques a` grand nombre de variables d’entrée et de sortie, selon la spécification de l’utilisateur et en utilisant un même support matériel. Dans la littérature anglo-saxonne on rencontre deux appellations différentes pour de tels circuits intégrés : le Programmable Logic Device - PLD et le Field Programmable Device - FPD. La différence entre ces deux appellations est liée a` la quantité et a` la complexité de la logique réalisable au sein de ces circuits, en général 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égulière (array) constituée d’un grand nombre de cellules logiques élémentaires programmables, d’un réseau dense d’interconnexions, lui aussi programmable et d’un certain nombre de bornes d’entrées et de sorties.

~~La disposition des différents éléments qui constituent un circuit FPGA est représentée de fa¸con schématique 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 élémentaire varie d’un concepteur et d’une famille de FPGA a` l’autre. Quelque soit le producteur ou la famille considérée, une cellule logique élémentaire est toujours composée de quelques mémoires de mots d’un bit, généralement de quelques bits d’adresse. Ces mémoires sont destinées a` la sauvegarde des différentes tables

92 3.1. Circuits FPGAs de vérité des fonctions logiques définies par le circuit a` réaliser. Chaque cellule logique est également dotée de bi-stables programmables1 permettant la réalisation des circuits synchrones.

Les cellules logiques élémentaires sont entourées d’un réseau dense d’interconnexions programmables. Ce réseau permet de réaliser des connexions spécifiques entre les différentes cellules logiques utilisées pour la réalisation d’un circuit particulier et de connecter ce circuit avec le monde extérieur via les bornes d’entrée/sortie.

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

En fonction de la technologie employée pour la fabrication des mémoires des cellules logiques élémentaires et de réseau d’interconnexions, il est possible de faire la distinction entre les FPGAs programmables et les FPGAs reprogrammables. Les premiers permettent de fixer définitivement la configuration du circuit, tandis que pour les derniers, le processus de programmation peut recommencer a` chaque nouvelle mise sous tension du circuit FPGA (ou lors d’un nouveau cycle de programmation). Nous nous intéressons ici uniquement aux FP- GAs reprogrammables car ils peuvent servir a` la conception et la réalisation des systèmes reconfigurables.

~~Une description plus détaillée de l’architecture d’une famille particulière des FPGAs reprogrammables, Virtex II de Xilinx, peut être trouvée dans l’Annexe B.~~

~~3.1.1.2 Ressources typiques des FPGAs actuels~~

La quantité des ressources logiques disponibles dans un circuit FPGA dépend du degré d’intégration et de la taille du support utilisé pour sa construction. Elle sera également in- fluencée par le choix concernant l’architecture de la cellule logique élémentaire : taille et le nombre des mémoires, leur agencement et le type d’interconnexions, présence ou non d’une quelconque logique et/ou de circuits arithmétiques dédicacés, etc... La quantité des ressources logiques disponibles est le plus souvent exprimée par le nombre de cellules élémentaires et/ou par le nombre équivalent de portes logiques, le paramètre déjà introduit dans le Chapitre 1.

En fonction de la quantité des ressources logiques disponibles, on distingue des circuits FPGA de faible, moyenne et haute densité. Actuellement les circuits FPGA de haute densité détiennent une importante puissance de calcul et peuvent être utilisés pour la réalisation de systèmes logiques combinatoires et/ou séquentiels complexes sur un grand nombre de variables d’entrée.

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

~~1Par un bi-stable programmable on sous-entend un élément mémoire qui peut être programmé de fa¸con a` reproduire le fonctionnement des bi-stables habituels : D, T, SR, JK.~~

93 Chapitre 3. Architectures dédicacées teurs de circuits logiques programmables : Xilinx, Actel et Altera. L’architecture d’une cellule logique élémentaire (CLE) varie fortement d’un producteur a` l’autre. Ainsi chez Xilinx une seule CLE possède 8 mémoires a` 4 bits d’adresse (16 mots d’un bit), huit bi-stables programmables et une logique dédicacée par mémoire pour des opérations arithmétiques. Chez Actel, une CLE est composée d’une mémoire a` 5 bits d’adresse (32 mots d’un bit) et d’un bi-stable programmable toutes les deux mémoires. Enfin une CLE de chez Altera est une mémoire a` 4 bits d’adresse (16 mots d’un bit), associée a` un bi-stable programmable et une logique dédicacée pour l’addition.

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

~~La dernière colonne du Tableau 3.1 indique le nombre maximal de bornes d’entrée/sortie pour des circuits FPGAs mentionnées.~~

~~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é des ressources logiques exprimée par le nombre de cellules logiques élémentaires (CLE) et le nombre de portes logiques équivalant (Np) en million de portes ; le nombre maximal de bornes d’entrées/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 étroitement liée au développement de la technologie de fabrication des circuits intégrés permettant la fabrication d’unités de plus en plus denses. Mais cette expansion n’aurait jamais pu avoir une telle ampleur sans le développement, en parallèle, d’outils performants permettant de faciliter le processus de conception des circuits logiques avec de la logique programmable. Ces outils assurent d’une part la description aisée des circuits logiques complexes et d’autre part la réalisation automatique de circuit a` partir de ces descriptions.

La réalisation d’un circuit logique, en fait le passage de sa description a` l’information nécessaire pour la réalisation d’une implémentation physique du circuit dans un FPGA (i.e la configuration), est dans la littérature anglo-saxonne appelé design flow. Ce processus est habituellement décomposé en plusieurs étapes distinctes, représentées schématiquement a` la Figure 3.2. Actuellement, grâce aux outils informatisés, certaines étapes de ce processus peuvent être réalisées de fa¸con entièrement automatique (notamment la synthèse, l’implémentation ainsi que la génération de la configuration pour le FPGA cible).

~~Analyse Simulation fonctionnelle~~

~~Description de Synthèse Implémentation Configuration FPGA circuit~~

~~Fig. 3.2: Différentes étapes du processus Design Flow depuis la description d’un circuit logique a` la configuration d’un circuit FPGA.~~

Description La première étape du design flow comprend la description formelle du circuit a` partir des spécifications. Aujourd’hui la description des circuits logiques est faite la plupart de temps a` l’aide des langages de description de matériel (dans la littérature 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ériel afin d’obtenir la meilleure performance possible de son circuit, la description est faite de fa¸con schématique3. Il existe d’autres formalismes permettant de décrire un circuit logique, souvent proposés par un producteur de

3Ici on pourrait faire une analogie entre les langages de programmation orienté objet et les langages HDL et entre la description schématique et le langage assembleur. Si les deux premiers permettent une description aisée de problèmes volumineux et complexes, ils le font parfois au détriment de la performance. Dans le Chapitre 2, nous avons pu montrer qu’une approche qui tient compte du matériel et utilise l’assembleur permet d’obtenir d’importants facteurs d’accélération par rapport a` une approche purement algorithmique, dans laquelle le langage de programmation hautement évolué permet de faire abstraction complète du matériel.

~~95 Chapitre 3. Architectures d´edicac´ees~~

FPGA particulier, comme par exemple l’éditeur graphique des machines a` états finis chez Xilinx. La description d’un circuit peut être faite exclusivement a` l’aide d’un formalisme bien particulier, ou combiner des formalismes différents. Les différentes parties d’un même circuit logique complexe peuvent donc être décrites de fa¸con différente avant d’être traduites en une configuration particulière pour un (ou plusieurs) FPGA cible.

Synthèse Lors de l’étape de la synthèse, les différentes descriptions établies lors de la première étape sont ramenées a` une description du circuit unique, optimisée pour une performance maximale ou une occupation minimale des ressources. Après l’étape de la synthèse il est possible d’effectuer une analyse fonctionnelle du circuit (vérification de la description a` travers la simulation) et de se rendre compte d’éventuelles erreurs, avant de passer a` l’étape de l’implémentation, généralement considérée comme lente4. L’analyse fonctionnelle n’est qu’une vérification partielle car elle ne peut tenir compte des délais introduits par le circuit réel, celui-ci n’étant pas encore réalisé. Lors d’une analyse fonctionnelle tous les délais du circuit obtenu après la

4Afin de s’assurer que la traduction des spécifications en description formelle est correcte, il faut passer par une étape de vérification. La vérification de la description peut être faite a` travers : la simulation - on ne peut pas garantir qu’elle soit correcte ; la vérification formelle - on dispose d’une preuve rigoureuse que la description répondra toujours aux spécifications. Bien entendu une description formelle des spécifications correcte ne peut encore garantir une réalisation matérielle qui lui serait entièrement équivalente. On peut supposer que dans le processus de matérialisation d’une description correcte il existe des choses indécidables, c’est pour quoi il est impossible de garantir la fiabilité absolue d’un système physique. Pour la vérification formelle des descriptions des systèmes combinatoires on dispose des techniques et des outils permettant de facilement traiter même des systèmes a` un grand nombre de variables [McF93]. Il n’en est pas de même pour des systèmes qui intègrent la notion de l’état, principalement a` cause de très grand nombre de séquences d’entrées possibles. Dans ce cas, lorsque il s’agit de vérifier formellement des programmes informatiques ou des systèmes séquentiels par exemple, d’autres méthodes doivent être employées. Ainsi pour vérifier formellement un programme (on dit encore établir la correction d’un programme) on peut utiliser la première méthode proposée historiquement, mais toujours d’actualité, celle des assertions introduite par Floyd et Hoare (voir [Flo67, Hoa69]). On considère un triplet (appelé aussi le triplet de Hoare) noté {P }S{Q} ou S désigne le programme considéré et {P } et {Q} désignent respectivement les assertions (ou énoncés sur l’état du programme) avant l’exécution de S (pré-condition) et après son exécution (post-condition). Vérifier la correction d’un programme consiste donc a` prouver que pour tout état initial qui satisfait la pré- condition {P }, l’application de S amènera le programme dans un nouvel état qui satisfait la post-condition {Q}. Comme il est impossible de prévoir si S termine (Halting Problem de Turing), on parle plutôt de la possibilité de prouver une correction partielle d’un programme (dans l’énoncé ”l’application de S” est alors remplacé par ”lorsque S termine”). Si une telle méthode permet de formellement prouver la correction (partielle !) d’un programme, elle est rarement utilisée en pratique principalement par la lourdeur de sa mise en oeuvre même pour des programmes simples. Signalons toutefois l’existence des outils permettent son automatisation (voir [BM85, Fra97]) en utilisant un générateur automatique des assertions et un démonstrateur de théorèmes. De tels outils sont généralement utilisés pour la validation de programmes sensibles qui exigent une grande robustesse (nucléaire, aviation, médical etc.). En ce qui concerne la vérification formelle des systèmes séquentiels on peut utiliser les réseaux de Petri. En effet, en montrant que le réseau de Petri correspondant possède des bonnes propriétés pour un marquage initial donné (M0), c’est a` dire qu’il est : – vivant - chaque transition du réseau reste franchissable – sauf - que le réseau est K-borné avec K=1 ; une place de réseau ne peut contenir plus qu’un jeton, – réinitialisable - si pour un marquage accessible M depuis le marquage initial M0 il existe une séquence de franchissement telle qui permet d’arriver au M0 on peut être surˆ que dans le système modélisé par ce réseau de Petri il n’y aura ni de blocage, ni des incohérences pour toute séquence de franchissement envisagée. Même si ce processus dans certains cas peut être automatisé, il ne peut pas être utilisé pour des circuits actuels complexes. Dans ce cas on fait appel a` d’autres méthodes. Dans [McF93, CW96] on peut trouver un recueil des différentes méthodes actuelles de vérification formelle.

~~96 3.1. Circuits FPGAs synthèse sont considérés comme nuls5.~~

Implémentation L’étape de l’implémentation est généralement divisée en trois sous-étapes distincts : le mapping, le placement et le routage. Le mapping consiste a` “traduire” le circuit logique obtenu par le processus de synthèse en mémoires des cellules logiques élémentaires d’un circuit FPGA particulier. Lors de la sous-étape de placement, une cellule logique existante, avec sa position unique au sein du FPGA cible, est attribuée a` chaque cellule logique nécessaire pour la réalisation du circuit. Ceci est bien entendu fait sous la contrainte des longueurs minimales des connexions entre les différentes cellules. Enfin la dernière sous-étape, le routage, consiste a` établir les différentes connexions physiques entre les cellules élémentaires placées. Lorsque l’étape de l’implémentation est achevée, il est possible de réaliser une simulation réaliste de fonctionnement du circuit, car a` ce stade on dispose de l’information précise sur les délais réels qui seront introduits par le circuit physique (vérification de l’implémentation).

Configuration Le processus de design flow se termine par la génération du fichier de configuration correspondant au circuit réalisé. Ce fichier peut être directement transféré dans le circuit FPGA cible depuis la plate-forme du développement ou depuis une mémoire programmable dans le cas d’une solution embarquée. Le circuit con¸cu devient alors opérationnel.

~~3.1.2.2 Perspectives de la description des circuits~~

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

Au cours de ces dernières années nous assistons a` un rapprochement entre les langages de programmation propres a` l’informatique, tels que C/C++ et même JAVA, et les langages de description de matériel. Une telle tendance se justifie par le fait que la densité des circuits FPGAs devient tellement importante qu’il est désormais possible de concevoir des systèmes très complexes, même au sein d’un seul circuit intégré. La gestion de la description d’un tel système peut s’avérer difficile, même si on utilise des langages de description de matériel tels que VHDL ou Verilog.

Selon une étude récente (voir [HT03]) les trois exemples peut-être les plus représentatifs des langages “hybrides”, c’est a` dire les langages qui tentent de combiner les formalismes soft et le hard sont : – HardwareC - développé a` l’Université de Stanford [Kup95, Mic99] – SA-C - développé a` l’Université de Colorado [DBH+00].

5Pour un circuit réel, en fait le circuit logique physiquement réalisé dans un FPGA, on peut déduire les délais de propagation des signaux a` travers le réseau d’interconnexion, les temps d’accès aux mémoires des cellules élémentaires, etc...

~~97 Chapitre 3. Architectures d´edicac´ees~~

– SpecC - développé a` l’Université de Californie [CG02] Les trois langages d’une syntaxe proche de C proposent des extensions nécessaires pour la description du matériel. Il s’agit des notions de calcul concurrent et de délais, ainsi que de la possibilité de spécification de contraintes sur les délais et l’espace utilisé pour le circuit final. Il est évidant que la principale difficulté rencontrée dans l’élaboration de tels langages réside dans la conception de compilateurs suffisamment performants en termes de qualité 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émentation, les langages de programmation traditionnels tel que C++ sont couramment utilisés pour l’élaboration de modèles de circuits et de systèmes complexes. Ces modèles visent a` reproduire le plus fidèlement possible le fonctionnement réel d’un système physique. L’exemple type d’un tel outil de modélisation est le SystemC (voir [GR00, Swa01, Ger00]). Il s’agit de l’ensemble des librairies écrites a` l’aide d’un langage de programmation typiquement logiciel, le C++. Grâce a` ces librairies il est possible d’écrire un programme, en fait le modèle d’un système très complexe, indépendamment de la technologie cible utilisée pour la réalisation matérielle (FPGAs, ASIC,...). Après la construction du modèle, il est possible d’effectuer une simulation, a` l’aide d’un simple ordinateur personnel et de tester le modèle dans son ensemble. Mis a` part la possibilité de simulation, l’utilisateur peut produire un cahier des charges très précis du système final, permettant de passer aisément du modèle a` la réalisation finale. Le SystemC apparaˆıt donc comme un outil puissant, mais limité lorsqu’il s’agit d’automatiser le processus de réalisation de circuit car le passage du cahier des charges a` l’information nécessaire a` l’implémentation doit se faire manuellement.

Les tendances actuelles de la recherche visent donc a` établir un langage unifié qui serait utilisé aussi bien pour la description des programmes informatiques que pour la description de matériel. Le choix entre la réalisation d’un fichier de configuration pour un circuit FPGA ou d’un programme exécutable a` partir d’une même description faite en langage de haut niveau d’abstraction, pourrait se faire sans aucune intervention sur la description formelle du problème et de fa¸con tout a` fait automatique. Nous n’émettrons pas de doute quant a` la faisabilité de tels langages et compilateurs associés, mais nous attirons l’attention sur la qualité des résultats 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ès peu le parallélisme d’un processeur de grande série 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é des outils actuels d’implémentation~~

Nous avons précisé que les outils de synthèse et d’implémentation peuvent de fa¸con entièrement automatique, assurer le passage d’un ensemble de descriptions différentes a` l’information nécessaire pour la réalisation d’un circuit dans un FPGA.

~~98 3.1. Circuits FPGAs~~

~~Cependant les questions relatives a` l’efficacité d’un processus d’implémentation entièrement automatisé sont toujours d’actualité. Ainsi on peut s’interroger :~~

– Dans quelle mesure les outils automatiques d’aujourd’hui produisent de bons résultats en termes de la quantité des ressources logiques mobilisées et de vitesse de circuit obtenue pour une description de circuit donnée ?

~~– 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éponse positive a` la question précédente, qu’elle est l’ordre de grandeur de l’amélioration que cette intervention peut apporter ?~~

Aujourd’hui on ne dispose pas de réponse définitive a` ces questions. Les communautés scienti- fiques et industrielles actives dans le domaine de la logique programmable sont plutôt divisées.

La réponse de certains est assez catégorique : les implémentations automatiques ne pourront jamais remplacer l’intervention d’un opérateur humain [AFSS00, TT01]. D’autres, de fa¸con plus modérée, suggèrent que les résultats obtenus a` l’aide des outils automatisés sont en général “satisfaisants” [VSS99].

Afin de se passer des jugements subjectifs et de donner une réponse claire a` ce genre de questions, Singh propose une étude comparative (voir [Sin00]) sur l’efficacité de l’implémentation automatique et “manuelle” (en fait l’implémentation automatique assistée par un opérateur 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 multiplicateurs a` coefficient constant, les filtres systoliques etc... Ces circuits ont été réalisés d’une part a` l’aide d’un processus d’implémentation entièrement automatisé et d’autre part avec l’intervention d’un expert dans le domaine de l’implémentation optimale des circuits logiques dans les FPGAs. Son intervention dans le processus d’implémentation se situe au niveau de placement d’une part et au niveau de spécification des contraintes explicites des délais de propagation.

Pour la plupart d’applications les résultats obtenus montrent un gain en vitesse de fonctionnement de circuit variable entre 30 % et 50 % en faveur des implémentations assistées par l’opérateur humain. Curieusement, l’implémentation manuelle d’un filtre systolique n’a pas abouti a` des améliorations semblables malgré une structure régulière qui, a priori, pourrait faire croire a` la supériorité d’un homme devant la machine, pour ce qui est, au moins, de la remarquer.

L’origine de ces améliorations réside dans le fait que l’opérateur humain fait intervenir dans le processus d’implémentation 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é de la solution et le temps consommé pour la trouver, le programme de placement et de routage mettra plus de temps de recherche d’une solution (dans l’étude proposée par Singh dans [Sin00] jusqu’à trois fois plus que dans un processus automatique).

~~99 Chapitre 3. Architectures d´edicac´ees~~

Dès 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érateur humain d’intervenir dans le processus de l’implémentation physique du circuit. Néanmoins cela reste toujours possible. 2. Les outils de synthèse et d’implémentation ne sont pas parfaits et la performance de circuit obtenue peut, dans certains cas, être sensiblement améliorée en assistant le processus d’implémentation.

~~3.1.3 Applications des FPGAs~~

L’augmentation de la densité des circuits FPGAs, combinée avec le développement de langages évolués de description de matériel et des outils permettant de passer de fa¸con automatique de la description a` la réalisation matérielle, a ouvert la voie a` l’application des FPGAs dans l’accélération du temps de traitement d’un grand nombre d’applications. Les domaines abordés sont très variés et touchent la cryptographie, le traitement des images numériques, la 3D,... la liste annoncée des applications est loin d’être exhaustive.

Dans ce qui va suivre nous nous intéresserons uniquement aux algorithmes et architectures FPGAs associés aux problèmes de traitement des images numériques et plus particulièrement a` ceux destinés au calcul des filtres non-linéaires.

~~100 3.2. Parallélisation du calcul des filtres non-linéaires~~

~~3.2 Parallélisation du calcul des filtres non-linéaires~~

Le calcul des filtres non-linéaires implique le tri, l’un des problèmes les plus récurrents de l’informatique appliquée. Dans le but d’accélérer ce type de traitement, un grand nombre d’algorithmes ont été proposés en vue de réaliser des programmes destinés a` l’exécution sur des architectures universelles parallèles. Malheureusement, le coutˆ et la taille de ces systèmes les rendent inutilisables pour des applications de tous les jours. C’est pour cette raison que nous nous intéresserons uniquement aux architectures dédicacées qui, dans certains cas précis peuvent rivaliser de performance avec les architectures universelles parallèles, tout en affichant un coutˆ nettement moins élevé6.

Au cours des dernières années de nombreux algorithmes et architectures associées ont été proposés pour des applications liées au domaine de traitement des images numériques. Dans cette section nous tenterons de donner un aper¸cu aussi complet que possible des différents algorithmes et de systèmes existants, utilisés pour le calcul des filtres non-linéaires.

Avant de donner des explications plus détaillées, nous proposons plusieurs classifications des solutions existantes concernant les algorithmes et les architectures associées déjà réalisées aujourd’hui. Ceci nous permettra de cerner la problématique de l’implémentation des filtres non-linéaires dans les systèmes dédicacés de fa¸con plus systématique et complète.

~~3.2.1 Classiﬁcation des algorithmes et des architectures existants~~

Une première classification des différents algorithmes et des architectures existantes pour le calcul des filtres non-linéaires peut être faite sur base du nombre d’opérandes et du nombre de bits calculés simultanément par l’unité de traitement. Si on se base sur un tel critère, il est alors possible de faire la distinction entre deux modes de fonctionnement suivants : – le mode bit-parallèle et – le mode bit-série.

~~Remarquons que ce critère de classification n’est pas uniquement applicable aux algorithmes et architectures destinés au traitement des images, son caractère est beaucoup plus général.~~

Une unité de traitement est habituellement construite autour d’une unité arithmétique/logique permettant de calculer des fonctions (les opérations) sur deux arguments (les opérandes) : 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 être effectué a` l’aide d’une seule unité de traitement a` deux opérandes en décomposant 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èles et les systèmes reconfigurables peut être trouvée dans [Vui94]. D’un coutˆ moindre, les systèmes reconfigurables montrent une meilleure performance que les architectures parallèles universelles.

~~101 Chapitre 3. Architectures d´edicac´ees~~

Une telle unité de traitement calcule donc la fonction f de n arguments de fa¸con séquentielle, en n 1 étapes. Malgré le caractère séquentiel du calcul, l’unité de traitement présente un − certain parallélisme, situé au niveau des bits qui codent le résultat de l’opération et les arguments. En effet, l’Equation´ 3.2 fait abstraction complète 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édiaires, mais qui fait l’abstraction du codage binaire des arguments, sera alors considérée comme bit-parallèle.

Par opposition au calcul bit-parallèle, le calcul effectué en mode bit-série remplace le pa- rallélisme des deux arguments au niveau de leur codage par le parallélisme situé au niveau du nombre d’arguments. Dans ce cas, l’unité de traitement opère sur un nombre d’opérandes égal au nombre d’arguments, chaque opérande étant constituée 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écessaires pour évaluer f(→−x ) ne dépend plus du nombre d’opérandes mais bien du nombre de bits utilisés pour coder les arguments. Bien entendu une telle unité de traitement manque d’universalité puisqu’elle doit être adaptée pour chaque type de calcul et en fonction du nombre d’opérandes requises.

Mis a` part cette classification, très générale mais très importante quant a` la parallélisation des problèmes en traitement des images, on peut citer celle de Charot, proposée dans [Cha93b]. Cette classification, destinée aux systèmes parallèles en traitement des images, combine les taxinomies des architectures universelles déjà présentées au Chapitre 1 : les systèmes MIMD, SIMD, pipeline, la topologie des interconnexions des unités de traitement : linéaire, matricielle, tore, . . . et le mode de fonctionnement pour l’unité de traitement même : les modes bit-série et bit-parallèle. Malheureusement son caractère trop général ne permet pas de définir toutes les architectures dédicacées qui ont été proposées depuis pour le calcul des filtres non-linéaires.

~~Une classification, consacrée uniquement aux architectures dédicacées destinées au calcul des filtres non-linéaires, est proposée par Chakrabarti et Lucke dans [CL98].~~

~~102 3.2. Parallélisation du calcul des filtres non-linéaires~~

Cette classification distingue trois architectures possibles : – Les architectures matricielles (Array architectures) – Les réseaux de tri (Sorting Network Architectures) – Les architectures dédiées aux filtres de piles

Architectures matricelles Dans le cas d’une architecture matricielle, la valeur de rang est calculée pour chaque pixel de voisinage Vi en cours de traitement. Lors du déplacement de la fenêtre, les rangs des pixels déjà calculés mais présents dans le voisinage suivant Vi+1, sont mis a` jour. Les rangs des nouveaux pixels définis par Vi+1 sont ensuite calculés : le voisinage complètement trié est obtenu avec peu d’opérations supplémentaires. La valeur filtrée est obtenue en identifiant le pixel de rang voulu.

Les architectures matricielles sont construites autour d’unités de traitement qui fonctionnent en mode bit-série ou en mode bit parallèle. Souvent, lorsque cela est possible, ces architectures intègrent le fonctionnement en pipe-line afin d’augmenter le débit des pixels traités.

Réseaux de tri Dans une architecture de type réseau de tri, les unités de traitement manipulent les valeurs de niveaux de gris des pixels du voisinage V plutôt que les valeurs de rang. A l’aide d’un ensemble de comparateurs chaque voisinage est trié individuellement, ou mis a` jour lors de l’avancement de le fenêtre. En sortie nous disposons d’un vecteur V˜ complètement trié. Dans le cas d’une recherche de rang particulier on peut se contenter d’un tri partiel dans un souci d’économie des ressources utilisées. Le résultat du filtrage est obtenu par l’indexation du vecteur a` la sortie.

Si l’implémentation des réseaux de tri implique a priori des architectures bit-parallèles, certains algorithmes en mode bit-série les utilisent pour les calculs intermédiaires, comme nous le verrons par la suite. Comme pour les architectures matricielles, les réseaux de tri intègrent le fonctionnement en mode pipe-line pour un plus grand débit des pixels traités.

Architectures dédiées aux filtres de piles Dans le Chapitre 1 une classe particulière de filtres non-linéaires a été décrite, les filtres de piles. Nous avons vu comment ces filtres peuvent être utilisés pour le calcul des filtres de rang classiques : Min, médian, Max. Du fait du codage particulier des valeurs des pixels, ces filtres se prêtent bien a` une implémentation dans les systèmes dédicacés parallèles. Dans ces architectures les unités de traitement sont forcément de type bit-série, mais il s’agit bien d’une architecture a` part entière du fait du codage particulier des arguments.

Pour donner un aper¸cu des différents systèmes de calcul des filtres non-linéaires nous retien- drons cette dernière classification en faisant la distinction entre deux modes de fonctionnement pour l’unité de traitement : le mode bit-série et le mode bit-parallèle. Egalemen´ t nous ne li- miterons pas l’appellation d’architecture matricielle uniquement aux celles basées sur des algorithmes manipulant les valeurs de rang. Par architecture matricielle nous allons entendre toute architecture de topologie mesh utilisée 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érie sont généralement dotées d’unités de traitement simples, permettant d’arriver a` un parallélisme massif, même avec un seul circuit intégré. Plusieurs systèmes basés sur ce type d’architecture particulière ont été con¸cus spécifiquement pour les problèmes de traitement des images. Nous en citerons ici les exemples les plus représentatifs : – 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é par NCR dans les années ’80, est une matrice de 6 12 unités de traitement qui fonctionnent selon le modèle SIMD de calcul. Chaque unité de × traitement est dotée de quatre registres d’un bit, d’une unité de calcul permettant d’effectuer des opérations logiques sur trois des quatre registres internes et d’une mémoire de 128 bits. Les instructions du GAPP sont de type LIW (Long Instruction Word) et permettent une exploitation directe du parallélisme des instructions propre a` son architecture. Les unités de traitement peuvent communiquer dans deux directions principales : nord-sud et ouest-est et ainsi effectuer des échanges de données. Les unités de traitement au bord du circuit peuvent être connectées soit entre elles, de fa¸con a` constituer un tore et permettre un échange de données cyclique au sein des unités de traitement d’un même circuit, soit avec d’autres circuits permettant la réalisation de systèmes massivement parallèles. Récemment, une nouvelle version du GAPP, mise a` jour au niveau de la technologie de fabrication, a été mise en service dans le domaine de la compression et de la transmission de la vidéo numérique (voir [Ack02]).

Le processeur GAPP peut être utilisé pour l’exécution des différents algorithmes qui se prêtent a` une parallélisation de type SIMD. Dans le domaine du traitement des images, son architecture est parfaitement adaptée au calcul sur des images binaires avec des voisinages de petite taille. Dans ce cas, la surcharge en communication entre les unités de traitement est faible, car le voisinage ne concerne que les huit voisins directs du pixel considéré. Il en résulte donc un bon équilibre entre le temps passé pour l’échange de données et le calcul proprement dit.

Pour des voisinages plus grands, des traitements sur des images en niveau de gris plutôt 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ès important. Dans ce cas l’équilibre entre l’échange des données et le calcul est rompu : le système passe plus de temps a` obtenir les données qu’à calculer. Pour illustrer ce propos, on peut comparer le nombre d’opérations nécessaires au calcul des opérateurs morphologiques classiques sur des images binaires, avec celui d’un filtre de rang sur des images en niveau de gris. Pour calculer un opérateur morphologique sur une image binaire dans un voisinage 3 3 il faut compter une dizaine d’opérations, alors que le calcul × 104 3.2. Parallélisation du calcul des filtres non-linéaires de la valeur médiane d’un même voisinage pour des pixels codés sur 8 bits nécessite plusieurs milliers d’opérations (source : [HSB84]).

PAPIA-2 La surcharge en communications peut être réduite en utilisant une meilleure connectivité entre les unités de traitement. Le système PAPIA-2 permet, grâce aux connexions directes de chaque unité de traitement avec ses huit voisins, de réduire considérablement le nombre d’opérations a` effectuer dans le cas de calcul sur des images en niveau de gris. Pour des pixels codés 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écessite néanmoins 745 opérations (source : [BCCM91]).

MGAP Le filtre médian peut être calculé avec un même nombre d’instructions a` l’aide de système MGAP (Micro Grained Array Processor). D’une architecture très proche de celle du GAPP, le système MGAP calcule le filtre médian d’un voisinage 3 3 pixels codés sur 8 bits en 675 × opérations (source : [BOI93b]).

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

~~3.2.2.2 Mode bit-parall`ele~~

Les unités de traitement fonctionnant en mode bit-parallèle requièrent une plus grande quantité de ressources logiques lors de leur implémentation que celles fonctionnant en mode bit-série. Ceci est principalement duˆ a` la complexité de l’unité de traitement et a` la taille des mémoires utilisées pour la sauvegarde des opérandes. Etan´ t donné une même technologie de fabrication et une même surface du circuit intégré, ceci conduira inexorablement vers un plus faible parallélisme des architectures fonctionnant en mode bit-parallèle. Cependant ces architectures présentent un avantage majeur : le nombre de pas de calcul, a priori plus faible que dans le cas des architectures matricielles. Parfois les unités de traitement fonctionnent en mode pipe-line, permettant ainsi d’augmenter le débit de pixels traités.

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

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

~~105 Chapitre 3. Architectures d´edicac´ees~~

~~nombre T de cycles d’exécution par pixel de l’image résultante, avec 0 T √NV , alors la ≤ ≤ surface occupée par unité de traitement diminue de ce même facteur T .~~

~~3.2.3 R´eseaux de tri~~

En 1968 Batcher introduit la notion des réseaux de comparateurs et des réseaux de tri pouvant être utilisés pour une implémentation parallèle du problème du tri a` l’aide de la logique programmable (voir [Bat68]). Nous exposerons ici brièvement le principe de fonctionnement des différents algorithmes. Pour une définition plus formelle de ces réseaux on peut se rapporter a` [Knu73].

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

Habituellement on représente un réseau de tri sous la forme d’un graphique composé de lignes horizontales parallèles. A chaque ligne de ce graphique est associée un élément particulier du vecteur a` trier. Sur ces lignes on dispose des nœuds qui effectuent les opérations de comparaison et de permutation. Les nœuds seront représentés par une flèche orientée dans le sens du chemin emprunté par le plus grand élément 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ême ligne verticale, les opérations de comparaison et de permutation peuvent être exécutées en parallèle. Le nombre de lignes verticales indique donc le nombre d’étapes de calcul a` effectuer, tandis que le nombre de flèches orientées indique le nombre de comparateurs a` mettre en œuvre.

~~Un réseau de tri est un réseau de comparateurs permettant de trier complètement un vecteur a` son entrée.~~

~~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éseau NV 1 nœuds sont utilisés pour trouver le maximum − du vecteur V qui est mis a` la place du dernier élément. La procédure est ensuite appliquée récursivement pour les éléments encore non-classés. Un tel réseau est composé de NV (NV 1)/2 nœuds qui trient complètement V ∗ − en 2NV 3 étapes, en tenant compte de la possibilité d’une exécution simultanée de − certaines opérations.

~~106 3.2. Parallélisation du calcul des filtres non-linéaires~~

~~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ême nombre de nœuds peut être utilisé pour la construction d’un réseau qui permet de trier complètement le vecteur a` l’entrée, en seulement NV étapes de calcul. Dans un tel réseau les nœuds effectuent les opérations de comparaison et de permutation entre les éléments d’index pair est les éléments d’index impair pour une étape impaire et inversement pour une étape 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éseau particulier se déroule en deux phases : dans un premier temps, le vecteur a` l’entrée, composé de 2p éléments, est trié de fa¸con a` ce qu’il constitue une suite bitonique7. La suite croissante et la suite décroissante de la suite bitonique obtenue sont ensuite fusionnées de fa¸con a` produire une suite p 2 2 1 2 complètement triée. Le nombre de nœuds nécessaires est 2 − (p + p) pour 2 (p + p) étapes 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 éléments a0, a1, . . . , an, est dite bitonique si ∃i, 0 ≤ i ≤ n tel que si la suite a0, a1, . . . , ai est croissante (ou décroissante) alors la suite ai+1, ai+2, . . . , an est décroissante (croissante).

~~107 Chapitre 3. Architectures d´edicac´ees~~

Les différents réseaux de tri ont été adaptés pour le calcul de filtre médian : Bubble dans [Ofl83, KOA90], Odd-even dans [Cha93a] et le bitonique dans [CS92]. Dans le cas particulier des voisinages habituellement utilisés (les voisinages de 9, 25 et 49 pixels), le réseau bitonique peut être optimisé quant au nombre de comparateurs utilisés, 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’étapes nécessaires au calcul d’un filtre médian, pour des voisinages considérés avec un réseau de tri de type odd-even et avec le réseau 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’étapes de calcul pour la réalisation des réseaux de tri odd-even et bitonique de Chung.~~

La réalisation d’un réseau de tri quelconque implique donc nécessairement l’emploi d’un grand nombre de circuits comparateurs, même dans le cas des algorithmes très optimisés. Néanmoins, l’implémentation de ces circuits particuliers dans des FPGAs pourrait être justifiée par le fait que ces circuits possèdent actuellement une logique dédicacée pour la réalisation des additionneurs/soustracteurs rapides. Ces ressources supplémentaires peuvent être facilement exploitées pour la construction de comparateurs très performants [ELS00].

Ainsi, un comparateur de deux mots de 8 bits a` l’entrée et 1 bit a` la sortie (1 si a > b et 0 dans le cas contraire) nécessitera 13 cellules élémentaires lors d’une implémentation efficace8 sur la famille Virtex II des FPGA Xilinx. Il faut cependant noter qu’une telle performance ne peut être obtenue en suivant le flot de conception automatique. Afin d’arriver a` de tels résultats, une méthodologie spécifique utilisée pour la description de circuit est a` suivre, comme par exemple celle donnée dans par Fulton dans [Ful99].

Pour des voisinages de petite taille, étant donné le faible nombre des noeuds, la quantité des ressources logiques nécessaires pour la réalisation d’un seul noeud et la densité des circuits FPGAs actuels (comme par exemple celle de la famille Virtex II, cf. Tableau B.1 de l’Annexe B), l’implémentation des filtres de rang sur base d’algorithmes de réseaux de tri peut donc constituer une solution valable au problème.

L’implémentation d’un réseau de comparateurs permettant de trouver la valeur médiane d’un voisinage 3 3 dans un FPGA a été proposée par Smith (voir [Smi96]). Pour cette × implémentation, un réseau de tri particulier a été utilisé, basé sur l’élimination successive des minima et des maxima locaux, comme le montre la Figure 3.7. Un tel réseau permet de réduire le nombre de nœuds nécessaires, en sacrifiant le tri complet de V .

~~8Une implémentation efficace signifie que le logiciel de synthèse et d’implémentation a effectivement exploité les ressources logiques additionnelles disponibles.~~

~~108 3.2. Parallélisation du calcul des filtres non-linéaires~~

~~V[0] V[1] V[2] V[3] V[4] V[5] med V[6] V[7] V[8] Fig. 3.7: Réseau de tri utilisé pour l’implémentation de filtre médian sur un voisinage de 3 3 pixels dans le FPGA 4000E. ×~~

Ce réseau peut être adapté au fonctionnement en mode pipe-line avec un avantage double. D’une part nous avons une réduction de la quantité des ressources logiques nécessaires : le nombre de comparateurs requis passe de 19 a` 13 ; et d’autre part nous avons une augmentation du débit des pixels traités.

Une unité de traitement qui calcule la valeur médiane de 9 pixels codés sur 8 bits nécessite 85 cellules logiques élémentaires lorsqu’elle est réalisée dans un FPGA Xilinx, de la famille 4000E9. Malheureusement aucune information sur la fréquence de fonctionnement de l’unité de traitement proposée n’est communiquée.

~~3.2.4 Architectures bit-s´erie~~

~~3.2.4.1 Algorithme pour le ﬁltre de rang~~

L’algorithme le plus connu permettant de trouver la valeur correspondante a` un certain rang dans un vecteur en mode bit-série est certainement celui décrit par Danielsson dans [Dan81]. Contrairement aux différents algorithmes proposés précédemment, qui se basent sur la recherche de la valeur correspondante au rang r par comparaisons, celle-ci est calculée en fonction des valeurs des différents plans de bits.

Considérons 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é 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é n0, ou des 1 (n1), dans le voisinage Vi en cours de traitement. Ce nombre est ensuite comparé avec la valeur de rang r recherché.

Dans la première itération 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érentes peuvent apparaˆıtre.

~~9Une cellule logique élémentaire pour ce FPGA compte 2 mémoires de 16 et une mémoire de 8 bits.~~

~~109 Chapitre 3. Architectures d´edicac´ees~~

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

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

Dans l’itération suivante on cherchera le nombre de voisins ayant pour les deux bits de poids plus fort la combinaison 01, noté n01. Ce nombre est ensuite soustrait de n0 et le résultat est de nouveau comparé avec la valeur du rang r. Les plans de bits des poids plus faible sont traités de fa¸con similaire. A chaque itération 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ésultat pour ce poids.

~~La Figure 3.8 montre la succession de comptage des 0 (des 1) et des comparaisons a` eﬀectuer 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é pour le calcul de la valeur correspondante a` un rang r en mode bit-série pour des mots codés 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élisation du calcul des filtres non-linéaires~~

Le tableau de la Figure 3.9 indique les valeurs du vecteur envisagé et les trois étapes de calcul marquées ①, ② et ③ pour chacun des trois plans de bits permettant d’arriver a` la valeur filtrée I˜ = 001, exprimée 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é peut être facilement adapté pour le calcul d’un filtre de rang des mots codés sur un plus grand nombre de bits.~~

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

~~3.2.4.2 Cas particulier de ﬁltre m´edian~~

Dans le cas particulier d’un filtre médian, la comparaison du nombre d’occurrences de 0 ou des 1 d’un plan des bits avec le rang r peut être réduit au calcul de la fonction majorité, comme le montrent Hiasat et al. dans [HAIG99]. Il est ainsi possible de bénéficier, pour cette étape de calcul, d’une importante économie de ressources logiques nécessaires.

La Figure 3.10 illustre le déroulement de l’algorithme de Danielsson utilisé pour le calcul de la valeur médiane d’un vecteur V de 5 éléments codés sur 4 bits en utilisant la fonction majorité. Les colonnes t0 a` t3 montrent les différentes étapes 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 être prises en compte lors

111 Chapitre 3. Architectures dédicacées de l’itération suivante par la valeur minimale (0) ou maximale (2b) des niveaux de gris10. Les pixels exclus dans l’itération suivante sont marqués 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édiane de 5 éléments codés sur 4 bits a` l’aide de l’algorithme de Danielsson.~~

Dans la première itération, la fonction majorité 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ésultat. 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érations suivantes. Pour le plan de bits de poids suivant (colonne t1) la fonction majorité 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ême procédé pour l’avant dernier et le dernier plan de bits on obtient la valeur médiane de vecteur V .

Lorsque l’on envisage la réalisation matérielle d’une unité de traitement exécutant cet algorithme, le point sensible de l’implémentation se situe au niveau du calcul de la fonction majorité. Pour des voisinages envisagés 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é le nombre de variables impliquées, l’implémentation d’un grand nombre de ces fonctions dans les FPGAs actuels peut encore s’avérer limitatif.

Lee et al. proposent un algorithme de calcul de la fonction majorité permettant une implémentation plus économique quant a` la quantité des ressources logiques nécessaires pour sa réalisation (voir [LLC03]). L’algorithme exposé, basé sur le calcul des valeurs des maximas, médianes et minimas locaux des vecteurs colonnes est destiné exclusivement aux voisinages 3 3. × On considère un plan de bits d’un voisinage V de taille 3 3 noté : × 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ère un voisinage V composé 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ême nombre de pixels ayant le niveau de gris 0 et 2b, la valeur médiane de V sera forcément ce dernier pixel. Pour chaque plan de bits nous avons donc un même nombre de 0 et de 1, plus un bit donné par ce dernier mot. La fonction majorité, calculée sur un plan de bits, va donc donner le bit de la valeur médiane pour ce poids.

~~112 3.2. Parallélisation du calcul des filtres non-linéaires~~

~~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éalisation matérielle de cet algorithme peut être 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 éléments en entrée et sort un vecteur trié dont les éléments sont placés dans des registres. Trois autres modules, disposés en parallèle, cherchent respectivement Min, Med et Max des valeurs temporaires. Le tout est organisé dans une architecture pipe-line permettant de calculer un bit de majorité d’un plan des bits de 9 éléments avec une latence d’une seule opération.

~~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émentation efficace en termes des ressources logiques nécessaires de la fonction majorité d’un plan de bits pour un voisinage de 3 3 pixels. ×

L’implémentation d’une seule unité de traitement basée sur cet algorithme, dans un FPGA Altera Flex EPF10K10, affiche une vitesse de fonctionnement de 38MHz et une occupation des ressources logiques équivalente a` 462 cellules logiques élémentaires de 576 cellules dispo- nibles11.

Le délais de calcul pour le premier pixel est de 11 cycles d’horloge, tandis que pour chaque nouvelle colonne des pixels a` l’entrée, la valeur du pixel de résultat est calculée après un seul

11Une cellule logique élémentaire de la famille Flex de chez Altera, comme d’ailleurs celle de la famille Stratix déjà mentionnée, est composée d’une mémoire de 16 bits, d’un bi-stable programmable et d’une logique dédicacée pour l’addition.

113 Chapitre 3. Architectures dédicacées cycle d’horloge. En négligeant le délais de calcul pour le premier pixel, une hypothèse qui sera vérifiée pour des images d’une taille horizontale beaucoup plus grande que la taille de voisinage, ce qui est généralement le cas, la performance d’un tel système, exprimée par le débit des pixels traités, est de 38 Mpx/sec (millions de pixels par seconde).

La performance d’un système basé sur cet algorithme a été comparée avec quelques algorithmes efficaces de calcul de la fonction majorité proposés précédemment. Pour que la comparaison soit pertinente, les algorithmes comparés ont été réalisés dans des circuits FPGAs de même famille. L’implémentation de cet algorithme particulier montre un facteur d’accélération de 1.1 par rapport a` l’algorithme de Chang et Lin basé sur les réseaux de tri de type odd/e- ven (cf. [CL92]) et de 1.8 par rapport a` l’algorithme de Benkrid, Crookes et Benkrid basé sur un additionneur et une LUT (cf. [BCB02]).

~~3.2.4.3 Généralisation de l’algorithme pour les filtres Min/Max~~

L’algorithme utilisé pour le calcul de la valeur médiane d’une voisinage V en mode bit-série peut être adapté 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éside dans le fait qu’une même réalisation matérielle, celle qui calcule le filtre médian, peut facilement être adaptée pour le calcul des filtres Min/Max. En outre, au lieu de réaliser 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é, quelque soit le rang r recherché. Malheureusement les auteurs ne présentent aucun résultat en terme de performance d’une implémentation physique.

La méthode exposée concerne un voisinage classique de 3 3, mais ici nous en faisons la × généralisation 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’était un filtre médian, on considère un vecteur “augmenté” V de 2NV 1 éléments. La valeur médiane de 0 − ce vecteur est indiquée par le rang r0 = NV . Le vecteur V non-trié est placé dans le vecteur V 0 de fa¸con a` ce que le rang r0 du vecteur “augmenté” V 0 indique le rang r voulu pour le vecteur V . En outre, le vecteur V est décalé dans le vecteur V en ajoutant au total NV 1 éléments 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édicacée au filtre médian un peu plus universelle (on calcule les filtres Min/Max avec la même architecture), cela est

~~114 3.2. Parallélisation du calcul des filtres non-linéaires~~

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énéralisation de l’algorithme de filtre médian bit-série pour le calcul des filtres Min/Max. rendu possible au détriment d’un plus grand nombre d’opérandes de l’unité de traitement. Même si le nombre d’opérandes croit de fa¸con linéaire avec la taille du voisinage d’un facteur de 2, cela complique l’unité de traitement de fa¸con non-négligeable. Ceci peut s’avérer contraignant lorsque l’implémentation dans le circuit FPGA vise un parallélisme massif avec des voisinages de plus grande taille.

~~3.2.4.4 Généralisation pour les autres filtres non-linéaires~~

Gasteratos et al. proposent dans [AIP00] une architecture spécifique permettant le calcul de plusieurs types de filtres non-linéaires. L’architecture proposée, réalisée sous forme d’un ASIC, 12 est capable de calculer des filtres de n’importe quel rang, des filtres pondérés de rang et des filtres morphologiques classiques ou mous.

L’algorithme de base utilisé dans la conception de ce circuit a déjà été présenté, 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é : au lieu de calculer la somme successivement pour chaque niveau de gris afin d’obtenir la valeur de rang souhaitée, 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és pour coder le pixel. Ensuite on compte le nombre de pixels (b 1) dans le voisinage V plus grands, égal ou plus petits que 2 − . En outre, l’histogramme du (b 1) voisinage V est divisé 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és dans chaque zone déterminée par 2 − et notés pp eq pg respectivement np , np et np avec la valeur de rang r il est possible de déduire la valeur de bit du poids b 1 de la valeur médiane grâce aux conditions suivantes : pp − – si np r, alors le bit de la valeur médiane 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édiane correspond bien a` la valeur 2 − , pg ≥ – si np r, alors le bit de la valeur médiane pour ce poids est 1. ≥ La procédure est itérative. Dans le pire des cas elle nécessite b itérations. Dans le meilleur des b 1 cas, quand la valeur médiane de V correspond a` la valeur 2 − le calcul est fait en une seule itération.

Le circuit intégré décrit est doté d’une seule unité de traitement qui opère sur un voisinage de 3 3 exclusivement. Avec une latence d’un seul cycle, ce circuit permet d’arriver au débit × de traitement de 3.5Mpx/sec.

~~3.2.5 Architectures dédiées aux filtres de piles~~

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

Le voisinage nouvellement codé est noté 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 étant le nombre de bits ∈ { − } utilisés 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éré.~~

L’implémentation physique des filtres de piles est habituellement faite a` l’aide des trois techniques suivantes : b 1. Threshold decomposition (voir [WCN86]) - Pour chacun de 2 plans de NV bits d’un voisinage transformé V¨ , une PBF (le minimum, la médiane, le maximum, ou n’importe quelle autre fonction logique selon le filtre) est calculée et le résultat empilé (ou directement additionné) pour obtenir la valeur filtrée. Si cette approche est assez directe et se prête assez bien a` une parallélisation massive, le nombre de PBFs a` évaluer devient important avec un plus grand nombre de bits utilisés pour coder le pixel d’une image. Dans le cas le plus courant, lorsque les pixels de l’image sont codés sur 8 bits, il faut compter 256 PBFs par voisinage traité. La réalisation d’un tel nombre de fonctions résulte soit d’un circuit de très grande taille (calcul de 256 fonctions en parallèle), soit d’un nombre important d’opérations a` effectuer (256 pas de calcul). 2. Range compression (voir [ICL+94]) - Une implémentation des filtres de piles plus efficace viserait donc la réduction du nombre de PBFs a` calculer. La méthode dite de Range compression permet de réduire le nombre de PBFs a` calculer au nombre de voisins dans le V . Cette réduction du nombre de PBFs est possible grâce a` la propriété 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’évaluation de PBFs peut se faire uniquement pour des plans de bits p, déterminés par les valeurs des pixels dans le voisinage.

~~116 3.2. Parallélisation du calcul des filtres non-linéaires~~

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énéralement plus petit que 2b. Fort malheureusement l’implémentation physique d’un tel algorithme implique la mobilisation d’importantes ressources logiques, notamment pour déterminer les plans de bits p pour lesquels il faut effectivement calculer les PBFs. 3. Binary refinement (voir [Che89]) - Une autre fa¸con de réduire le nombre d’opérations liées a` l’évaluation 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é. Pour calculer la valeur médiane d’un voisinage V on considère les plans des bits correspondants et dans (b 1) un premier temps le plan médian situé donc au niveau 2 − . Pour ce plan de bits on calcule la PBF médiane. Si la valeur obtenue vaut 1, alors la médiane devrait se trouver dans la moitié “supérieure” de l’ensemble des plans de bits13. Dans le cas ou` on aurait obtenu un 0, la médiane se trouverait dans la moitié “inférieure” de l’ensemble des plans de bits. L’espace de recherche est ainsi divisé par deux a` chaque nouveau pas de calcul. L’algorithme reste itératif, mais le nombre de PBF a` évaluer passe de 2b a` b seulement. Woolfries et al. comparent les implémentations dans le FPGA des trois méthodes ex- posées de calcul des filtres de piles (voir [WLM+98a, WLM+98c, WLM+98b]). Les résultats montrent que la méthode la plus efficace en terme de ressources mobilisées et de vitesse de fonctionnement de circuit est celle basée sur la méthode du Binary refinement. L’implémentation d’une seule unité de traitement, pour un voisinage de 3 3, a été effectué sur un circuit × FPGA Xilinx XC621614 pour des pixels codés sur 8 bits. Pour une occupation d’environ 800 cellules logiques élémentaires du circuit FPGA considéré, une seule unité de traitement est caractérisée par un débit de 15Mpx/sec.

13 (b 1) Dans ce cas la médiane 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é d’une matrice de 64 × 64 cellules logiques élémentaires. Mais contrairement a` l’architecture habituelle des FPGAs Xilinx (les mémoires de 16 bits par cellule), la cellule possède une mémoire de seulement deux entrées.

~~117 Chapitre 3. Architectures d´edicac´ees~~

~~3.3 Conclusion~~

Nous allons clôturer ce chapitre par une discussion sur les différents systèmes décrits, leur performance, leurs avantages et inconvénients et leurs principales limitations. Dans un premier temps et avant de donner un récapitulatif des performances, nous insisterons sur la difficulté d’une comparaison croisée entre les différents systèmes. Ensuite viendront les remarques, d’abord d’ordre général avant de passer aux remarques spécifiques pour chaque type d’architecture envisagée. Enfin la dernière section nous permettra de faire le point sur ces remarques et de fixer les enjeux d’une nouvelle architecture, proposée au Chapitre 4.

~~3.3.1 Performance des systèmes dédicacés existants~~

La performance des différents algorithmes est le plus souvent exprimée par le nombre d’opérations nécessaire a` une unité de traitement pour calculer un seul pixel de l’image résultante. Si l’algorithme est accompagné d’une réalisation matérielle d’une unité de traitement sous forme d’un ASIC ou FPGA, sa performance est alors exprimée par la fréquence maximale de fonctionnement du circuit correspondant. En connaissant l’algorithme employé, c’est a` dire le nombre de pas de calcul nécessaires pour réaliser le traitement (les BOPs définies dans le Chapitre 1), il est alors possible de déduire le débit des pixels traités par le système proposé.

En disposant de ces chiffres on pourrait croire que pour effectuer une comparaison croisée des différents algorithmes ou des systèmes existants il suffirait de comparer le nombre d’instructions nécessaires a` l’exécution et/ou la fréquence de fonctionnement (ou le débit des pixels traités) pour une réalisation matérielle. Malheureusement, une telle comparaison hâtive peut induire en erreur.

Dans une étude purement théorique, le seul nombre d’instructions a` exécuter ne permet pas d’établir la performance réelle d’un système. En effet le débit réel de pixels traités que l’on pourrait obtenir dépendra de la vitesse de fonctionnement des unités de traitement correspondantes et du nombre de ces unités travaillant en parallèle.

Dans le cas d’une implémentation physique dans un circuit FPGA, la fréquence du fonctionnement de circuit réalisé est fortement influencée par le choix du circuit FPGA cible. En effet, pour un algorithme et une description de circuit donnée, la performance du circuit physique dépendra de la performance brute du FPGA (voir Annexe B). Or, comme on peut se l’imaginer, celle-ci est étroitement liée a` la technologie de fabrication des circuits intégrés et dépend donc du moment de la réalisation du circuit.

La vitesse de fonctionnement du circuit est également influencée par la qualité du processus d’implémentation. Malgré l’amélioration constante des logiciels utilisés pour la synthèse et l’implémentation de la logique programmable, a` l’heure actuelle l’intervention humaine peut améliorer le processus automatique d’implémentation (voir Section 3.1).

Les deux approches de la parallélisation des filtres non-linéaires qui ont été abordées dans la section précédente : l’une purement théorique (notamment les architectures matricielles et les réseaux de tri) et l’autre pratique (les réalisation sous forme d’ASIC ou FPGA), fournissent

118 3.3. Conclusion des résultats qui sont donc difficilement comparables. Pire, comme nous venons de le constater, une comparaison entre les différents résultats pratiques fournis a` des moments différents n’est par pertinente non plus. C’est sans doute pour cette raison que les performances des systèmes proposés sont souvent données telles quelles, sans ou avec très peu de points de comparaison avec les systèmes semblables.

Malgré les difficultés d’une comparaison croisée entre les différents systèmes proposés, nous résumons les résultats cités dans la Section 3.2 a` titre indicatif dans le Tableau 3.3. Il serait éventuellement possible d’extrapoler les résultats en employant la loi de Moore. Ainsi toutes les données seraient ramenées a` un même instant de temps, mais nous avons préféré ne pas appliquer une telle démarche, a` cause de son caractère 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édicacée bit-série 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érentes architectures existantes pour le calcul des filtres non-linéaires.~~

~~3.3.2 Remarques~~

L’ensemble des solutions de la parallélisation du calcul des filtres non-linéaires présenté mérite un certain nombre de remarques. Certaines sont communes a` toutes les architectures envisagées, tandis que d’autres sont propres a` une architecture particulière.

~~3.3.2.1 Remarques g´en´erales~~

Taille de voisinage Dans la plupart des travaux cités, les algorithmes proposés et les architectures associées impliquent le calcul des filtres sur un voisinages fixe, l’incontournable 3 3. Ceci peut s’avérer × limitatif, puisque dans certains cas le traitement va nécessiter des calculs sur des voisinages plus grands.

La grande majorité des algorithmes décrits peut être adaptée a` des plus grands voisinages, mais pas tous. Celui proposé par Lee, par exemple ne pourra donc pas être utilisé pour des voisinages plus grands que 3 3. × Lorsque l’algorithme permet le calcul sur des voisinages plus grands et lorsque la complexité théorique de l’unité de traitement en termes de ressources est exprimé en fonction de la

119 Chapitre 3. Architectures dédicacées taille de voisinage, il serait alors possible d’extrapoler les résultats pour des voisinages plus grands. Malheureusement, une telle approche peut s’avérer fort imprécise. La complexité théorique ne peut être utilisée pour une évaluation précise des ressources logiques nécessaires a` la réalisation d’une unité de traitement travaillant sur un plus grand voisinage. C’est un peu comme la complexité algorithmique : on peut prévoir la croissance de temps de calcul en fonction de la taille du problème, mais on ne peut pas en déduire un temps d’exécution exact.

Faible parallélisation La totalité des réalisations décrites ne traite que des implémentations d’une seule unité de traitement. Ceci est vrai même pour des systèmes dont la quantité de ressources logiques nécessaires pour leur réalisation est nettement inférieure a` celle disponible dans le FPGA cible. Les ressources non-exploitées pourraient alors être utilisées pour l’implémentation d’autres unités de traitement, permettant ainsi une exécution en parallèle15.

Une simple extrapolation des données obtenues pour l’implémentation d’une seule unité de traitement ne peut être a` nouveau appliquée. Dans le cas d’une implémentation dans un FPGA, l’accroissement des ressources logiques nécessaires pour la réalisation de multiples unités identiques n’est pas forcément une fonction linéaire de nombre d’unités de traitement. Ensuite, a` cause de la présence de multiples unités de traitement, la fréquence maximale de fonctionnement du circuit va diminuer et ceci d’autant plus que le degré de parallélisme augmente. Les deux remarques combinées auront pour conséquence un débit réel des pixels traités plus faible par rapport a` celui que l’on pourrait déduire théoriquement.

~~3.3.2.2 Remarques sp´eciﬁques a` l’architecture~~

Architectures matricielles en mode bit-série Ces architectures présentent l’avantage d’un fonctionnement en mode SIMD, d’une possibilité de parallélisme massif et d’une scalabilité16 quasi immédiate. Leur architecture, organisée autour d’unités de traitement identiques et simples, peut conduire a` une implémentation efficace dans des circuits FPGA. Cependant ces architectures, même les plus performantes, nécessitent 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équence de fonctionnement et/ou un nombre important d’unités de traitement pour qu’un tel système soit compétitif avec une architecture universelle. En effet, comme nous l’avons montré dans le Chapitre 2 une architecture universelle nécessite actuellement une dizaine de BOPs par pixel pour le calcul d’un filtre non-linéaire. Une architecture matricielle fonctionnant en mode bit-série en nécessite environ 20 fois plus dans le meilleur des cas (architecture proposée par Chang). A la même

15L’implémentation proposée par Woolfries et al. pourrait impliquer quatre unités de traitement, or le débit des pixels traités présenté ne se base que sur le fonctionnement d’une seule unité. 16Par scalabilité on fait référence au terme anglais scalability qui signifie une possibilité d’augmentation sub- stantielle de degré de parallélisme tout simplement en augmentant le nombre d’unités de traitement employés.

~~120 3.3. Conclusion fréquence de fonctionnement17 il faudrait donc 20 fois plus d’unités de traitement pour arriver a` un débit de pixels traités obtenu par une architecture universelle.~~

Architectures matricielles en mode bit-parallèle Les architectures matricielles en mode bit-parallèle permettent de réduire considérablement le nombre de pas de calcul par rapport aux architectures de même type en mode bit-série. L’architecture proposée par Chakrabarti par exemple nécessite un seul pas de calcul pour la réalisation d’un filtre médian. Le prix a` payer en termes des ressources logiques employées est cependant élevé.

Une unité de traitement nécessitera une importante quantité des ressources logiques pour sa construction a` cause de ses circuits arithmétiques et mémoires fonctionnant en mode bit- parallèle. Ce mode de fonctionnement mobilisera également des importantes ressources en interconnexions et en entrées/sorties. Si l’on envisage une implémentation dans un circuit FPGA ceci aura pour conséquence un faible degré de parallélisme et des faibles vitesses de fonctionnement. Donc un faible débit des pixels traités.

Réseaux de tri Le principal désavantage des réseaux de tri réside dans le nombre de comparateurs. Même dans les cas d’un réseau optimisé 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ésavantage de ces architectures est lié au fait que le calcul des différents rangs : Min/Max d’un côté et Médian de l’autre, implique un nombre fort différent de comparateurs. Ainsi pour trouver un Min/Max d’un voisinage 3 3 on a besoin de seulement 8 comparateurs × (avec un réseau Bubble par exemple), alors que pour un filtre médian le réseau le plus performant (le réseau bitonique adapté par Chung) en nécessite 24. Ce déséquilibre se traduira par une sous-exploitation des ressources disponibles dans le cas d’un système reconfigurable qui viserait la réalisation des deux traitements puisque c’est la configuration la plus complexe qui déterminera le choix du circuit FPGA a` employer. Pour des réseaux de tri, la même remarque concernant la quantité des ressources en connexions internes et en entrées/sorties que celle faite pour des architectures matricielles en mode bit-parallèle reste valable.

Architectures dédicacées en mode bit-série Les architectures dédicacées fonctionnant en mode bit-série semblent les plus adaptées a` l’implémentation dans des circuits logiques programmables FPGA. Les principaux arguments sont : le mode de fonctionnement SIMD, la simplicité des unités de traitement, la possibilité d’un parallélisme massif et de la scalabilité, les faibles ressources nécessaires pour les interconnexions et les entrées/sorties et le petit nombre de pas de calcul. Cependant les remarques générales, faite dans la Section 3.3.2.1 restent valables pour ces architectures.

~~Architectures dédiées aux filtres de piles Malgré le mode de fonctionnement en mode bit-série et les algorithmes qui réduisent le nombre~~

17Ce qui est un cas plus réaliste que celui d’une fréquence de fonctionnement 20 fois plus grande. En comparant par exemple le temps d’accès a` une seule mémoire de CLE (voir Annexe B) avec le temps d’exécution d’une opération par le processeur, on se rend compte que ces temps sont très proches : de l’ordre d’un dixième de nano-seconde. Or pour un FPGA , tout circuit dont le nombre d’entrées dépasse le nombre d’entrées d’une mémoire de CLE sera réalisé par une mise en série des différents mémoires. Le temps d’accès ne sera donc que plus long.

121 Chapitre 3. Architectures dédicacées de PBFs a` calculer, ces architectures sont caractérisées par des importantes ressources logiques nécessaires même pour l’implémentation d’une seule unité de traitement. Si la partie de traitement proprement dite est simple a` réaliser : il s’agit d’une seule fonction logique a` NV variables d’entrée, ces sont les étapes avant et après le calcul de la PBF qui sont parti- culièrement 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ésentent le plus gros des ressources occupées par l’unité de traitement.

~~3.3.3 Objectifs~~

~~Sur base des remarques exposées, nous pouvons dégager trois principaux objectifs pour le système qui sera abordé 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 équilibrée aborder l’implémentation des différents filtres de rang pour les différentes tailles de voisinage. De cette fa¸con seront dépassés les défauts des systèmes déjà abordés.

2. Parallélisation massive La densité des circuits FPGAs actuels et leur richesse en ressources des entrées et des sorties les rend parfaitement adaptés a` l’implémentation d’un grand nombre d’unités de traitement. La quantification de degré de parallélisme qu’il serait possible d’obtenir a` partir d’un circuit FPGA de haute densité sera étroitement lié a` la comparaison de performance entre un système reconfigurable et une architecture universelle.

3. Comparaison En etablissant´ la meilleure performance possible (BOPs) des architectures universelles nous avons créé un point de comparaison auquel peut se référer toute autre architecture destinée au calcul des filtres non-linéaires. Ce point de comparaison peut facilement être adapté de fa¸con a` suivre l’évolution temporelle de la technologie, l’évolution dont dépend étroitement la performance d’un système. Ce point est essentiel dans la validation d’un quelconque système dédicacé devant un système universel.

~~122 Chapitre 4~~

~~Architecture reconﬁgurable~~

L’étude de l’implémentation des filtres non-linéaires sur des architectures universelles, abordée 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é les diverses manifestations de parallélisme (notamment le parallélisme des instructions et le parallélisme des données - le modèle SIMD de calcul) nous avons pu identifier deux principales raisons qui limitent la performance de tels systèmes a` l’égard du problème posé : 1. accès inadéquat aux données nécessaires au calcul (la redondance en lecture de données pour le calcul des voisinages successifs) en raison du nombre limité de registres de micro-processeur et 2. faible degré de parallélisme de l’unité de traitement.

Néanmoins l’usage du parallélisme des architectures universelles nous a permis d’obtenir d’importants facteurs d’accélération par rapport a` une approche dite classique qui ne tient compte que des aspects algorithmiques de la résolution du problème.

Dans une chaˆıne de traitement des images numériques la performance des architectures universelles peut s’avérer 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éaire est appliqué avant d’autres traitements, il convient alors de rechercher une solution alternative.

Le développement d’un système dédicacé pour le calcul des filtres non-linéaires peut améliorer le temps de calcul des filtres non-linéaires. L’optimisation des algorithmes employés, ainsi que la multiplication des unités de traitement (parallélisation) conduisent a` des architectures plus performantes, comme nous avons pu le voir dans le Chapitre 3. Cependant les solutions envi- sagées jusqu’à présent ne sont pas sans défaut, notamment en ce qui concerne les limitations au niveau de la taille des voisinages considérés et le manque de parallélisation massive (voir les commentaires de la Section 3.3.2).

Pour illustrer la nécessité d’un traitement encore plus rapide, on peut prendre comme exemple la performance des caméras numériques actuelles. Les modèles courants affichent déjà un débit de pixels qui est de l’ordre de 50MB/sec (voir [Gro00] par exemple). Pour des caméras numériques a` haute vitesse d’acquisition ces débits sont encore plus importants et peuvent,

123 Chapitre 4. Architecture reconfigurable dans certain cas, atteindre les 250MB/sec ([PS04]). Clairement, la performance des architectures décrites, aussi bien universelles que dédicacées, n’est pas suffisante pour répondre en temps réel a` une telle vitesse d’acquisition.

Dans ce chapitre nous allons décrire la conception d’un système original, dédicacé au calcul des filtres de rang, basé sur des circuits FPGAs, donc reconfigurable, permettant d’arriver a` de hauts débits de traitement.

La notion de reconfigurablité est ici utilisée pour décrire un même système dédicacé (un même système physique) capable de calculer les différents filtres de rang pour des voisinages de tailles et de formes différentes. Pour un filtre et un voisinage donné on aura une configuration particulière de système permettant d’effectuer le calcul demandé. Ainsi il serait possible d’imaginer une bibliothèque de différentes configurations, sauvegardées dans une mémoire de type EPROM ou Flash par exemple. A partir de cette bibliothèque l’utilisateur pourrait facilement faire le choix du traitement qu’il souhaite appliquer.

Les algorithmes qui seront utilisés pour la conception des unités de traitement sont basés sur le calcul qui est de type bit-série et ont l’avantage d’être plus simples que ceux basés sur le calcul en mode bit-parallèle. Cette différence est d’autant plus marquée lorsque la taille du voisinage augmente car le nombre de pas de calcul de ces algorithmes est indépendant de la taille du voisinage traité. De plus, de tels algorithmes s’adaptent particulièrement bien a` la structure interne des FPGAs qui est de type grain fin : un grand nombre de mémoires permettant la réalisation des fonctions logiques d’un faible nombre de variables.

La technologie actuelle de fabrication des circuits FPGAs permet l’intégration de circuits de très haute densité. La simplicité des algorithmes envisagés, combinée a` une importante quantité de ressources logiques des FPAGs de haute densité, résultent d’une possibilité de parallélisation massive et donc d’un plus grand débit de données traitées.

Ces deux constatations nous permettent de poser deux questions fondamentales : "Quelle serait la performance d’un système dédicacé reconfigurable basé sur un algorithme de calcul des filtres non-linéaires en mode bit série, etant´ donnée la haute densité des circuits FPGAs actuels ?"

~~"Quel est le gain en performance d’un tel système par rapport aux architectures universelles classiques et aux architectures dédicacées existantes ?"~~

~~Ce chapitre propose de donner la réponse a` ces questions a` travers cinq sections brièvement décrites ci-dessous :~~

Section 1 - Nous commencerons par donner une description globale du système dédicacé reconfigurable pour le calcul des filtres non-linéaires. Ici nous introduisons les principaux éléments de l’architecture proposée : la partie traitement et les différentes mémoires nécessaires a` son fonctionnement. On donnera également une brève description d’une carte, disponible

~~124 actuellement sur le marché, dotée d’un circuit FPGA de haute densité et des mémoires permettant l’intégration d’un tel système.~~

Section 2 - Cette section propose la description détaillée de la mémoire locale du système reconfigurable permettant la mise en format des données de l’image a` traiter et de l’image traitée nécessaires pour un fonctionnement en mode bit-série. Nous présentons également la validation de la description formelle d’un tel circuit ainsi que les résultats des différentes implémentations relatives a` plusieurs configurations possibles de la mémoire. De tels résultats nous permettent de déduire la performance de ce sous-système particulier.

Section 3 - Dans cette section on offre les explications relatives a` la partie traitement : description détaillée des algorithmes utilisés et des unités de traitement correspondantes. Comme pour la mémoire locale, la description formelle de l’unité de traitement est accom- pagnée d’une validation et des résultats de l’implémentation en termes de la quantité des ressources logiques employées et la vitesse de fonctionnement.

Section 4 - Cette section décrit l’assemblage des différentes parties décrites dans ce que nous allons appeler un module de traitement. Le système reconfigurable complet sera composé de plusieurs modules de traitement indépendants, assurant un haut niveau de parallélisation. Un accent particulier sera mis sur le processus d’optimisation du processus d’implémentation, permettant d’obtenir la meilleure performance possible étant donné un FPGA particulier de haute densité. Sur base des résultats de l’implémentation d’un système reconfigurable complet, nous allons déduire le débit maximal de traitement qu’il serait possible d’obtenir avec la carte décrite dans la Section 1.

~~Section 5 - Enfin, la dernière section propose une conclusion sur l’implémentation des filtres de rang a` l’aide de l’architecture reconfigurable décrite.~~

~~125 Chapitre 4. Architecture reconﬁgurable~~

~~4.1 Description globale du système dédicacé reconfigurable~~

~~4.1.1 Introduction~~

~~Le système que nous allons décrire apparaˆıt comme un système de traitement d’information numérique 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ème dédicacé reconfigurable.~~

En toute généralité la source de l’image peut être n’importe quel système capable de fournir l’information numérique sur l’image a` traiter. Cela peut être bien entendu un ordinateur classique mais également tout autre système d’acquisition d’images : un scanner, une caméra ou un appareil photo numérique, etc.

Si la source de l’image est un ordinateur personnel, le système reconfigurable dédicacé apparaˆıt alors comme un processeur attaché au système hôte (voir la taxonomie des architectures dédicacées exposée dans la Section 1.2.2.2). L’avantage d’une telle configuration réside alors dans le fait que le système dédicacé peut facilement accéder a` toute source d’image a` laquelle cet ordinateur a accès : tout support de stockage, toute sorte de sources analogiques via un système de capture etc.

Dans le cas ou le système reconfigurable dédicacé est attaché a` un quelconque système d’acquisition, son emploi se limite a` l’application d’un filtre juste après l’acquisition. L’utilisateur récupère une image déjà traitée et a peu de possibilité d’interaction avec le système de traitement, 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ème, l’utilisateur désireux d’en connaˆıtre la performance doit pouvoir répondre aux questions suivantes : 1. Quel serait l’algorithme le plus approprié pour une implémentation dans un circuit FPGA ?

2. Quel est le nombre d’unités de traitement (i.e. le degré de parallélisme) qu’il serait possible d’obtenir pour des applications envisagées étant donnée les FPGAs de haute densité ?

~~3. Quelle sera la fréquence de fonctionnement maximale d’un tel système (le débit des pixels traités) ?~~

~~126 4.1. Description globale du système dédicacé reconfigurable~~

En ce qui concerne le choix des algorithmes, nous avons vu dans le Chapitre 3 que les algorithmes de calcul des filtres non-linéaires peuvent être repartis en deux grandes classes : les algorithmes de type bit-série et les algorithmes de type bit-parallèle. La première classe d’algorithmes s’adapte particulièrement bien a` une implémentation dans les systèmes dédicacés, réalisés a` base de circuits FPGAs, et ce pour deux raisons.

Tout d’abord il y a la simplification de l’unité de traitement due a` la suppression du pa- rallélisme au niveau des mots qui codent les pixels de l’image. Ceci a pour conséquence une moindre quantité de ressources logiques nécessaires pour la réalisation d’une unité de traitement par rapport au cas du parallélisme de type bit-parallèle. L’avantage en est double : la vitesse des unités de traitement augmente ainsi que leur nombre pour un même circuit FPGA.

Le deuxième avantage d’une architecture bit-série réside 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és pour quantifier la couleur des pixels de l’image. Ainsi les unités de traitement auront besoin d’un même nombre de pas de calcul, qu’elle que soit la taille du voisinage considéré.

Lors d’une réalisation pratique il est évident que la performance d’une unité de traitement fonctionnant en mode bit-série va aussi dépendre de la taille du voisinage choisi et que le débit des pixels traités ne sera pas le même pour toutes les tailles de voisinages envisagées. En effet, pour des voisinages plus grands, le nombre de cellules logiques élémentaires, ainsi que le nombre de ”couches“ logiques1, seront plus grands. La conséquence de ce fait est double : la vitesse de chaque unité de traitement va diminuer et le nombre d’unités de traitement par circuit FPGAs utilisé aussi. Ceci conduira inexorablement a` un débit des pixels traités plus faible.

~~4.1.2 Parties constitutives~~

D’un point de vue macroscopique, l’architecture dédicacée reconfigurable proposée est composée des mêmes modules qu’une architecture universelle classique au sens Von Neumann du terme. Nous avons donc les trois modules suivants :

1. une unité de contrôle, 2. une mémoire globale contenant l’image I a` traiter et l’image traitée I˜, 3. une partie traitement composée d’une mémoire locale pour les opérandes (les valeurs des pixels des différents voisinages - une fenêtre de traitement) et pour le résultat (les valeurs filtrées - la fenêtre filtrée).

~~Ces trois modules sont représentés schématiquement a` la Figure 4.2.~~

1Une ”couche logique“ est définie comme un ensemble des LUT s du FPGA, permettant de calculer un certain nombre de fonctions logiques en un seul temps d’accès a` la LUT . La décomposition 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érie de plusieurs LUT s, introduisant donc plusieurs ”couches“ logiques.

~~127 Chapitre 4. Architecture reconﬁgurable~~

~~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ème dédicacé reconfigurable pour le calcul des filtres non-linéaires.~~

L’image a` traiter et l’image traitée se trouvent dans la mémoire globale. Grâce a` l’unité de contrôle, des parties de l’image a` traiter sont lues depuis la mémoire globale, fenêtre par fenêtre dans la mémoire locale des opérandes des unités de traitement.

Lorsqu’une fenêtre entière est disponible dans la mémoire locale des opérandes, elle est traitée et les résultats sauvegardés dans la mémoire locale de résultat. Depuis la mémoire locale, la fenêtre traitée est ensuite transférée vers la mémoire 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ème qui réalise le traitement est construite autour d’une matrice d’unités de traitement identiques a` laquelle sont associées deux mémoires locales : – une mémoire pour la fenêtre a` traiter - la mémoire locale source, – et une autre pour la fenêtre traitée - la mémoire locale destination.

Les unités de traitement et les mémoires associées re¸coivent le même flux d’instructions, émis par l’unité de contrôle. Chaque unité de traitement travaille sur un voisinage particulier, mais les données communes au traitement des voisinages successifs ne sont pas répliquées. Comme la matrice des unités de traitement fonctionne en mode SIMD de calcul, les résultats de filtrage d’une fenêtre F entière de l’image sont calculés simultanément.

La Figure 4.3 illustre le principe de découpage d’une image en fenêtres, la sauvegarde de la fenêtre dans la mémoire source locale, le calcul effectué par des unités de traitement associées a` cette mémoire et la sauvegarde des résultats dans la mémoire locale destination. Pour cet exemple concret la taille de la fenêtre a` traitée est fixée a` 9 9 pixels, a` quoi correspond une × matrice de 7 7 unités de traitement pour un filtre de taille 3 3, a` cause de l’effet de bord. × × 128 4.1. Description globale du système dédicacé 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être en cours de traitement de 9 9 × pixels, les 7 7 unités de traitement associées et le résultat de filtrage. ×

Pour une fenêtre de taille fixe et pour des filtres travaillant sur des voisinages de tailles différentes, le nombre d’unités de traitement sera variable a` cause de l’effet de bord. Par conséquent la taille de la mémoire destination locale sera aussi variable, ce qui ne pose pas de problème étant donné que le système est reconfigurable.

Comme notre choix se porte sur des algorithmes de type bit-série, la mémoire source locale devrait non seulement jouer le rôle d’une mémoire des opérandes mais devrait également effectuer la mise en forme des données pour un traitement en mode bit-série. La mémoire locale destination devrait a` son tour remettre les données au format habituel. Les deux mémoires peuvent être facilement réalisées a` l’aide d’un ensemble de registres a` décalage, comme nous allons le voir par la suite (Section 4.2).

~~4.1.2.2 M´emoire globale~~

La mémoire globale contient donc l’information sur l’image a` traiter et sur l’image traitée et joue un rôle d’intermédiaire entre le système reconfigurable et le monde extérieur. Etan´ t donné que les unités de traitement travaillent en mode bit-série, la mémoire globale présente deux modes de fonctionnement (cycles lecture/écriture) distincts : le mode série et le mode fenêtre. Ces deux modes de fonctionnement sont représentés schématiquement a` la Figure 4.4.

~~129 Chapitre 4. Architecture reconﬁgurable~~

~~Vx-1 Ix Ix~~

~~Vy-1~~

~~Iy Iy~~

~~a) b)~~

~~Fig. 4.4: Deux modes de fonctionnement de la mémoire : a) série et b) par fenêtre.~~

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ésigne les pixels de l’image a` parcourir et M le pointeur d’une zone de mémoire de la taille de l’image I. Ce mode de lecture/écriture de l’image est aussi appelé ”raster“.

En mode fenêtre, représenté a` la Figure 4.4 b), plutôt que des lignes de l’image, ce sont des lignes de la fenêtre qui sont lues, l’une après l’autre, également de gauche a` droite et de haut en bas (le vecteur de mémoire est de taille de la fenêtre F ). Remarquons le recouvrement des fenêtres, de Vx 1 et de Vy 1 pixels, avec Vx et Vy qui désignent respectivement la − − taille horizontale et verticale de voisinage V . Ce recouvrement est nécessaire pour le calcul des pixels au bord des fenêtres successives.

~~Le fonctionnement en mode fenêtre peut être modélisé a` l’aide de quatre boucles : les deux~~

130 4.1. Description globale du système dédicacé reconfigurable premières relatives aux parcours des fenêtres dans l’image2 et les deux autres relatives aux parcours des pixels a` l’intérieur de la fenêtre :

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é M désigne maintenant un pointeur vers la zone mémoire de taille de la fenêtre (Fx Fy). ∗ La mémoire globale source est alors définie comme une mémoire ayant des propriétés suivantes : – en écriture elle fonctionne en mode sériel - on effectue le chargement de l’image a` traiter, pixel par pixel, de fa¸con a` respecter la source qui généralement fourni les données en mode série, – en lecture elle fonctionne en mode fenêtre - on lit pixel par pixel de la fenêtre en cours de traitement.

La mémoire globale destination fonctionne en mode inversé par rapport a` la mémoire globale source : – en écriture elle fonctionne en mode fenêtre - on effectue le chargement de la fenêtre traitée, pixel par pixel, – en lecture elle fonctionne en mode sériel - on lit pixel par pixel l’image traitée.

~~4.1.2.3 Unit´e de contrˆole~~

L’unité de contrôle permet de gérer le fonctionnement de l’ensemble. Tout d’abord elle assure les deux types de fonctionnement de la mémoire globale, permettant les transferts vers et depuis la mémoire locale. Ensuite, elle est responsable de la génération des instructions nécessaires a` la matrice des unités de traitement (et les mémoires locales) lors du calcul.

Etan´ t donné que les algorithmes employés sont de type bit-série et que les unités de traitement correspondantes sont dédicacées, la partie contrôle de celles-ci se résume a` des machines d’états extrêmement 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évoir un recouvrement de l’avant dernière et de la dernière fenêtre a` l’extrême droite de l’image (il y aura une redondance de calcul).

~~131 Chapitre 4. Architecture reconﬁgurable~~

~~4.1.3 Hypoth`eses de travail~~

~~Pour une implémentation physique, le système décrit peut être divisé selon sa ”configura- bilité” 3 en deux parties distinctes :~~

~~– Partie figée - La configuration matérielle de cette partie est fixe, mais programmable. Elle regroupe les deux mémoires globales et leur contrôle.~~

– Partie reconfigurable - Comme la partie traitement vise la réalisation de plusieurs filtres différents pour des voisinages de tailles et de formes différentes a` l’aide d’un même système physique, c’est elle qui sera réalisée dans un (ou plusieurs) circuit FPGA. Cette partie comprendra donc les mémoires locales et la matrice des unités de traitement, ainsi que leur contrôle.

Une telle décomposition du système de traitement est d’autant plus justifié qu’actuellement il existe sur le marché des solutions matérielles dont la partie figée est déjà développée et prête a` l’emploi. Dans ce cas, le développement d’un système de traitement se limite uniquement a` la réalisation 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é d’un circuit FPGA Xilinx de la famille Virtex II de haute densité, nous avons le choix entre le circuit xc2v6000 ou xc2v8000. Le circuit FPGA et couplé aux deux mémoires de type DDR-SDRAM4. Chacune de ces mémoires, d’une capacité totale de 0.5 ou 1 GB, est placé sur son propre bus d’adresses et le bus de données, d’une largeur de 256 bits. Une telle configuration de la mémoire permet une bande passante théorique maximale de 12.8 GB/sec.

Pour la connexion avec le monde extérieur, la carte ADP-WRC-II est dotée d’une interface PCI permettant une connexion avec un système hôte, typiquement un ordinateur personnel. On dispose également d’une connexion de type CMC (Common Mezzanine Card, le standard IEEE 1386) permettant la connexion de la carte avec d’autre modules, tels que cartes d’acquisition de données.

Dans ce qui va suivre nous allons supposer avoir accès aux différentes fenêtres de l’image et que les deux bus de données : le premier pour l’image a` traiter et le deuxième pour l’image traitée sont d’une largeur fixe, de 256 bits.

Nous allons également supposer disposer d’un FPGA de haut densité, le circuit xc2v8000 en l’occurrence. La validation des circuits proposées se fera donc par simulation des modèles des circuits générées automatiquement après le processus d’implémentation.

3Voir Section 1.2.2.3 Taxonomie des architectures selon la configurabilité. 4L’acronyme DDR-SDRAM signifie Double Data Rate - Synchronous Dynamic RAM. Il s’agit de mémoires rapides permettant les cycles de lecture/écriture 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écédente nous avons vu que la mémoire locale source permet a` la matrice des unités de traitement d’accéder aux pixels des différents voisinages d’une fenêtre de fa¸con a` ce que la fenêtre entière soit traitée simultanément. Avant le traitement, les pixels d’une fenêtre seront donc transférés de la mémoire globale source vers la mémoire locale source. Outre son rôle de mémoire des opérandes, la mémoire locale source va donc également intervenir dans la mise en forme des données de la fenêtre, de fa¸con a` ce que chaque unité de traitement dispose des différents plans de bits requis.

~~Considérons une fenêtre F de l’image I a` traiter, composée de NF pixels et notée 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ée en binaire. Le bit de poids w, du pixel m de la fenêtre F est noté F [m, w]. Lorsque les pixels de l’image sont codés sur b bits, nous avons donc pour une fenêtre 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ême poids w : un plan de bits de la fenêtre F - P BF w. Nous disposons donc de b plans de bits notés :

w P BF = F [0, w], F [1, w], . . . , F [NF 1, w] w 0, . . . , b 1 (4.3) { − } ∀ ∈ { − } La mémoire locale source va donc générer les différents plans de bits P BF w a` partir des données d’une fenêtre F provenant de la mémoire globale source en mode raster.

L’architecture adoptée pour la mémoire locale source est représentée schématiquement a` la Figure 4.5. Elle est composée : – d’une mémoire tampon permettant la sauvegarde d’une seule ligne de la fenêtre F a` traiter, – de la matrice de NF = Fx Fy registres a` décalage. ∗ La mémoire tampon est composée d’une ligne (le bloc en trait interrompu marquée tmp) de

~~Fx registres (marqu´ees tmp0, . . . , tmpFx 1), a` chargement et a` sortie parall`ele. −~~

~~La matrice des registres a` décalage est composé d’une ligne (marquée L0) de Fx registres~~

(R0,0 . . . R0,Fx 1), a` chargement parallèle et a` un bit de sortie - le bit de poids le plus fort. La − matrice est ensuite complétée par Fy 1 lignes (notées L1, . . . , LFy 1) de Fx registres chacune, − − a` un bit d’entrée et un bit de sortie. Tous les registres ont une longueur de b bits.

~~133 Chapitre 4. Architecture reconﬁgurable~~

Le chargement des données dans la matrice des registres peut se faire soit depuis la mémoire tampon, soit depuis la sortie des registres a` décalage eux mêmes (les démultiplexeurs a` l’entrée 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ées depuis les registres, permettant ainsi plusieurs passages pour chaque plan de bits, si nécessaire. La matrice des registres apparaˆıt alors comme un système

~~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~~

~~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émoire locale source : la mémoire tampon et la matrice de registres a` décalage~~

~~ayant b bits a` l’entrée et NF = Fx Fy bits a` la sortie. Ce système transforme un flux de × données a` son entrée pixel par pixel en un flux de données des plans de bits successifs.~~

Le choix d’une telle architecture pour la mémoire locale des unités de traitement a été fait de fa¸con a` répondre aux deux objectifs suivants : – Minimiser la largeur des chemins de données - Comme les unités de traitement travaillent en mode bit-série, on effectue le traitement plan de bits par plan de bits, l’accès aux données peut être limité uniquement aux données d’un seul plan de bits.

– Minimiser les ressources logiques mobilisées - Dans un circuit FPGA la réalisation des registres a` décalage a` sortie et a` entrée parallèle est faite a` l’aide des bi-stables programmables d’une cellule logique élémentaire CLE. Pour réaliser 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ète. Par contre un registre a` décalage a` un seul bit d’entrée et a` un bit de sortie est réalisé a` l’aide d’une seule LUT de la CLE. Dans ce cas il est possible de réaliser 8 registres de maximum 16 bits dans une seule CLE 5.

Les pixels de la fenêtre sont d’abord sauvegardés dans la mémoire tampon de la matrice, un par un, dans l’ordre de leur arrivée. Lorsque une ligne de la fenêtre est chargée dans la mémoire tampon, elle est ensuite copiée dans la ligne L0 des registres. Comme la ligne L0 est composée de registres a` chargement parallèle, ce transfert peut être réalisé en un seul cycle d’horloge. Depuis la première ligne de la matrice, les valeurs de pixels sont ensuite propagées dans les registres a` décalage des lignes suivantes, de fa¸con a` ce que la matrice contienne la fenêtre F entière. Le transfert depuis la première ligne vers les autres lignes de la matrice est réalisé bit par bit (le décalage des lignes), puisqu’il s’agit des registres a` un seul bit d’entrée et de sortie.

~~Le principe de fonctionnement de la matrice et le chargement d’une fenêtre peut être résumé 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érations de chargement de la mémoire tampon, la copie vers la ligne L0 et le décalage des lignes sont des tâches exécutées de fa¸con concurrentielle (le pipe-line de chargement). La Figure 4.6 montre le chronogramme des différents signaux de contrôle nécessaires pour le fonctionnement de la matrice des registres a` décalage et met en évidence les taches exécutées 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êtres successives sur le bus de sortie (P BF w).

La sauvegarde des pixels de l’image se fait au rythme d’une horloge noté Clk 6 sur le chronogramme de la Figure 4.6. Après Fx cycles d’horloge, une ligne complète de la fenêtre F est chargée dans la mémoire tampon. Au cycle suivant, cette ligne est copiée dans la matrice des

5Pour rappel : une CLE dans la terminologie des circuit FPGA -Virtex de Xilinx est appelé un CLB. Un CLB est composé de quatre tranches, chacune ayant deux mémoires de 16 bits. Voir Section 3.1 de l’Annexe 3 pour une explication plus détaillée de l’architecture d’une CLE. 6Afin de simplifier le dessin, les flancs descendants de ce signal ne sont pas représentés sur la figure.

135 Chapitre 4. Architecture reconfigurable registres grâce au signal de contrôle CopyLineIn. En même temps qu’un nouveau cycle de chargement d’une ligne dans la mémoire tampon a lieu, le contenu de toute la matrice est décalée de b places (le signal de contrôle ShiftMatrix).

Lorsque Fy lignes de la fenêtre F seront chargées (après Fx Fy cycles), les nouveaux b cycles ∗ permettant de charger une nouvelle ligne dans la matrice donneront l’accès aux bits de la w fenêtre F1 (les données de la première fenêtre 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éplacement horizontal ou un déplacement vertical de la fenêtre F , comme le montre la Figure 4.7.~~

Etan´ t donné l’effet de bord lié au calcul dans un voisinage, le traitement sur une nouvelle fenêtre ne doit pas forcément comprendre le chargement de Fx Fy nouveaux pixels. En ∗ effet certains pixels, ceux appartenant aux zones grisées a` la Figure 4.7, sont des pixels déjà présents dans la matrice des registres a` décalage et ils peuvent être réutilisés pour le calcul de la fenêtre suivante. Le nombre des nouveaux pixels a` charger dans la matrice est alors donné 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être) et non par colonne, c’est le déplacement vertical de la fenêtre 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êtres 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éré.

Ainsi pour minimiser ∆T nous allons prendre comme taille verticale de le fenêtre 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être suivante. En ce qui concerne la taille horizontale de la fenêtre, elle dépendra de l’algorithme utilisé.

Pour des algorithmes en mode bit-série ne nécessitant qu’un seul passage a` travers les différents 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émoire locale des unités 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és de traitement.

137 Chapitre 4. Architecture reconfigurable traitement de pixels codés sur 8 bits et avec les voisinages 3 3, 5 5 et 7 7 cela veut dire × × × 6, 4 et 2 unités de traitement par entrée de 8 bits.

Par contre pour des algorithmes en mode bit-série nécessitant plusieurs passages a` travers les plans de bits, on peut choisir la taille horizontale de la fenêtre Fx (en gardant toujours Fy = Vy) de fa¸con a` ce que le débit de pixels traités soit toujours le même, quelque soit le nombre de passage a` effectuer. Nous avons donc Fx = r n, ou` r indique le rang recherché. ∗

~~4.2.2 Description de la m´emoire locale destination~~

Il est possible de spécifier la mémoire locale destination de fa¸con similaire a` la mémoire locale source. Le nombre de registres en jeu est cependant plus petit en raison de l’effet de bord lié au calcul dans un voisinage. En effet, lorsque la taille verticale de la fenêtre correspond a` la taille verticale de voisinage (Fy = Vy), le nombre de pixels de la fenêtre filtrée est donné par :

~~N = Fx (Vx 1) F˜ − − = F˜x (4.6)~~

La mémoire locale destination est représentée schématiquement a` la Figure 4.8. Elle est com- posée donc de F˜x registres a` décalage de b bits. Ces registres sont chargés en mode série, mais il peuvent être lus en parallèle pour un transfert vers la mémoire tampon.

~~Image~~

~~Vx-1 Vx-1~~

~~Fi-1~~

~~Vy-1 Fi-1 Fi Fi+1 Fy~~

~~Vy-1 Fi+1~~

Fig. 4.7: Déplacement de la fenêtre dans la direction horizontale (les fenêtres successives sont marquées en trait plein) ou verticale (en trait interrompu) et recouvrement des pixels de deux fenêtres différentes duˆ a` l’effet de bord.

~~138 4.2. M´emoire locale des unit´es de traitement~~

La mémoire tampon, notée tmp, est composée de F˜x registres a` chargement et a` sortie pa- rallèle. A leur entrée apparaissent soit les valeurs des pixels en provenance des registres a` décalage, soit ceux situés immédiatement avant (les multiplexeurs représentés a` la Figure 4.8).

Lorsque le dernier bit de traitement (le bit de poids le plus faible) est arrivé dans la ligne de registres a` décalage, le contenu de ces registres est copié vers la mémoire tampon (signal CopyLineOut a` la Figure 4.6). Les pixels traités sont ensuite transférés vers la mémoire destination globale, au rythme d’horloge Clk et en même temps que le chargement d’une nouvelle ligne de la fenêtre.

~~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émoire locale destination : la matrice de registres a` décalage et la mémoire tampon de sortie.~~

La mémoire source locale, la matrices des unités de traitement et la mémoire destination locale fonctionnent donc en mode pipe-line. Après un temps de latence lié au chargement et le calcul de la première fenêtre (négligeable 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ée a` la sortie (notons qu’à la sortie on aura Fx valeurs effectives, mais ce sont les premières F˜x valeurs a` prendre en compte).

~~4.2.3 Validation de la description~~

Les deux mémoires locales que nous venons de voir ont été formellement décrites en utilisant le langage de description matérielle VHDL. Afin de faciliter la conception des différentes configurations possibles, cette description fait appel a` la génération automatique d’un nombre variable d’instances des différentes parties constitutives de la matrice.

~~Pour une m´emoire locale source il s’agit de :~~

~~139 Chapitre 4. Architecture reconﬁgurable~~

– Fx instances de registres a` décalage, a` chargement et a` sortie parallèle (mémoire tampon), – Fx instances de registres a` décalage, a` chargement parallèle/série et a` sortie série, – Fx (Fy 1) instances de registres a` décalage, a` chargement et a` sortie série. ∗ − Ici, au lieu de créer explicitement chacune des instances, la fonction generate, imbriquée dans les boucles for, a été utilisée pour définir les différentes structures répétitives (voir [IEE00]). Dans cette description Fx, Vy, F˜x, et b apparaissent alors comme des paramètres a` fixer au début du processus d’implémentation.

Une telle approche permet d’automatiser entièrement le processus de génération de la description formelle des deux types de mémoires pour les différentes tailles de fenêtre et en fonction du nombre de bits utilisés pour coder la couleur d’un pixel.

La validation de la description de deux types de mémoires a été faite en simulant le processus de chargement et d’exploitation d’une fenêtre F de l’image a` traiter. La simulation en question a été réalisée a` l’aide du logiciel ModelSim (pour plus de détails techniques concernant le flot de conception utilisé, voir Section C.1 de l’Annexe C).

Plusieurs configurations de la matrice en termes de taille et de nombre de bits utilisés pour coder la couleur du pixel ont été réalisées et testées. Nous présentons ici les résultats d’une seule simulation, qui pour des raisons de clarté de l’exposé a été limitée a` une fenêtre de seulement 9 par 3 pixels, codés sur 4 bits.

~~Les valeurs des pixels de la fenêtre utilisée sont indiquées 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être utilisée pour la simulation, exprimées en binaire et leurs équivalents décimaux par plans de bits calculés selon l’Equation´ 4.7~~

La première partie du tableau montre les différentes valeurs des pixels de la fenêtre considérée, codés en binaire avec le bit de poids le plus fort a` gauche. Afin de faciliter la lecture des données sur le bus de sortie, celui-ci a été organisé de la fa¸con suivante : on considère b Fx mots de w ∗ Fy bits notés M [j] et calculés en fonction des différents plans de bits de la fenêtre 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ème partie du Tableau 4.1 (les quatre dernières lignes) on donne les équivalents décimaux des différents plans de bits en utilisant ce codage particulier.~~

La Figure 4.9 montre le chronogramme de fonctionnement de la mémoire locale source obtenu pour la fenêtre décrite. On constate qu’à 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ère ligne de la deuxième partie du tableau, le plan de bits w = 0, peuvent être lues a` l’instant indiqué t1, la deuxième (plan de bits w = 1) a` l’instant t2 et ainsi de suite.

~~4.2.4 Impl´ementation~~

Après la validation de la description il est possible de passer a` l’étape de placement et de routage du circuit afin d’obtenir d’une part la quantité réelle de ressources logiques employées - Qr exprimée en nombre de tranches occupées et d’autre part la vitesse maximale de circuit. A ce stade-ci, le processus d’implémentation a été effectué avec une méthodologie qui privilégie le faible temps de calcul de la solution et non la qualité du circuit obtenu (pour plus de détails concernant les différentes méthodologies d’implémentation utilisées, voir Annexe D, Section D.2). Il s’agit donc plutôt d’un indice de performance car les résultats pourraient a priori être améliorés, au détriment d’un temps d’implémentation plus long, ce qui sera fait lors de l’intégration du système complet (voir Section 4.4).

Les résultats d’implémentation pour une mémoire locale source dans un FPGA de densité moyenne sont indiqués dans le Tableau 4.2. Le modèle de FPGA utilisé est un xc2v2000-6 avec une matrice de 56 48 CLEs, ce qui équivaut donc a` 10.752 tranches. ×

Pour une même taille verticale de fenêtre Fy = Vy = 7, on montre les résultats pour différentes tailles de Fx (la troisième colonne du tableau indique le nombre de pixels NF dans la fenêtre). Pour quelques Fx choisis arbitrairement on donne : – la quantité des ressources logiques Qr obtenue après l’implémentation exprimé en nombre de tranches, – le pourcentage d’occupation du circuit FPGA cible, – la fréquence maximale du signal d’horloge - FClk, – le temps de calcul machine lié au placement et le routage - tpar .

~~En ce qui concerne la mémoire locale destination, les résultats sont semblables étant donné que son architecture ne diffère guère de celle de la mémoire 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émoire locale source pour une fenêtre de Fx = 9, Fy = 3 pixels codés sur 4 bits pour les données 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ésultats de l’implémentation d’une mémoire locale source pour différentes tailles de fenêtre a` traiter : quantité réelle 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ée la configuration particulière des mémoires locales, la quantité de ressources logiques mobilisées pour un FPGA de moyenne densité est tout a` fait acceptable, permettant l’implémentation :

– soit d’un faible nombre de fenêtres larges (Fx grand), lorsque le traitement vise plusieurs passages a` travers les différents plans de bits, – soit d’un grand nombre de fenêtres étroites (Fx petit), lorsque le traitement ne vise qu’un seul passage dans les plans de bits.

2. La vitesse de fonctionnement de la mémoire des opérandes est élevée, permettant d’importants débits de pixels traités malgré une méthodologie d’implémentation privilégiant le temps de calcul par rapport a` la qualité de circuit obtenue. Nous avons donc un système a` haut débit de traitement, pour autant que les unités de traitement puissent suivre.

3. La diminution de la vitesse de fonctionnement due a` l’accroissement de la taille de la fenêtre est faible, ce qui garanti des performances semblables lors d’une éventuelle parallélisation plus massive.

~~143 Chapitre 4. Architecture reconﬁgurable~~

~~4.3 Unit´es de traitement~~

~~Les différentes unités de traitement qui seront décrites se basent sur deux algorithmes fonctionnant en mode bit-série.~~

Le premier algorithme exposé permet de trouver la valeur maximale, et avec très peu de modifications la valeur minimale, dans un voisinage de NV pixels. Cet algorithme est ensuite adapté pour le filtre de rang généralisé, calculé par élimination successive des maxima/minima locaux de voisinage.

Le deuxième algorithme utilisé est celui de Danielsson déjà exposé dans la Section 4.2.4.1. Même si cet algorithme est connu depuis 1981, son implémentation dans des architectures dédicacées n’a visé que sa variante simplifiée pour le calcul de filtre médian sur un voisinage 3 3. Ici nous présenterons son implémentation généralisée, pour les différents voisinages × envisagés et pour n’importe quelle valeur de rang r.

~~Nous commencerons par des explications détaillées d’algorithmes, avant de passer a` la conception des unités de traitement correspondantes et leur implémentation.~~

~~4.3.1 Algorithmes~~

~~4.3.1.1 Algorithme Max~~

~~Considérons une fenêtre F de l’image a` traiter I et un voisinage V au sein de cette fenêtre, composé de NV pixels :~~

V = V [0], V [1], . . . , V [NV 1] (4.8) { − } Tous les pixels du voisinage sont codés sur b bits. La valeur de la couleur des pixels est exprimée en binaire : le bit de poids w, de pixel m de V sera noté 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érents pixels pour ce même poids, deux situations différentes 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ésultat aura pour le bit de ce poids la même 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érents :

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ération 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é uniquement des pixels de V dont le bit du poids précédant, b 1 en − l’occurrence, valait ’1’.

Le même procédé de comparaison des bits est ensuite appliqué a` ce nouveau plan de bits P BV b 2 pour obtenir le bit de poids b 2 de résultat. − − L’algorithme est exécuté de fa¸con itérative jusqu’à obtention du dernier plan de bits P BV 0 et du bit de poids 0 de résultat.

Le pixel, ou les pixels (car il est possible que plusieurs pixels aient la même valeur de niveau de gris au sein d’un même voisinage), qui n’a (n’ont) pas été exclu(s) au bout de b itérations sera le maximum du voisinage V .

L’algorithme ressemble a` l’algorithme de tri par classement déjà mentionné (voir Section 2.2.1.7) en ce sens que les valeurs de voisinages sont distribuées dans des groupes. La principale différence est qu’ici le nombre de groupes est limité a` deux : le groupe des candidats potentiels et le groupe des valeurs certainement plus petites que les candidats potentiels. Une autre différence réside dans le fait qu’il n’existe pas de phase de recherche de la valeur après 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 également faire le rapprochement entre cet algorithme et celui de binary refinement utilisé pour le calcul des filtres de piles (voir Section 3.2.5). Même si pour ces deux algorithmes nous avons le nombre de pas de calcul égal a` b, pour les filtres de piles il faut

~~145 Chapitre 4. Architecture reconﬁgurable~~

b 1 effectuer la threshold decomposition au préalable et sauvegarder les 2 − bits pour chaque pixel de voisinage. De ce fait l’unité de traitement correspondante nécessitera une importante quantité de ressources logiques limitant ainsi sa performance de traitement.

La Figure 4.10 illustre les différentes étapes du calcul de la valeur maximale pour un exemple concret de filtrage d’un voisinage 3 3. Le voisinage est d’abord transformé en 8 plans de 9 × bits chacun, notés P BV 7 a` P BV 0. Pour chaque plan des bits les cellules grisées représentent les pixels a` exclure dans l’itération suivante et les cellules noires les pixels déjà exclus dans les itérations précédentes. On montre également la construction du mot de résultat au fur et a` mesure que l’on avance dans le traitement des différents plans de bits.

~~4.3.1.2 Algorithme Min~~

~~L’algorithme de calcul d’un filtre Max exposé peut être adapté au calcul des filtres Min de plusieurs fa¸cons différentes.~~

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ésente néanmoins un petit inconvénient : la description de l’unité de traitement change fortement, ce qui impliquerait d’importantes modifications de l’unité de traitement existante.

Une autre approche nous permet d’arriver au filtre Min, mais sans devoir passer par des modifications importantes de l’unité de traitement Max. Pour calculer le filtre Min on peut aussi tout simplement calculer un filtre Max sur les plans de bits inversés car nous avons :

~~min(A, B) = max(A, B) (4.13) ou` A et B désignent les compléments de A et B (l’application d’un NON logique bit a` bit). En effet pour les deux mots A et B codés 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éthode pour le calcul du filtre Min ne modifie en rien la quantité des ressources logiques nécessaires pour la réalisation d’une unité de traitement, comme nous allons le voir dans la Section 4.1.2.

~~4.3.1.3 Algorithme pour le filtre généralisé~~

Algorithme d’élimination successive des maxima/minima locaux L’algorithme exposé pour le calcul d’un filtre Max/Min peut être utilisé pour le calcul d’un filtre de rang généralisé. En effet, en éliminant successivement NV r maxima (ou r minima) − 146 4.3. Unités 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ême principe que pour l’algorithme utilisé pour les architectures universelles, exposé dans la Section 2.2.2). L’élimination des différents maxima locaux de V est faite en rempla¸cant sa valeur dans le voisinage par ’0’.

Pour illustrer ceci on peut prendre le même exemple de voisinage que celui utilisé 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 éliminés, respectivement 182, 182, 175 et 175 la valeur médiane (174) est trouvée, comme le Max de voisinage résultant : V = 174, 129, 0, 0, 0, 139, 0, 130, 131 . { } Lorsque dans le voisinage il existe plusieurs maxima locaux (dans l’exemple considéré 182, 182 et 175, 175), il faut donc compter le nombre de pixels éliminés.

Si une telle modification d’algorithme nous permet d’arriver rapidement a` une architecture qui calcule le filtre de rang généralisé, sa performance dépendra de la valeur du rang r et de la taille de voisinage considérée. C’est ici que le choix de la taille horizontale de la fenêtre joue un rôle 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éservant le débit des pixels traités. Comme le système est reconfigurable et comme la mémoire 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ême nombre de pixels quel que soit la valeur de rang recherchée (ceci sera abordé de fa¸con plus détaillée dans la Section 4.4.).

Algorithme de Danielsson Si l’emploi de l’algorithme d’élimination successive des maxima/minima locaux peut être 8 justifié lorsque NV est petit et r est petit ou grand , il n’en est pas de même pour des voisinages plus grands et des rangs proches du médian. En effet, la quantité de ressources logiques mobilisée pour préserver le débit de pixels traités devient trop importante.

Pour la conception de l’unité de traitement nous allons cependant modifier quelque peu l’algorithme exposé. 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ésultat de la comparaison sera utilisé pour choisir la valeur de bit de résultat pour ce poids, pour décider 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é, mais dans un voisinage masqué, de la même fa¸con comme que pour les filtres Max/Min. Le nombre des ’0’ est alors calculé comme étant la différence entre le nombre de pixels dans le voisinage qui n’ont pas encore été exclus et le nombre des ’1’ dans le voisinage masqué.

Considérons les différents 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érations suivantes :

8En fonction de la valeur de rang recherchée on choisira l’élimination des maxima ou des minima locaux. Ainsi si le rang est proche de NV on choisira d’éliminer les maxima et si par contre il est proche de 1, alors on choisira d’éliminer les minima.

~~148 4.3. Unit´es de traitement~~

~~1. Calculer le voisinage masqué, noté P BV M comme un ET logique (noté ) entre le · registre de masque a` l’itération 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ésigne le nombre de pixels dans le voisinage n’ayant pas encore été exclus. Au début nous avons bien entendu np = NV . 4. Calculer la valeur de n :~~

w n = n + n1 , si la valeur de résultat valait ’0’ n = n nw, si la valeur de résultat valait ’1’ (4.17) − 0 Avant de calculer le premier plan de bits le résultat est mis a` ’0’ de fa¸con a` ce que dans w la première itération on calcule : n = n + n1 , avec n qui au départ 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ération suivante, – mettre a` jour le nombre de pixels dans le voisinage masqué : 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ération suivante, – mettre a` jour le nombre de pixels dans le voisinage masqué : np = np nw. − 1 Pour le même exemple de voisinage utilisé pour le filtre Max, le Tableau 4.3 indique les différentes étapes du calcul d’un filtre médian sur un voisinage 3 3. ×

~~4.3.2 Description de l’unit´e de traitement pour les ﬁltres Max/Min~~

La description de l’algorithme Max/Min met clairement en évidence trois parties distinctes de l’unité de traitement : 1. Construction des plans de bits masqués. 2. Calcul de la condition de mise a` zéro du masque. 3. Calcul de la valeur filtrée.

~~Nous allons maintenant formaliser chacune de ces trois parties.~~

~~149 Chapitre 4. Architecture reconﬁgurable~~

~~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érentes étapes de calcul, plan de bits par plans de bits, du filtre médian 3 3 avec l’algorithme de Danielsson. × 1. Construction des plans de bits masqué b 1 0 La construction des différents plans de bits : P BV − , . . . , P BV , a` partir d’un voisinage V est faite a` l’aide de la mémoire locale - la matrice des registres a` décalage dont la description a été donnée dans la Section 4.2.

L’exclusion des mots dans le voisinage peut être faite a` l’aide d’un mot de ”masque“, noté M, de NV bits, associé a` chaque voisinage V de la fenêtre F en cours de traitement. Chaque bit de ce mot M est associé a` un pixel particulier de voisinage V . Ainsi, le bit marqué 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é : P BV M w le résultat w b w d’un ET logique, bit a` bit, entre le mot P BV et le mot M − , au moment de l’itération 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érations 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érents états de M seront noté M 1, M 2, . . . M b avec l’état M 1 qui correspond a` l’état initial et l’état M b a` l’état de mot de masque après le traitement de tous les plans de bits. Les bits de mots de masque après 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ôle. Lorsque la forme du voisinage change, pour ne plus être l’habituel carré, il suffit, lors de la phase d’initialisation, de placer dans le

~~150 4.3. Unités 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ès le départ.~~

2. Calcul de la condition de la mise a` zéro du masque Les différents états 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égalité entre les bits.

Pour déterminer s’il y a une inégalité entre les bits il est plus simple de partir de la condition d’égalité. Tous les bits d’un plan de bits masqué P BM w seront égaux 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ée Le bit de résultat pour le poids w peut être calculé comme un OU logique (noté +) des différents bits de plan de bits masqué 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 suﬃt 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éma fonctionnel d’une unité de traitement pour les filtres Max/- Min. Elle est composée de NV mémoires d’un bit (marquées M[0], . . . , M[NV 1]) et d’une − logique combinatoire permettant de calculer les fonctions décrites : – Resultat - le résultat du filtrage, – NEqu - la non-égalité, – ResetM - la mise a` zéro des mémoires.

~~151 Chapitre 4. Architecture reconﬁgurable~~

~~Le signal InitM sert a` initialiser le registre de masque M lors de la première itération. Dans le cas d’un voisinage carré, le mot M est tout entier constitué des ’1’.~~

Chaque plan de bits en provenance de la mémoire source locale - la matrice de registre a` décalage - apparaˆıt sur le bus P BV . Le plan de bits est ensuite masqué (le bus P BV M). Sur le plan de bits masqué on calcule ensuite les fonctions logiques F 1 et F 2 (l’équation 4.23). En utilisant ces deux fonctions intermédiaires on calcule : le résultat de filtrage pour le plan de bits w - Result, la variable NEqu et les conditions de mis a` zéro 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éma fonctionnel d’une unité de traitement pour le filtre Max en mode bit-série.~~

Pour le filtre Min, les entrées des portes ET utilisées pour le calcul du plan de bits masqué du voisinage sont précédées par des inverseurs : on modifie l’équation 4.18 utilisée pour le calcul du plan de bit masqué :

~~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émoires des CLEs, par ailleurs déjà utilisées pour le calcul d’un ET logique entre les bits du plan et le mot de masque, l’ajout

~~152 4.3. Unités de traitement de ces inverseurs ne changera donc rien quant a` la quantité de ressources logiques nécessaires a` la réalisation d’une unité de traitement 9.~~

~~4.3.3 Description de l’unité de traitement pour le filtre de rang généralisé~~

~~4.3.3.1 Algorithme d’´elimination successives des maxima/minima locaux~~

Pour la réalisation d’une unité de traitement basée sur l’algorithme d’élimination successive des maxima/minima locaux on part de la même description donnée pour l’unité de traitement Max/Min. Selon l’algorithme décrit (voir la Section 4.1.1.3) a` celle-ci il faut ajouter :

1. un nouveau mot de masque, de NV bits, permettant d’exclure du voisinage V les maxima/minima locaux un par un, 2. un module permettant de sélectionner un seul maxima/minima local parmi ceux trouvés, après chaque cycle de b itérations.

Le nouveau mot de masque sera noté MM w. Comme pour le mot M, tous les bits du mot MM sont, au début de traitement mis a` ’1’ de fa¸con a` ce que tous les pixels du voisinage soient pris en compte (le signal noté InitMM).

~~L’introduction de ce nouveau mot de masque implique quelques modifications des équations données pour l’unité de traitement Max/Min.~~

~~Ainsi, le plan de bits masqué (l’équation 4.18 pour l’unité 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éro du mot de masque M (l’équation 4.21 pour l’unité 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éro des bits de masque MM, elle n’aura lieu qu’après le traitement de tous les plans de bits (ce qui sera marqué par un signal ResetMM) et pour une seule valeur de maxima/minima local.

Comme après une itération complète 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é vaut ’1’. Pour ce faire, nous

9Comme le nombre de variables reste le même, c’est le même nombre de LUT s qui sera nécessaire pour le calcul de plan de bit masqué, dans les deux cas. La seule chose qui change est la table de vérité, 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é sur le mot M. Les sorties de cet encodeur, notées sous forme d’un vecteur P de NV bits, sont calculées 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é pour définir la mise a` zéro 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éma fonctionnel de l’unité de traitement pour le filtre Max/Min, modifié pour le calcul du filtre de rang généralisé. On remarquera l’ajout d’un nouveau mot de masque MM et de l’encodeur de priorité 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éma fonctionnel d’une unité de traitement pour le filtre généralisé en mode bit-série (l’algorithme d’élimination des Maxima/- Minima locaux).~~

~~4.3.3.2 Algorithme de Danielsson~~

~~La description de l’algorithme de Danielsson met en évidence les différentes parties d’une unité de traitement : 1. Calcul du voisinage masqué 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é : n1 Pour calculer le nombre de ’1’ dans le voisinage masqué nous allons utiliser NVx circuits additionneurs de NVy opérandes d’un seul bit. On calculera d’abord le nombre de ’1’ par colonnes, le résultat final étant obtenu en sommant le nombre de ’1’ des différentes colonnes. De cette fa¸con et pour des voisinages successifs lors d’une parallélisation on évitera de répéter inutilement le calcul du nombre de ’1’ par colonne. Le nombre de ’1’ est codé 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ésultat obtenu pour le plan de bits précédant 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éro, b ainsi que le résultat 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ésultat de la comparaison de n avec le rang r donne la valeur du résultat 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ésultat courant vaut ’1’ nous allons soustraire de nombre de pixels dans le voisinage np le nombre des ’0’, sinon le nombre de ’1’ calculé pour ce plan de bits.

7. Calcul de la nouvelle valeur de masque M Si le résultat 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é de traitement correspondante a` l’algorithme de Danielsson se montre plus complexe que les deux unités de traitement envisagées précédemment, principalement a` cause de la présence de plusieurs circuits arithmétiques. Mais du fait des ressources logiques dédicacées a` l’arithmétique du FPGA et du faible nombre de bits codant les mots n0, n1, n et np on peut néanmoins espérer une implémentation efficace.

~~155 Chapitre 4. Architecture reconﬁgurable~~

~~La Figure 4.13 montre le schéma fonctionnel d’une unité de traitement pour le filtre de rang généralisé 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éma fonctionnel d’une unité de traitement pour le filtre généralisé en mode bit-série (algorithme de Danielsson).~~

~~4.3.4 Validation de la description~~

Les différentes unités de traitement proposées ont été décrites en langage VHDL pour une implémentation dans un circuit FPGA. Les différentes configurations de l’unité de traitement sont obtenues a` partir d’une même description de circuit de fa¸con a` ce que : le nombre de bits utilisés pour coder la couleur du pixel, le type de filtre (Min ou Max dans le cas d’une unité de traitement spécifique et la valeur de rang dans le cas d’une unité de traitement généralisé) ainsi que la taille de voisinage apparaissent comme des paramètres d’implémentation.

Dans un premier temps la description des unités de traitement a été validée pour un exemple concret : le réalisation d’une unité de traitement permettant de calculer la valeur maximale, minimale et médiane d’un voisinage de 3 3, 5 5 et 7 7 pixels codés sur 8 bits. Nous × × × présentons ici les résultats de la simulation pour le voisinage 3 3. Les résultats de la validation × pour des voisinages de 5 5 et 7 7 pixels peuvent être trouvés dans la Section C.2 de l’Annexe × × C.

Le voisinage utilisé pour la simulation est le même que celui utilisé chaque fois jusqu’ici : V = 174, 129, 182, 175, 175, 139, 182, 130, 131 , a` quoi correspond le voisinage trié : 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écrit, exprimées en binaire. La valeur binaire de chaque pixel peut être 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ère colonne indique la valeur décimale 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é pour la simulation : valeurs des pixels × et des plans de bits correspondants (en binaire et en décimal). La dernière ligne indique la valeur de rang pour chaque pixel.

~~157 Chapitre 4. Architecture reconﬁgurable~~

La Figure 4.14 montre le chronogramme de fonctionnement de l’unité de traitement Max et Min obtenu pour le voisinage décrit. Après la phase d’initialisation du registre de ”masque“, on peut voir l’évolution du calcul du résultat suite au traitement des 8 plans de bits successifs. Les résultats obtenus par simulation correspondent aux valeurs de Max et de Min du voisinage considéré.

~~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é de traitement calculant les filtres Max a) et Min b), pour un voisinage de 3 3 × pixels codés sur 8 bits.~~

La Figure 4.15 montre le chronogramme de fonctionnement de l’unité de traitement pour le filtre généralisé. Le processus d’élimination, ici des maxima locaux (c’est l’unité de traitement Max qui a été utilisée), a été arrêté après quatre itérations de fa¸con a` ce que la valeur maximale représente la médiane de V (la valeur 174). Signalons l’évolution de l’état du registre de deuxième 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é de traitement calculant le filtre médian par élimination, pour un voisinage de 3 3 pixels codés sur 8 bits. ×

La Figure 4.16 montre le chronogramme de fonctionnement de l’unité de traitement pour le filtre généralisé basé sur l’algorithme de Danielsson. Mis a` part la valeur de résultat (signal Resultat) on montre également la valeur de masque (signal Mask) et le nombre de ’1’ (signal NOnes). Le tableau de la même figure indique les différents calculs liés au traitement des différents plans de bits.

~~4.3.5 Impl´ementation~~

La description des circuits décrits est validée a` travers le processus de simulation pour un ensemble de vecteurs a` l’entrée différents (en fait des voisinages), ce qui nous permet de passer au processus d’implémentation proprement dit. Après l’implémentation nous serons en mesure de caractériser la performance du circuit réalisé en termes de quantité des ressources logiques nécessaires et de vitesse du circuit obtenu. Signalons qu’à ce stade les résultats présentés sont obtenus avec une méthodologie d’implémentation qui favorise un temps d’implémentation rapide plutôt que la qualité du résultat obtenu. Pour plus de détails techniques concernant cette méthodologie voir Section C.1 de l’Annexe C.

Les résultats de l’implémentation concernent le même circuit FPGA que celui utilisé pour l’implémentation de la mémoire locale. Pour rappel il s’agit du circuit portant la référence xc2v2000-6 dont les ressources logiques comptent 10752 tranches.

~~159 Chapitre 4. Architecture reconﬁgurable 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é de traitement calculant le filtre médian par l’algorithme de Danielsson, pour un voisinage de 3 3 pixels codés sur 8 bits. × 160 4.3. Unités de traitement

~~4.3.5.1 Unit´e de traitement bas´ee sur l’algorithme Min/Max~~

Le Tableau 4.5 indique les résultats de l’implémentation, obtenus pour une unité de traitement d’un filtre Max. Les résultats sont les mêmes pour une unité 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ésultats de l’implémentation pour une seule unité de traitement (filtre Max/Min) pour les trois voisinages envisagés. Circuit FPGA : xc2v2000-6.~~

Le Tableau 4.6 montre les résultats de l’implémentation pour une unité de traitement calculant le filtre de rang généralisé par l’algorithme d’élimination 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ésultats d’implémentation pour une seule unité de traitement (filtre généralisé obtenu par élimination des maxima/minimas locaux) pour les trois voisinages envisagés. 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ésultats de l’implémentation obtenus pour une seule unité 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ésultats de l’implémentation pour une seule unité de traitement (filtre généralisé par algorithme de Danielsson) pour les trois voisinages envisagés. Circuit FPGA : xc2v2000-6.

~~161 Chapitre 4. Architecture reconﬁgurable~~

~~4.3.5.3 Discussion~~

~~La quantification de la performance des différentes unités de traitement nous permet de faire des conclusions importantes suivantes :~~

– Ressources logiques Les unités de traitement, même lorsqu’elle calculent des filtres sur des voisinages de grande taille, nécessitent une faible quantité de ressources logiques par rapport a` la quantité des ressources logiques disponibles au sein d’un circuit FPGA. Nous pouvons donc compter sur un parallélisme de grain très fin, même pour des FPGAs de moyenne densité.

– Performance Même si la vitesse de fonctionnement des circuits est faible, comparée a` la vitesse des microprocesseurs actuels, le pipe-line de traitement et un grand nombre d’unités de traitement potentiellement réalisables au sein d’un même circuit FPGA annoncent la possibilité de traitement a` très haut débit.

– Optimisation En imposant des contraintes d’implémentation plus sévères et en for¸cant le logiciel de placement et de routage a` chercher une solution plus optimale, on peut espérer arriver a` des circuits plus rapides et donc a` des débits de traitement plus importants.

Bien entendu lors de l’implémentation de plusieurs unités de traitement au sein d’un même FPGA, la quantité des ressources logiques utilisée et la performance dépendront du nombre d’unités effectivement réalisées. Si l’augmentation du nombre d’unités de traitement a pour corollaire la diminution de la performance, une méthodologie d’implémentation qui vise la performance aura elle, la tendance inverse. La quantification des résultats de l’implémentation nous permettra dans ce cas de déduire le débit réel des pixels traités par le système reconfigurable, pour différents algorithmes et pour différents voisinages envisagés. Les aspects de la multiplication du nombre d’unités de traitement et leur implémentation sous fortes contraintes feront l’objet de la Section suivante.

~~162 4.4. Syst`eme reconﬁgurable complet~~

~~4.4 Syst`eme reconﬁgurable complet~~

~~4.4.1 Description du syst`eme complet~~

Les différentes parties constitutives du système reconfigurable étant décrites et leur fonctionnement vérifié, nous pouvons a` présent passer a` l’intégration du système complet. Plu- sieurs configurations du système sont possibles quant a` la manière d’écrire et de lire les données dans les mémoires locales. Le choix d’une configuration particulière est a` faire en fonction de l’architecture du matériel utilisé pour son implémentation. Signalons toutefois que du fait de sa description paramétrable, le changement de configuration du système reconfigurable décrit n’implique que des modifications mineures par rapport a` la description existante. Ainsi, le système proposé peut être adapté a` un matériel autre que celui que nous allons présenter ici.

Dans ce qui va suivre nous allons présenter une configuration particulière de notre système reconfigurable, adaptée a` une carte existante et destinée a` la conception des systèmes reconfigurables en général. Il s’agit de la carte Alpha Data ADP-WRC-II, déjà mentionnée dans la Section 4.1. L’avantage de cette carte, outre le fait qu’elle peut accueillir un circuit FPGA de haute densité, est qu’elle dispose de deux mémoires DDR-SDRAM, addressables de fa¸con indépendante et d’une largeur de 256 bits. Une telle architecture permet donc d’arriver a` de très hauts débits de transfert de données entre le circuit FPGA et les deux mémoires.

Au sommet de la hiérarchie du système reconfigurable complet on trouve n modules de traitement identiques. Chaque module possède une mémoire source locale permettant la sauvegarde d’une fenêtre a` traiter de Fx Vy pixels. A cette mémoire sont associés F˜x unités de traite- × ment et une mémoire destination locale permettant la sauvegarde de F˜x pixels traités. Chaque module re¸coit un flux de données a` travers un bus de 8 bits (DataIn). Les données traitées apparaissent sur un autre bus, lui aussi d’une largeur de 8 bits (DataOut).

La mémoire source locale, les unités de traitement et la mémoire destination locale fonctionnent en pipe-line. Ainsi, pour chaque nouveau chargement d’une ligne de la fenêtre a` traiter de Fx pixels, le système sort en même temps la fenêtre traitée, en fait une ligne de F˜x pixels.

Le nombre de modules de traitement a` réaliser au sein d’un même circuit FPGA sera limité par la largeur du bus de données sur lequel est placé le système reconfigurable d’une part et par les ressources logiques nécessaires pour la réalisation de chaque module d’autre part.

Pour l’exemple de la carte considérée, les deux bus de données étant de 256 bits, nous pouvons donc réaliser au maximum 32 modules de traitement. En ce qui concerne la quantité exacte des ressources logiques nécessaires pour la réalisation d’un module complet, elle sera déterminée après son implémentation. Néanmoins sur base de l’information de la quantité des ressources logiques disponibles dans le FPGA, nous pouvons déduire la quantité 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és de traitement basées sur l’algorithme Max/Min et celui de Danielsson peuvent travailler

163 Chapitre 4. Architecture reconfigurable sur des fenêtres de taille plus petite que celle basée sur l’algorithme par élimination10, tout un préservant le haut débit de traitement, ce sont elles qui vont être retenues pour cette implémentation particulière.

L’image a` traiter est sauvegardée dans la mémoire source globale (une mémoire physique de la carte) et découpée en 32 bandes de largeur fixe. A chaque bande est associé un module de traitement. Les bandes présentent un recouvrement de Vx 1 pixels permettant de calculer − les pixels au bord de la bande. Une adresse de la mémoire source correspond donc a` 32 pixels, chacun appartenant a` l’une de 32 bandes de l’image.

Chaque bande est a` son tour découpée en fenêtres de traitement qui, elles aussi, représentent un recouvrement de Vx 1 pixels. Pour l’image traitée nous avons une situation semblable, le − premier pixel de l’image résultat est sauvé 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érieure de l’image .

La Figure 4.17 montre le principe de la sauvegarde de l’image a` traiter dans la mémoire source globale (Mém.1), le découpage de l’image en bandes, l’association de différents modules de traitement pour chaque bande et l’écriture des bandes traitées dans la mémoire destination globale (Mém.2).

Une telle fa¸con de lire les données dans la mémoire globale source peut être réalisée au stade de l’écriture de l’image a` traiter, ou lors de sa lecture pour le traitement. Signalons que d’autres schémas de lecture/écriture de données depuis la mémoire globale sont également possibles, notre choix s’est porté sur celui-ci car il permet de maximiser le nombre de pixels traités pour l’architecture adoptée du système 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éer un certain nombre d’instances des différentes parties constitutives du système reconfigurable. Pour déterminer le nombre d’instances, a` savoir le nombre de registres de la mémoire locale source, le nombre d’unités de traitement correspondant et le nombre de registres de la mémoire locale destination, il faut fixer la taille de la fenêtre de traitement.

Pour ce qui est de la taille verticale de la fenêtre, lorsque la lecture des données de l’image (en fait de la bande) est faite pixel par pixel, et ligne par ligne, nous avons montré que le fonctionnement de pipe-line de traitement est optimal lorsque Fy = Vy (voir Section 4.2). Par

10Dans le cas d’une unité de traitement basée sur l’algorithme par élimination, pour préserver le débit des pixels traités (à chaque cycle d’horloge nous avons un pixel entrant et un pixel sortant du système) il faut avoir une fenêtre de traitement suffisamment large. En effet, comme nous l’avons remarqué 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é des FPGAs actuels nous permet d’imaginer une implémentation des modules de traitement basé sur l’algorithme par élimination travaillant sur des fenêtres très larges, c’est le nombre de modules qui sera fortement limité. 11En fait les pixels au bord de l’image ne sont pas calculés. L’image résultat présente un bord d’une épaisseur 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és, ce bord a une épaisseur de 1, 2 et 3 pixels respectivement.

~~164 4.4. Syst`eme reconﬁgurable 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ème reconfigurable complet : 32 modules de traitement. contre la taille horizontale de la fenêtre sera déterminée de fa¸con a` maximiser le nombre de pixels traités.~~

La taille horizontale de la fenêtre dépendra du nombre de pas de calcul : il faut que le nombre de pixels chargés soit au moins égal au nombre de pas de calcul a` effectuer. Lorsqu’il y a une égalité, nous avons alors un parfait équilibre entre le chargement des données a` traiter, le calcul sur ces données et la sauvegarde des résultats (il n’y aura pas d’attente ni du côté des unités de traitement ni du côté de la mémoire).

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être. Le deuxième facteur qui jouera un rôle important dans le choix de Fx est lié a` l’effet de bord lié au calcul dans une fenêtre. En sachant que pour chaque nouvelle ligne de la fenêtre, donc pour Fx pixels a` l’entrée, nous n’avons pas Fx pixels de résultat mais bien F˜x, car il existe une perte. En outre, pour déterminer le temps total de traitement, nous devons nous baser sur la quantité de pixels sortants (en fait ceux qui sont effectivement calculés) et non sur la quantité des pixels entrants, a` cause de l’effet de bord.

La perte de performance du système reconfigurable due a` l’effet de bord (redondance en lecture de données) peut être quantifiée a` travers un facteur de rendement du système reconfigurable,

165 Chapitre 4. Architecture reconfigurable noté η. Nous allons définir ce facteur comme un rapport entre le nombre de pixels effectivement calculés et le nombre de pixels qu’il faut charger dans la mémoire locale. Dans le cas d’un déplacement 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’équation 4.32, on voit que pour minimiser la perte due a` l’effet de bord (i.e. maximiser le rendement du système) nous avons intérêt de prendre Fx le plus grand possible. Pour se donner une idée de la valeur du rendement, la Figure 4.18 montre son évolution en fonction de la taille de la fenêtre Fx et pour différentes tailles envisagées de voisinages.

~~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érisant la perte de performance liée au calcul dans une fenêtre de taille proche de la taille de voisinage.~~

La taille horizontale de la fenêtre sera fixée 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éalisables au sein du FPGA d’autre part. En outre, on choisira Fx de fa¸con a` ce que 32 modules de traitement puissent être intégrés dans un seul FPGA de haute densité.

Ici il convient de préciser que la diminution de la vitesse de fonctionnement d’un module de traitement due a` l’augmentation du nombre d’unités de traitement, pour les ordres de grandeurs de Fx envisagés, n’est pas significative. Ainsi l’implémentation d’un module Max/Min pour le traitement sur un voisinage de 3 3 pixels lorsque la taille horizontale de la fenêtre × passe de 10 a` 20 pixels a montré une même vitesse de fonctionnement du module.

~~En fixant la taille de la fenêtre nous pouvons ensuite déduire tous les paramètres de la description du module nécessaires a` son implémentation.~~

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 reconﬁgurable complet~~

Pour la simulation du fonctionnement des différents modules nous utiliserons une fenêtre dont les valeurs de pixels varient de 1 a` Fx Fy, après quoi la dernière valeur est maintenue jusqu’à ∗ la fin de la simulation. Un cycle de simulation comprendra le traitement de trois fenêtres successives.

Le choix des valeurs de pixels a` traiter a été fait tout simplement pour la facilité que représente la spécification d’un tel stimulus a` l’entrée d’un module et la simplicité avec laquelle on peut interpréter les résultats obtenus (voir Figure 4.19). En effet, dans une première fenêtre de 10 3 pixels, les valeurs maximales des 8 voisinages correspondront a` des valeurs allant de 23 × a` 30 (à la Figure 4.19 les valeurs entourées d’un cercle de fond blanc), tandis que les valeurs médianes seront de 12 a` 19 (les valeurs entourées d’un carré de fond blanc). Pour le filtre Max, tous les pixels des deux fenêtres suivantes traitées auront la valeur de 30 (les valeurs entourées d’un cercle gris clair et gris foncé). Pour le filtre médian, les valeurs de la deuxième fenêtre iront de 22 a` 29 (les valeurs entourées d’un carré de fond gris clair), tandis que pour la troisième nous aurons 30 partout (les valeurs entourées d’un carré de fond gris foncé).

~~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êtres successives et le valeurs Max et médianes pour les différentes voisinages.~~

La Figure 4.20 a) montre le chronogramme de fonctionnement (généré par le logiciel de simulation) d’un seul module dont l’unité de traitement est basée sur l’algorithme Max/Min (en l’occurrence il s’agit d’un filtre Max). Après la phase de chargement de la mémoire source locale avec les valeurs de la première fenêtre a` traiter (mis en route du pipe-line de traitement), les 8 premiers pixels sortants ont bien la valeur maximale des différents voisinages, ainsi que les pixels résultats pour les deux fenêtres 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é pour la recherche de la valeur médiane. On remarque sur le bus de données de sortie que les 8 premières valeurs sont effectivement les valeurs médianes pour les trois fenêtres considérées.

Les résultats d’implémentation des deux modules de traitement, pour le circuit FPGA xc2v2000- 6 sont indiqués dans le Tableau 4.8. Le choix de la largeur de la fenêtre Fx a été fait de fa¸con a` ce que un module de traitement ne dépasse pas 1200 tranches de circuit FPGA12.

12Le choix de limiter un module a` 1200 tranches a été fait de fa¸con a` ce que les 32 modules réalisés dans le FPGA le plus dense, le circuit xc2v8000-5, ne dépasse 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 traitement obtenus par simulation pour un voisinage de taille 3 3 pixels. × 168 4.4. Système reconfigurable complet

Pour les différents modules et les voisinages ce tableau indique : – la taille de la fenêtre et le nombre d’unités de traitement correspondantes (Fx et NUT ), – la quantité de ressources logiques utilisées par module - Qr, exprimée en nombre de tranches, – la fréquence maximale de fonctionnement du circuit - FClk, – le temps nécessaire pour le placement et le routage - tpar.

~~La deuxième partie du tableau indique les résultats d’implémentation 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ésultats de l’implémentation d’un seul module de traitement (algorithmes Max/Min et Danielsson) pour les trois tailles de voisinages envisagées. Circuit FPGA : xc2v2000-6.~~

Les résultats de l’implémentation d’un seul module de traitement nous permettent de faire les deux remarques suivantes : 1. La quantité des ressources logiques nécessaires a` la réalisation d’un module complet est telle que l’on peut envisager de travailler avec les fenêtres suffisamment larges, permettant de minimiser le facteur de perte lié au calcul dans le voisinage. 2. La vitesse de fonctionnement d’un module reste élevée, malgré la multiplication des unités de traitement nécessaires au calcul simultané dans une fenêtre.

~~4.4.3 Etablissen´ t d’une correspondance entre ressources n´ecessaires et ressources disponibles~~

La quantité de ressources logiques nécessaires a` la réalisation d’un seul module nous permet d’estimer la quantité de ressources logiques nécessaires a` un système reconfigurable complet composé de 32 modules de traitement. Ces chiffres peuvent ensuite être mis en correspondance avec la quantité de ressources logiques disponibles dans des circuits FPGAs de haute densité.

Le graphique de la Figure 4.21 indique la quantité estimée de ressources logiques nécessaires a` l’implémentation de 32 modules différents, pour les deux types de modules et pour les trois tailles des voisinages envisagés. En ordonnée, on indique également la quantité des ressources logiques disponible pour les deux circuits FPGAs Xilinx de haute densité : xc2v6000 et xc2v8000 (respectivement 33.792 et 46.592 tranches).

~~169 Chapitre 4. Architecture reconﬁgurable~~

~~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é de ressources logiques nécessaires a` l’implémentation de 32 modules de traitement.~~

Nous pouvons constater que pour la réalisation de 32 modules de traitement travaillant sur une fenêtre dont la largeur permet de maximiser le nombre de pixels traités, l’implémentation du système reconfigurable complet peut être 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ésultats de l’implémentation obtenus pour un système reconfigurable complet, pour les deux stratégies d’implémentation différentes et pour le circuit FPGA xc2v8000-5. Pour la quantité de ressources logiques utilisées (exprimée en nombre de tranches), le chiffre entre parenthèses indique le pourcentage de l’occupation du FPGA, qui a été volontairement limité a` un maximum de 80 %.

De telles vitesses de fonctionnement du système reconfigurable complet impliquent la même performance pour la mémoire globale source et pour la mémoire globale destination. Comme cela a été montré dans [Gop04], une mémoire DDRAM peut être contrôlée avec un circuit FPGA a` une fréquence de 200MHz, ce qui est largement au dessus de ce qui est requis par le système reconfigurable.

~~170 4.4. Syst`eme reconﬁgurable 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ésultats de l’implémentation du système reconfigurable complet pour les trois tailles de voisinages envisagés. Circuit FPGA : xc2v8000. 4.4.5 Débit des pixels traités~~

Sur base de l’architecture adoptée pour le système reconfigurable complet, sur base de l’information de la vitesse de fonctionnement maximale (un pixel de résultat est calculé a` chaque cycle d’horloge) et du rendement du système reconfigurable complet, nous pouvons calculer le débit que le système proposé pourrait atteindre lors d’une implémentation physique selon l’expression suivante :

~~D = 32 η FClk [P x/sec] (4.33) × ×~~

Dans les deux cas extrêmes de filtre de rang : le calcul d’un filtre Max/Min et le calcul d’un filtre médian, le Tableau 4.10 indique les débits de traitement du système reconfigurable complet, exprimés en millions de pixels traités par seconde, calculés selon l’expression 4.33 pour différentes tailles envisagées des voisinages. Les résultats présentés sont basés sur des fréquences de fonctionnement indiquées dans le Tableau 4.9 et majorées d’un facteur de sécurité de 80 %.

~~Débit de pixels traités [MPx/sec] Voisinage 3 3, η = 0.9 5 5, η = 0.8 7 7, η = 0.7 × × × Max/Min 2650 2355 1649 Médian 1912 1188 806~~

~~Tab. 4.10: Débits de traitement pour un système reconfigurable complet composé de 32 modules de traitement.~~

~~171 Chapitre 4. Architecture reconﬁgurable~~

~~4.5 Conclusion~~

Dans ce chapitre nous avons décrit une architecture dédicacée reconfigurable basée sur des circuits FPGAs de haute densité permettant de calculer différents filtres de rang en mode bit-série, pour des voisinages de taille et de forme paramétrables.

Dans un premier temps nous avons montré un algorithme simple, permettant de calculer les filtres Max/Min. L’implémentation d’une unité de traitement basée sur cet algorithme s’avère particulièrement intéressante tant au niveau de la quantité des ressources logiques nécessaires a` sa réalisation qu’au niveau de sa grande vitesse de fonctionnement, même avec des voisinages de grande taille.

Nous avons ensuite montré qu’il est possible d’arriver a` un filtre de rang généralisé, en partant de l’algorithme Max/Min et en éliminant successivement les maxima/minima locaux dans le voisinage. Cependant l’unité de traitement correspondante présente un inconvénient majeur : la grande quantité de ressources logiques nécessaires lorsque l’on souhaite préserver un haut débit de traitement. Si pour des voisinages de petite taille et pour des petites valeurs de rang cette méthode reste intéressante, très vite on arrive a` la limite des ressources logiques disponibles, même pour un FPGA de haute densité.

Afin d’améliorer la performance du système reconfigurable pour la recherche de la valeur du rang proche du médian et surtout lorsque la taille du voisinage augmente, nous avons utilisé l’algorithme de Danielsson. Cet algorithme, connu depuis 1981, a été souvent utilisé pour l’implémentation des filtres médians 2D. Cependant les implémentations proposées visaient principalement le voisinage de 3 3 pixels, pour lequel cet algorithme peut être fortement sim- × plifié. Ici, nous avons présenté l’implémentation de cet algorithme dans sa forme généralisée, 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émoire spécifique des opérandes contenant les données a` traiter, une matrice (plutôt un vecteur) d’unités de traitement et une mémoire pour les résultats nous avons pu définir la notion de module de traitement. Un tel module est capable de calculer pour chaque nouvelle nouvelle ligne de la fenêtre a` l’entrée, une ligne des pixels filtrés, au facteur de perte prêt.

Du fait de la faible quantité de ressources logiques nécessaires a` l’implémentation d’un seul module de traitement au regard de la quantité de ressources logiques disponibles dans un circuit FPGA de haute densité, nous avons pu montrer qu’une parallélisation massive est donc possible. En effet, le nombre d’unités de traitement travaillant en parallèle est de l’ordre de la centaine.

Le système reconfigurable présenté peut être facilement intégré dans une solution matérielle disponible actuellement et permettant la conception de systèmes reconfigurables a` l’aide des FPGAs de haute densité. Pour un exemple concret d’une telle solution, la carte Alpha Data ADP-WRC-II, nous avons pu quantifier les débits de traitement maximaux qu’il serait possible d’obtenir si l’on implémentait vraiment les circuits décrits. Pour les deux cas extrêmes de filtres de rang : le filtre Max/Min et le filtre médian et pour des voisinages de 3 3, 5 5 et 7 7 × × × pixels, nous avons montré que le débit des pixels traités pourrait atteindre 2649, 2355 et 1380 [MPx/sec] pour un filtre Max/Min et 1450, 880 et 645 [MPx/sec] pour un filtre médian.

~~172 Chapitre 5~~

~~Discussion et conclusion~~

~~5.1 Problème, motivation et intérêt~~

Dans le cadre de ce travail nous avons traité le problème de l’accélération des filtres de rang, souvent utilisés dans le traitement des images numériques. Ces filtres constituent un outil permettant d’effectuer des traitements sur des images avec des buts divers : l’élimination de bruit impulsionnel, les transformations morphologiques etc.

Une chaˆıne de traitement des images numériques est constituée de plusieurs traitements a` effectuer l’un après l’autre. L’utilisation des filtres de rang est généralement liée a` la phase de pré-traitement, donc tout en amont de la chaˆıne, juste après l’étape de l’acquisition.

~~Le plus faible temps d’exécution possible est donc souhaitable de fa¸con a` ce que d’autres traitements, ou une analyse d’image plus complexe, soient toujours réalisables en temps réel.~~

Ici, il convient de préciser que la notion du temps réel dépendra de l’application visée. Dans l’imagerie numérique par temps réel le plus souvent on sous entend une cadence de l’ordre de 25 images par seconde, liée traditionnellement par le cinéma et la vidéo a` la vision humaine.

Ce chiffre est cependant loin d’être le même pour toutes les applications possibles de l’imagerie numérique. Ainsi, lorsque on parle du contrôle de qualité en milieux industriels par exemple, le nombre d’images acquises par seconde sera déterminé en fonction de la nature du processus a` contrôler et la vitesse maximale avec laquelle on peut acquérir des telles images.

Des caméras numériques actuelles sont capables d’acquérir des images a` très haute résolution et a` une très grande vitesse. Elles peuvent donc être utilisées dans des processus de traitement beaucoup plus rapides que ceux de 25 images par seconde. Dans ce cas une importante quantité de données est générée en très peu de temps, imposant des très courtes fenêtres de temps, pour un traitement des images en continu.

~~Pour de telles applications, le temps d’exécution de filtres de rang peut s’avérer contraignant et ceci principalement a` cause de l’opération de tri.~~

~~Pour un ﬁltre 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’éléments (pixels). 2. Pour tout pixel de l’image a` traiter dont la taille est de l’ordre d’un million de pixels. Même si nous disposons aujourd’hui d’algorithmes de tri efficaces, le nombre d’opérations a` effectuer par une architecture informatique classique est tellement grand que les temps de traitement deviennent inacceptables dans le cas des applications annoncées et surtout lorsque la taille de voisinage et/ou la taille de l’image augmentent.

~~L’accélération de ce type de traitement particulier voit alors tout son intérêt.~~

Par ce travail nous avons apporté des solutions au problème d’accélération de temps de calcul des filtres de rangs. Ces solutions visent l’implémentation de ces filtres sur deux architectures informatiques différentes : l’architecture universelle et l’architecture dédicacée reconfigurable.

~~5.2 Impl´ementation sur l’architecture universelle~~

Dans le Chapitre 2 nous avons présenté l’implémentation des filtres de rang sur un ordinateur personnel d’une configuration actuelle, basé sur un micro-processeur d’architecture Pentium 4. Un tel choix est justifié par le fait que ces ordinateurs présentent une importante puissance de calcul grâce a` la haute vitesse de fonctionnement des micro-processeurs et de la mémoire, aux différentes manifestations de parallélisme (notamment le parallélisme d’instructions, de données et dans certain cas le parallélisme inter-processeur), sans parler d’une mise en ”grappe“ (cluster) de plusieurs ordinateurs.

De tels systèmes sont de plus en plus utilisés pour le calcul des problèmes complexes dans des temps acceptables, mettant a` l’écart des solutions traditionnelles beaucoup plus onéreuses telles que stations de travail ou encore super-ordinateurs.

Cependant l’exploitation de toutes les possibilités offertes par les ordinateurs personnels d’aujourd’hui présente un inconvénient majeur : elle n’est pas automatique en ce sens que les compilateurs ne sont pas encore capables d’extraire le parallélisme a` partir d’un code écrit dans un langage de programmation évolué, tel que C ou C++.

Cette constatation implique que de telles architectures peuvent être abordées de deux fa¸con différentes : 1. On ne considère un problème qu’à travers le choix (et/ou la conception) d’algorithmes et de leur codage a` l’aide d’un langage de programmation évolué. Dans ce processus on fait l’abstraction complète de l’architecture du processeur et du matériel sous-jacent (c’est d’ailleurs la raison d’être des langages de programmation évolués).

2. La conception et l’implémentation des algorithmes tient compte de l’architecture du matériel cible. Dans le cas d’un ordinateur personnel ce seront : (a) L’exploitation des différents niveaux de parallélisme, notamment celui de données (le fonctionnement en mode SIMD du micro-processeur).

~~174 5.3. Implémentation sur des architectures dédicacées reconfigurables~~

(b) La conception d’algorithmes en fonction du couplage entre le micro-processeur et la mémoire (les aspects liés a` la lecture des données). (c) L’application des différentes techniques de programmation avancées, nécessaires pour une implémentation efficace des algorithmes décrits (optimisation du codage d’algorithmes).

~~Avec les implémentations des filtres de rang dans une architecture universelle de deux fa¸con différentes décrites, nous avons montré que :~~

1. Lorsque l’implémentation des filtres de rang tient compte de l’architecture de l’ordinateur ciblé, des facteurs d’accélération de l’ordre de 10 peuvent être obtenus par rapport a` une approche du problème purement algorithmique (le débit des pixels traités passe de quelques méga pixels par seconde a` quelques dizaines de méga pixels par seconde).

2. Même si l’on tient compte de parallélisme de l’architecture universelle, lorsque la taille de voisinage augmente et la valeur de rang recherché approche la médiane, l’affaiblissement de la performance est inévitable.

3. Dans une architecture universelle, quelque soit le type d’algorithme utilisé, nous sommes toujours limité par : l’accès inadéquat aux données de l’image par le biais de la mémoire centrale, le faible nombre de registres internes (mémoire des opérandes) et un faible degré de calcul concurrent (faible parallélisation).

~~5.3 Implémentation sur des architectures dédicacées reconfigurables~~

~~Si l’on veut encore accélérer le temps de traitement, nous sommes obligés de faire appel a` des solutions matérielles dédicacées, basées sur des circuits ASIC ou FPGA.~~

Dans le Chapitre 3 nous avons fait un tour d’horizon des différents algorithmes qui peuvent être utilisés pour le calcul de filtres de rang avec des systèmes dédicacés. Nous avons également présenté quelques implémentations des systèmes de traitement correspondants.

Le parcours des systèmes dédicacés existants a permis de dégager deux conclusions importantes : 1. La plupart des solutions proposées jusqu’à présent se limitent au calcul dans un voisinage de 3 3 pixels. × (a) Or dans les traitements des images numériques envisagés habituellement il est souvent nécessaire (voire indispensable) de paramétrer la taille et la forme de voisinage de fa¸con a` adapter le filtre au mieux a` l’application visée.

~~175 Chapitre 5. Discussion et conclusion~~

2. Les implémentations existantes se contentent de l’implémentation d’une seule unité de traitement. (b) Or, les avancés technologiques liées a` l’intégration des circuits intégrés de plus en plus denses impliquent que les FPGAs actuels sont caractérisés par une importante quantité 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é pour objectif la conception d’un système dédicacé reconfigurable massivement parallèle, basé sur des circuits FPGA et permettant de calculer les filtres de rang avec des voisinages dont la taille et la forme sont paramétrables.

~~Avec une implémentation originale des filtres de rang sur une architecture reconfigurable décrite dans le Chapitre 4 nous avons montré que :~~

1. En utilisant les algorithmes fonctionnant en mode bit-série on arrive a` des unités de traitement nécessitant une faible quantité des ressources logiques, caractérisées par une grande vitesse de fonctionnement même lorsqu’il s’agit de travailler avec des voisinages de grande taille.

2. La faible quantité des ressources logiques nécessaire pour la réalisation d’une unité de traitement permet une parallélisation massive au sein d’un FPGA de haute densité, tout en préservant la haute vitesse de traitement.

3. La vitesse élevée de fonctionnement de l’unité de traitement et leur grande nombre, ainsi que le pipe-line de traitement : le chargement des pixels dans la mémoire locale, la construction de plans de bits pour le traitement, le traitement même et la récupération des résultats a` la sortie, résultent d’un débit de traitement qui est de l’ordre de 1000 méga pixels par seconde.

Pour un exemple concret d’une carte existante permettant l’intégration des systèmes reconfigurables a` l’aide des FPGAs Xilinx de haute densité (la carte Alpha Data ADP-WRC-II), nous avons pu quantifier les débits de traitement qu’il serait possible d’obtenir si le système décrit avait vraiment implémenté.

Le Tableau 5.1 mets en évidence la différence de performance, exprimé par le débit des pixels traités (en MPx/sec) entre une architecture universelle basée sur un processeur Pentium 4 et l’architecture reconfigurable proposée, pour les deux cas extrêmes de filtre de rang : les filtres Max/Min et le filtre médian. Une telle différence en performance s’explique :

1. Du fait d’un fonctionnement en mode bit-série, le nombre de pas de calculs (BOPs) nécessaires au calcul de la valeur filtrée d’un voisinage est réduit au nombre de bits utilisés pour coder la couleur du pixel, quelle que soit la taille du voisinage.

~~2. Dans le système reconfigurable décrit nous disposons d’un accès aux données parfaitement adapté a` l’application envisagée. Tout d’abord l’accès a` la mémoire centrale du~~

~~176 5.4. Am´eliorations possibles~~

~~D´ebit de pixels trait´es [MPx/sec]~~

~~V Universelle standard Universelle parall`ele Reconﬁgurable~~

~~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é d’un processeur Pentium 4 (architecture universelle standard et pa- rallèle) et de l’architecture dédicacée reconfigurable proposée.

système via les bus de données larges et distincts pour l’image a` traiter et pour l’image traitée. Ensuite la grande taille de la mémoire locale des opérandes permet le calcul simultané des pixels successifs dans une fenêtre de l’image quelque soit la taille du voisinage.

3. Du fait de la configuration de la mémoire centrale et de la haute densité des circuits FPGAs, le système reconfigurable est massivement parallèle et permet : (a) de minimiser la redondance en lecture des données nécessaires pour le calcul des fenêtres successives dans un module de traitement d’une part, (b) et de maximiser le nombre de modules de traitement réalisés dans un FPGA, d’autre part.

~~5.4 Am´eliorations possibles~~

Pour ce qui est de la performance des ordinateurs personnels basées sur le micro-processeur Pentium 4, nous pensons que très peu de place reste pour des améliorations 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é de l’architecture du micro-processeur que de la mémoire.

Nous pouvons également citer la voie alternative au calcul par le CPU qui est liée a` l’exploitation de la GPU (Graphics Processor Unit). Ces circuits, utilisés pour le calcul et l’affichage rapide des images 3D, sont dotés d’une importante puissance de calcul et sont de plus en plus utilisés pour le calcul autre que la 3D, avec une performance défiant celle d’un processeur normal.

~~177 Chapitre 5. Discussion et conclusion~~

~~En ce qui concerne les améliorations du système reconfigurable elles serait possibles a` travers :~~

1. Optimisation de la description formelle des circuits pour chaque voisinage Dès le départ nous nous sommes efforcé de faire une telle description formelle du système, que le changement de paramètres liés a` la taille et la forme de voisinage soit aisé (scala- bilité du problème). Nous nous trouvons donc bien dans une logique qui met en opposition : l’universalité de la description et sa performance. A notre avis, un important gain en performance pourrait être obtenu en considérant chaque voisinage séparément et en faisant une description formelle spécifique a` chaque voisinage envisagé. Dans ce cas et surtout lorsque la taille de voisinage augmente, une unité de traitement pourrait être découpée en un nombre plus important d’étages de pipe-line, permettant d’augmenter le débit de traitement.

2. Optimisation du processus d’implémentation Dans le processus d’implémentation nous nous sommes basé sur des résultats obtenus par un processus d’implémentation automatisé, mais néanmoins guidé par des contraintes de performances imposées. Etan´ t donnée la simplicité des unités de traitement et la régularité avec laquelle elles se multiplient, ce sera intéressant de réaliser le placement manuel pour une seule unité de traitement et ensuite utiliser ce motif de placement pour toutes les autres unités de traitement d’un système reconfigurable complet.

~~5.5 Conclusion ﬁnale~~

Les ordinateurs d’architecture universelle sont des machines polyvalentes permettant la résolution automatisée d’un grand nombre de problèmes. 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é d’un grand nombre de couches superposées permettent a` l’homme de faire l’abstraction de la complexité du matériel et de ”communiquer“ avec elle dans un langage qui lui est proche.

Le prix a` payer, pour une universalité de l’application d’une même machine et pour une facilité de communication entre l’homme et cette machine, est lié a` son rendement, variable en fonction de l’application qu’elle exécute.

Dans le cas de traitement des images, ce rendement est particulièrement faible, duˆ a` la quantité de données qui est en jeu et le calcul dans le voisinage qui lui est propre. Pour le calcul des filtres de rang (système a) de la Figure 5.1), le mauvais rendement se traduit par un débit de pixels traités D0 de l’ordre de quelques méga pixels par seconde.

L’exploitation du parallélisme des architectures universelles (système b) de la Figure 5.1) peut améliorer la performance du calcul des filtres non-linéaires. Dans ce cas le débit des pixels traités D1 peut être augmenté d’un facteur de 10 par rapport au débit D0.

~~Si une architecture universelle introduit la possibilité de calcul de problèmes différents sur une même machine, le paradigme de calcul reconfigurable grâce aux circuits FPGAs introduit~~

~~178 5.5. Conclusion ﬁnale~~

~~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émentation des filtres de rang sur trois architectures différentes. la notion de l’adaptation du matériel au calcul du problème. Cela se traduit par une grande liberté des approches possibles et forcement le choix des meilleures.

Pour les applications en traitement des images numériques et plus particulièrement pour le calcul des filtres de rang, l’approche reconfigurable en mode bit-série permet de faire une parallélisation plus ”naturelle“ du problème posé. Un grand nombre d’unités de traitement qui opèrent sur des voisinages entiers, plutôt que sur des pixels séparément, permet de minimiser le nombre d’opérations a` effectuer pour chaque nouveau pixel a` calculer.

Dans le cadre de ce travail nous avons pu montrer qu’une telle approche (système c) de la Figure 5.1), étant donné la technologie actuelle, résulte en un meilleur rendement de la machine par rapport a` l’application donnée et une performance (débit des pixels traités D2) 10 fois supérieure par rapport a` une architecture universelle parallèle et 100 fois par rapport a` une architecture universelle standard.

~~179 Chapitre 5. Discussion et conclusion~~

~~180 Annexe A~~

~~Architecture universelle~~

~~A.1 Présentation générale de l’application~~

Les différents algorithmes décrits dans le Chapitre 2 ont été codés et les procédures correspondantes intégrées dans une application permettant d’évaluer leur performance sur un ordinateur doté d’un processeur Intel - Pentium 4. L’interface graphique de l’application développée (Figure A.1), hormis les fonctionnalités standards de manipulation des fichiers d’images accessibles depuis la barre d’outils classique, propose deux boites a` outils sous forme de deux fenêtres indépendantes. Une première boite (fenêtre Séquentiels, Figure A.1) est des- tinée a` l’exécution des procédures basées sur des algorithmes de filtre de rang généralisé et des algorithmes dédicacés (cf. Section 2.2) qui exploitent l’architecture standard. Une autre boite a` outils (fenêtre Extensions, Figure A.1) permet d’accéder aux procédures qui utilisent les différentes extensions de l’architecture standard, i.e. le parallélisme intra-processeur (cf. Section 2.3).

En ce qui concerne l’exploitation de parallélisme inter-processeur, il est possible, grâce au panneau de configuration (panneau Priorité, Figure A.1), d’exécuter une procédure dans deux threads distincts. De plus, l’utilisateur peut affecter une valeur de priorité maximale pour le process et pour le thread exécutant la procédure choisie (cf. Section A.3.2)1.

Pour l’exécution d’une procédure l’utilisateur spécifie un certain nombre de paramètres tels que la taille de voisinage, la valeur de rang recherché ou encore le nombre de fois que la même procédure sera appliquée a` la même image (Filtre, Figure A.1). Les butons dédicacés permettent de choisir rapidement les valeurs des voisinages les plus couramment utilisés : 3 3, 5 5, 7 7. De même, il est possible de spécifier les valeurs typiques pour les rangs × × × (Min, Med, Max), dont la valeur numérique est automatiquement calculée en fonction de la taille de voisinage.

Une fenêtre de texte est utilisée pour l’affichage des diverses informations concernant les actions entreprises (panneau Info Figure A.1). Après chaque traitement, les données liées a` la

1Par défaut tous les procédures sont exécutées a` travers un seul thread et avec une priorité normale pour le process et le thread. Le changement de priorité n’affecte que le thread qui exécutera la procédure choisi - les valeurs de priorité normale sont rétablies dès la fin d’exécution de la procédure.

181 Annexe A. Architecture universelle procédure exécutée sont affichées : le type de l’algorithme et la procédure correspondante, la taille de voisinage, la valeur de rang et le temps d’exécution total. Egalemen´ t, lorsque une même procédure est exécutée plusieurs fois les temps caractéristiques : minimal, moyen et maximal sont affichés ainsi que l’écart type des mesurés effectuées. Les différents informations obtenues sont automatiquement sauvegardées dans un fichier texte pour une éventuelle utilisation postérieure.

Afin d’automatiser le processus de test, l’utilisateur a la possibilité de choisir plusieurs procédures, voir toutes (panneau “Automation”, Figure A.1), et les exécuter sur une même image, pour un ou tous les voisinages standard.

Dans la barre de menu classique on retrouve un menu supplémentaire (“Extras”) qui permet d’accéder aux fonctionnalités liées a` la comparaison des différents niveaux de priorité(cf. Section A.3.2), les mesures de performance de la mémoire et les procédures combinées (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érentes méthodes de mesure de temps~~

La mesure de temps d’exécution d’une procédure est habituellement faite a` l’aide de la fonction API WIN322 - GetTickCount(), qui renvoie le temps écoulé depuis la dernière mise en route de système d’exploitation. Deux appels a` cette fonction, avant et après la procédure a` évaluer, nous donnent les temps dont la différence représente le temps d’exécution. La résolution théorique de la fonction GetTickCount() est de l’ordre d’une milliseconde, mais en réalité une telle précision n’est jamais atteinte. Ainsi, pour les systèmes d’exploitation Windows95 (ou 98) la précision réelle est de seulement 55ms et de 10 a` 15ms pour le Windows NT [Lou00]. Pour les temps d’exécution des procédures envisagées, cette précision s’avère insuffisante.

Il est possible de mesurer des temps beaucoup plus petits en utilisant une autre fonction API - QueryPerformanceCounter(). Cette fonction permet d’accéder a` un compteur haute résolution3, incrémenté par une horloge spécifique. La fréquence d’incrémentation de cette horloge varie d’un matériel a` l’autre ; dans notre cas elle a été évaluée a` 3579545 Hz4, ce qui nous permet de mesurer des temps d’exécution a` 0.3µs près. Le coutˆ d’appel de cette fonction est cependant non négligeable : pour le système utilisé il a été évalué a` 60µs.

Enfin signalons qu’il est possible d’effectuer des mesures de temps avec une précision encore plus élevée, de l’ordre d’un cycle processeur. Ceci est possible grâce a` un compteur des cycles effectifs exécutés par le processeur. L’accès a` ce compteur est assuré par l’instruction assembleur RDTSC Read Time Stamp Counter dont l’utilisation est largement décrite dans [Not97].

Même si l’emploi de l’instruction RDTSC offre des mesures de loin les plus précises, nous avons adopté le compteur haute résolution car sa précision est largement suffisante pour les mesures de temps des procédures envisagées.

~~A.2.2 Analyse des mesures pour les proc´edures types~~

Le temps d’exécution d’une même procédure sur un même lot de données n’est pas constant et les variations de 10 a` 20 % entre les temps mesurés sont courantes pour les systèmes d’exploitation de famille Windows[Fom99]. Les origines de telles variations sont nombreuses et relatives a` la complexité du matériel sous-jacent et de leur interaction avec le système d’exploitation. Tout d’abord nous nous trouvons dans un environnement multi-taches : le temps d’exécution va donc dépendre des autres taches en cours d’exécution et de la politique

2Application Programming Interface - les fonctions de système d’exploitation accessibles par une application extérieure. 3Tous les ordinateurs personnels n’intègrent pas ce compteur, un test de présence avant son utilisation est donc indispensable. 4La valeur de la fréquence d’incrémentation 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ésordre, donc il ne doit pas forcement être le même d’une exécution a` l’autre.

Afin d’analyser le problème de la mesure de temps d’exécution quatre procédures type ont été retenues pour l’analyse : – deux exploitant l’architecture standard : tri a` bulle et tri rapide hybride notées Proc.1 et Proc.2 – deux exploitant le parallélisme de données a` travers les extensions MMX et SSE2 notées Proc.3 et Proc.4 Ces quatre procédures ont été exécutées 100 fois et les temps d’exécution mesurés ont été enregistrés. Le choix de ces procédures particulières a été guidé par les différents ordres de grandeurs de temps d’exécution en jeu. Pour éviter l’influence d’autres threads en cours d’exécution, la priorité de process et de thread exécutant ces quatre procédures ont été fixé a` leur plus grande valeur (le processeur ne change pas de contexte d’exécution, il consacrera tout son temps a` l’exécution de la procédure en question tant que celle-ci n’est terminé).

Sur base des données enregistrées, pour chaque procédure type nous présentons quatre graphiques suivantes : 1. Diagramme temporel des mesures - pour identifier des éventuelles anomalies des mesures (valeurs atypiques) 2. Diagramme de décalage6 - pour vérifier que les différentes mesures de T ne sont pas autocorrélées 3. Histogrammes7 - pour voir la distribution de T 4. Graphique des mesures ordonnées en fonction des quantiles de la distribution normale8 - pour vérifier l’hypothèse sur la distribution, présumée normale Egalemen´ t, chaque graphique est accompagné d’un tableau des valeurs de statistiques de position usuelles : le nombre de mesures n, les valeurs : minimum, médian, moyenne m, maximum et l’écart type s des mesures ainsi que l’intervalle de confiance calculé pour 95 %.

Pour les Proc. 1. et 2. (Figure A.2) les diagrammes temporels de mesures ne présentent aucune dérive importante de la série. Le diagramme de décalage ne présente pas de motif régulier ni de valeurs atypiques - les données ne semblent pas être autocorrélées. Les deux histogrammes sont symétriques et bien en forme de cloche. Le diagramme de quantiles est proche d’une droite et confirme l’hypothèse d’une distribution normale. Dans ce cas nous pouvons conclure que les mesures de temps d’exécution peuvent être représentées par un modèle de type univarié : Ti = C + Ei ou Ti est la mesure réelle, C composante déterministe et Ei la composante 2s aléatoire. 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éduire l’influence sur le temps d’exécution des autres process en cours d’exécution en attribuant a` un thread spécifique, la priorité la plus élevé. 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 équivalente a` 0.3s, s étant l’écart type. 8Le graphique montre la fonction T [i] = m + sZ[i] avec T [i] les temps mesurés ordonnés, m valeur moyenne des mesures, s l’écart 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érente. Les diagrammes temporelles relèvent quelques valeurs atypiques, tout au début de la séquence de mesures. Les diagrammes de décalage mettent ces points encore plus en évidence. Si l’histogramme pour la Proc. 3. se montre plus ou mois symétrique 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ès faible valeur de l’écart type.

Nous avons procédé a` l’élimination des quelques valeurs atypiques (2 pour le Proc. 3. et 7 pour le Proc. 4), les nouveaux diagrammes sont présentés a` la Figure A.4. Sans les valeurs atypiques les mesures approchent une distribution normale.

Enfin en utilisant l’écart type obtenu, nous pouvons calculer le nombre minimal de mesures nécessaires a` effectuer pour que la moyenne des mesures soit a` d unités prêt 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écision a` 10% de la valeur moyenne de temps d’exécution 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` été fixé 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 être effectué par un appel a` la fonction haut niveau AfxBeginThread(). Cette fonction a comme argument le nom de la fonction a` exécuter ainsi que quelques paramètres de configuration notamment ceux de la priorité. Deux appels successifs a` cette fonction créeront donc deux threads qui, dans le cas d’une machine multi-processeur, pourraient être exécutés de fa¸con concurrentielle.

Dans le cas d’une exécution sur un système multi-processeur, le nombre de processeurs peut être obtenu avec la fonction GetSystemInfo(), il est possible d’explicitement spécifier quel thread sera exécuté sur quel processeur a` l’aide de la fonction SetThreadAffinityMask().

~~A.3.2 Influence de la priorité des threads sur le temps d’exécution~~

Dans le système d’exploitation utilisé, le temps de processeur est partagé entre les différents threads en cours d’exécution. A chaque thread est associé un des 32 niveaux possibles de priorité. L’attribution d’un niveau de priorité particulier est faite en respectant la hiérarchie existante entre le process et le thread. Ainsi, chaque process possède son propre attribut de priorité. Chaque thread créé par ce process hérite la priorité de base du process qui l’a créée, mais peut encore raffiner cette valeur dans la plage fixé par la priorité du process de base 10.

A chaque niveau de priorité est attribué une file d’atteinte spécifique. Les files d’atteinte de niveau de priorité supérieur sont servis d’abord avec un ordonnancement qui se déroule selon le schéma round robin : chaque thread re¸coit une quantité fixe de temps processeur appelé time slice quantum11. Après avoir consommé un quanta de temps, le thread en cours d’exécution est mis a` la fin de la file d’atteinte et le thread suivant peut être servi.

Un mécanisme de changement dynamique de la priorité permets au threads d’une priorité basse de recevoir le temps processeur malgré la présence des threads d’une priorité élevée. Egalemen´ t le système d’exploitation défini un intervalle de temps (de l’ordre d’une seconde) dans lequel chaque thread doit être exécuté au moins une fois.

Par défaut, le process et le thread ont une priorité qualifié de “normale”, équivalente a` la valeur 9 de l’échelle de priorité. Les valeurs de priorité plus basses correspondent aux process et aux threads que l’on souhaite exécuter en arrière plan (les process dits idle), tandis que la valeur la plus élevée correspond aux threads dont l’exécution est dite critique - les threads dont l’exécution est dite “temps réel”. Lorsque un thread est lancé avec la priorité maximale, le processeur consacrera tout son temps a` son exécution jusqu’à 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é d’un thread apparaˆıt donc comme un ”offset” de la priorité de process. 11Ce temps varie d’un système d’exploitation a` l’autre. Il est généralement admis que les quantas plus longs permettent a` une application de calcul intensif d’être plus performante, tandis que les quantas plus courts conviennent mieux lorsque plusieurs applications demandent une certaine interactivité avec l’utilisateur.

187 Annexe A. Architecture universelle il est donc nécessaire de lui attribuer le plus haut niveau de priorité possible, une pratique courante dans le domaine de traitement des images temps réel (voir p.e. [CD99, Fom99]). Signalons cependant que le changement de priorité n’apporte aucun gain supplémentaire sur le temps d’exécution global si l’application considérée est la seule en cours d’exécution. Le temps processeur consommé par ces services de base du système d’exploitation est négligeable.

Afin d’éviter toute interférence possible avec d’autres process en cours d’exécution, les priorités de process et de thread d’exécution ont été fixées a` la plus haute valeur possible pour toutes les mesures effectuées.

~~A.4 Mesure de performance de la m´emoire~~

La performance de la mémoire joue un rôle important dans le temps d’exécution d’une procédure de traitement des images étant donnée la quantité de données en jeu. La bande passante théorique est de l’ordre de 3.2 GB pour la mémoire centrale, et de 48 et de 96 GB/s ([Int99b, Int99e]) pour les deux niveaux de la mémoire cache (le niveaux L1 - mémoire cache hors-processeur et L2 - mémoire cache dans le processeur même). En réalité les débits effectifs vont dépendre non seulement de la performance individuelle des composants (de la mémoire, de la vitesse de bus etc.) mais aussi d’une configuration matérielle a` l’autre (le taux d’occupation de bus qui est partagé p.e.) et il conviens donc de le quantifier pour l’ordinateur utilisé.

Pour établir la bande passante réelle de la mémoire de l’ordinateur utilisé, plusieurs méthodes de déplacement d’une quantité fixe de données (un bloc contiguë de 8 MB) ont été évaluées. 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ès loin des 3.2 GB théoriques énoncé. Une procédure spécifique, basée sur l’exploitation des extensions a` l’architecture standard 12 arrive a` des débits qui sont de l’ordre de 405 MB/s. Les tests de lecture/écriture depuis la mémoire, mais impliquant le passage par le processeur a` travers les registres de l’extensions, affichent une performance de 980 MB/s pour l’écriture et pour la lecture. L’utilisation de ces mêmes fonctions mais cette fois-ci en exploitant le chargement explicite des données dans la mémoire cache (prefetch) permettent d’arriver a` débits de l’ordre de 5.6 GB/s.

Nous constatons donc une importante différence de performance en fonction de méthode utilisée pour réaliser le transfert de données. La bande passante de la mémoire n’est donc pas uniquement fonction du matériel mais aussi de la fa¸con comment il a été programmé.

~~A.5 Code auto-modiﬁable pour le calcul d’adresses~~

Nous avons vu dans la Section 2.3 tout l’intérêt de chargement des lignes de l’image depuis la mémoire 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éférence a` une adresse sauvegardée dans le registre esi et une constante (1024) définie 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’écriture de programme - au moment de la compilation. Si le changement de la valeur de esi permet d’accéder au différentes lignes de l’image, la valeur de l’offset permet d’accéder aux lignes de l’image, en faite de la fenêtre nécessaire pour le calcul des pixels courants.

Le désavantage d’un tel mode d’adressage réside dans le fait que la taille de l’image, i.e. offset de déplacement, est spécifié 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ême adressage explicite, mais aussi pour des valeurs qui pourraient être définies au moment de l’exécution du programme.

Afin de permettre au programme de se modifier par lui-même, il faut dans un premier temps demander au système d’exploitation les droits permettant d’y effectuer une opération d’écriture. Sans ses droits, l’écriture dans la mémoire de programme provoque une faute de protection générale ce qui, en d’autres termes, signifie l’arrêt d’exécution de programme im- posé par le système d’exploitation. Le changement de droits est effectué par une fonction API (b.] dans le listing A.1) juste le temps d’effectuer l’écriture nécessaire. La zone mémoire qui va subir le changement des droits déterminée par les balises start et end.

~~Les droits attribués par défauts sont restaurés après l’opération de l’écriture (c.] dans le listing).~~

~~Le programme effectue ensuite une opération d’écriture a` l’endroit détermine 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-modiﬁable

~~189 Annexe A. Architecture universelle~~

~~190 Annexe B~~

~~Circuits FPGAs Xilinx~~

La société Xilinx est l’un des principaux producteurs spécialisés 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érentes familles de FPGAs se sont succédées : 2000, 3000, 4000, Spartan, Virtex, Virtex II, Virtex II-Pro.

Au premier abord l’architecture des différentes familles de FPGA est fort semblable et proche de la description générale présentée dans la Section 3.1. Cependant, l’évolution des FPGAs Xilinx montre d’importantes avancées notamment au niveau de l’architecture de la cellule logique élémentaire, de la topologie du réseau d’interconnexions, ainsi que dans l’introduction des ressources supplémentaires telles que la logique nécessaire a` la construction des additionneurs et des multiplicateurs performants, la mémoire RAM etc.

Bien entendu, les familles les plus récentes telles que Virtex II ou encore Virtex II-Pro bénéficient des dernières technologies employées pour la fabrication des circuits intégrés. Ces technologies combinent réalisation des circuits en plusieurs couches avec un λ de l’ordre du dixième de microns (8 couches de 0.15 µ pour la famille Virtex II et 9 couches de 0.13 µ pour Virtes II-Pro) et possibilité d’implémentation d’un nombre important d’entrées/sorties. Les FPGAs fabriqués avec une telle technologie sont donc des circuits de très haute densité, ils impliquent une grand quantité de ressources logiques et offrent la possibilité de traitement d’un grand nombre de variables.

Comme tout circuit FPGA, les FPGAs de la famille Virtex II de Xilinx sont construits autour de trois éléments essentiels déjà mentionnés : les cellules logiques élémentaires, le réseau d’interconnexion et les bornes d’éntrées/sorties. En plus de ces ressources, les FPGAs de cette famille possèdent un certain nombre de mémoires RAMs et des circuits multiplicateurs dédicacés. Les circuits FPGAs de la famille Virtex II-Pro sont même dotés de microprocesseurs embarqués : l’unité FPGA la plus dense de cette famille 2VP125 possède 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 élémentaire est appelée Configurable Logic Block - CLB. Bien que ce nom soit resté identique tout au long de l’évolution des différentes familles des FPGAs, l’architecture qu’il désigne a fortement changé depuis l’introduction des circuits de la famille Virtex.

A partir de la première génération de la famille Virtex, un CLB est composé de quatre sous- cellules identiques appelées tranches (slices) représentées schématiquement 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ède un certain nombre de ressources logiques. Nous décrivons les plus importantes d’entre elles : – Mémoires F et G - Il s’agit des mémoires de 16 bits que l’on peut adresser avec deux bus d’entrée indépendants de quatre bits chacun. Ces mémoires possèdent deux sorties : une sortie D qui donne le contenu de la mémoire selon l’adresse présente sur le bus F R (ou GR) et une sortie D15, le dernier bit adressé par la mémoire. Chaque mémoire possède également une entrée supplémentaire Din. Cette entrée, combinée avec la sortie D15, est utilisée pour la construction des registres a` décalage a` plus grand nombre de bits a` partir de plusieurs mémoires F (ou G) mis en série (connexion Shift sur la Figure B.1).

– Logique dédicacée d’addition CY - La logique supplémentaire (notée CY sur la Figure B.1 par tranche permet d’effectuer efficacement l’opération d’addition (ou de soustraction). A cette logique est associée une connexion spécifique permettant de tenir compte d’un éventuel report de l’étage précédant et de propager le report calculé

~~192 B.1. Architecture des FPGAs Virtex~~

aux tranches situées immédiatement au dessus de la tranche considérée (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émoire F (ou G) peut être dirigée vers deux bi-stables programmables R1 et R2. Ces bi-stables peuvent être utilisés pour la réalisation des latch ou des flip-flops habituels lors de réalisation des circuits synchrones.

~~– Multiplexeurs - L’ensemble des multiplexeurs (non représentés a` la Figure B.1) permettent la réalisation de multiplexeurs a` grand nombre de canaux.~~

Dans chaque tranche, les sorties D des mémoires F et G peuvent être : soit dirigées directement vers d’autres circuits combinatoires et/ou séquentiels (sorties X, Y ) ; soit mémorisées dans les deux éléments mémoire R1 et R2 dans le cas de la réalisation 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édicacées pour des tranches adjacentes au CLB considéré, soit via la matrice des connexions a` des CLBs situés plus loin dans le FPGA (voir Section A.1.6).

~~B.1.2 Modes de fonctionnement d’un CLB~~

Un CLB se présente donc comme une ressource logique polyvalente. En fonction de la configuration attribuée, il peut adopter l’un de plusieurs modes de fonctionnement distincts, dont nous présentons les plus importants :

Générateur des fonctions logiques Les mémoires des CLBs (en fait les mémoires des tranches) contiennent des tables de vérité permettant le calcul des fonctions logiques. Un CLB peut donc réaliser au maximum 8 fonctions logiques différentes, chacune sur 4 variables d’entrées différentes.

Registres Chaque mémoire (F ou G) peut fonctionner comme un registre a` décalage de 16 bits a` écriture synchrone mais a` lecture asynchrone. Les deux éléments mémoire peuvent cependant être utilisés pour une lecture synchrone depuis F et G. La lecture d’un poids particulier d’un registre fait a` l’aide des mémoires est effectuée par l’intermédiaire des variables d’entrée, en fait les 4 bits d’adresses des mémoires F ou G. Indépendamment de ce registre a` décalage, et donc des mémoires F et G, les R1 et R2 peuvent être utilisés pour la réalisation de différents types de registres a` lecture parallèle. Un registre de 8 bits nécessitera donc pour sa réalisation un seul CLB.

Mémoire Comme chaque CLB possède 8 mémoires de 16 bits, chacune des mémoires peut être organisée pour contenir des mots de 1, 2, 4 et 8 bits a` simple accès, ou en des mémoires de mots de 1, 2, 4 bits en double accès. L’adressage double, dans le cas d’un cycle d’écriture/lecture simultanées aux adresses différentes, est fait a` l’aide des deux bus supplémentaires W F et W G de mémoires F et G.

~~193 Annexe B. Circuits FPGAs Xilinx~~

Multiplexeurs Les mémoires F et G ainsi que les différents multiplexeurs associés au CLB permettent la réalisation des multiplexeurs de 4, 8, 16 et 32 canaux a` l’aide de 1, 2, 4 et 8 tranches respectivement.

Logique dédicacée pour l’arithmétique Chaque CLB ayant des ressources logiques spécifiques pour le calcul et la propagation du report (le bloc CY a` la Figure B.1) permet une implémentation très efficace des circuits arithmétiques tels qu’additionneurs ou soustracteurs. Il est ainsi possible de réaliser un additionneur ou un soustracteur complet sur deux mots d’un bit en tenant compte d’un éventuel report de l’étage précédent (Cin) a` l’aide de seulement une tranche de CLB. Le report généré est directement transmis a` la tranche supérieure Cout pour la construction des additionneurs ou des soustracteurs de mots codés sur plusieurs bits.

Calcul de SdP Chaque tranche possède une porte logique OU généralisée (notée ORCY ) ayant comme entrée le signal Cout de la tranche considérée et le même signal provenant de la tranche située immédiatement a` sa gauche (voir Figure B.2). Les sorties des différentes portes ORCY provenant des tranches adjacentes peuvent être mises en série. Il est ainsi possible de calculer aisément des expressions logiques de type somme des produits - SdP, sans pour autant consom- mer de CLBs supplémentaires pour calculer la somme après avoir calculé 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énéralisée par tranche du CLB.~~

~~B.1.3 Bloc de m´emoire RAM~~

Il s’agit de mémoires RAM d’une capacité de 18Kbits qui peuvent être exploitées en simple ou en double accès (cycles écriture/lecture simultanées sur des adresses différentes). Ces mémoires sont configurables et peuvent être organisées en mémoires 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émoire RAM est associé un circuit multiplicateur de deux mots de 18 bits. Plusieurs de ces circuits peuvent calculer de fa¸con simultanée la multiplication sur des données sauvegardées ailleurs dans le FPGA, mais sont optimisés pour les opérations sur des opérandes provenant des blocs de mémoire RAM. L’utilisation des circuits de multiplication s’avère particulièrement utile lors de l’implémentation des applications de traitement de signal,

~~194 B.1. Architecture des FPGAs Virtex caractérisées par un nombre important de cycles lecture - multiplication - accumulation de résultats.~~

Le nombre de circuits multiplicateurs (également des blocs de mémoire RAM) dépend de la taille et de la densité du circuit FPGA considéré. Ainsi nous disposons d’un multiplicateur et d’un bloc de mémoire RAM toutes les 4 lignes de CLBs et ceci toutes les 2, 4 ou 6 colonnes, en fonction de la densité 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ère permettant une gestion efficace des différents signaux d’horloge (Digital Clock Manager - DCMs) nécessaires au fonctionnement optimal d’un circuit logique réalisé dans un FPGA. Le rôle principale de cette ressource consiste a` générer des signaux d’horloge internes au FPGA mais parfaitement en phase avec les horloges sources venant de l’extérieur. Ainsi les délais de distribution du signal d’horloge dans les endroits éloignés de la source seront complètement éliminés. Grâce a` ces unités il est également possible de générer un grand nombre de fréquences d’horloge différentes, a` travers un ensemble des diviseurs/multiplicateurs de fréquence.

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ôle principal des blocs d’entrée/sortie (Input/Output Block - IOB) est d’assurer la communication entre la logique interne au FPGA et le monde extérieur au circuit et ceci pour l’ensemble des standards électriques les plus répandus.

Chaque IOB peut être programmé de fa¸con a` ce que la patte de circuit qui lui est associée puisse être utilisée soit comme une entrée, soit comme une sortie, soit les deux (une patte bidirectionnelle). Chaque IOB dispose également de 6 éléments mémoires configurables en tant que bascule D ou en tant que latch. Pour un mode de fonctionnement particulier de l’IOB (entrée, sortie ou bidirectionnelle) les deux éléments de mémoire permettent de doubler le débits de données entrantes/sortantes puisque leur synchronisation peut (en fait doit) être faite avec deux signaux d’horloge de même période mais déphasés de 180˚. Un tel signal d’horloge peut facilement être construit a` l’aide d’un DCM décrit plus haut.

~~B.1.7 R´eseau d’interconnexions~~

Le réseau d’interconnexions permet la réalisation des connexions (i.e. le routage) entre les différentes tranches au sein d’un même CLB, entre les différents CLBs, les DCMs, les multiplicateurs, la mémoire RAM et les IOBs utilisés pour la construction d’un circuit donné.

~~195 Annexe B. Circuits FPGAs Xilinx~~

Au sein d’un même CLB, les différentes tranches peuvent communiquer via des connexions rapides. Une matrice des connexions programmables (Programmable Switch Matrix - PSM) est associée a` chaque CLB, IOB, DCM, a` la mémoire RAM et au circuit multiplicateur. Le rôle de cette matrice est de réaliser une connexion programmée entre les conducteurs “entrants” et “sortants”. La programmation de la connexion est établie a` l’aide d’un mot de mémoire défini par la configuration. Grâce aux PSMs toute ressource peut donc accéder 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és entre les lignes et le colonnes des CLBs. Il en existe différents 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 également les connexions spécifiques de propagation du report déjà mentionnées 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és en clusters. A chaque cluster de CLB est associé un bloc de mémoire RAM et un circuit multiplicateur.

La Figure B.3 montre le cluster de CLBs du coin supérieur gauche d’un circuit FPGA. On peut y voir les IOBs associés, un cluster de 2 4 CLBs, la mémoire RAM et le multiplicateur × associé, le DCM et les matrices des connexions programmables PSM associées.

~~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éalisé au sein d’un FPGA dépendra : – des performances respectives de tous les éléments individuels du FPGA ; ce que nous désignerons comme la performance brute du circuit – des ressources effectivement utilisées pour la construction du circuit définitif.

En ce qui concerne la performance brute des FPGAs, la famille Virtex II propose pour chaque circuit particulier trois classes de performance notées : -4, -5, -6 ; -6 étant l’indice qui désigne 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érents éléments d’un FPGA Virtex II (d’après 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é totale des différentes mémoires RAM en Kbits, le nombre de DCMs, le nombre maximal de bornes d’entrée/sortie.

~~197 Annexe B. Circuits FPGAs Xilinx~~

Pour se faire une idée de cette performance, voici quelques données caractéristiques pour un circuit d’indice -6 : – le temps d’accès a` une mémoire F ou G est de 0.35ns lorsqu’elle fonctionne comme un générateur de fonctions logiques et de 1.63ns lorsque elle travaille en mode mémoire

~~– 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ète concernant la performance brute des différents éléments on peut se rapporter a` [Xil03d].~~

Pour un circuit donné, la performance va dépendre de sa complexité : le nombre et la position des blocs IOB, le temps de transmission des signaux depuis les entrées jusqu’à la logique combinatoire et/ou séquentielle, la vitesse avec laquelle celle-ci calculera les fonctions logiques réalisées a` l’aide d’un ensemble des mémoires 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émoire a` simple accès de 4096 mots de 4 bits fonctionne a` une fréquence d’horloge de 278MHz.~~

~~198 Annexe C~~

~~Architecture reconﬁgurable~~

~~C.1 Impl´ementation des circuits propos´ees~~

L’implémentation du système reconfigurable décrit dans le Chapitre 4 a été faite a` l’aide de la plate-forme de développement des FPGAs Xilinx : Integrated Software Environment 6.2. - (ISE). Cette plate-forme regroupe un ensemble d’outils permettant de faire la description et la synthèse, la vérification, l’implémentation et la vérification après l’implémentation (validation) des circuits destinés a` l’intégration dans des FPGA.

La Figure C.1 montre l’organigramme du flot de conception et les différents outils associés utilisés. Une telle approche a` l’implémentation est largement inspirée de la diverse documen- tation proposée par Xilinx (voir [Xil03h, Xil03a, Xil03c, Xil03b]), permettant de maximiser la performance des circuits réalisés, tout en minimisant le temps de développement, un facteur important lorsqu’il s’agit de construire des circuits a` la carte.

Description et synthèse Un circuit est d’abord décrit en langage VHDL et sa description vérifiée a` l’aide d’un simulateur, en l’occurrence le logiciel ModelSim XE II, version 5.7. A la description de circuit sont associés les différents stimuli (en fait les vecteurs de données a` l’entrée) sous forme des bancs d’essai, décrits également en langage VHDL. La description de circuit et le fichier de stimulus sont ensuite passés au logiciel de simulation, permettant d’effectuer une vérification fonctionnelle de la description.

Après la vérification de la description, la synthèse du circuit peut être effectuée a` l’aide de programme XST - Xilinx Synthesis Technology. Outre la possibilité de visualiser le circuit sous forme d’un schéma RTL, nous pouvons disposer d’une première estimation de la performance pour le circuit décrit. Bien entendu la performance donnée ne sera qu’une indication, car la performance réelle ne pourra être obtenue qu’après le placement et le routage définitifs.

Implémentation L’étape de synthèse fourni au processus d’implémentation un fichier contenant la description physique de circuit, sous forme d’un ensemble de primitives (briques de base) des circuits

~~199 Annexe C. Architecture reconﬁgurable~~

~~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és pour une implémentation physique des circuits décrits.~~

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émentation proprement dit, en fait les trois sous-étapes : translate, map et place and route, nécessitent la définition d’un ensemble de paramètres permettant de contrôler leur déroulement. Ces paramètres peuvent être classés en deux groupes distincts : les paramètres des programmes d’implémentation et les contraintes de la performance. 1. Paramètres des programmes d’implémentation Les paramètres liés aux différents programmes d’implémentation sont introduits via l’interface graphique de la plate-forme de développement 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é et le choix d’une des 100 différentes tables de coutsˆ utilisée pour le placement. L’influence de choix d’une table de coutˆ sur la performance de circuit définitif peut être significative car chaque table produira un placement particulier. Les expériences ont montré qu’une différence en performance de 30 % est possible, pour une même description de circuit mais pour les différentes tables de cout[Wha02ˆ ]. Lorsque l’on souhaite pousser la performance d’un circuit au maximum, alors l’implémentation peut être faite pour un certain nombre de tables de coutsˆ (ou toutes) dans une implémentation dite Multi-Pass Place and Route - MPR. La table de coutˆ offrant la meilleure performance serait alors retenue pour le placement et le routage définitifs. Pour les circuits décrits, l’implémentation d’un module de calcul avec les différentes tables de coutˆ n’a pas relevée des différences aussi significatives, la raison

~~200 C.1. Impl´ementation des circuits propos´ees~~

~~pour laquelle nous nous sommes limité a` la table des coutsˆ utilisée par défaut.~~

2. Les contraintes sur la performance de circuit que l’on souhaite obtenir sont introduites dans le processus d’implémentation 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ère. Pour les circuits synchrones, la spécification des contraintes peut être faite de manière globale (de telles contraintes sont valables pour le circuit eniter) a` l’aide de trois types de contraintes différentes : (a) Période minimale (fréquence maximale) - Cette contrainte agit sur le délai maximal qui peut y avoir entre tout élément synchrone source et tout élément synchrone destination. C’est donc la fréquence maximale avec laquelle le circuit synchrone peut fonctionner dans le FPGA. (b) Contrainte sur les entrées (Pad to setup time) - Comme le circuit FPGA re¸coit les données du monde extérieur, il faut également tenir compte de délais liés au transit de données depuis la frontière physique du FPGA (les pattes d’entrées) jusqu’au premier élément synchrone. Même si le premier élément synchrone se trouve dans un IOB du FPGA, ces délais sont néanmoins a` prendre en compte. (c) Contrainte sur les sorties (Clock to Pad) - Le même raisonnement est d’application pour les sorties du FPGA. La spécification des contraintes est faite en fonction de la complexité du circuit, de la performance brute du FPGA cible et des performances que l’on souhaite obtenir. Afin de fixer une performance réaliste pour le circuit, généralement après l’étape de mapping et avant le placement et le routage, on effectue une analyse des délais a` l’aide de l’outil Timing Analyser. A ce stade, une telle analyse nous donne l’information sur les délais introduits par la logique pure (en fait les délais introduit par des LUT s) et peut servir d’une première estimation de la performance du circuit final. Généralement on considère que le temps passé pour le calcul des fonctions logiques et le routage doit être partagé avec un rapport de 50-50 %. Une estimation correcte de la performance du circuit avant le placement et le routage évitera donc une perte de temps lié a` la tentative de l’implémentation d’un circuit avec des performances tout simplement impossibles d’atteindre. Les paramètres des programmes d’implémentation et les contraintes de la performance du circuit étant définis, le circuit peut être placé et routé dans le FPGA cible. Après le processus d’implémentation on peut aisément vérifier si les contraintes imposées ont été rencontrées oui ou non. Si ce n’est pas le cas, il faut alors affaiblir des contraintes imposées et refaire le processus d’implémentation. Nous sommes donc bien dans un cycle itératif des étapes : la définition des contraintes - l’implémentation - la vérification des résultats d’implémentation.

Validation Lorsque le circuit obtenu a rencontrés les contraintes imposées, le processus d’implémentation est terminé. La dernière étape consiste alors a` effectuer la validation de fonctionnement du circuit réalisé dans des conditions espérées. Cette vérification peut être faite de fa¸con matérielle, avec le circuit FPGA dans lequel on aurait chargé la configuration et qui on placerait dans un banc d’essai matériel. Mais cette vérification peut être également faite de fa¸con logicielle. Afin de réduire les coutsˆ (le temps) lié au développement des circuits intégrés en général, on

201 Annexe C. Architecture reconfigurable utilise de plus en plus des solutions logiciels permettant une vérification par simulation. Dans ce cas, un modèle physique de circuit, généré automatiquement sur base de l’information du circuit réalisé, est utilisé pour une simulation réaliste.

Comme nous n’avons pas disposé d’un circuit FPGA suffisamment dense pour effectuer une vérification matérielle, c’est la méthode de vérification par simulation qui a été utilisée.

Stratégies d’implémentation La description du flot de l’implémentation met en évidence deux objectifs opposés : un temps d’implémentation 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ésultant présente une performance particulière, l’effort d’implémentation (le temps) doit être plus important. C’est pour cette raison que nous avons adopté deux stratégies d’implémentation différentes : l’implémentation sous contraintes faibles et l’implémentation sous contraintes fortes.

1. Implémentation sous contraintes faibles Dans cette stratégie d’implémentation nous allons privilégier un temps d’implémentation court par rapport a` la performance du circuit. Elle sera utilisée systématiquement pour chaque circuit décrit, de fa¸con a` établir la quantité des ressources logiques nécessaires et une performance de circuit que l’on pourrait qualifier de minimale. Pour cette stratégie d’implémentation les paramètres des différents programmes utilisés pour l’implémentation sont tout simplement ceux par défaut, car ils garantissent le meilleur rapport entre le temps d’implémentation et la qualité des résultats 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ées a` des valeurs largement au dessous d’une performance maximale. Ces valeurs ont été déterminées de fa¸con empirique, en estimant grossièrement la complexité du circuit et en connaissant la performance brute de FPGA cible. En l’occurrence, quelque soit le type de circuit présenté nous avons toujours 20ns pour la période minimale et 10ns pour les contraintes sur les entrées et les sorties.

2. Implémentation sous contraintes fortes Dans cette stratégie d’implémentation l’objectif est de maximiser la performance de circuit final, et ceci au détriment d’un temps d’implémentation plus long, comme en témoignent les résultats pour le système reconfigurable complet, exposés a` la fin du Chapitre 4. Pour une implémentation sous contraintes fortes nous avons utilisé un effort maximal pour le processus de placement et de routage. En ce qui concerne les contraintes, elles sont dans un premier temps fixées a` des valeurs proches de celles obtenus par le processus de synthèse. Ensuite, elles sont progressivement affaiblies, jusqu’à ce qu’elle ne soit pas rencontrées par le processus d’implémentation.

~~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écrites correspondent deux plans de bits suivants, codés en décimal :~~

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écrits. La Figure C.3 montre le chronogramme de fonctionnement d’une unité de traitement calculant le filtre de rang (la valeur médiane pour le 5 5 et r = 36 pour × le 7 7) a` l’aide de l’algorithme par élimination. La Figure C.4 montre le chronogramme de × calcul de filtre médian pour les deux voisinages décrits en utilisant l’unité de traitement basée sur l’algorithme de Danielsson.

~~203 Annexe C. Architecture reconﬁgurable~~

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 ﬁltres 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 0~~

~~1 7 1 3~~

~~0 3 5 1 2 1 2 r= 0 Med.~~

~~0 0~~

~~4 0~~

~~0 8 1~~

~~0 1 6 3 0 8 2 1 r=~~

~~1 r= 0~~

~~5 0~~

~~1 9 1~~

~~1 7 1 3 111 2 1 r= 0 r= 0~~

~~1 6~~

~~0 9 0 1 1 2~~

~~0 4~~

~~1 1 28~~

~~0 r=~~

~~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~~

~~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 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 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 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 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é de traitement calculant le filtre de rang généralisé (l’algorithme par élimination) pour les voisinages de 5 5 et de 7 7 pixels. × ×

~~205 Annexe C. Architecture reconﬁgurable~~

~~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é de traitement calculant le filtre médian (l’algorithme de Danielsson) pour les voisinages 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é qu’il est possible de réaliser après le processus de placement et de routage une simulation réaliste du circuit réalisé 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èrement automatique, générer un modèle de circuit qui tient compte des délais réels introduits par une implémentation physique.

Le modèle généré, ainsi que le fichier de banc d’essais propre a` une simulation physique sont passés au logiciel de simulation, le même que celui utilisé pour la simulation fonctionnelle (ModelSim). Pour le modèle généré et le banc d’essai fourni, le simulateur vérifie qu’aucune violation des temps requis pour un fonctionnement correcte de circuit ne s’est produit au cours de la simulation (des éventuels erreurs sont communiquées a` l’utilisateur).

Nous présentons ici les résultats de la simulation des modèles de deux modules de traitement, calculant le filtre Max et le filtre médian (l’algorithme de Danielsson) dans un voisinage de 3 3 pixels. La taille de la fenêtre du module de traitement (Fx) a été fixé a` 10 pixels. × Pour les deux simulations, la vitesse d’horloge a été fixé a` 67 MHz, permettant un débit de 54 MPx/sec.

Le fichier de banc d’essai (le même pour les deux modules), écrit 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ées sur 8 bits), de mettre les données aux format nécessaire pour le traitement (lecture pixel par pixel, ligne par ligne), de passer les données a` traiter au modèle du module de calcul et effectuer la simulation.

Les pixels calculés (l’image traité) sont ensuite écrits dans un fichier de résultat, de même format que l’image a` traiter. En utilisant un logiciel de manipulation et de traitement des images, il est ensuite possible de vérifier le résultat obtenu.

Les Figures C.5 et C.6 illustrent les résultats 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être successives.

~~– La bande de résultat, obtenue après le traitement, l’agrandissement sur les lignes correspondantes des fenêtres traitées.~~

~~– La partie du chronogramme de fonctionnement d’un module de traitement correspondant au traitement des fenˆetres successives indiqu´ees.~~

Pour les deux modèles de circuit et les bancs d’essai fourni, le processus de simulation n’as rapporté aucune erreur de simulation. Les fichiers des images de résultat montrent bien l’effet du filtrage.

207 Annexe C. Architecture reconﬁgurable 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ésultats de la simulation du modèle de circuit obtenu après 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ésultats de la simulation du modèle de circuit obtenu après le placement et le routage. Module de calcul de filtre médian (l’algorithme de Danielsson) pour un voisinage de 3 3 pixels. ×

~~209 Annexe C. Architecture reconﬁgurable~~

~~210 Glossaire~~

API Application Programming Interface ASIC Application Specific Integrated Circuit Bit-série voir p.101 Bit-parallèle voir p.101 CCD Charge Coupled Device CISC Complex Instruction Set Computer CLB Configurable Logic Bloc CLE Cellule logique élémentaire 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être 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émoire 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être PBV Plan de bits du voisinage Process voir p.49 RAM Random Access Memory RISC Reduced Instruction Set Computer Réseau de tri voir p.106 SISD voir p.27 SIMD voir p.27 SSE Streaming SIMD Extensions Thread voir p.49 UAL Unité arithmétique 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 enhancement. 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écis 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ès. 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öhm, 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és par des assertions. PhD thesis, L’Université de Nice - Sophia Antipolis U.F.R. Faculté 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 Microprocessors With Focus on PA-8700, April 2000. [Hil02] D. Hilbert. Sur les problèmes futurs des mathématiques : les 23 questions. Gauthier- Vilars réimpr.Sceaux, Gabay, 1902. Comptes rendus du IIème Congrès International de mathématiques 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ècles de mécanique 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ème Congrès de la Société Internationale de Morphologie Mathématique, 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ézier 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 simd extensions 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~~