à Mohamed SHAWKY pour m'avoir patiemment …shawky/hanifi/rapport_these_hanifi.pdf · 3.2 PHASE DE...
Transcript of à Mohamed SHAWKY pour m'avoir patiemment …shawky/hanifi/rapport_these_hanifi.pdf · 3.2 PHASE DE...
i
Une thèse ne peut être menée à bien que dans un environnement scientifique adéquat et sans
le soutien d'amis. Je tiens donc à exprimer ma gratitude à tous ceux qui ont bien voulu prendre
sur leur temps pour m'aider. Mes plus vifs remerciements vont :
en premier lieu au professeur Florent CHAVAND, pour m'avoir accueilli dans le laboratoire
CEMIF et pour avoir mis à ma disposition les moyens matériels nécessaires ;
à Claude BARRET, d'avoir accepté de m'encadrer ;
à Mohamed SHAWKY pour m'avoir patiemment conseillé et dirigé et qui a toujours su se
montrer enthousiaste pour mes réalisations ;
à Edwige PISSALOUX, Dominique MEIZEL et Didier DEMIGNY qui ont bien voulu être
mes rapporteurs et ce malgré leur charge de travail ;
enfin à tous les membres du laboratoire CEMIF pour leur bonne humeur et à tous mes
camarades (M'HENI Zoher, groupe des H etc.).
Djamel
ii
RESUME
Générateur d’architectures pour plate-forme reconfigurable dédié au
traitement d’image
’une des évolutions de la thématique «architectures informatiques dédiées au
traitement du signal et de l’image » conjuguée avec l’avancement technologique a
apporté des solutions communément appelées ‘systèmes de traitement
reconfigurables’ (Reconfigurable computing, Custom Computing), basées sur les
technologies des composants reprogrammables à haute densité (FPGA).
Le gain de performance réalisé par ce genre d’architectures – si le parallélisme massif est
convenablement exploité - peut atteindre 100 à 1000 par rapport à un système traditionnel,
équipé d’un processeur à gros grain (µP classique ou DSP).
Or, l’effort de parallélisation et d’adaptation de l’algorithme habituellement fait par le
programmeur, en vue d’une implantation matérielle, demeure difficilement conceptualisable
pour le rendre systématique.
Dans le but d’apporter une contribution à cette problématique, nous nous sommes basés sur
une description procédurale de l’algorithme, dans un langage dédié au traitement de l’image
et faisant suffisamment abstraction du support technologique.
Nous avons développé un environnement de génération d’architectures (PERCIP
Programming Environment on Reconfigurable Components for Image Processing), qui, à
partir d’une description de l’algorithme en langage Apply, génère l’architecture équivalente
L
iii
sous forme de VHDL structurel, en s’appuyant sur un ensemble de cellules élémentaires et en
les organisant selon un modèle d’évolution des calculs de type systolique.
Les tests comparatifs ont montré les avantages et les limites d’une telle approche. Néanmoins,
cela nous a aidés à mieux appréhender la méthodologie de conception de ce genre
d’architectures.
Finalement, PERCIP nous a permis de prototyper rapidement une application industrielle de
filtrage d’images numériques couleurs, de qualité de diffusion (broadcast), en utilisant le filtre
médian hybride.
Mots clés : FPGA, traitement d’image, réseaux systolique, compilateurs, architectures
parallèles pour le traitement d’image.
iv
TABLE DES MATIERES
INTRODUCTION................................................................................................................................................. 1
CHAPITRE 1 : TRAITEMENT D'IMAGE ET ARCHITECTURES PARALLÈLES ETRECONFIGURABLES ........................................................................................................................................ 3
1 INTRODUCTION.............................................................................................................................................. 4
2 TRAITEMENT D’IMAGE ............................................................................................................................... 4
3 PARALLÉLISME ET IMAGE......................................................................................................................... 5
4 ARCHITECTURES PARALLÈLES ............................................................................................................... 8
5 ARCHITECTURES RECONFIGURABLES................................................................................................ 11
5.1 EXEMPLE DE FPGA : FPGA DE XILINX...................................................................................................... 12
5.2 SYSTÈMES RECONFIGURABLES.................................................................................................................... 15
5.2.1 PAMs : Programmable Active Memories ........................................................................................... 15
a. Système DECPeRLe-1.......................................................................................................................................... 17
b. Programmation des PAMs.................................................................................................................................... 19
5.2.2 Système Splash 1................................................................................................................................. 20
Programmation de Splash 1...................................................................................................................................... 22
5.2.3 Système Splash 2................................................................................................................................. 23
Programmation du système Splash 2 ........................................................................................................................ 25
6 CONCLUSION................................................................................................................................................. 26
INTRODUCTION............................................................................................................................................... 28
1 INTRODUCTION............................................................................................................................................ 30
1.1 HISTOIRE ET NÉCESSITÉ DU VHDL ............................................................................................................. 31
2 MODÉLISATION EN VHDL......................................................................................................................... 31
3 TYPES DE MODÉLISATION EN VHDL .................................................................................................... 32
3.1 VHDL COMPORTEMENTAL ......................................................................................................................... 33
3.2 VHDL STRUCTUREL ................................................................................................................................... 34
3.3 VHDL RTL (REGISTER-TRANSFER-LEVEL) ............................................................................................... 38
4 CONCLUSION................................................................................................................................................. 39
v
1 INTRODUCTION............................................................................................................................................ 41
2 EXEMPLE : LE FILTRE DE SOBEL........................................................................................................... 42
3 ARGUMENTS D’UNE PROCÉDURE APPLY............................................................................................ 43
4 GESTION DES BORDS .................................................................................................................................. 45
5 TYPES DE DONNÉES .................................................................................................................................... 46
6 MOT-CLÉ SAMPLE....................................................................................................................................... 46
7 CONCLUSION................................................................................................................................................. 48
1 APPROCHE TRADITIONNELLE DE L’IMPLANTATION CÂBLÉE ................................................... 50
2 STRUCTURE GÉNÉRALE D’UN COMPIL-ATEUR ................................................................................ 52
3 GÉNÉRATEUR D’ARCHITECTURES DE PERCIP ................................................................................. 55
3.1 PHASE D’ANALYSE ...................................................................................................................................... 55
3.2 PHASE DE SYNTHÈSE ................................................................................................................................... 56
3.3 RÈGLES DE SYNTHÈSE ................................................................................................................................. 56
3.3.1 tbni linéaires....................................................................................................................................... 57
a. Modèle FIR........................................................................................................................................................... 58
b. Modèle systolique................................................................................................................................................. 59
b.1 Principe de fonctionnement du réseau........................................................................................................... 60
b.2 Preuve formelle ............................................................................................................................................. 62
b.3 Utilisation du réseau pour le calcul simultané de deux filtres ....................................................................... 63
b.4 Extension au calcul simultané de plus de deux filtres ................................................................................... 65
c. Techniques d’optimisation.................................................................................................................................... 66
c.1 Bibliothèque .................................................................................................................................................. 67
c.2 Optimisation de l’additionneur ...................................................................................................................... 69
3.3.2 tbni non linéaires ................................................................................................................................ 70
a. If sans imbrication ................................................................................................................................................ 70
b. If à deux niveaux d’imbrication............................................................................................................................ 71
4 CONCLUSION................................................................................................................................................. 74
1 INTRODUCTION............................................................................................................................................ 75
2 FILTRE DE SOBEL........................................................................................................................................ 76
3 FILTRE MÉDIAN ........................................................................................................................................... 82
3.1 ARCHITECTURE BASÉE SUR UN TRI COMP-LET ............................................................................................ 89
3.2 FILTRE MÉDIAN HYBRIDE ............................................................................................................................ 92
vi
4 COMPARAISON ENTRE DES IMPLANTAT-IONS AVEC PERCIP ET MANUELLES ..................... 97
5 MOYENS DE VALIDATION DES ARCHIT-ECTURES GÉNÉRÉES..................................................... 98
5.1 VALIDATION PAR SIMULATION.................................................................................................................... 98
5.2 CARTE PAMETTE ......................................................................................................................................... 99
6 CONCLUSION......................................................................................................................................... 101100
CONCLUSION ET PERSPECTIVES ............................................................................................................ 102
SYNTAXE DU LANGAGE APPLY................................................................................................................ 104
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Introduction 1
INTRODUCTION
a recherche de la puissance de calcul a donné naissance à différents types
d’ordinateurs. En particulier, de nombreuses machines parallèles ont vu le jour
depuis le début des années 80. On peut citer pour exemple Warp [Annaratone 87] et
CLIP7A [Fountain 88]. Comparée à un ordinateur conventionnel, une machine parallèle
présente notamment une difficulté particulière quant à sa programmation. Avec l’apparition
des FPGAs, vers le milieu des années 80, les architectes ont conçu des systèmes hybrides dont
la partie reconfigurable se charge des calculs lourds. Cette partie a pris une telle ampleur que
ces systèmes de traitement ont eu l’aspect d’être complètement reconfigurables. Splash2
[Buell 96] est un exemple de cette évolution.
Un ordinateur est un système de traitement de l’information composé d’une partie matérielle
et d’une partie logicielle. Cette définition paraît simpliste ; pourtant, elle met en évidence, les
deux composantes d’un système générique de traitement de l’information. La couche
logicielle entraîne des possibilités de modification et, par conséquent, de la souplesse. A
contrario, la couche matérielle entraîne de la rigidité. La conception de machines
reconfigurables, quoiqu’elle soit encore dans son adolescence, fait se déplacer la limite
matériel/logiciel au profit du logiciel. En effet, les machines reconfigurables offrent de
nombreuses possibilités de modification, y compris celle du modèle de programmation. Or, le
modèle de programmation d’un ordinateur conventionnel, notamment celui de von Neuman,
s’avère inadéquat pour certaines applications. Cependant, en contrepartie des degrés de liberté
plus élevés offerts par rapport à ceux des machines de la précédente décennie, leur
programmation s'est compliquée davantage ; surtout pour des utilisateurs non-architectes qui
veulent profiter des performances offertes par cette nouvelle technologie, sans entrer dans sa
L
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Introduction 2
structure interne. En effet, les machines reconfigurables, qui pénètrent timidement le monde
industriel, disposent actuellement d’un support logiciel moins développé que celui des
machines classiques. La difficulté de programmation des plates-formes reconfigurables et la
croissance prometteuse des circuits FPGA nous ont incité à mettre au point l'environnement
de génération d’architectures PERCIP (Programming Environment on Reconfigurable
Components for Image Processing).
Le premier chapitre commence par évoquer le lien étroit entre les architectures parallèles et le
traitement d’image. Les principes et les notions de base des architectures parallèles sont
ensuite rappelés. Une panoplie de machines parallèles classifiées, dédiées généralement au
traitement d’image, est présentée. Nous présentons ensuite les machines reconfigurables, en
commençant par détailler l’élément technologique qui a permis la mise au point de ce genre
de machines : le FPGA. Plusieurs systèmes reconfigurables sont décrits par la suite.
Le second chapitre, quant à lui, expose en détail les langages utilisés pour la description des
applications de traitement bas niveau d’image (TBNI) et des architectures correspondantes :
Apply et VHDL. Nous commençons par justifier le choix d’Apply ; ensuite nous donnons les
spécifications de ce langage. Puis nous décrivons les différents types de modélisation en
langage VHDL et nous présentons la notion de synthétisabilité.
Le chapitre 3 décrit l'environnement PERCIP. Pour mieux éclaircir la difficulté de
"programmation" ou plutôt d’utilisation des plates-formes reconfigurables, nous rappelons
dans un premier temps le cycle de développement classique d’une application en vue d’une
implantation matérielle et nous évoquons les problèmes relatifs à ce cycle itératif. Nous
détaillons ensuite le générateur d'architectures, les règles de passage d’une description Apply
à une implantation câblée, les modèles d’exécution choisis et quelques techniques
d’optimisation utilisées.
Sont présentées dans le chapitre 4, différentes applications TBNI avec leurs implantations, en
utilisant PERCIP. Une étude détaillée du filtre médian y est exposée.
Enfin, nous tirons nos conclusions sur ce travail et nous évoquons les perspectives de
recherches et de développement dans le domaine des architectures reconfigurables.
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'image et architectures parallèles et reconfigurables 3
CHAPITRE 1
TRAITEMENT D’IMAGE ET
ARCHITECTURES PARALLELES
ET RECONFIGURABLES
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'image et architectures parallèles et reconfigurables 4
1 INTRODUCTIONLes champs d’application du traitement numérique de l’image sont, aujourd’hui, extrêmement
variés : multimédia, télévision numérique, imagerie satellite, imagerie médicale ou militaire,
vision industrielle, etc. Ces domaines entraînent de nombreuses applications comme la
gestion de base de données images, la compression d’images fixes ou animées en vue de leur
stockage ou leur transmission, l’analyse et la reconnaissance d'objets, etc…
Une chaîne classique de traitement d’image comporte des éléments d’acquisition de l’image,
puis des étapes de filtrage, d’extraction de paramètres (contours, formes, …) et, selon les
applications, des étapes de reconnaissance et de prise de décision. En allant du début de la
chaîne vers sa fin, la quantité de données traitées décroît, entraînant ainsi une décroissance
notable de la puissance de calcul requise. Parallèlement et inversement, la complexité des
algorithmes s’accroît. Aussi règnent en maître, au début de cette chaîne, des approches de
type ASIC ou FPGA, effectuant un nombre important de GOPS. Inversement, les machines
programmables, éventuellement parallèles à base de processeur à granularité grosse
(DSP, …), sont plus adaptées aux algorithmes utilisés à la fin de la chaîne, où la puissance de
calcul se mesure en MIPS. En effet ces machines gardent leur caractère "générique", ce qui
entraîne une certaine flexibilité.
2 TRAITEMENT D’IMAGEEn raison de la nature bidimensionnelle des images, la structure de données de base
manipulée en traitement d’image est un tableau qui représente la distribution spatiale des
valeurs de luminance (niveaux de gris ou couleur). Comme illustré par la figure 1, trois
niveaux de traitement d’image peuvent être distingués : le bas niveau, le niveau intermédiaire
et le haut niveau. Notons que les limites entre ces niveaux, notamment celles du niveau
intermédiaire avec les autres, sont quelque peu floues.
La majorité des algorithmes de bas niveau (TBNI) consiste en l’application d’un ensemble
d’opérations en chaque point de la structure des données image ; cela permet de réaliser ces
opérations en parallèle pour chaque élément du tableau.
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'
Dans ce travail nous nous sommes intéressés au traitement de bas niveau, à cause de la
simplicité relative d'automatiser la parallélisation de ses algorithmes et par conséquent la
facilité de génération d'architectures (câblées). Par ailleurs, le TBNI se compose de deux
catégories d’algorithmes : les algorithmes linéaires et les algorithmes non-linéaires. Dans la
catégorie des algorithmes linéaires nous pouvons citer les masques de convolution tels que les
filtres de Sobel ou de Prewitt [Horaud 93]. Dans la catégorie des algorithmes non-linéaires
nous avons utilisé un filtre très répandu dans le débruitage d’images : le filtre médian. Deux
variantes de ce filtre existent : le médian pur et le médian hybride.
3 PARALLEToute manipulation d’ima
de calcul inhérent à de
capacité de traitement d’
un contexte temps réel
techniques de parallélisat
Ainsi les contraintes tem
Haut niveau
(Reconnaissance des formes
Niveau intermédiaire
Bas niveau
e
Figure 1 : Niveaux du traitement d’imagimage et architectures parallèles et reconfigurables 5
LISME ET IMAGEge met en jeu un volume considérable de données, aussi le volume
nombreuses applications de traitement d’image excède souvent la
une machine conventionnelle. Le problème s’accentue encore dans
(suivre le taux vidéo par exemple). Fort heureusement, plusieurs
ion peuvent être appliquées aux algorithmes de traitement d’image.
porelles non respectées par une machine conventionnelle seront
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'image et architectures parallèles et reconfigurables 6
respectées par des architectures mieux adaptées ou, si nécessité il y a, des architectures
"taillées sur mesure".
Pour traiter une image sur une machine parallèle, son partitionnement sur les processeurs de
la machine est indispensable. Selon la topologie d'interconnexion du réseau des processeurs
de la machine, l'approche de partitionnement de l'image diffère. A titre d'exemple, la
topologie grille, la plus proche de la structure bidimensionnelle de l’image, permet une
correspondance directe pixel-processeur. Etant donnée la taille importante des images traitées,
une telle correspondance entraîne forcément une machine massivement parallèle. Or, toutes
les machines ne le sont pas, et de ce fait elles disposent d’un nombre de processeurs inférieur
à la taille des images traitées. Aussi un découpage de l'image s’impose. Supposons que la
dimension du réseau est n x n processeurs et que la taille de l’image est de m x m pixels
( )mn < . Deux approches sont possibles dans ce cas (figures 2 et 3) :
1. La première consiste à affecter à chaque processeur une sous-image de taille m/n x m/n.
2. La seconde est l’approche la plus couramment utilisée. Elle consiste à distribuer l’image
entre les processeurs en mémorisant chaque pixel (i, j) d’une sous-image de taille n x n
dans le même module mémoire. L’image est donc préalablement divisée en sous-images
de taille n x n.
Avant d'entamer les architectures reconfigurables, nous commençons par parler, ci-dessous,
des architectures parallèles classiques.
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traiteme
m
image m xréseau de n x n processeurs
nt d'image et architectures parallèles et reconfigurables
m
m/n
)
m/n
Figure 2 : Division de l’image en blocs m/n x m/n (1ere approche)
image m x
n
n
m/n
m/n
module
sous-image
module
Figure 3 : Division de l’image en blocs n x n (2ème approche
n
n
7
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'image et architectures parallèles et reconfigurables 8
4 ARCHITECTURES PARALLELESTout d’abord, nous présentons quelques notions de base des architectures parallèles : le mode
de fonctionnement des machines et la topologie d’interconnexion de leur réseau. En suivant
une approche basée sur la multiplicité ou l’unicité des flots de contrôle et de données, quatre
modes de contrôle des ordinateurs (architectures parallèles ou non) peuvent être énumérés :
SISD, SIMD, MIMD et MISD (classification de Flynn) :
• SISD pour Single Instruction Single Data stream : le mode séquentiel traditionnel,
où une suite d’instructions est exécutée sur un seul flot de données. Ce mode ne
fait évidemment pas partie du monde des architectures parallèles.
• SIMD pour Single Instruction Multiple Data streams : dans cette première forme
de parallélisme une même suite d’instructions est exécutée simultanément sur
plusieurs flots de données. Autrement dit, à un instant donné chacun des
processeurs de la machine exécute la même instruction sur des données différentes.
• MIMD pour Multiple Instruction Multiple Data streams : comme son nom
l’indique, plusieurs suites d’instructions s’exécutent simultanément sur plusieurs
flots de données.
• MISD pour Multiple Instruction Single Data stream : l’approche suivie conduit
logiquement à ce dernier mode de fonctionnement, bien que cette forme de
parallélisme reste théorique. Dans ce mode plusieurs suites d’instructions sont
exécutées sur le même flot de données.
Ces modes ont servi de critères pour la classification de Flynn introduite en 1970. Des critères
qui s’avèrent très insuffisants pour établir une classification fine de toutes les machines
parallèles actuelles. D’autres modes de fonctionnement très adaptés au traitement d’image
existent : le pipeline et le systolique. Ces modes ne sont pas exclusifs avec les quatre modes
cités précédemment. En effet, une machine peut avoir, à titre d'exemple, à la fois un mode de
fonctionnement systolique et MIMD. C'est le cas de Warp par exemple [Annaratone 87].
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'image et architectures parallèles et recon
D’autres critères peuvent être pris en compte pour classer les machines parallèles : la
topologie du réseau d’interconnexion, l’autonomie des processeurs, leur structure interne et
l’arithmétique supportée. Les topologies d’interconnexion, l’un des critères importants, sont
variées : grille, tore, anneau, réseau linéaire, pyramide, hypercube etc. La figure 4 illustre
quatre d’entre elles.
Une panoplie de machines parallèles, utilisées dans le traitement d’image, classifiées selon
trois critères (le mode d'exécution, la topologie d’interconnexion et l’arithmétique supportée)
est illustrée par la figure 5.
Les machines présentées sur la figure 5 ont toutes un mode de fonctionnement et une
topologie du réseau d’interconnexion fixes, excepté le tore polymorphique qui intègre la
notion de réseau configurable. Cependant, cette configurabilité reste très limitée. En effet, ces
machines présentent une certaine rigidité. L’apparition de l’élément technologique FPGA a
entraîné la naissance d’une nouvelle génération de machines : les machines reconfigurables,
présentées ci-dessous.
u
e
En grille
En annea
En pyramid
figu
En hypercube
Figure 4 : Topologies de connexion
rables 9
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'image et architectures parallèles et reconfigurables 10
mode detopologie exemplesarithmétique
MIMD
multi étage
hypercube
grille
linéaire
flottant
flottant
flottant
flottant
PASM (université Purdue, 81) multi-SIMD
NCUBEiPSCVICTOR (IBM) à base de transputer
WARP (CMU, 1986)
pipeline linéaire bit-série
entier
Cytocomputer (inst. Rech. Michigan, 81)
PIPE
SIMD
n-cube
pyramide
tore
grille
linéaire
bit-série
bit-série
bit-série
bit-série
entier
Connection Machine
SPHINX (Orsay)
YUPPIE (IBM, 88)
DAP (76)CLIP4 (Londres, 80)MPP (NASA, 80)GAPP (NCR, 84)BLITZEN (NCSU, 90)
AIS-5000 (87)
CLIP7 (Londres, 82)SLAP (Fisher, 88)Sympati 2 (CEA, IRIT, 90)
Princeton (centre rech. SARNOFF, 89)
bit-série
Figure 5 : Classification des machines de traitement d’images
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'image et architectures parallèles et reconfigurables 11
5 ARCHITECTURES RECONFIGURABLESL’objectif des architectures reconfigurables est non seulement de pouvoir modifier les
interconnexions entre les différentes parties du système, mais surtout d'adapter la partie
opératoire à l'application. Plusieurs technologies existent pour doter un circuit de la propriété
de (re)configurabilité (cellules RAM statiques (SRAM), anti-fusibles, transistors EPROM et
transistors EEPROM, etc). Ces technologies diffèrent par le moyen par lequel les entités
modifiables par l’utilisateur peuvent être interconnectées. La technologie qui permet la
reconfigurabilité la plus rapide est celle des cellules SRAM. Dans cette approche, pour
permettre la personnalisation du circuit, des transistors de passage, des transistors d’une porte
de transmission ou encore les entrées de sélection d’un multiplexeur, comme illustré sur la
figure 6, sont commandés par des cellules SRAM. La technologie des cellules SRAM est
utilisée dans les circuits FPGA de plusieurs constructeurs (Xilinx, Algotronix, Concurrent
Logic, Altera, etc). En guise d’exemple, nous détaillons ci-dessous les FPGAs de Xilinx.
Cellule RAM
Ligne Ligne
Transistor de
Cellule RAM
LigneLigne
Porte de
Cellule RAM
Cellule RAM
MUX
Lignes
Vers les Cellules
Figure 6 : Principe d'interconnexion des CLBs
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement
5.1 EXEMPLE DE FPGA : FPGA DE XILINX
C’est en 1985 que la société Xilinx a introduit, pour la première fois, les composants
électroniques de type FPGA. Les FPGAs de cette société ont eu, de 1985 à 1994, une
croissance de 35% par année en vitesse, 55% par année en densité et une diminution de 46%
IOB
IOB
CLB CLB CLB CLB
CLB CLB CLB CLB
CLB CLB
CLBCLB
CLB CLB
CLB CLB
S S
S
S
S
SS
S
Plan de cellules SRAM Ressources d’interconnexion
Matrice d’interrupteurs
Figure 7 : Structure de base d’un composant FPGA
d'image et architectures parallèles et reconfigurables 12
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'image et architectures parallèles et reconfigurables 13
par année en coût par fonction [Xilinx 94]. En effet, comme ceux des autres constructeurs, ces
composants ne cessent de s’améliorer et sont, par conséquent, très prometteurs.
Vu par l’utilisateur, un FPGA de Xilinx est formé essentiellement de trois éléments : les blocs
logiques appelés CLB, les blocs d'entrée/sortie (IOBs) et un réseau de routage qui comprend
des connexions locales directionnelles, des connexions globales traversant verticalement ou
horizontalement tout le circuit, et enfin des aiguillages pour router les liaisons à travers le
réseau. Cette structure de base est illustrée par la figure 7. Les FPGAs de Xilinx diffèrent
principalement, d'une famille à l'autre, par la complexité interne des CLBs. Comme illustré
par la figure 8, les CLBs des familles XC3000 et XC4000 se composent d’une partie
combinatoire et de deux éléments mémoire (bascule). La partie combinatoire du CLB de la
famille XC4000 consiste en deux tables de correspondance (LUT) de 16 (24) bits chacune,
permettant ainsi d'implanter deux fonctions binaires quelconques à quatre variables. Quant au
CLB de la famille XC3000, il dispose d’une LUT à 32 (25) bits et permet, par conséquent,
d’implanter toute fonction combinatoire à 5 entrées.
Avant d’utiliser un composant FPGA, nous devons impérativement le configurer. Cette
configuration est en quelque sorte l’équivalent de la configuration des registres d’un
périphérique programmable. Le processus de configuration consiste au chargement d’un
fichier de bits dans le FPGA à configurer, via le réseau sous-jacent de configuration,
transparent à l’utilisateur. Le fichier de bits, appelé bitstream dans la terminologie Xilinx, est
généré après compilation, avec les outils logiciels Xilinx (XACT par exemple), de la
description textuelle ou schématique du circuit-application. La taille du bitstream dépend du
type du composant utilisé et non pas du circuit-application. La famille XC4000 utilise environ
350 bits de configuration par CLB et interconnexions associées [Xilinx 94]. A titre
d’exemple, la configuration d’un XC4025 nécessite un bitstream contenant 422168 bits, quel
que soit le circuit-application. Notons tout de même que la taille du circuit-application ne doit
pas dépasser la capacité du composant cible. Le temps de configuration est aux alentours de
1µs par bit. La configuration prend alors de quelques millisecondes à une centaine de
millisecondes.
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'image et architectures parallèles et reconfigurables
DIN
F’
DIN
MULTIPLEXEUR C
PROGRAMME DE
G3
G2
G1
G4FONCTION
LOGIQUE
DE
G’
FONCTION
LOGIQUE
DE
H’
DSD
EC RD
C1 C2 C3 C4
H1 DIN S/R EC
CONTRÔLE
CONTRÔLEF3
F2
F1
F4FONCTION
LOGIQUE
DE
F’
F’G’H’
G’H’
H’
K(HORLOGE)
CLB de la famille XC4000
F’G’H’
1
1
DSD
EC RD
Figure 8 : Schéma bloc des CLBs des familles XC3000 et XC4000
F
D
CLB de la f
DERIVATION
QYQ
Y
XQ
DERIVATION
ONTRÔLE PAR LE
CONFIGURATION
X
Q
X
Fonction
QX
QY
G
D
QRD
F
D
INam
Q
F
G
AB
C D E0
M
1
UX
D QRD
0
M
1
UX
F
D
ING
VARIABLESLOGIQUES
ENTREEDES DONNEES
DI
1 (AUTORISE)
VERROUILLAGED’HORLOGE
EC
HORLOGE
KRESETDIRECT
R
0 (INHIBE)
ille XC3000
RESETGLOBALX
Y
SORTIESDU CLB
14
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'image et architectures parallèles et reconfigurables 15
5.2 SYSTEMES RECONFIGURABLES
Grâce aux circuits FPGAs, la mise au point de systèmes reconfigurables est devenue possible.
En effet, dès la fin des années 80, des chercheurs architectes ont commencé à développer cette
nouvelle forme de machine. Ces machines, appelées PAM (Programmable Active Memories)
dans [Vuillemin 95] ou CCM (Custom Computing Machine) dans [Buell 96], sont détaillées
dans le paragraphe suivant. Nous présentons ensuite, en suivant une certaine logique de
présentation, les réalisations majeures des systèmes reconfigurables, mis au point au cours de
cette dernière décennie. En effet, pour chaque réalisation nous commençons par décrire le
système puis nous insistons sur l'esprit architectural de la programmation des systèmes
présentés, qui diffère de notre approche : utilisation d'une description procédurale des
applications.
5.2.1 PAMS : PROGRAMMABLE ACTIVE
MEMORIES
L’appellation PAM rapproche cette nouvelle forme de coprocesseur des mémoires RAM.
Branchées, elles aussi, sur un bus à haute vitesse de l’ordinateur hôte, les PAMs peuvent être
assimilées à des mémoires actives. Elles doivent cette caractéristique au fait qu’à la différence
d’une RAM, la PAM traite les données entre les instructions d’écriture et de lecture. Un
système type à base de PAM est, comme illustré dans la figure 9, composé d’un ordinateur
hôte, d’une matrice de composants reconfigurables et de la mémoire locale propre à la partie
reconfigurable. L’une des fonctions de l’hôte est de charger les fichiers de configuration
(bitstreams) dans la PAM. Après cette configuration, la PAM se comporte électriquement et
logiquement comme un ASIC défini par les fichiers de configuration (bitstreams), qui peuvent
être mis à jour par l’hôte en quelques millisecondes ; ce qui justifie le qualificatif
"programmable".
Trois modes de fonctionnement d'une PAM sont possibles. En effet, elle peut fonctionner
dans un mode autonome, dans lequel la PAM sera reliée à un système externe via les liens in’
et out’ (cf. figure 9). Elle peut également fonctionner comme un coprocesseur, sous le
contrôle de l’hôte, ayant comme rôle l’accélération de quelques calculs cruciaux. Elle peut
enfin fonctionner dans les deux modes et connecter ainsi l’hôte à des systèmes externes, tels
que des composants audio, vidéo ou une autre PAM.
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Ch
Ra
est
cop
leu
qua
nou
cla
bén
plu
coû
ma
la p
con
L’a
le f
Les
dan
sté
hau
t
’
Ordinateurapitre 1 : Traitement d'image et architect
jouter du matériel spécifique à une mach
une idée qui a donné naissance
rocesseurs matériels ne servent à rien qu
r. A titre d’exemple, un coprocesseur
nd le système effectue des tâches tel
velle forme de coprocesseurs, consti
ssiques. En effet, une PAM profite des a
éficie par conséquent de la souplesse d
sieurs applications, la technologie des PA
t, par rapport aux autres technologies
ssivement parallèles et les machines con
uissance de calcul virtuellement dispon
ventionnels d’un facteur de 10 à 100
ugmentation du taux d’intégration des c
ossé entre les processeurs conventionnel
domaines d’utilisation des PAMs sont
s le calcul arithmétique, la cryptograp
réovision, la compression vidéo, la synth
te énergie, la thermodynamique, la biolo
Tableau de
FPGA
RAM locale propre à la
partie reconfigurable
In
ures parallèles et recon
ine conventionnelle, p
aux coprocesseurs c
and le système effectu
dédié à la compressio
les que la cryptograp
tuée par les PAMs,
vantages des deux mo
u logiciel et des perfo
Ms a montré sa supér
, y compris les supe
ventionnelles. En 199
ible sur une PAM dép
0, en fonction de l’
ircuits intégrés accroît
s et les PAMs.
très variés. En effet, ce
hie, la correction d’er
èse de son, les réseaux
gie et l’astronomie.
In’
OuOut
figurables
our accélé
lassiques.
e une tâch
n vidéo n’
hie ou la
diffère de
ndes, logic
rmances d
iorité, en p
rcalculateu
2, à des co
assait celle
application
, en terme
s derniere
reur, l’ana
de neuron
Composants
Configuration
Figure 9 : Structure générale d’un système à base de PAM
16
rer le traitement,
Cependant, ces
e différente de la
aura pas de rôle
stéréovision. La
s coprocesseurs
iel et matériel, et
u matériel. Dans
erformance et en
rs, les machines
ûts comparables,
des processeurs
[Vuillemin 95].
de performance,
s ont été utilisées
lyse d’image, la
es, la physique à
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traiteme
Un composant expérimental des PAMs a été réalisé au sein du laboratoire DEC-PRL1 en
1992 : DECPeRLe-1, présenté ci-après.
a. SYSTEME DECPERLE-1Le DECPeRLe-1 est conçu à base de FPGAs Xilinx XC3090 (23 FPGAs). Ces composants
comportent 320 (16*20) CLBs [Xilinx 94]. Une douzaine de copies du système DECPeRLe-1
est fonctionnelle dans différents centres scientifiques dans le monde [Vuillemin 95]. Le cœur
de calcul du DECPeRLe-1 est une matrice de 16 (4*4) FPGAs (lettre M sur la figure 10).
Chaque FPGA est co
FPGAs de chaque li
partagé par les 4 FPG
bus de 64 bits trav
organisation est de m
effet, le DECPeRLe
d’étranglement des c
1Digital Equipmen
S
C E
>><<
SRN
C
Adaptateur
Les FIFOs
nt d'image et architect
nnecté via 16 connex
gne partagent alors un
As de chaque colonn
ersant le tableau ho
ieux extrapoler, au n
-1 ressemble à un g
onnexions, en raison
t Corporation’s Paris
adrNadr
ures parall
ions directe
bus de 16
e. Il en rés
rizontalem
iveau du P
rand FPG
du nombr
Research L
S
R
adr
M MM M RW
adrèles et reconfigurables
s à chacun de ses quatre vo
bits. Un bus de 16 bits es
ulte, en un sens, une config
ent et verticalement. Le b
CB, la structure interne du
A de 64*80 CLBs, except
e moins important des fils
aboratory
M MM
M MM
M MM
M
M
M
S
S R
E
adrS
adradrS
adrW
Figure 10 : Architecture du DECPeRLe-1
17
isins. Les 4
t également
uration de 2
ut de cette
FPGA. En
é le goulot
, comparé à
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'image et architectures parallèles et reconfigurables 18
celui de l’intérieur du FPGA, disponibles sur le PCB. Par ailleurs, avec l’avancement de la
technologie des FPGAs, l’équivalent du DECPeRLe-1 est actuellement disponible sur une
seule puce.
La PAM DECPeRLe-1 est également équipé de 4 MB de RAM statique organisée sous forme
de 4 bancs indépendants de 256K mots de 32 bits (1 MB) chacun (représentés par la lettre R
sur la figure 10). Les 18 bits d’adresses et les signaux de lecture/écriture de chaque RAM sont
générés dans l’un des deux FPGAs contrôleurs (lettre C, figure 10). Les données destinées à
ou en provenance de chaque RAM passent par le FPGA switch correspondant (lettre S).
Pour communiquer avec l’ordinateur hôte et le monde extérieur, le DECPeRLe-1 dispose de 4
liens de 32 bits chacun. Trois d’entre eux (non représentés sur la figure 10) relient la matrice
des FPGAs aux connecteurs externes (monde extérieur). Ces connecteurs, qui peuvent
fonctionner à une fréquence allant jusqu’à 33 MHz, sont utilisés dans des applications temps
réel. Ils servent notamment à relier le DECPeRLe-1 à des dispositifs externes tels que les
dispositifs audio, vidéo ou autres. La bande passante globale des liens externes présente un
pic dépassant les 400 MB/s. Quant au quatrième lien, il relie le DECPeRLe-1 à l’ordinateur
hôte via un adaptateur à 100 MB/s. Afin d’éviter la synchronisation de l’horloge de la PAM
avec celle de l’hôte, les données en provenance de ou en partance pour l’hôte passent par deux
FIFOs, une pour chaque sens (PAM/hôte et hôte/PAM).
Un des FPGAs du DECPeRLe-1, appelé par les développeurs du système POM par analogie
avec les ROMs, n’est pas programmable par l’utilisateur. Ce FPGA assure entre autres les
premières communications de la PAM avec l’hôte (le firmware). En effet, ce composant aide
l’hôte à configurer la PAM (1,5 Mb pour le DECPeRLe-1). Le protocole logique du bus de
l’hôte est lui-même programmé dans la configuration de la POM. Une adaptation d'un format
de bus à un autre format (VME, HIPPI, PCI, etc.) est une simple reprogrammation de la
POM. Par ailleurs, il est possible de reconfigurer le DECPeRLe-1 jusqu’à 50 fois par seconde,
une caractéristique cruciale dans certaines applications.
Les circuits-applications destinés à la PAM sont des circuits synchrones. En effet, tous les
registres sont mis à jour à chaque cycle horloge. Ainsi, la vitesse maximale d’une application
est directement déterminée par le chemin combinatoire critique. Ce chemin variant en
fonction de l’application, il a été donc nécessaire de concevoir un système de distribution
d’horloge dont la vitesse est programmable comme une partie de la configuration de
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'image et architectures parallèles et reconfigurables 19
l’application. Sur le DECPeRLe-1 l’horloge peut être finement ajustée, avec des pas de
l’ordre de 0.01%, pour des fréquences allant jusqu’à 100 MHz.
Une application DECPeRLe-1 type reçoit un flot ininterrompu de données à travers la FIFO
d’entrée, effectue un certain traitement et fournit ses résultats à l’hôte via la FIFO de sortie.
Le remplissage et le vidage des FIFOs sont des tâches accomplies par l’hôte. Par ailleurs et
afin d’éviter de lire une FIFO vide ou d’écrire dans une pile remplie, il existe un mode de
fonctionnement du firmware dans lequel de telles opérations arrêtent automatiquement
l’horloge de l’application.
La combinaison de deux possibilités offertes par le DECPeRLe-1 constitue un outil de
débogage puissant et réduit radicalement, par conséquent, le besoin d’un logiciel de
simulation. La première est la relecture (readback) dynamique de l’état interne des registres
de chaque CLB, une des caractéristiques des XC3090. La seconde est la facilité de
manipulation de l’horloge. En effet, l’horloge principale peut être arrêtée et des cycles
d’horloge déclenchés un à la fois par l’hôte la remplacent. Cette combinaison nous permet
alors de prendre l’image de l’état interne complet du système après chaque cycle d’horloge.
b. PROGRAMMATION DES PAMS
Nous détaillons maintenant l'aspect programmation des PAMs. Un programme PAM est
décrit en C++ et compte trois parties :
• Le logiciel de commande : partie du programme, destinée à l’hôte, qui contrôle le matériel
proprement dit de la PAM.
• Les équations logiques : elles décrivent le circuit-application servant à configurer la carte
PAM.
• Les directives de placement/routage : cette partie, complémentaire des équations logiques,
guide l’implantation de ces dernières.
Pour décrire les circuits-applications, de nouveaux types de données plus appropriés ont été
définis. A titre d’exemple le type Net est utilisé pour décrire les équipotentielles du circuit.
Les opérateurs booléens à leur tour ont été surchargés pour la description de la logique
combinatoire, et d’autres primitives ont été rajoutées pour décrire des éléments tels que les
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chap
regis
techn
l’abs
addit
langa
la de
derni
L'évo
ordin
carte
5.2Pour
chaîn
la ma
sein
2S
template<int N>
struct RippleAdder : Block {
RippleAdder( ) : Block("RippleAdder"){}
void logic(Net<N>& a, Net<N>& b, Net<N>& c, Net<N>& sum, Net& carry) {
input(a) ; input(b) ; output(c) ;
output(sum) ; output(carry) ;
for ( int i 0 ; i < N ; i++){
itre 1 : Traite
tres. Bien qu
iques de pro
traction des
ionneur n-bi
ge procédura
scription de
er que de son
lution des P
ateur du com
est en effet d
.2 SYS
exécuter un
es) utilisé po
chine spécif
du SRC2, Di
upercomputi
+
Figure 11 : Description d'un circuit additionneur en C+ment d'image et architectures parallèles et reconfigurables 20
e cette description soit de bas niveau, elle est allégée par l’utilisation des
grammation de base comme les tableaux, les boucles for, les procédures et
données. La figure 11 illustre un exemple de code représentant un
t à retenue propagée. Bien que le langage de description utilisé soit un
l de haut niveau (C++), la description reste très architecturale. Par exemple,
l'additionneur présenté sur la figure 11 est plus proche de la structure de ce
comportement.
AMs a donné naissance à une carte qui se place sur le bus PCI d'un
merce : la carte Pamette, utilisée comme plate-forme de PERCIP. Cette
étaillée dans le dernier chapitre.
TEME SPLASH 1 certain algorithme dit edit-distance (correspondance approximative des
ur la comparaison des séquences d’ADN, Dick Lipton de Princeton a réalisé
ique P-NAC (Princeton Nucleic Acid Comparator). Vers la fin de 1986 au
ck Kunze et Paul Schneck ont eu l’idée du système Splash 1. Dick Lipton,
ng Research Center renommé en mai 1995 Center for Computing Sciences
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'ima
Dick Kunze et Paul Schneck
machine P-NAC. Au printem
[Buell 96].
La carte Splash 1, achevée au
par les carrés 0 à 31 de la f
FPGAs de Splash 1, appelés
Les deux FPGAs X0 et X31
former un anneau. Pour la s
contrôlées par X0 et X31. P
mémoires RAM de 128K mo
Les XC3090 de Splash 1 pe
Pour s’adapter aux applicatio
généralement des problèmes
0
0
8
e
1
M
ge et arc
ont voul
ps de 19
début d
igure 12
X0 à X3
des extr
ynchron
ar ailleu
ts de 8 b
uvent at
ns lente
de place
4
M
3
M
2
M
4
M
5
M
6
M
u
1
i
i
t
s
7
M
8 0
9M
M11
M
1
M
5
12M
13
M
1
M
1
M
hitectures parallèles et reconfig
faire des machines Splash-like
87, l’essentiel de l’architecture
e 1989, est composée de 32 FPG
et se place sur le bus VME d’
, sont connectés linéairement p
émités du réseau peuvent être c
sation avec l'hôte, Splash 1 ut
rs, comme l'illustre la figure 1
ts chacune placée entre chaque
eindre une fréquence d’horlog
ne pouvant pas fonctionner à
ment/routage ou de l’incapacité
29
M
urables
une gén
de Spla
As XC3
une stat
ar un ch
onnecté
ilise une
2, Splash
paire de
e maxim
cette fré
du Bus
2
M
31
M
30
M
24
M
25
M
26
M
i
s
27
M
21
M
2
M
23
M
22
M
16
M
17
M
18
M
19
M
interface
interfaccontrôle
Bus VSB
Bus VMEFigure 12 : Architecture de Splash 1
21
éralisation de la
sh 1 a été défini
090 représentés
on Sun. Les 32
emin de 32 bits.
entre eux pour
paire de FIFOs
1 est dotée de
FPGAs.
ale de 32 MHz.
quence, à cause
VME de fournir
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'image et architectures parallèles et reconfigurables 22
des données à une vitesse suffisamment grande, la fréquence d’horloge peut être fixée à une
valeur comprise entre 1 et 32 MHz.
PROGRAMMATION DE SPLASH 1La programmation de Splash 1 faisait appel aux outils de développement du constructeur3 des
composants utilisés dans Splash 1. La description des circuits-applications passait à l’origine
par un éditeur supporté par le logiciel4 de ce constructeur. Plus tard, une interface graphique5
de saisie de schéma a été introduite dans la chaîne de développement. Cependant, des
difficultés considérables existaient toujours dans le développement des applications Splash 1,
particulièrement pour les utilisateurs peu habitués au développement matériel. L'utilisation
des outils de développement proposés par les constructeurs des composants n’est, par ailleurs,
pas facile. Afin de rendre la machine plus accessible, un langage de haut niveau appelé LDG6
a été mis au point au SRC [Buel 96]. Ce langage a quelque peu allégé la programmation et a
permis, par conséquent, d’échapper à quelques détails de bas-niveau du matériel ; mais la
programmation est restée tout de même une tâche non triviale. En effet, des problèmes
existaient à plusieurs niveaux de programmation, qui était toujours faite dans un contexte
matériel. A titre d’exemple, des éléments tels que les compteurs et les séquenceurs devaient
être explicitement construits et connectés aux unités logiques qui les contrôlent. Les
informations temporelles du circuit-application étaient difficiles à obtenir, et l’incapacité de
faire une relecture (readback) de l’état complet compliquait le processus de débogage. De
surcroît, le programme de placement/routage (APR7) utilisé constitue en lui-même un
problème. En effet, ce programme est lent et échoue souvent dans le routage complet du
circuit-application sur les composants. Il est souvent, sinon toujours, nécessaire que
l’utilisateur intervienne afin d’avoir des circuits-applications complètement routés avec des
vitesses d’exécution acceptables. Combler ces lacunes était un objectif majeur de l’évolution
de Splash 1 vers Splash 2, présenté ci-après.
3 Xilinx4 XACT5 L'interface de Viewlogic6 Logic Description Generator7 Automatic Place and Route : programme de placement/routage du logiciel XACT
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement
Encore une fois, le moyen de spécification des algorithmes utilisé pour la programmation de
Splash 1 est architectural nécessitant donc que la phase de transformation
algorithme/architecture soit réalisée par le programmeur.
5.2.3 SYSTEME SPLASH 2Le projet Splash 2 a commencé au sein du SRC en septembre 1991 et a été fini au printemps
de 1994. Le système Splash 2 est constitué de composants FPGA XC4010. Le XC4010
6
6
Carte élémentaire 1
Carte élémentaire 2s
Entrée externeoptionnelle
Sortie externeoptionnelle
M0
d'image
M1
X1
et arch
M2
X2
itecture
5
M3
X3
s paral
M4
X4
lèles et
M5
X5
reconfi
M6
X6
gurable
2
M7
X7
s
M8
X8
X16
M16
X1
M15
X14
M14
X13
M13
X12
M12
X11
M11
X10
M10
X9
M9
Jeu d’interrupteurs programmables (crossbar switch)
X0Extension
du SBus
36
3
36
3
Venant des
cartes
Bus SIMD
Vers les
cartes
RBus
Figure 14 : Architecture de la carte élémentaire de Splash
Carte élémentaire n
Station
Sparc
Carte
SBuSIMD
SBus
RBus
Figure 13 : Architecture de Splash 2
23
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'im
consiste en un tableau de 400 (20*20) CLBs [Xilinx 94]. Comme illustré sur la figure 13,
Splash 2 est composé d’un ensemble de cartes élémentaires, d’une carte d’interface et de
l’ordinateur hôte : une station Sparc. L’architecture du système est faite de sorte qu’il puisse
supporter jusqu’à 16 cartes élémentaires. Bien que la majorité des systèmes aient été réalisés
avec 2 ou 4 cartes, un système contenant 8 cartes a vu le jour et fonctionne correctement
[Buell 96].
La carte élémentaire de Splash 2, dont le schéma est présenté sur la figure 14, contient 17
FPGAs ; 16 d’entre eux, X1 à X16, forment le vecteur de traitement et sont connectés à la fois
linéairement par un chemin de données de 36 bits et par le jeu d’interrupteurs programmables
(crossbar switch). La présence de ce jeu d’interrupteurs permet au programmeur d’aller au-
delà de la structure rigide du chemin linéaire en faisant des sauts afin par exemple de
maintenir la synchronisation. Cette possibilité est rarement offerte par les machines
classiques. Par ailleurs, à chaque FPGA de la carte élémentaire est connectée une mémoire de
512 K octets.
La carte d’interface (figure 15) assure le lien entre l’ensemble des cartes élémentaires et
l’hôte. Les fonctions principales de cette carte sont : le contrôle du bus nommé SBus sur la
figure 13 et le transfert des données, la génération de l’horloge système et les pré- et post-
e
e
Horlog
age et architectures parallèles et
C
A
Banc
D
CanalCanal B
Canal
Mémoire
rec
XL
o
XR
36
25
32
36
25
nfigurabl
32
7
e
32
36
36
Entrée
externedresses
ADonnées
Sortie
xterne
s
Extension
du SBus
Bus SIM
RBus
Figure 15 : Architecture de la carte d’interface
24
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'image et architectures parallèles et reconfigurables 25
traitements des données à destination ou en provenance de l’ensemble des cartes élémentaires.
Les programmes destinés à Splash 2 sont chargés par l’ordinateur hôte dans le système via la
liaison Sbus. Les données provenant de l’hôte sont de taille 32 bits. Les chemins de données
de 36 bits, sur le système Splash 2 proprement dit, résultent de l’ajout des 4 bits d’étiquetage.
Bien que les données provenant des signaux externes puissent être de taille 36 bits, dans la
majorité des applications les bits d’étiquetage sont rajoutés ou lus par les FPGAs de la carte
d’interface : XL (Xilinx Left) et XR sur la figure 15. Le système Splash 2 dispose de deux
modes de fonctionnement (synchronisation du système Splash 2 avec l’hôte) : synchrone et
asynchrone. Dans un mode asynchrone, les bits d’étiquetage peuvent servir à indiquer la
validité des données. Les FPGAs des cartes élémentaires font alors passer ces données et ne
commencent le traitement que si une étiquette indiquant une donnée valide est détectée.
D’une façon similaire, le FPGA de la carte d’interface qui traite les sorties doit rejeter tout
résultat avant de recevoir une étiquette de donnée valide. Les bits d’étiquetage peuvent avoir
une autre utilisation dans le cas où la machine serait vue comme une machine SIMD. En effet,
les 4 bits supplémentaires sont considérés comme l’opcode de l’instruction. Cet opcode peut
être utilisé par X0 pour traiter les données ou contrôler la diffusion, comme pour toute
machine SIMD hiérarchique.
PROGRAMMATION DU SYSTEME SPLASH 2Pour la programmation de sa partie reconfigurable, Splash 2 utilise le langage VHDL et les
outils de CAO électronique du commerce. Afin d’assurer l’interface entre l’hôte et le reste du
système Splash 2, une partie logicielle a été mise au point. Cette partie, dédiée à l’hôte,
consiste en une bibliothèque C et un débogueur symbolique interactif. Le développement de
la partie de l’application dédiée à la configuration suit le cycle classique de développement
d’une application en vue d’une implantation matérielle. Ce cycle, détaillé dans le chapitre 3,
exige du programmeur une bonne connaissance du matériel. De surcroît, plusieurs itérations
sont généralement nécessaires avant de satisfaire les contraintes exigées. Le programmeur
doit, par ailleurs, partitionner lui-même son circuit-application sur les FPGAs. Une analyse
temporelle appliquée sur les résultats finaux est souvent nécessaire pour déterminer les
chemins critiques ainsi que la fréquence de fonctionnement maximale.
Même dans la seconde version de Splash et bien que le langage utilisé pour la description de
la partie de l'application dédiée à la configuration du système soit le VHDL (un langage de
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'image et architectures parallèles et reconfigurables 26
description de haut niveau), la description est demeurée architecturale et la parallélisation
manuelle.
6 CONCLUSIONLa présentation des systèmes reconfigurables a été volontairement précédée par celle des
architectures parallèles classiques, car à nos yeux ces systèmes sont une nouvelle génération
de machines parallèles. Il n'est par ailleurs pas nécessaire de présenter la totalité des systèmes
reconfigurables. C'est pourquoi nous avons présenté uniquement les réalisations majeures.
Avant d’entamer ces deux présentations, une partie a été consacrée au traitement d’image et à
son lien étroit avec les architectures parallèles. En effet, nous constatons que le mode de
fonctionnement SIMD est bien adapté au TBNI, la partie du traitement d’images à laquelle
nous nous sommes intéressés dans ce travail, puisque le TBNI se réduit à un certain nombre
d’instructions, généralement simples, exécutées simultanément sur l’ensemble des données
image (pixels). Par ailleurs, la simplicité des instructions se traduit par l’utilisation de
processeurs à granularité fine : processeurs dont le jeu d’instructions se réduit à quelques
instructions simples.
Plusieurs raisons militent en faveur des architectures parallèles spécialisées où le système est
"taillé sur mesure" pour une catégorie de problèmes sinon pour un problème spécifique :
nécessité d’atteindre la plus grande vitesse de traitement possible (temps réel), de compacter
le système (matériel embarqué), progrès de la technologie des circuits VLSI. Deux
possibilités se présentent : l’utilisation d’un système reconfigurable ou le développement d'un
système à base d’ASICs. Or, la leçon principale que les concepteurs des PAMs ont tiré de leur
expérience est que la programmation d’une PAM est beaucoup plus facile que le
développement d’ASIC [Vuillemin 95]. En effet, des étudiants sans un acquis électronique
fort sont capables d’utiliser ces systèmes après quelques semaines d’apprentissage, quand
seulement des ingénieurs hautement qualifiés sont capables de développer un système à base
d’ASICs.
Comparée à une machine conventionnelle, l’utilisation d’une machine parallèle est plus
difficile. A titre d’exemple, le débogage d’un programme nécessite la connaissance de l’état
interne de la machine. Or, il est difficile de garder mentalement l’image de l’état dans lequel
devrait être une machine parallèle. En outre, pour une implantation optimale, l’utilisateur doit
Générateur d'architecture pour plate-forme reconfigurable dédié au traitement d'image
Chapitre 1 : Traitement d'image et architectures parallèles et reconfigurables 27
effectuer une adéquation algorithme/architecture avant d’entamer l’implantation. Si les
machines parallèles présentent déjà des difficultés par rapport aux machines conventionnelles,
la tâche de l’utilisateur d’un système reconfigurable se complique encore davantage. En effet,
l’implémentation optimale dans ce cas exige une adéquation algorithme/"granularité". Par
granularité nous sous-entendons la granularité de la technologie et la granularité des calculs.
La granularité des supports technologiques reconfigurables tel que le FPGA est généralement
prédéfinie (le CLB dans le cas des FPGAs de Xilinx). Même si l’utilisateur arrive à la
meilleure adéquation de son algorithme avec la granularité du support technologique
reconfigurable, il a peu de contrôle sur le partitionnement du circuit-application sur le support
technologique, qui est effectué par les outils de CAO utilisés et précisément les outils de
placement/routage du constructeur. Quant à la granularité des calculs, l’utilisateur est libre
d’utiliser une arithmétique bit-série, entier ou à virgule flottante. Notons tout de même que la
capacité encore restreinte des FPGAs actuels, limite l’utilisation d’une arithmétique à virgule
flottante.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2 : Moyens de description : VHDL et Apply 28
CHAPITRE 2
MOYENS DE DESCRIPTION :
VHDL ET APPLY
INTRODUCTIONNous présentons dans ce chapitre, composé de deux parties distinctes, les langages utilisés
pour la description des applications TBNI et des architectures correspondantes : Apply et
VHDL. La première partie du chapitre traite du langage VHDL. Nous y détaillons, en nous
appuyant sur l’exemple d’un filtre FIR, les différents types de modélisation de ce langage.
Nous exposons ensuite notre conclusion sur cette partie et nous justifions la nécessité d'un
autre langage de haut niveau (Apply) pour la description des applications TBNI et le choix du
type de modélisation VHDL adopté pour PERCIP afin d’atteindre notre objectif : générer du
code VHDL synthétisable en partant d'une description procédurale (en Apply).
La seconde partie traite d'Apply. Nous commençons par justifier le choix de ce langage, puis,
à travers un exemple illustratif, nous expliquons l'approche de développement en utilisant
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2 : Moyens de description : VHDL et Apply 29
Apply. Les types de données et d’autres constructions spécifiques à Apply sont ensuite
présentés. La syntaxe complète du langage est donnée en annexe.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2 : Moyens de description : VHDL et Apply 30
Première partie
Langage de description des
architectures utilisé : VHDL
1 INTRODUCTIONA la mise au point de PERCIP, nous avons décidé d’en faire un générateur d’architectures.
Naturellement le choix du moyen de description des architectures générées s’imposait.
Plusieurs raisons militent pour le choix d’un langage de description de matériel de haut
niveau. En effet, choisir un format intermédiaire d’une chaîne de développement telle que
celle de Xilinx, comme le format XNF (Xilinx Netlist Format) ou LCA (Logic Cell Array),
entraîne le développement d’une ou de plusieurs parties d’un compilateur de silicium
(synthétiseur, routeur, etc.). Or, il est plus ingénieux d’utiliser un compilateur de silicium du
commerce complet, dont toutes les parties sont bien maîtrisées par ses constructeurs. De
surcroît, les formats intermédiaires sont peu compréhensibles et spécifiques au constructeur
de composants. Aussi cela compliquerait-il un éventuel portage vers d’autres technologies.
Pour toutes ces raisons nous avons choisi le langage VHDL, un langage standard (possibilité
de portage), de haut niveau et accepté par la quasi-totalité des chaînes de CAO du commerce.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2 : Moyens de description : VHDL et Apply 31
Dans cette partie, nous exposons à travers l’exemple d’un filtre FIR les différents types de
modélisation en VHDL. Mais tout d’abord nous commençons par l’historique et la nécessité
de ce langage.
1.1 HISTOIRE ET NECESSITE DU VHDLAu début des années 80 un phénomène nouveau apparaît : la technologie avance à une vitesse
telle que la durée opérationnelle des équipements s’est fortement réduite. Or, faire profiter à
ses systèmes des avancées scientifiques, est le souhait évident de tout organisme, dont le
Département de la Défense des Etats-Unis (le DoD). Cependant, la maintenance s’englue dans
des problèmes rendus insolubles par le nombre important de fournisseurs, la diversité des
calculateurs et la variété des langages utilisés. La dépendance vis-à-vis du fournisseur n’a
cessé de s’accroître, jusqu'à devenir stratégiquement insupportable par le DoD, qui a aussitôt
senti la nécessité d’une description non ambiguë des systèmes matériels et logiciels. La
solution fut alors la normalisation de langages puissants et suffisamment généraux pour
couvrir tout le champ des besoins. Ce sera Ada pour le logiciel et VHDL pour le matériel.
Une fois cette normalisation effectuée, il ne restera qu’à mettre derrière cette norme toute la
puissance du DoD (énorme en termes de dollars et de marchés).
Nés de préoccupations similaires, et parrainés par le même organisme, VHDL et Ada vont
avoir de grandes ressemblances. Ada est le langage de programmation qui ressemble le plus à
VHDL et, réciproquement, VHDL est, sans conteste, le langage de description de matériel le
plus proche d’Ada. IEEE a pris ensuite les droits de standardisation : le standard IEEE1076.
2 MODELISATION EN VHDLQuand le DoD a décidé de faire de VHDL le langage de description de matériel du projet
VHSIC8, VHDL était destiné naturellement à la micro-électronique. Paradoxalement, ce
langage s’élève bien au-dessus du cadre des circuits intégrés pour s’appliquer aux cartes de
composants et même à des systèmes entiers comprenant à la fois des parties matérielles et des
parties logicielles.
8 Very High Speed Integrated Circuits
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2 : Moyens de description : VHDL et Apply 32
Entrée
Sortie
tmp2tmp1
Une description VHDL se compose de deux entités : l’entity et l’architecture. L’entity est
une vue externe du système à modéliser. C’est en quelque sorte l’équivalent du prototype
d’une fonction en C. L’architecture, quant à elle, détaille le fonctionnement du système en
question. Analogie oblige, l’architecture est l’équivalent du corps d’une fonction C.
Un même système peut être modélisé en VHDL de différentes façons. Nous détaillons ci-
dessous les différents types de modélisation en VHDL.
3 TYPES DE MODELISATION EN VHDLPrincipalement trois types de modélisation peuvent être distingués : le comportemental, le
structurel et le RTL (Register Transfer Level). Ces termes n’ont nullement été définis par le
standard IEEE 1076. Aussi leurs définitions sont-elles vagues et varient. Néanmoins les
définitions présentées ci-dessous sont communément admises. Afin de mieux distinguer les
trois types, la définition de chacun d’eux est accompagnée de la description dans ce type d’un
filtre FIR, dont le diagramme est illustré sur la figure 16. Comme le type de modélisation
intervient au niveau de l’architecture, l’entity du filtre est la même, excepté dans le cas d’une
description comportementale, où des signaux de bas niveau (horloge et reset) ne figurent pas.
L’entity est alors donnée une seule fois pour les deux types structurel et RTL.
Z-1 Z-1 Z-1++
Coefficient1
1
Coefficient2
2
Coefficient3
3
Figure 16 : Diagramme du filtre FIR
Multiplieur
Z-1 Elément de retard
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2
3.1 VHDL COMPORTEMENTAL
Le VHDL comportemental est un type de codage qui décrit le comportement du circuit-
application. En effet, ce type a tendance à faire abstraction du matériel et garde par
conséquent une certaine distance par rapport à l’électronique. La figure 17 illustre la
description comportementale du filtre FIR.
A première vue, le programme de la figure 17 ressemble à n’importe quel programme écrit en
un langage procédural classique. Cependant VHDL présente une différence capitale : ce que
l’on appelle les instructions concurrentes. En effet, deux instructions concurrentes
"s’exécutent" simultanément. Ainsi l’ordre de présentation des instructions est sans
importance. C’est pourquoi nous avons volontairement présenté les lignes (13, 14 et 15) dans
cet ordre, alors que dans un langage où les instructions s’exécutent d’une façon séquentielle,
ces lignes devront être dans l’ordre inverse : (15, 14, 13). La règle des instructions
concurrentes est toujours valable en VHDL, excepté dans certaines constructions
séquentielles tels que les processus (process), les fonctions (function) ou les procédures
(procedure).
entity fir_filter is -- 1
port(entree : in integer; -- 2
sortie : out integer); -- 3
end fir_filter; -- 4
-- 5
architecture comportementale of fir_filter is -- 6
constant retard : time 100 ns; -- 7
constant coefficient1 : integer := 1; -- 8
: Moyens de description : VHDL et Apply 33
Figure 17 : Description comportementale du filtre FIR
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2 : Moyens de description : VHDL et Apply 34
3.2 VHDL STRUCTUREL
A l’inverse du type de modélisation comportemental, le type structurel décrit la structure du
circuit-application. En effet, dans ce type de modélisation le codage consiste à tisser
l’architecture à partir d’un certain nombre de cellules élémentaires. C’est en quelque sorte,
une façon textuelle de dessiner le schéma du circuit-application. Aussi le code de la figure 19
est-il l’image textuelle du schéma de la figure 18. Notons que les cellules élémentaires
utilisées dans le code de la figure 19 sont à ce niveau uniquement déclarées (lignes 9 à 23).
Leurs descriptions sont données plus loin dans le code de la figure 20. Par ailleurs, ce type de
modélisation est très utilisé dans la génération automatique de code VHDL par les outils de
CAO du commerce.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2 : Moyens de description : VHDL et Apply 35
1
Add2
Add1Mul1
Mul3
Mul2
a
b*
a
b+
a
b*
a
b*
3
2
d
clkreset
q
d
clkreset
q
d
clkreset
qa
b+
Reg3Reg2
Reg1
Figure 18 : Schéma de la description structurelle du filtre FIR
Prod2
Prod3
Prod1Tmp1
Som1
Tmp2
Som2 Sortie
Reset
Horloge
Entrée
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapit
entity fir_filter is --1
port(entree : in integer; --2
sortie : out integer; --3
horloge : in bit; --4
reset : in bit); --5
end fir_filter; --6
--7
architecture structurelle of fir_filter is --8
component reg --9
port ( d : in integer; --10
clk, reset : in bit; --11
q : out integer); --12
end component; --13
--14
component mul --15
port ( a, b : in integer; --16
s : out integer); --17
end component; --18
--19
dd
re 2 : Moyens de description : VHDL et Apply 36
Figure 19 : Description structurelle du filtre FIR
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre
Fig
entity reg is
port ( d : in integer;
clk, reset : in bit;
q : out integer);
end reg;
architecture behav of reg is
begin
process(reset, clk)
begin
if (clk’event and clk = ‘1’) then -- front montant de l’horloge
if(reset = ‘1’) then q <= 0; -- mise à zéro
else q <= d;
end if;
end if;
end process;
end behav;
2 : Moyens de description : VHDL et Apply 37
ure 20 : Description comportementale des cellules élémentaires utilisées dans la
description structurelle
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2
3.3 VHDL RTL (REGISTER-TRANSFER-LEVEL)
Parce que la majorité des outils de synthèse logique du commerce exige un VHDL RTL pour
effectuer une synthèse "correcte", ce type de codage est le type le plus communément utilisé.
La principale caractéristique de ce type est le fait d’expliciter l’horloge et les mémorisations
dans la description. Sur le code de la figure 21, correspondant à la description RTL du filtre
FIR, les conditions sur le signal d’horloge figurent au niveau de la ligne 14, où un front
montant est attendu pour exécuter la suite des instructions.
Le code de la figure 21 mérite, par ailleurs, une explication plus détaillée. En effet, en VHDL
dans un process les instructions suivent une opération séquentielle. Or, à première vue ce
code semble ne pas modéliser le filtre FIR, puisque la sortie semble être calculée uniquement
à partir de l’entrée à un instant (t) donné. Cependant, VHDL réserve un traitement spécial
architecture RTL of fir_filter is -- 1
constant coefficient1 : integer := 1; -- 2
constant coefficient2 : integer := 2; -- 3
constant coefficient3 : integer := 3; -- 4
signal tmp1, tmp2 : integer; -- 5
-- 6
begin -- 7
process(reset, horloge) -- 8
begin -- 9
: Moyens de description : VHDL et Apply 38
Figure 21 : Description RTL du filtre FIR
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2 : Moyens de description : VHDL et Apply 39
pour les signaux dans un process. En effet, les signaux dans un process ne se mettent à jour
qu’à la sortie de ce dernier. Aussi la ligne 17 utilise-t-elle la valeur de tmp2 à l’instant (t-1)
pour calculer la sortie. Quant à la ligne 16, elle utilise, à l’instant (t-1), la valeur de tmp1 à
l’instant (t-2) pour calculer tmp2. Ainsi la sortie sera calculée à partir des valeurs de l’entrée
aux instants t, (t-1) et (t-2) ; ce qui modélise bien le filtre FIR.
4 CONCLUSIONLes trois sous-ensembles VHDL : VHDL comportemental, VHDL structurel et VHDL RTL,
peuvent être représentés comme illustré dans la figure 22. En effet, une description en VHDL
ne peut être à la fois comportementale et structurelle. Cependant, les deux autres
combinaisons sont possibles : structurel et RTL ou comportemental et RTL. Par ailleurs, le
sous-ensemble structurel ne va pas jusqu’au bas de la hiérarchie. En effet, les composants
élémentaires finaux utilisés dans une description structurelle ne sont jamais écrits dans un
type de modélisation structurel. Une description structurelle est souvent utilisée au plus haut
niveau de la hiérarchie.
Un point crucial mérite d’être analysé : la "synthétisabilité" du code VHDL. Ce que nous
appelons synthétisabilité est l’existence d’une description au niveau porte correspondant au
code VHDL. Commençons par le type de modélisation comportemental. Bien que ce type
offre plus d’abstraction vis-à-vis du matériel, ce qui est l’objectif d’un langage de haut niveau,
le comportemental est le type qui assure le moins la synthétisabilité. Le RTL est
VHDL VHDL
VHDL R.T.L.
(Register Transfer Level)
Niveaux
de
Figure 22 : Sous-ensembles du VHDL
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2 : Moyens de description : VHDL et Apply 40
"théoriquement" un type qui assure la synthétisabilité car il est assez proche de l’électronique.
Toutefois, avec les outils de synthèse du commerce actuels, des difficultés notables existent
encore lors du processus de synthèse. Ainsi, la synthétisabilité n’est pas toujours assurée.
Quant au structurel, il assure naturellement la synthétisabilité puisque c’est l’utilisateur qui
fait le travail de l’outil de synthèse.
Comme la synthétisabilité du code généré était notre principal objectif, pour la mise au point
de PERCIP, nous avons choisi le type structurel avec des cellules élémentaires décrites en
VHDL comportemental ou RTL. Ces cellules ont été toutes synthétisées par l’outil de
synthèse dont nous disposons9 pour s’assurer de leur synthétisabilité.
Bien que le VHDL soit un langage de haut niveau, nous étions obligés de choisir un autre
langage pour la description des applications TBNI. En effet, VHDL est inadéquat pour
l'approche que nous avons adoptée, qui consiste à contourner la parallélisation des
algorithmes en fixant au préalable des modèles d’exécution appariés à l’ensemble des
algorithmes considérés : le systolique et le FIR, détaillés dans le chapitre 3. L'esprit du
langage VHDL, même comportemental, reste plus architectural que procédural. Le langage de
description que nous avons choisi est orienté image et est à esprit procédural. Il s'agit d'Apply,
qui est présenté dans la seconde partie de ce chapitre.
9 AutologicII de Mentor Graphics
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2 : Moyens de description : VHDL et Apply 41
Seconde partie
Un langage orienté image : Apply
1 INTRODUCTIONLes systèmes de traitement reconfigurables peuvent atteindre, si le parallélisme massif est
convenablement exploité, un gain de performance de 100 à 1000 par rapport à une
architecture parallèle classique. Cependant, la contrepartie de ce gain est la difficulté de
programmation de ces nouveaux systèmes. Pour remédier à ce problème, une abstraction du
matériel est indispensable. Aussi nous était-il indispensable de trouver un langage offrant
assez d’abstraction pour la spécification des algorithmes de manière procédurale séquentielle.
VHDL, même comportemental, reste plus architectural que procédural. En outre, le langage
recherché devait être orienté TBNI et son niveau d’abstraction devait décharger le
programmeur de la gestion des entrées/sorties, puisque cette dernière sera de toute manière
dictée par le moyen d’acquisition et le taux vidéo.
Apply, langage développé par un groupe de chercheurs de l’université Carnegie Mellon
[Hamey 89], a été notre choix pour satisfaire ces exigences. La philosophie d’Apply est d’être
fortement lié au domaine d’application (le TBNI) et de rester le plus abstrait possible vis-à-vis
de la machine. Des tâches reproduites systématiquement, pour tout algorithme de TBNI,
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2 : Moyens de
comme le cas de la
première plate-forme d
d’autres machines, ont
qu’on appelle machine
Une centaine d’algorit
citées ci-dessus [Walla
Nous expliquons ci-de
Apply.
2 EXEMPLL’utilisateur d’Apply
pixels de l’image. En e
la fenêtre, noté (0,0). C
Les programmes Appl
"--" dans l’exemple de
des lignes n’est pas
programme.
La procédure Sobel c
d’entrée inimg, de la c
de type array of byte
Le mot-clé border raj
l’image. Dans cet exem
des constantes, le cas
donnée invariable pour
1 2 1
0 0 0
1 0 -1
2 0 -2
Sobel vertical Sobel horizontal
Figure 23-a : Coefficients du filtre de Sobel
description : VHDL et Apply 42
boucle de balayage, sont devenues alors implicites dans Apply. La
’implantation d’Apply est la machine Warp. Des compilateurs, pour
été mis au point par la suite. Ces machines sont, principalement, celles
s Warp-like et les machines ayant Unix comme système d’exploitation.
hmes de TBNI a été implantée, en utilisant Apply, sur les machines
ce 89].
ssous à travers un exemple l’approche de développement en utilisant
E : LE FILTRE DE SOBELn’a pas à expliciter que son traitement se fera pour l’ensemble des
ffet, toute procédure Apply est écrite en se référant au pixel central de
ela permet à l’utilisateur de se concentrer sur le fond du traitement.
y sont tous écrits sous forme de procédure, mot-clé procedure(). Les
la figure 23-b indiquent le début d’un commentaire. La numérotation
obligatoire, elle a été rajoutée pour simplifier l’explication de ce
omporte une liste de paramètres - ligne 1- constituée de la variable
onstante thresh et de la variable de sortie mag. La variable inimg, est
qui correspond à un tableau ; en l’occurrence une fenêtre de taille 3*3.
outé à la déclaration de l’entrée indique la façon de gérer les bords de
ple on étend l’image avec des zéros. Apply permet aussi la déclaration
de tresh dans notre exemple. Une constante au sens d’Apply, est une
toute l’image, contrairement à inimg qui est la valeur des pixels.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2 : Moyens d
3 ARGUMELes arguments d’une p
sorties (mot-clé out)
présentent aucune par
plus de précision. En
traduit, au niveau arch
règle. L’exemple de la
array(-1..1, -1..1) of b
de 3 lignes d’éléments
in array représente le
si une troisième dimen
procedure Sobel ( inimg : in array (-1. . 1, -1. . 1) of byte border 0, -- 1
thresh : const real,
mag : out real) is --2
horiz, vert : integer ; --3
begin --4
horiz := inimg(-1, -1) + 2 * inimg(-1, 0) + inimg(-1, 1) --5
- inimg(1, -1) - 2 * inimg(1, 0) - inimg(1, 1) ;
Figure 23-b : Version Apply du filtre de Sobel
e description : VHDL et Apply 43
NTS D’UNE PROCEDURE APPLYrocédure Apply peuvent être de 3 types : des entrées (mot-clé in), des
ou des constantes (mot-clé const). Les sorties et les constantes ne
ticularité, cependant la façon dont les entrées sont interprétées mérite
effet, un vecteur d’entrée (in array à une dimension) de taille N est
itecture, par N-1 éléments mémoire pipelinés. La figure 24 illustre cette
figure 23-b utilise, pour décrire un masque 3*3, la syntaxe "inimg : in
yte", qui est traduit, comme illustré dans la figure 25, par un ensemble
mémoire pipelinés. D’une façon générale, la première dimension d’un
s pixels d’une même ligne, la seconde les lignes d’une même image et
sion existe, elle représenterait les plans image.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2 : Moyen
procedure exemple(image : in array(-1..1) of byte,
sortie : out byte) is
begin
sortie := image(-1) + image(0) + image(1);
image(1) image(0) image(-1)
+
sortie
M M
Figure 24 : Interprétation d’un in array à une dimension
s
inimg(1,-1) inimg(0,-1) inimg(-1,-1)M M
inimg(1,0) inimg(0,0) inimg(-1, 0)M M
inimg(1,1) inimg(0,1) inimg(-1,1)M M
s
Figure 25 : Interprétation d’un in array à deux dimensionde description : VHDL et Apply 44
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2 : Moyens de descr
4 GESTION DES BORDSLa gestion des bords est une tâche, pour le moins, ambiguë. En pratique, elle est laissée au
programmeur qui décide de dupliquer les bords, les mettre à 0 ou à une autre valeur. Par
ailleurs, cette tâche est commune à tout algorithme de TBNI. C’est pourquoi Apply l’intègre
et ainsi décharge le programmeur de ces détails. A cet effet, un mot-clé approprié a été défini :
border. Suivi d’une expression (expression peut être un entier ou une opération sur des
entiers), border permet d’ét
être utilisé avec le mot-clé m
illustré par la figure 26, aprè
(0, 1) seront égales.
)
)
)
)
)
) )
)
)
))
)
P(0,0)
iption : VH
endre l’ima
irrored p
s utilisation
)
P(1,0)
P(1,1)
P(0,0
P(0,0
P(0,1
P(0,0
P(0,1
g
o
P(1,0
P(0,1
P(1,1P(1,0
P(1,0
P(1,1)
P(0,1
P(1,1DL et Appl
e avec la v
ur duplique
de border
P(2,0)
P(2,0)
P(0,2
Figure 26 : Image résultat de border mirrored
y 45
aleur de l’expression. Il peut, également,
r les bords. A titre d’exemple, et comme
mirrored les valeurs des pixels (-1, -2) et
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2 : Moyens de description : VHDL et Apply 46
5 TYPES DE DONNEESLa syntaxe originale d’Apply compte 3 types de donnée : byte, integer et real. La capacité
limitée des FPGAs ne nous a pas permis d’utiliser le type real. Quant aux deux autres types, il
nous a paru raisonnable de traduire un byte, type adapté à la représentation des données pixel,
par une donnée 8 bits et un integer par une donnée 16 bits ; les deux ont une représentation en
complément à deux. Par ailleurs, Apply propose le mot-clé signed pour désigner les nombres
signés, et unsigned pour les entiers naturels. Pour des raisons de simplicité, le mot-clé
unsigned est ignoré, ce qui induit, au niveau des architectures générées, des données toujours
signées (représentation en complément à deux).
6 MOT-CLE SAMPLELe traiteur d’image est parfois amené à réduire ou augmenter la taille de ses images. Par
ailleurs, Apply, de par sa nature, décrit les traitements au niveau pixel ; ce qui implique une
certaine inaccessibilité à l’image entière et par conséquent l’impossibilité de modifier la taille
des images. Pour combler cette lacune, Apply propose le mot-clé sample. Utilisé au niveau
des arguments d’une procédure Apply, sample(s1, s2) est interprété comme suit :
Le pixel (0, 0) occupera les positions (0, 0), (0, s2), ..., (0 n*s2),..., (m*s1, n*s2).
Notons au passage qu’un sample(1, 1) est équivalent à une déclaration sans sample.
Pour mieux illustrer le mécanisme de sample les figures 24 et 25 présentent des exemples
utilisant sample(2,2) pour réduire et agrandir l’image originale d’un facteur 4. L’exemple de
la figure 27 réduit une image de taille N*N, en attribuant à chaque pixel de sortie la moyenne
d'une fenêtre 4*4 de l'image d'entrée, en une image de taille N/2*N/2. L'agrandissement de
l'image, illustré par l’exemple de la figure 28, est effectué par la génération d’un tableau pour
chaque pixel central, en utilisant une interpolation linéaire.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2 : Moyens
procedure reduce(image : in array(0..3, 0..3) of byte sample(2,2),
sortie : out byte) is
sum : integer;
i, j : integer;
begin
sum := 0 ;
procedure
begin
sortie(0
Figure 27 : Procédure Apply de réduction
d
t
magnify(image : in array(-1..1, -1..1) of byte
border morrored,
sortie : out array (0..1, 0..1) of byte) is
, 0) := (image(-1, -1) + image(-1, 0)
+ image(0, -1) + image(0, 0)) / 4;
Figure 28 : Procédure Apply d’agrandissemen
e description : VHDL et Apply 47
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 2 : Moyens de description : VHDL et Apply 48
7 CONCLUSIONSimple, plus intuitif pour le traitement d’image : ce sont les remarques qui nous traversent
l’esprit lors de la lecture d’un programme Apply. Hélas, ce langage a ses limites. Puisqu’il a
été conçu pour le TBNI, son utilisation est, naturellement, inadéquate pour la description
d’algorithmes de traitement de niveau intermédiaire ou de haut niveau d’image. En effet, des
algorithmes tels que la transformée de Hough [Zhou 95], la FFT ou l’histogramme, sont
difficiles sinon impossibles à écrire en Apply.
Quelques constructions du langage Apply sont inadaptées à l'automatisation de la génération
d'une architecture câblée à partir d'une description procédurale. Ce sont les boucles, le mot-clé
border, le mot-clé sample et le type real. Pour les boucles, leur suppression n’a pas un grand
impact sur l’ensemble des algorithmes de TBNI à décrire, puisque tous ces algorithmes
peuvent être décrits sans avoir recours à ce type de construction. La gestion des bords,
nécessite la génération d’une logique supplémentaire, qui est fonction de la façon dont les
bords sont gérés et de la taille des opérateurs de TBNI décrits. Cette logique présente une
certaine irrégularité, du moins l’automatisation de sa génération n’est pas évidente. Le mot-
clé sample influe au niveau architecture sur l’échantillonage, ce qui est également
difficilement automatisable. Le type real, quant à lui, dépend de la capacité des FPGAs. Les
prochaines générations de FPGAs vont permettre l’intégration de ce type de données.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’environnement PERCIP 49
CHAPITRE 3
ENVIRONNEMENT PERCIP
Outre l’utilisation des systèmes reconfigurables, un environnement de génération
d’architectures a pour objectif la facilité d’utilisation de ces systèmes. Les plates-formes à
base de FPGAs, de par la complexité de leur utilisation, ont particulièrement besoin de cette
facilité. Nous avons constaté que la grande majorité des environnements dédiés aux plates-
formes reconfigurables sont basés sur une description architecturale de l'algorithme. Le
programmeur aura donc à transformer "manuellement" son algorithme en architecture avant
de décrire l'application sous l'environnement utilisé [Alves 94]. Contrairement à ces
environnements, nous avons décidé de baser la description de l'algorithme sur une approche
procédurale. PERCIP transforme donc, à la place du programmeur, l'algorithme en
architecture.
Nous allons détailler dans ce chapitre les composantes de l’environnement PERCIP. Nous
commençons par décrire le principe de fonctionnement du cœur de PERCIP : le générateur
d’architecture. Nous enchaînons par les règles de passage d’une description haut niveau à une
architecture câblée en détaillant les modèles d’exécution utilisés. Nous décrivons ensuite la
bibliothèque et les différentes techniques d’optimisation utilisées. Pour illustrer ce qui
distingue PERCIP de l'approche traditionnelle de câblage d'un algorithme, nous commençons
par détailler celle-ci.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’environnement PERCIP 50
1 APPROCHE TRADITIONNELLE DE
L’IMPLANTATION CABLEEAvant de commencer le codage VHDL d’un algorithme, le programmeur cherche
intuitivement des dépendances entre les données. Il implante alors les opérations manipulant
des données dépendantes de façon séquentielle, alors que celles manipulant des données
indépendantes seront, elles, implantées de façon parallèle. Ce codage est souvent fait en un
VHDL comportemental, sans doute à cause de la compréhensibilité de ce type de
modélisation. Pour valider le bon fonctionnement de l’algorithme, une première simulation,
dite fonctionnelle, est effectuée. Cette simulation permet de corriger d’éventuelles erreurs
Codage en VHDL
Simulation fonctionnelle
Erreur ?
Non
Oui
Synthèse logique ;Simulation post-synthèse ;
Erreur ?
Non
Oui
Routage ;Simulation post-routage ;
Erreur ?
Non
Oui
Configuration du FPGA
Figure 29 : Cycle de développement d’une application en vue d’uneimplantation câblée
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’environnement PERCIP 51
relatives au fonctionnement de l’algorithme. La synthèse logique, étape qui permet d’avoir
une description au niveau porte, est lancée ensuite en prenant en entrée le VHDL
comportemental. Après avoir effectué l’étape de synthèse, une première simulation temporelle
peut être lancée, qui sert à valider le comportement de la description au niveau porte
résultante. Ce comportement doit être identique à celui de la description VHDL à une
différence près due à l'introduction de la notion de temps de traversée. Notons tout de même
que le langage VHDL permet d’exprimer des actions temporisées ; mais la notion de temps de
traversée que nous évoquons ici est celle due aux délais de propagation des signaux dans les
portes logiques. Cette première simulation temporelle prend en compte uniquement des délais
approximatifs de propagation dans les portes et ignore ceux des connexions (routage), car le
constructeur du synthétiseur est différent du fabriquant des circuits cibles (FPGA ou ASIC).
Néanmoins, cette simulation aide à rectifier, éventuellement, le code d’entrée afin de satisfaire
des contraintes temporelles et donne un ordre d’idée sur la vitesse maximale de
fonctionnement. Après le routage, qui est effectué par les outils de CAO électronique du
constructeur des composants, une simulation post-routage est nécessaire. Cette simulation
prend en compte non seulement les délais exacts de propagation dans les portes mais aussi
ceux des connexions. Ce qui fait d’elle une simulation "fiable". Cette étape doit sa nécessité à
la complexité du débogage d’une application sur le composant. Cela est, sans doute, dû au
manque d’accessibilité aux variables intermédiaires. La figure 29 illustre les étapes de
développement d’une application en vue d’une implantation câblée.
Outre la maîtrise du VHDL, ce cycle exige la connaissance des différents outils effectuant les
étapes citées ci-dessus. Pour garantir le synchronisme dans l’évolution des calculs dans le
FPGA, une étape d’optimisation est généralement nécessaire. Or cette optimisation nécessite
une connaissance intime de la technologie cible. De surcroît, l’intervention de l’utilisateur,
durant le processus de synthèse, est très restreinte : elle se limite généralement à un choix
d’optimisation de taille ou de vitesse. Le contrôle restreint du cycle de développement,
reporte le problème au niveau du codage VHDL. Comme la synthèse logique dépend en
grande partie de l’outil utilisé, ce codage exige de l’utilisateur une certaine expertise.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’environnem
L’objectif principal de PE
utilisé en assurant la synth
générateur d’architectures
PERCIP génère à partir d
synthétisable. Ce code ali
programmes de configurat
Concrètement, le générate
code Apply en un code VH
classique. Aussi, avant d
générale d’un compilateur.
2 STRUCTUR
ATEURPour convertir un program
des étapes transforme le p
10 Existence d’une desc
procedure entree(
x : in array(-1..0)of byte,
s : out byte) is
GENERAEUR
D’ARCHITECTURES
BIBLIOTHEQUE
Figure 30 : L’environnement PERCIP
ent PERCIP
RCIP est d'éviter la dépendance vis-à-vis de
étisabilité10 du code VHDL généré. Composé
et la bibliothèque, comme illustré sur la figure
’une description Apply d’une application TB
mente ensuite une chaîne de CAO du comme
ion de la plate-forme reconfigurable.
ur d’architectures de PERCIP est un program
DL. En effet, sa fonction est comparable à ce
e décrire ce générateur, nous rappelons ci-
E GENERALE D’UN C
me, le compilateur suit un processus à plusie
rogramme source d’une représentation en un
ription au niveau porte correspondant au code V
X
l’outil
de deux
30, l’env
NI, un c
rce pour
me qui
lle d’un
dessous
OM
urs étap
e autre q
HDL
S
+PERCIP
52
de synthèse
entités : le
ironnement
ode VHDL
générer les
convertit un
compilateur
la structure
PIL-
es. Chacune
ui doit être
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’enviro
équivalente au sens
transformation d’un
être regroupées en
Parallèlement à ces é
la Gestion des erreu
La phase d'analyse e
analyses lexicale,
l'identification dans
lexèmes. Concrètem
valeur constante, etc
sous forme d’un arb
syntaxiques définies
suite sur la structu
informations nécessa
des opérandes d’une
Programme source
Analyse lexicaleLe compilateur
d
Analyse
Analyse syntaxique
Analyse grammaticale
Génération de code intermédiaire
Optimisation du code
Génération de code
Synthèsennement PERCIP
mathématique du terme. Comme illustré sur la figure 31
compilateur classique se compose typiquement de six ét
deux phases de trois étapes chacune : l’analyse
tapes, deux tâches interviennent : la Gestion de la table
rs.
st définie par les spécifications du langage d’entrée. E
syntaxique et grammaticale. L’analyse lexicale
le programme source des éléments de base (les mo
ent un lexème peut être un opérateur, un mot clé, un i
. L’analyse syntaxique construit une structure abstra
re qui peut être obtenu en assemblant les lexèmes en s
par les spécifications du langage. L’analyse grammatica
re produite par l’analyse syntaxique. Son rôle est
ires à l’étape suivante. A titre d’exemple, elle doit contr
opération. Une multiplication d’un nombre entier et d’u
Programme cible
Figure 31 : Etapes du processus de compilation
Gestion de
la table des
symboles
Gestion
es erreurs
53
, le processus de
apes, qui peuvent
et la synthèse.
des symboles et
lle comprend les
a pour objet
ts) du langage :
dentificateur, une
ite, généralement
uivant les règles
le travaille par la
de collecter des
ôler la cohérence
n nombre flottant
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’environnement PERCIP 54
ne peut être réalisée directement à cause de l’incompatibilité de leurs représentations internes.
Le compilateur doit alors convertir l’un des nombres ou, si le langage ne permet pas de
conversion, signaler l'erreur.
La phase d'analyse étant achevée, le compilateur procède à la synthèse du programme cible.
Cette phase débute par la génération du code intermédiaire, destiné à une machine virtuelle.
Bien qu’il soit générique, ce code doit être, à la fois, simple à générer et proche de la machine
cible pour pouvoir être facilement traduit en langage cible. L’exemple type du code
intermédiaire est le code générique à trois adresses, où chaque instruction utilise deux
opérandes source et un opérande destination. Une instruction dans ce code correspond à une
affectation et à l’exécution d’au plus une opération (addition, multiplication, etc…), ce qui
correspond à ce que peut faire un processeur classique en une instruction. L’étape qui suit
celle de la génération du code intermédiaire est l’Optimisation du code intermédiaire. Son
principal objectif est d’améliorer ce code pour une exécution plus rapide du programme cible.
Il peut s’agir de la modification du choix d’un opérateur (un opérateur de décalage au lieu
d’une multiplication ou une division), la simplification algébrique des expressions,
l’élimination des instructions redondantes, etc. L’ultime étape est la génération du code pour
la machine cible, qui traduit le programme écrit en code intermédiaire en une description
basée sur le jeu d’instructions de la machine cible. C’est à ce niveau que le compilateur doit
avoir le plus de détails sur la machine cible. La séparation des étapes de compilation facilite
considérablement le portage du compilateur sur d’autres machines cibles. En effet il suffit de
modifier l’étape de Génération de code pour accomplir ce portage.
Deux tâches s’exécutent parallèlement aux étapes du processus de compilation : la gestion de
la table des symboles et celle des erreurs. La table des symboles permet d’enregistrer des
informations, collectées tout au long de la compilation, relatives aux identificateurs (noms de
fonctions, noms de variables, etc.). Pour une fonction, le compilateur a besoin de collecter des
informations concernant son type et le nombre et le type de ses arguments. Les informations
devant être collectées pour une variable sont son type, sa portée et son emplacement mémoire.
Quant à la gestion des erreurs, il est primordial qu’un compilateur signale à son utilisateur
l’existence d’une erreur et l'explique dans la mesure du possible. En outre, la détection d’une
première erreur ne doit pas arrêter le processus de compilation, afin de trouver toutes les
erreurs du programme.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’environnement PERCIP 55
3 GENERATEUR D’ARCHITECTURES DE
PERCIPLa génération de l’architecture est effectuée en passant par cinq étapes. Les deux premières
sont les analyses lexicale et syntaxique. Une fois la phase d'analyse achevée, la génération de
l’architecture est entamée. Cette architecture est ensuite optimisée pour finalement générer le
code VHDL correspondant. La figure 32 illustre les étapes du processus de conversion d’un
programme Apply, détaillées ci-dessous.
3.1 PHASE D’ANALYSE
Les deux analyses sont intimement liées, car l’analyse syntaxique déclenche l’analyse
lexicale. Des outils, existant sous le système Unix, nous ont permis de réaliser cette phase :
lex et yacc [Aho 91][Levine 95]. Lex permet de générer, à partir de la définition des unités
lexicales d’un langage, un fichier source en langage C contenant un analyseur lexical pour ce
langage. L’analyseur lexical produit par lex est sous forme d’une fonction (yylex) appelée par
programme.apl (code Apply)
Analyse lexicale
Analyse syntaxique
Génération de l’architecture
Optimisation de l’architecture
Génération du code VHDL
architecture.vhdl
Figure 32 : Etapes de génération d’une architecture à partir d’un
programme Apply
Le générateur d’architecture de PERCIP
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’environnement PERCIP 56
la suite par l’analyseur syntaxique pour déclencher l’analyse lexicale. Quant à l’analyseur
syntaxique, il est produit par l'outil yacc. En partant des règles du langage d’entrée, yacc
génère un fichier écrit en langage C contenant la fonction yyparse, appelée par la suite par le
programme principal du générateur d'architecture (main) afin d’effectuer la phase d’analyse.
Pendant que la fonction yyparse effectue la phase d’analyse, elle crée la représentation
arborescente du programme source. Cette structure est utilisée par la suite par la phase de
synthèse, détaillée ci-dessous, pour générer le code VHDL.
3.2 PHASE DE SYNTHESE
A partir de la représentation sous forme d’arbre du programme Apply, résultat de la phase
d'analyse, cette phase synthétise le code cible (VHDL). La synthèse se fait en trois étapes : la
génération de l’architecture, l’optimisation de cette architecture et la génération du code
VHDL correspondant. La génération d’une architecture câblée à partir d’une description
procédurale, exige naturellement des règles de synthèse, présentées ci-dessous.
3.3 REGLES DE SYNTHESE
Ayant choisi une approche procédurale, des règles de passage d’une description Apply à une
architecture câblée s’imposent. Par ailleurs, Apply est un langage dédié aux TBNI, domaine
composé de deux catégories de traitements : les traitements linéaires et les traitements non
linéaires. Pour les TBNI linéaires, nous avons contourné le problème de type génération de
graphe en fixant au préalable deux modèles d’exécution. Cette approche présente l’avantage
d’être simple à mettre au point. Cependant, elle limite le nombre d’algorithmes considérés.
Cette limitation n’est pas un grand handicap, puisque nous avons restreint le domaine
d’application au TBNI. Comme modèle d’exécution, nous avons le choix entre l’un des deux
modèles : systolique ou, ce que nous avons appelé modèle FIR. Ces deux modèles sont
détaillés plus loin. Quant aux TBNI non linéaires, leur synthèse nous épargne l’utilisation
d’un quelconque modèle d’exécution. Différents cas sont traités dans §3.3.2 pour montrer
comment sont synthétisés les TBNI non linéaires. Mais tout d’abord détaillons le cas des
TBNI linéaires.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L
3.3.1 TBNI LINEAIRES
Les filtres linéaires de TBNI consistent en la convolution d’une fenêtre, appelée aussi le
masque, avec l’image originale, comme illustré par la figure 33. Nous citons comme exemple,
le filtre de Sobel, celui de Prewitt et le Laplacien [Horaud 93]. Le filtre Laplacien et sa
description Apply sont donnés dans la figure 34.
Le terme convolution incite à utiliser les filtres FIR (filtre à réponse impulsionelle finie). C'est
notre premier modèle d’exécution. En analysant de près cette catégorie d’algorithmes (TBNI
linéaires), nous nous sommes rendu compte qu’une solution systolique était possible. Le
générateur d’architectures de PERCIP a été alors réalisé de sorte qu’il puisse, selon le choix
de l’utilisateur, générer deux architectures pour chaque application TBNI linéaire.
Figure 33 : Convolution d’une image avec un masque 3*3 centré
’environnement PERCIP 57
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’environnement PERCIP
a. MODELE FIRLa principale caractéristique des filtre
sortie, à un instant donné, ne dépend
aux filtres à réponse impulsionelle infi
antérieures, à la fois, de l’entrée et
XK
W0W1
M
M Elément de retard
-1 -1 -1
-1 8 -1
Le filtre Laplacien
procedure Laplacien ( image : in array(-1..1,-1..1) of byte,
sortie : out integer) is
begin
sortie := - image(-1,-1) - image(0,-1) - image(1,-1)
Figure 34 : Description Apply du filtre Laplacien
s à réponse impulsionelle finie est que la valeur de la
que des valeurs antérieures de l’entrée ; contrairement
nie (IIR) dont la valeur de la sortie dépend des valeurs
de la sortie. Rappelons par la formule (1), la forme
M
W2 WN-1
YK
M
+
+ +Figure 35 : Forme canonique du filtre FIR
XK-1
XK-2 XK-N+158
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’environn
canonique du filtre FIR [Evans 93], qui est également illustrée par la figure 35.
)1......(............................................................... 1122110 +−−−− ++++= NKNKKKK XWXWXWXWY
La nature bidimensionnelle des images exige, pour permettre l’implantation, l’extension du
filtre FIR à deux dimensions. Le Laplacien, présenté dans la figure 34, sera implanté comme
illustré par la figure 36.
b. MODELE SYSTOLIQUE
Le modèle d'exécution d'une machine conventionnelle (modèle de von Neuman) est inadéquat
à l'implantation d'une convolution, car cette dernière se voit généralement comme le
glissement d'un masque sur l'image à traiter, ce qui implique un nombre élevé d'accès
mémoire pour des instructions relativement simples sur une machine de type von Neuman.
L'alternative est d'alimenter le masque par les pixels de l'image. En effet ce principe est très
adapté aux réseaux systoliques où les données subissent les traitements en traversant le réseau
et seuls les processeurs de bord communiquent avec le monde extérieur (mémoire par
exemple).
Ce modèle a été, initialement, appliqué à des machines à base de processeurs à granularité
large. La machine Warp, première plate-forme d’implantation d’Apply, en est un bon
exemple. Le réseau systolique que nous avons utilisé est appelé dans [Quinton 89] MAC
(Multiplication et ACcumulation). Un réseau de ce type à une dimension est illustré par la
figure 37 ; sa cellule de base est présentée sur la figure 38.
FIR 1D (-1, -1, -1)
FIR 1D (-1, 8, -1)
FIR 1D (-1, -1, -1)
Figure 36 : Implantation du Laplacien
ement PERCIP
+
image(k, -1)
image(k, 0)
image(k, +1)
sortie
59
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’environnement P
Deux caractéristiques principal
temps fixe de traversée. La m
atteindre la capacité des FPGA
TBNI de taille quelconque. Qua
plus une addition, il assure le re
b.1 PRINCIPE DE F
Pour respecter la synchronisati
tous les deux cycles horloge, co
une vitesse de ½, entraînant
expliquer le mécanisme du rése
de la figure 39. La dernière l
résultat de la forme 21 +k WXW
k
koX
koY
Y
Figure 37 : Réseau systolique MAC à une dimension
W3W2W1
+
Figur
• kiX , k
iY : Entrées de la cellule
• koX ,Yo
k : Sorties de la cellule
• W k : CoefficientkiX
kiY
*
WERCIP
es de ce ré
odularité p
s), laquell
nt au temp
spect de la
ONCTI
on dans le
mme illus
ainsi une
au, le table
igne du tab
31− +k WX
e 38 : Cellu
• L’exposant k indique le rang de
O
r
t
v
a
X
Xi
60
seau ont attiré notre attention : la modularité et le
ermet une extension illimitée du réseau (jusqu’à
e se traduit par l’implantation de filtre linéaire de
s de traversée, qui est le temps d’une multiplication
contrainte du temps réel.
NNEMENT DU RESEAU
éseau, ce dernier doit recevoir une nouvelle entrée
ré par la figure 39. On dit alors que X se propage à
itesse égale (½) sur la ligne Y. Afin de mieux
u 1 présente quelques itérations en partant de l’état
leau, correspondant aux valeurs de Y, donne un
2−k , semblable à l’équation d’un FIR.
le de base du réseau MAC
la cellule dans le réseau
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’environnemen
1
Y PT5 PT4
PT3PT2PT1
M
M
M
M
M
M
Tableau 1 : Flot de données dans le réseau
Temps (cycle) 1 2 3 4 5 6 …
PT1 X2 X2 X3 X3 X4 X4 …
PT2 X1 X2 X2 X3 X3 X4 …
PT3 X1 X1 X2 X2 X3 X3 …
PT4 W3X W3X W3X W3X W3X
t PERCIP
+
*
+
*
+
*
X4X4X3X3X2X2 X X1W3
W2 W1Figure 39 : Architecture du réseau systolique
0
PTn : Point n
61
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’environnement PERCIP 62
Par ailleurs, nous constatons que le réseau présente la même valeur pendant deux temps
(existence d’un temps mort), conséquence logique de la vitesse de propagation de X. Ceci
peut être contourné par l’utilisation du réseau pour le calcul simultané de deux filtres
[Quinton 89]. Ce principe est extensible au calcul simultané de plus de deux filtres,
moyennant quelques modifications du réseau [Hanifi 98]. Ces deux points sont détaillés
ultérieurement. Par ailleurs, Si N est la profondeur du réseau (N=3 pour le réseau de la figure
39), sa latence11 serait de 2N-1. La preuve formelle du fonctionnement du réseau est présentée
ci-dessous.
b.2 PREUVE FORMELLE
Le but de cette démonstration est plutôt de montrer le choix de la vitesse de propagation de X
(respect de la synchronisation dans le réseau) que de vérifier le bon fonctionnement du réseau.
C’est pourquoi, au cours de cette démonstration, nous exprimons la sortie du réseau en
fonction de l’entrée X de la première cellule. Notons, par ailleurs, que la Nème cellule (la plus
à droite) reçoit une valeur nulle sur l’entrée Y ( 0=NiY ).
L’expression de l’entrée X d’une cellule quelconque du réseau (la kème ), à l’itération j, en
fonction de l’entrée X de la cellule adjacente est :
)2.....(....................................................................................................).........1()( 1 −= − jXjX ki
ki
Par récurrence, on aboutit à l’équation qui exprime cette entrée en fonction de l’entrée X de la
première cellule :
)3(....................................................................................................))........1(()( 1 −−= kjXjX iki
L’équation exprimant la sortie Y de la kème cellule est :
)4....(....................................................................................................................................*)1()1()( 1 kki
ko
ko WjXjYjY −+−= +
11 Latence : nombre de cycles nécessaires au réseau pour fournir la première donnée valide
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’environnement PERCIP 63
(3) et (4) donnent :
)5........(................................................................................*)()1()( 11 ki
ko
ko WkjXjYjY −+−= +
En exploitant (5) et toujours par voie de récurrence, on trouve :
)6..(..................................................).........(*)22(
*)42(...*)()(11
211
kNjYWkNjX
WkNjXWkjXjYN
oN
i
Ni
ki
ko
+−+++−+
++−++−=−
−
Par ailleurs, l’équation de la sortie Y de la Nème cellule est :
)7...(................................................................................*)2()( 1 Ni
No WkNjXkNjY +−=+−
(6) et (7) donnent :
)8(..................................................*)2(*)22(
*)42(...*)()(111
211
Ni
Ni
Ni
ki
ko
WkNjXWkNjX
WkNjXWkjXjY
+−+++−+
++−++−=−
−
Cette équation est valable pour toute cellule du réseau, et en particulier la première (k=1).
Sachant que )()( 1 jYjY o= et )()( 1 jXjX i= , (8) devient :
)9.......(..................................................*)12(*)32(
...*)3(*)1()(1
21
NN WNjXWNjX
WjXWjXjY
+−++−+
+−+−=−
Ce résultat rend évident le choix d’une vitesse de ½ sur la ligne X.
b.3 UTILISATION DU RESEAU POUR LE CALCUL
SIMULTANE DE DEUX FILTRES
Le handicap du temps mort, cité précédemment, peut être contourné par l’utilisation du réseau
pour le calcul simultané de deux filtres. L’idée est d’alterner les coefficients des masques tout
en respectant la synchronisation dans le réseau. Cette synchronisation est respectée si le
réseau est initialisé de sorte que ces coefficients suivent l’ordre indiqué dans la figure 40. Le
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chap
table
(B1,
Temps
(cycle)
1 2 3 4 5 6 7 …
PT1 X2 X2 X3 X3 X4 X4 X5 …
PT2 A1 B1 A1 B1 A1 B1 A1 …
PT3 X1 X2 X2 X3 X3 X4 X4 …
PT4 B2 A2 B2 A2 B2 A2 B2 …
PT5 X1 X1 X2 X2 X3 X3 X4 …
itre 3 : L’environnem
au 2 illustre quelques
B2, B3).
PT1
M
M
M
Tableau 2 : Calcul simultané de deux filtres
ent PERCIP
itérations correspondant au calcul des masques (A1, A2, A3) et
1
2
PT5
PT7PT8
PT3
P4PT2
MM
MM
M
M
M
M
+
*
+
*
+
*
MX4X4X3X3X2X2
X1 XT6
BA2
A3
B3
A1
B1
0
Figure 40 : Utilisation du réseau pour le calcul simultané de deux filtres
Y
PT
64
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
+
*
+
*
+
*
2 1
Y
PT1 PT3
PT7PT8
1
M
M
M
M
MM
M
M
X4X3X3X3X2XChapitre 3 : L’environnement PERCIP
b.4 EXTENSION AU CALCUL SIMULTANE
DEUX FILTRES
Le calcul simultané de N filtres exige qu’une valeur de X reste, sur
chaque ligne du réseau, N cycles durant. Il en découle une vitesse de
chaque ligne. Pour ce faire, (N-2) éléments de retard doivent être s
entre deux cellules adjacentes. Un réseau pour le calcul de 3 filtres (
figure 41. Pour que le réseau fonctionne normalement, un certain o
coefficients des masques est nécessaire. En effet, comme illustr
coefficients de chaque filtre doivent se propager en diagonale. Le ta
itérations pour montrer le bon fonctionnement du réseau de la figure 4
Insérer (N-2) éléments de retard pour le calcul de N opérateurs est une
PT4PT2
1
M
M
MM
M
M
X
DE PLUS D
un point quelconque
propagation de 1/N
ystématiquement insé
N=3) est présenté sur
rdre de présentation
é sur la figure 41,
bleau 3 donne quelq
1.
règle généralisable a
PT6
3
3
M
M
M
0
Figure 41 : Utilisation du réseau pour le calcul simultané de trois filtres
PT5
X1
X X2C2
A2
B2
A
B
C3
B1
C1
A
65
E
de
sur
rés
la
des
les
ues
ux
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Ch
ca
fil
no
élé
ill
Un
op
da
c.L’
Temps
(cycle)
1 2 3 4 5 6 7 8 9 …
PT1 X2 X2 X3 X3 X3 X4 X4 X4 X5 …
PT2 B1 C1 A1 B1 C1 A1 B1 C1 A1 …
PT3 X1 X2 X2 X2 X3 X3 X3 X4 X4 …
PT4 C2 A2 B2 C2 A2 B2 C2 A2 B2 …
PT5 X1 X1 X1 X2 X2 X2 X3 X3 X3 …
apitre 3 : L’envi
s N = 2 et N = 1
tres (sans aucun
mbre d’éléments
ment mémoire
ustrée par la figu
e fois l’archit
timisations poss
ns le cas des TB
TECHNIQ
utilisation systé
1
Tableau 3 : Extension au calcul de plus de deux filtres
ronnement PERCIP
. En effet, le réseau initial (N = 2) permettait le calcul simultané de deux
e modification). Le cas N=1, quant à lui, mérite plus de précision, car le
à insérer est négatif. Si nous traduisons ce résultat par l’enlèvement d’un
de chaque cellule, le réseau systolique rejoint une seconde architecture,
re 42, des filtres FIR [Mohanakrishnan 93][Evans 93].
ecture trouvée, le générateur d’architecture cherche les différentes
ibles afin de gagner de la place sur le silicium. Les optimisations utilisées
NI linéaires sont décrites ci-dessous.
UES D’OPTIMISATION
matique des cellules MAC pour générer un réseau systolique est une
+
***
MMM
+ +…X3X2X
0
Figure 42 : Seconde solution du handicap du temps mort
W3
W2 W1Y
66
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’environnement PERCIP 67
méthode simple et directe. Cependant, elle est coûteuse en terme de ressources logiques.
Grâce à la reconfigurabilité des FPGAs, l’architecture est générée en fonction des
coefficients. En effet, selon la valeur du coefficient et la position de la cellule dans le réseau,
différentes optimisations peuvent être effectuées. Dans la limite du possible, les multiplieurs
sont remplacés par des complémenteurs, des décaleurs ou des complémenteurs-décaleurs. Les
optimisations relatives aux coefficients, valables pour les deux types de réseau (systolique et
FIR), sont possibles dans les cas suivants :
- Coefficient dont la valeur est égale à 0, 1 ou –1
- Coefficient dont la valeur est égale à (+ ou -) une puissance de 2
Quant aux optimisations relatives à la position des cellules, elles sont uniquement valables
dans le cas d’un réseau systolique. En effet, une cellule MAC située à droite du réseau ne
reçoit aucune donnée de la droite et n’alimente aucune cellule adjacente sur sa droite. Une
telle cellule sera alors simplifiée : plus besoin d’additionneur ni de registre sur la ligne de
propagation des pixels. En outre, si le coefficient de cette cellule est nul, elle sera
complètement supprimée. La figure 43 illustre l’exemple d’une cellule MAC simplifiée à
cause d’un coefficient nul (excepté la position droite) pour donner naissance à la cellule
MAC0.
Ces optimisations, prises séparément ou combinées entre elles, ont donné naissance à la
grande majorité des éléments de la bibliothèque de PERCIP, présentée ci-dessous.
c.1 BIBLIOTHEQUE
Les éléments de la bibliothèque sont les cellules utilisées par le générateur d’architectures
pour tisser l’architecture résultante. Ces éléments sont la cellule MAC, les cellules qui en
découlent après optimisation (ENDMAC,…), les multiplieurs, les additionneurs, les
Registre 8
Registre 16
Figure 43 : Cellule MAC0
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitr
comparateurs et les multiplexeurs (TBNI non-linéaire). Quelques éléments résultant des
optimisations du réseau systolique sont :
- Cellules MAC0, MAC1, MAC2, MAC4,…, MAC128 : respectivement pour les
coefficients 0, 1, 2, 4,…, 128.
- Cellules MACM1, MACM2, MACM4,…, MACM128 : respectivement pour les
coefficients -1, -2, -4,…, -128.
- Cellule ENDMAC : position droite avec un coefficient quelconque
- Cellules ENDMAC1, ENDMAC2,…, ENDMAC128 : position droite avec coefficient = 1,
2,…, 128.
- Cellules ENDMACM1, ENDMACM2,…, ENDMACM128 : position droite avec
coefficient = -1, -2,…, -128.
Toutes
simulée
hard-m
terme
Xilinx)
Pour o
Or eff
possibi
Cellule Valeur du coefficient Coût (CLBs)MAC x 99
ENDMAC x 87MAC0 0 12MAC1 1 21
ENDMAC1 1 9MACM1 -1 37
ENDMACM1 -1 34MAC2 2 37
ENDMAC2 -2 34
Tableau 4 : Quelques cellules élémentaires avec leurs coûts en termes de CLBs
e 3 : L’environnement PERCIP 68
les cellules de la bibliothèque sont écrites en VHDL comportemental, synthétisées et
s (simulation temporelle). Cependant, elles ne sont pas placées : il ne s'agit pas de
acros. Le tableau 4 présente quelques éléments de la bibliothèque avec leurs coûts en
de CLB (Configurable Logic Block : unité de ressource logique dans les FPGAs
.
btenir la sortie, les deux types de réseau requièrent généralement une addition finale.
ectuer une addition de N entrées avec des additionneurs à deux entrées ouvre la
lité à une optimisation, détaillée ci-dessous.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’environnement PERCIP
c.2 OPTIMISATION DE L’ADDITIONNEUR
Quelle que soit la façon dont les additionneurs sont organisés, une addition de N entrées,
utilisant des additionneurs à deux entrées, requiert N-1 additionneurs. Cependant, la façon
dont les additionneurs sont disposés influe sur le temps de traversée de l’additionneur
+
+
+
++
+
+
+
E0
E1
E2
E3
+
EN-1+
S
Figure 44-a : Organisation non optimale des additionneurs
(N-1) * τ
τ
E0
E1
E2
E3
EN-1
S
Figure 44-b : Organisation optimisée des additionneurs
P * τ
τ
EN-2
69
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’environnement PERCIP 70
résultant. En effet, l’organisation de la figure 44-a implique un temps de traversée de
τ*)1( −N , si nous supposons que τ est le temps de traversée d’un additionneur.
L’organisation de la figure 44-b donne un temps de traversée inférieur : P * τ, où P est calculé
selon la formule (10).
)10........(............................................................1))(int(log
)(log)(log
2
22
+=
nonsiN
entierestNsiNP
Si, après application de cette technique, le temps de traversée reste important et limite en
conséquence la fréquence maximale de fonctionnement, nous pouvons découper, avec des
éléments mémoire, les étages additionneurs afin de réduire le cycle de pipeline. Cette solution
augmente, en contrepartie, la latence du réseau.
3.3.2 TBNI NON LINEAIRES
Les TBNI non linéaires se caractérisent, au niveau d’Apply, par les instructions de test : if
expression then liste_d’instructions else liste_d’instructions end if. Seulement deux niveaux
d’imbrication des if sont permis, d'une part pour des raisons de simplicité et d'autre part parce
que la quasi-totalité des algorithmes non linéaires de TBNI peuvent être aisément exprimés.
En outre, et toujours pour les mêmes raisons, nous avons limité les instructions incluses dans
les if, autre que les tests, à des affectations simples (var1 := var2;). En effet, la liste
d’instructions du premier niveau se limite à des instructions d’affectation et des instructions
de test, tandis que celle du second se limite à des instructions d’affectation.
Des comparateurs et des multiplexeurs suffisent pour traduire les instructions if en une
architecture câblée. Nous présentons ci-dessous les différents cas possibles et les architectures
correspondantes.
a. IF SANS IMBRICATION
Deux cas de figure peuvent être distingués : l’instruction if de la forme if expression then
liste_d’instructions else liste_d’instructions end if, que nous appelons if complet ; et le if de la
forme if expression then liste_d’instructions end if, que nous appelons if incomplet. Le code
Apply d’un if complet et l’architecture correspondante sont représentés sur la figure 45. Si
l’expression est fausse dans un if incomplet, naturellement aucun traitement n’est effectué.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’en
Autrement dit, toutes les variables doivent garder leurs anciennes valeurs (phénomène de
mémoire). Cela se traduit au niveau architecture par un rebouclage de la sortie sur l’entrée
correspondante du multiplexeur, comme indiqué sur la figure 46.
b. IF A DEU
Le test multiple
comparateurs et
certains points do
- A chaque va
ensemble de
ensemble, cor
- Le placement
sortie est la v
ComparateurA
B
S
MUX
sel0
1s
e1
e2
procedure if_complet (e1, e2 : in byte,
s : out byte) is
begin
if e1 < e2 then
s := e1 ;
Figure 45 : Code Apply et architecture d’un if complet
vironnement PERCIP 71
X NIVEAUX D’IMBRICATION
obéit à la même règle que le if sans imbrication : il est synthétisé par des
des multiplexeurs. Cependant, pour générer l’architecture correspondante,
ivent être suivis :
riable de gauche d’une instruction d’affectation, doit correspondre un
multiplexeurs et de comparateurs. Pour l’exemple de la figure 47, un seul
respondant à la variable S, est généré.
des multiplexeurs s’effectue de droite à gauche : le multiplexeur dont la
ariable de gauche (S sur la figure 47) est placé le premier, contrairement à
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’e
ceux dont le
placés les de
- Les compara
niveau (celu
multiplexeur
Quant aux if inc
que dans le cas d
procedure if_incomplet (e1, e2 : in byte,
s : out byte) is
begin
if e1 < e2 then
ComparateurA
BS
MUX
sel0
1s
e1
e2
Figure 46 : Code Apply et architecture d’un if incomplet
nvironnement PERCIP 72
s entrées sont les variables de droite (f1, f2 et f3 sur la même figure) qui sont
rniers.
teurs sont placés en commençant par celui correspondant au if du premier
i dont les entrées sont e1 et e2 sur la figure 47). Ce comparateur commande le
final (dont la sortie est la variable de gauche).
omplets, (ligne 12 à 14 sur la figure 47), ils seront traités de la même façon
’un if sans imbrication (phénomène mémoire).
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’environ
procedure if_deux (e1, e2, e3, e4, e5, e6 : in byte, -- 1
f1, f2 : in byte, -- 2
S : out byte) is -- 3
begin -- 4
if e1 < e2 then -- 5
if e3 < e4 then -- 6
S := f1; -- 7
l 8
ComparateurA
BS
e1
e2
e5
e6
e3
e4
MUX
sel01
f1f2
f3
S
ComparateurA
BS
ComparateurA
BS
MUX
sel01
MUX
sel01
Figure 47 : if à deux niveaux d’imbrication
nement PERCIP 73
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 3 : L’environnement PERCIP 74
4 CONCLUSIONL’objectif de PERCIP était de générer, en partant d’une description procédurale d’une
application TBNI, un code VHDL synthétisable. Cet objectif a été atteint en adoptant un type
de modélisation structurel du VHDL généré. Ce type nous a obligé de mettre au point une
bibliothèque dont les éléments sont utilisés pour la génération des architectures. Ces éléments
ont été écrits en VHDL comportemental, synthétisés et simulés (simulation temporelle) pour
s’assurer de leur bon fonctionnement (respect des contraintes). Cependant, ils ne sont pas
préplacés comme dans le cas des hard-macros.
Ayant choisi une approche procédurale pour la description des applications TBNI, des règles
de synthèse se sont imposées. Pour mettre au point ces règles, nous avons traité séparément
les TBNI linéaires et les non linéaires. La première catégorie est caractérisée au niveau
d’Apply par des instructions de la forme (variable := expression;). Quant à la seconde, elle
est caractérisée par des instructions de la forme (if « expression » then « suite d’instructions »
else « suite d’instructions » end if). Pour la catégorie des TBNI linéaires les modèles
d’exécution choisis remplacent les règles de synthèse. Deux modèles permettent de réaliser le
passage : le modèle FIR et le modèle systolique. Quant à la seconde catégorie, nous avons
donné les différents cas possibles et leurs résultats de synthèse.
La syntaxe originale du langage Apply ne permet pas l’appel de fonction. Nous ne l’avons pas
rajouté, car la majorité des algorithmes de TBNI peut être décrite sans avoir recours à cette
option. Tous les programmes Apply sont alors des programmes mono-fonction.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 4 : Applications 75
CHAPITRE 4
APPLICATIONS
1 INTRODUCTIONQuelques exemples de TBNI sont présentés dans ce chapitre. Bien qu’ils soient relativement
simples, ces exemples mettent en œuvre la totalité des règles de synthèse adoptées dans
PERCIP.
Le TBNI se compose de deux catégories de filtres : les filtres linéaires et les filtres non-
linéaires. Nous commençons par présenter la première catégorie. Comme la synthèse des
filtres de cette catégorie suit une seule règle (l’utilisation du modèle d’exécution systolique ou
du modèle FIR), un seul filtre est traité : le filtre de Sobel. Le code Apply ainsi que la
description VHDL généré par PERCIP de ce filtre sont présentés.
Quant aux traitements non-linéaires, nous focalisons la présentation sur le filtre médian, très
utilisé dans le débruitage d’image. La présentation consiste en une étude du médian "pur" qui
nous conduit à deux variantes de ce filtre : une version simplifiée et une basée sur les
algorithmes de tri. Une version du médian "hybride" est également présentée. Un médian
hybride contient à la fois une partie linéaire et une partie non-linéaire. Pour toutes ces
variantes nous présentons à chaque fois le code Apply et le code VHDL décrivant
l’architecture correspondante généré par PERCIP. Nous présentons également une
comparaison entre l'implantation en utilisant PERCIP et l'implantation manuelle de quelques
filtres de TBNI. Nous finissons le chapitre par la présentation des moyens de validation des
architectures générées par PERCIP.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 4 : Applications76
2 FILTRE DELe filtre de Sobel, utilisé p
sur la figure 48-a deux mas
description Apply de ce fi
expliqué dans le chapitre 2
sqrt(). Une version simplif
version nous avons gard
1 2 1
0 0 0
1 0 -1
2 0 -2
Sobel vertical Sobel horizontal
procedure Sobe
t
m
horiz, vert : int
begin
horiz := inimg(
i i (
Figure 48-a : Les masques du filtre de Sobel
SOBELour la détection des contours d’une image, utilise comme illustré
ques de taille 3*3 correspondant au Sobel vertical et horizontal. La
ltre est illustrée par la figure 48-b. Ce code, qui a été présenté et
, ne peut être pris comme tel par PERCIP à cause de la fonction
iée acceptée par PERCIP est décrite dans la figure 49. Dans cette
é uniquement le Sobel vertical. L’instruction if est également
l ( inimg : in array (-1. . 1, -1. . 1) of byte border 0,
hresh : const real,
ag : out real) is
eger ;
-1, -1) + 2 * inimg(-1, 0) + inimg(-1, 1)
1 1) 2 * i i (1 0) i i (1 1)
Figure 48-b : Filtre de Sobel écrit en Apply
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 4 : Ap
supprimée pour n’utiliser que des éléments linéaires.
PERCIP peut générer deux architectures possibles pour un filtre linéaire de TBNI, basées
respectivement sur les réseaux systoliques et sur les filtres FIR. La figure 50 présente
l’architecture systolique du filtre de Sobel et la figure 51 illustre son code VHDL. Quant à la
version FIR, son architecture est présentée figure 52 et la description VHDL de cette
architecture est illustrée par la figure 53. Toutes ces architectures sont présentées après
optimisation (coefficient = 0,1…).
procedure SobelVertical ( inimg : in array (-1. . 1, -1. . 1) of byte,
vert : out integer) is
begin
vert := inimg(-1 -1) + 2 * inimg(0 -1) + inimg(1 -1)
Figure 49 : Version simplifiée du filtre de Sobel : Sobel vertical
plications 77
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 4 : Applications78
Figure 50
+M M
M
M
M
1
M M
M
M
M
+ t
* 2
* (-2)* (-1) * (-1)
: Architecture systolique de la composante
verticale du filtre de Sobel
+
inimgM1
+
+inimgP
ver
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 4 : Application
Figure 51 :
Description VHDL de l’architecture systolique de lacomposante verticale du filtre de Sobel
-- Nombre de CLBs utilisés : 169
use ieee.std_logic_1176.all;
use arithmetic.std_logic_arith.all;
entity SobelVertical is
port ( CLK : in std_logic;
inimgM1 : in std_logic_vector(7
downto 0);
inimgP1 : in std_logic_vector(7
downto 0);
vert : out std_logic_vector(15
downto 0));
end SobelVertical;
architecture systolique of
SobelVertical is
-- Déclaration des cellules élémentaires
-- MAC1
component MAC1
s
-- ENDMAC1
component ENDMAC1
port (CLK : in std_logic;
inx : in std_logic_vector(7 downto 0);
outy : out std_logic_vector(15
downto 0));
end component;
-- ENDMACM1
component ENDMACM1
port (CLK : in std_logic;
inx : in std_logic_vector(7 downto 0);
outy : out std_logic_vector(15
downto 0));
end component;
-- Déclaration des signaux intermédiaires
-- Signaux de la ligne inimgM1
signal C_1_1_OY : std_logic_vector(15
downto 0);
79
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 4 : Applications80
Figure 52
inimgM1
1 2 1
M M
inimgP1
-1 -2 -1
M
+
M
+ t
: Architecture FIR de la composante
verticale du filtre de Sobel
+
++
ver
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Figure 53 : Code VHDL de l’architecture FIR de la composante verticale du filtre de Sobel
C
-- Nombre de CLBs utilisés : 134
use ieee.std_logic_1176.all;
use arithmetic.std_logic_arith.all;
entity SobelVertical is
port ( CLK : in std_logic;
inimgM1 : in std_logic_vector(7
downto 0);
inimgP1 : in std_logic_vector(7
downto 0);
vert : out std_logic_vector(15
downto 0));
end SobelVertical;
architecture FIR of SobelVertical is
-- Déclaration des cellules élémentaires
-- REG8
component REG8
port (CLK : in std_logic;
D : in std_logic_vector(7 downto
0);
Q : out std_logic_vector(7
do nto 0))
hapitre 4 : Applications
signal MUL_1_1_O : std_logic_vector(15
downto 0);
signal MUL_1_2_O : std_logic_vector(15
downto 0);
signal MUL_1_3_O : std_logic_vector(15
downto 0);
signal ADD_1_1_O : std_logic_vector(15
downto 0);
signal ADD_1_2_O : std_logic_vector(15
downto 0);
-- Signaux de la ligne inimgP1
signal M_3_1_O : std_logic_vector(7
downto 0);
signal M_3_2_O : std_logic_vector(7
downto 0);
signal MUL_3_1_O : std_logic_vector(15
downto 0);
signal MUL_3_2_O : std_logic_vector(15
downto 0);
signal MUL_3_3_O : std_logic_vector(15
downto 0);
signal ADD_3_1_O : std_logic_vector(15
downto 0);
81
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 4 82
3 FILTRE MEDIANLe filtrage médian est une technique très efficace pour éliminer, tout en préservant la qualité
des contours, les bruits de type "sel et poivre". En effet, cette technique est utilisée dans
plusieurs applications industrielles qui vont de la vision industrielle à la robotique en passant
par l’imagerie médicale. Un filtrage médian consiste, d’une façon générale, en l’extraction de
la valeur médiane d’un certain nombre de valeurs. Bien que nous nous intéressions au cas
d’un signal 2D (image), il est tout à fait possible d’effectuer un filtrage médian pour un signal
1D. Dans ce cas, la valeur médiane sera extraite du voisinage temporel. Le cas 2D, où un
voisinage spatial est utilisé, considère en général une fenêtre carrée de taille N*N, centrée sur
le pixel à traiter. La définition mathématique de la valeur médiane de l’ensemble de valeurs
),...,( 1 nxx est :
médiane x x xn ii
n
( ,..., ) arg min11
= −∈ℜ =
∑µ
µ
où la fonction argmin renvoie la valeur de l’argument µ qui donne la plus petite valeur de la
somme. Un exemple pratique pour mieux éclaircir le principe du filtrage médian, appliqué au
traitement d’image, est présenté sur la figure 54.
MEDIAN
e e
1
: Ap
3
plica
9
5
7
1113
2 4tions
e
5
Figure 54 : Filtrage médian d’une imag
Image original
TraitementImage traité
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapit
Pour extraire la valeur médiane, un tri des valeurs à traiter est incontournable. Pour effectuer
une telle opération, plusieurs algorithmes existent. Ces algorithmes utilisent, tous, un élément
de base qui est l’unité de comparaison et d’échange (UCE). Le principe de l’UCE, tel que
l’illustre la figure 55, est de comparer deux valeurs A et B et, selon le résultat de la
)
)
)
Br
A
e
Bre 4 : Applications
Max(A,B
Min(A,B)
UCE
MEDIANMéd
Médian
A
B
C
Figure 56-a : Filtrage médian de trois valeurs
iane
Figure 56-b : Médian 2D
Max(A,B
Min(A,B
A
B
A>
ComparateuFigure 55 : Schéma logique de l’unité de comparaison et d’échange (UCE)
83
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 4 : 84
comparaison, transmettre tel quel ou permuter A et B.
Comme illustré sur la figure 56-a, trois UCE sont nécessaires pour trier trois valeurs. Par
ailleurs, il nous semble évident d’utiliser quatre filtres médian 1D (figure 56-b) pour
construire un médian 2D et extraire ainsi la valeur médiane d’une fenêtre 3*3, souvent utilisée
dans le traitement d’image. La figure 58 présente la description Apply du médian en adoptant
cette décomposition. Bien que cette méthode soit utilisée en raison de sa simplicité, elle ne
donne pas toujours la vraie médiane. Le cas de la figure 57 constitue un contre-exemple. En
effet, dans cet exemple nous nous attendions à avoir la valeur 5, alors que notre filtre nous
fournit 4. Pour avoir la vraie valeur médiane, le passage par des algorithmes de tri complet est
indispensable. Nous détaillons ce point ci-dessous.
1
MEDIAN
2A
5
pp
3
4
6
lica
7
tions
8
92
4
8e
4
Figure 57 : Contre-exempl
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 4 : Applica
Figure 58 :
Description Apply du filtre médian en adoptant la méthode dedécomposition
procedure Median2D ( inimg : in array (-
1..1, -1..1) of
byte,
Mediane : out byte)
is
si : array(-1..1) of byte;
begin
if inimg(-1, -1) < inimg(-1,0) then
if inimg(-1,0) < inimg(-1,1) then
si(-1) := inimg(-1,0);
else if inimg(-1, -1) < inimg(-1,1) then
si(-1) := inimg(-1,1);
else
si(-1) := inimg(-1,-1);
end if;
tions
if inimg(1, -1) < inimg(1,0) then
if inimg(1,0) < inimg(1,1) then
si(1) := inimg(1,0);
else if inimg(1, -1) < inimg(1,1)
then
si(1) := inimg(1,1);
else
si(1) := inimg(1,-1);
end if;
end if;
else if inimg(1,-1) < inimg(1,1)
then
si(1) := inimg(1,-1);
else if inimg(1, 0) < inimg(1,1)
then
si(1) := inimg(1,1);
85
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
M M)
inimg(1,-1)Chapitre 4 : Applications86
M
M
mux0 1
comp<
mux0 1
comp<
comp<
comp<
mux0 1
mux1 0
)
Figure 59 :
inimg(0,-1)
M)
M)
)
e
inimg(-1,-1
)
inimg(1,0) inimg(0,0 inimg(-1,0)
inimg(1,1) inimg(0,1 inimg(-1,1comp<
mux0
1)
si(1MEDIAN 1D
MEDIAN
MEDIANMEDIAN
si(0
si(-1Median
Architecture du filtre médian générée par PERCIP en adoptant la
méthode de décomposition
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
C
-- Nombre de CLBs utilisés : 144
entity Median2D is
port ( CLK : in std_logic;
inimgM1 : in std_logic_vector(7
downto 0);
inimg0 : in std_logic_vector(7
downto 0);
inimgP1 : in std_logic_vector(7
downto 0);
Mediane : out std_logic_vector(7
downto 0));
end Median2D;
architecture archi of Median2D is
-- Déclaration des cellules élémentaires
-- REG8
component REG8
port (CLK : in std_logic;
D : in std_logic_vector(7 downto
0);
hapitre 4 : Applications
signal CMP_2_O : std_logic;
signal CMP_2S1_O : std_logic;
signal CMP_2S1SN1_O : std_logic;
signal CMP_2SN1_O : std_logic;
signal CMP_2SN1SN1_O : std_logic;
signal CMP_3_O : std_logic;
signal CMP_3S1_O : std_logic;
signal CMP_3S1SN1_O : std_logic;
signal CMP_3SN1_O : std_logic;
signal CMP_3SN1SN1_O : std_logic;
signal CMP_4_O : std_logic;
signal CMP_4S1_O : std_logic;
signal CMP_4S1SN1_O : std_logic;
signal CMP_4SN1_O : std_logic;
signal CMP_4SN1SN1_O : std_logic;
-- Sorties des multiplexeurs
87
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
-- Sorties des médians 2D
signal siM1 : std_logic_vector(7 downto 0);
signal si0 : std_logic_vector(7 downto 0);
signal siP1 : std_logic_vector(7 downto 0);
begin
-- Eléments de retard
M_1_1 : REG8 port map (CLK, inimgM1,
M_1_1_O);
M_1_2 : REG8 port map (CLK, M_1_1_O,
M_1_2_O);
M_2_1 : REG8 port map (CLK, inimg0,
M_2_1_O);
M_2_2 : REG8 port map (CLK, M_2_1_O,
M_2_2_O);
M_3_1 : REG8 port map (CLK, inimgP1,
M_3_1_O);
M_3_2 : REG8 port map (CLK, M_3_1_O,
M_3_2_O);
Chapitre 4 : Applications88
CMP_2SN1SN1 : COMP8 port map
(M_2_1_O, M_3_1_O,
CMP_2SN1SN1_O);
MUX_2 : MUX8 port map
(MUX_2SN1_O, MUX_2S1_O, CMP_2_O,
si0);
MUX_2S1 : MUX8 port map
(MUX_2S1SN1_O, M_2_1_O,
CMP_2S1_O, MUX_2S1_O);
MUX_2S1SN1 : MUX8 port map
(M_1_1_O, M_3_1_O, CMP_2S1SN1_O,
MUX_2S1SN1_O);
MUX_2SN1 : MUX8 port map
(MUX_2SN1SN1_O, M_1_1_O,
CMP_2SN1_O, MUX_2SN1_O);
MUX_2SN1SN1 : MUX8 port map
(M_2_1_O, M_3_1_O, CMP_2SN1SN1_O,
MUX_2SN1SN1_O);
CMP_3 : COMP8 port map (M_1_2_O,
M_2_2_O, CMP_3_O);
CMP_3S1 : COMP8 port map (M_2_2_O,
M 3 2 O, CMP 3S1 O);
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre
3.1 AL
A l’inve
d’extrair
Nous ci
dessous,
sur les d
8
Figure 60 : Code VHDL généré par PERCIP pour le programme de la figure 5MUX_4 : MUX8 port map (MUX_4SN1_O, MUX_4S1_O, CMP_4_O, Mediane);
MUX_4S1 : MUX8 port map (MUX_4S1SN1_O, si0, CMP_4S1_O, MUX_4S1_O);
MUX 4S1SN1 MUX8 t ( iM1 iP1 CMP 4S1SN1 O MUX 4S1SN1 O)
4 : Applications
RCHITECTURE BASEE SUR UN TRI COMP-ET
rse de la méthode de décomposition, les algorithmes de tri complet permettent
e la vraie valeur médiane. Cependant, ces algorithmes sont relativement complexes.
tons parmi eux le tri bulle, le tri pair-impair et le tri bitone. Nous détaillons, ci-
le plus simple conceptuellement d’entre eux : le tri bulle. Pour de plus amples détails
eux autres, se référer à [Demassieux 91].
)
3
7
3
3
S
AB
E
Max(A,B
Min(A,B)
UC
4
3
4
3
8 4 138
8
1
8
7
8
7
13 3 713
4
13
74
Figure 61 : Principe du tri-bulle pour N=5
PIXEL
89
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 4 : Appl90
Le principe de l’algorithme de tri bulle est inspiré du phénomène des bulles d’air dans un
liquide. En effet, dans une architecture basée sur cet algorithme, les plus grandes valeurs
montent progressivement jusqu’à occuper les positions les plus hautes, et inversement les plus
petites rejoignent les positions basses. La figure 61 présente un exemple pour illustrer ce
principe. Supposons un nombre N impair de pixels, N couches de tri sont nécessaires et
suffisantes pour effectuer le tri. Chaque couche contenant 2
1−N UCEs, le nombre total
d’UCEs dans le réseau est( )
2
1−NN.
Il est vrai que les algorithmes de tri fournissent non seulement la valeur médiane, mais toute
une chaîne triée. Si nous voulions avoir uniquement la médiane sans nous préoccuper du reste
de la chaîne, nous pourrions réduire le nombre d’UCEs à )1(8
3 2 −N . Pour N très grand
M M
inimg(1,-1)ications
M
M
inimg(0,-1)
M
M)
3
2
inimg(-1,-1)
)
inimg(1,0) inimg(0,0) inimg(-1,0inimg(1,1)
inimg(0,1 inimg(-1,1)UCE
UCE2
UCE UCEMedian
Figure 62 : Architecture du médian 2D avec tri en adoptant une optimisation
Médian
UCEGénérateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 4 : Applications 91
( ∞→n ) le gain est de %25 . La figure 62 présente l’architecture du médian 2D en adoptant
cette optimisation. Le programme Apply correspondant est indiqué sur la figure 63.
Nous avons traité jusqu’à présent les deux catégories de TBNI (linéaire et non-linéaire)
séparément. Le filtre médian hybride, traité ci-dessous, découle du mariage de ces deux
catégories.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 492
3.2 FILTRE MEDIAN HYBRIDE
Le filtre médian hybride est une combinaison du filtre FIR et du filtre médian. En effet, au
lieu d’extraire la médiane d’un certain nombre de pixels (une fenêtre 3*3 par exemple), des
pixels sont réunis en blocs et remplacées par leur moyenne. Le tri se fait ensuite sur les
Figure 63 : Code Apply du filtre médian 2D basé sur un algorithme de tri
procedure Median2D ( inimg : in array (-1..1, -1..1) of byte,
Mediane : out byte)
is
UCEMAX : array(1..29) of byte;
UCEMIN : array(1..28) of byte;
begin
-- UCE1
if inimg(1, 0) < inimg(1,-1) then
UCEMAX(1) := inimg(1,-1);
UCEMIN(1) := inimg(1, 0);
l
: Applications
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 4 : Applica
moyennes et les pix
deux blocs de 4 pixe
L’un des avantages
effet, et à titre d’ex
alors qu'un filtre mé
La description App
généré par PERCIP
Cette application a
système de filtrage p
en format numériqu
dans cette applicati
rapport au son. Da
générer l'architectur
constaté qu'il était i
parasites dans l'ima
manière indépendan
Bien que l'architec
vectorielle combina
d'établir rapidemen
hybride.
moyenne
moyenne
N
Figure 64 : Médian hybride appliqué à une fenêtre 3*3
tions
els restants. La figure 64 illustre le p
ls.
évident du médian hybride est la réduc
emple, le tri de 9 pixels (cas d’une fen
dian hybride requiert uniquement 3 UC
ly du médian hybride est présentée p
est donné sur la figure 66.
donné lieu à une collaboration industr
our des images télévisuelles satellites
e (4-2-2) couleur en temps réel [Har
on est l'absence de pipeline, afin d'é
ns une première approche, l'environn
e nécessaire pour un seul plan (mono
nadéquat de tripler cette architecture à
ge résultante, en essayant d'appliquer
te.
ture finale ait été développée spécia
nt les pixels des 3 plans-couleurs simu
t l'ordre de grandeur des ressources
MEDIA
rincipe pour un
tion du nombre
être 3*3) reque
Es.
ar la figure 65
ielle concernan
au niveau de di
douin 98]. Le s
viter tout décal
ement PERCIP
chrome). Nous
cause de l'app
le filtre sur ch
lement en suiv
ltanément, PER
nécessaires pou
Médiane
93
e fenêtre 3*3 avec
de pixels à trier. En
rrait )9( 2O UCEs,
et le code VHDL
t la réalisation d'un
ffusion (broadcast),
ujet le plus défiant
age de l'image par
nous a permis de
avons rapidement
arition de couleurs
aque couleur d'une
ant une technique
CIP nous a permis
r ce filtre médian
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 4 : Applicatio94
procedu
begin
-
Figure 65 : Code Apply du filtre médian hybride
re MedianHybride (inimg : in array (-1..1, -1..1) of byte,
Mediane : out byte)
is
M1, M2 : byte;
M1 := (inimg(-1, 0) + inimg(-1, -1) + inimg(0, -1) + inimg(1,
1))/4;
M2 := (inimg(-1, 1) + inimg(0, 1) + inimg(1, 1) + inimg(1, 0))/4;
ns
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 4 : Applications 95
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
-- Nombre de CLBs utilisés : 78
use ieee.std_logic_1176.all;
use arithmetic.std_logic_arith.all;
entity MedianHybride is
port ( CLK : in std_logic;
inimgM1 : in std_logic_vector(7
downto 0);
inimg0 : in std_logic_vector(7 downto
0);
inimgP1 : in std_logic_vector(7
downto 0);
Mediane : out std_logic_vector(7
downto 0));
end MedianHybride;
architecture archi of MedianHybride is
-- Déclaration des cellules élémentaires
-- REG8
component REG8
port (CLK : in std_logic;
Chapitre 4 : Applications96
signal M2 : std_logic_vector(7 downto 0);
signal M_1_1_O : std_logic_vector(7 downto
0);
signal M_1_2_O : std_logic_vector(7 downto
0);
signal M_2_1_O : std_logic_vector(7 downto
0);
signal M_2_2_O : std_logic_vector(7 downto
0);
signal M_3_1_O : std_logic_vector(7 downto
0);
signal M_3_2_O : std_logic_vector(7 downto
0);
-- Sorties des comparateurs
signal CMP_1_O : std_logic;
signal CMP_1S1_O : std_logic;
signal CMP_1S1SN1_O : std_logic;
signal CMP_1SN1_O : std_logic;
signal CMP 1SN1SN1 O : std logic;
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chap
4 CI
L'auto
contr
de tai
par P
quelq
Co
ave
Co
ADD_2_1 : ADD8 port map (M_2_2_O, M_1_2_O, ADD_1_1_O);
ADD_2_2 : ADD8 port map (ADD_1_1_O, M_1_1_O, ADD_1_2_O);
ADD_2_3 : ADD8 port map (ADD_1_2_O, inimgM1, ADD_2_3 _O);
SHIFT_2 : SHIFT2R8 port map (ADD_2_3_O, M2);
-- Média n
CMP_1 : COMP8 port map (M1, M_2_1_O, CMP_1_O);
itre 4 :
OM
ONmatisa
epartie.
lle, que
ERCIP
ues filt
û
c
û
Figure 66 : VHDL généré par PERCIP pour le filtre médian hybride
PARAISON ENTRE DES IMPLANTAT-S AVEC PERCIP ET MANUELLEStion de la génération d'architectures offerte par PERCIP présente une
En effet, les architectures générées par PERCIP sont moins optimisées, en terme
celles obtenues par une implantation manuelle. Pour estimer le surplus introduit
, nous avons effectué les implantations manuelles et en utilisant PERCIP de
res de TBNI. Nous présentons dans le tableau 5 le coût en terme de CLBs des 2
Filtre de TBNI Sobel vertical Laplacien Prewit Median2D
t de l'implantation
PERCIP (CLBs)
134 108 115 144
t de l'implantation 100 84 90 122
Tableau 5 : Comparaison entre l'implantation avec PERCIP et l'implantation manuellede quelques filtres de TBNI
Applications 97
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 4 : Applications98
implantations de 3 filtres de TBNI linéaire (Lalacien, Prewit et Sobel vertical) et du filtre
Médian 2D (TBNI non-linéaire). D'une façon générale le coût des implantations manuelles
des filtres est inférieur d'environ 20% de celui d'une implantation utilisant PERCIP.
5 MOYENS DE VALIDATION DES ARCHIT-ECTURES GENEREES
Le code généré par PERCIP est un code destiné à configurer une plate-forme reconfigurable.
Au début de ce travail nous ne disposions pas encore d’une telle plate-forme. La validation du
code passait alors par la simulation. La plate-forme reconfigurable dont nous disposons
actuellement est une carte à base de 5 FPGAs Xilinx : la "Pamette". Nous détaillons ci-
dessous la validation par simulation et dans le paragraphe suivant nous présenterons la carte
"Pamette".
5.1 VALIDATION PAR SIMULATION
A la mise au point de PERCIP, nous n’avions nullement l’intention de remplacer les outils de
CAO électronique existants. C’est pourquoi, avant d’entamer la simulation, le VHDL généré
par PERCIP doit être synthétisé par le moteur de synthèse d’un des outils de CAO du
commerce. Comme outils de CAO, nous disposions, au début de ce travail, de la chaîne de
développement de Mentor Graphics (AutologicII, qvsim, qvpro,…) et de celle de Xilinx
circuit-application
(résultat de synthèse
Unité de Contrôle et
de Synchronisation
Modules
Figure 67 : Schéma synoptique de validation par simulation
d’une architecture générée par PERCIP
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 4 : Applications 99
(Xact,…). Plus récemment, nous avons acquis de nouveaux outils comme le moteur de
synthèse Leonardo d’Exemplar Logic, dédié aux FPGAs. En effet, AutologicII est dédié à la
synthèse des ASICs d’une façon générale et a été adapté au besoin aux FPGAs. Ses résultats
de synthèse pour FPGA ne sont, par conséquent, pas optimaux, contrairement à ceux de
Leonardo.
Le schéma type de validation d’un code généré par PERCIP comporte (figure 67) le circuit-
application (résultat de synthèse par AutologicII du VHDL généré par PERCIP), des
mémoires pour stocker l’image à traiter et l’image résultat et une unité de contrôle et de
synchronisation décrite en VHDL comportemental. Les modules mémoire utilisés sont des
composants suivant un modèle propre à Mentor Graphics. En effet, un module mémoire
consiste en un symbole, servant à instancier le module sur le schéma, un fichier de données
sur disque pour stocker les données image par exemple et un ensemble d’attributs pour établir
le lien entre le symbole et le fichier de données. Comme le format de ces fichiers est propre à
Mentor Graphics, nous avons dû développer des programmes de passage, dans les deux sens,
du format Mentor Graphics au format reconnu par les outils de visualisation d’image
(BMP, … …) tel que xv ou autre.
Les schémas de validation comportent des composants dans différentes descriptions : VHDL
comportemental, description au niveau porte et modèle mémoire propre à Mentor Graphics.
Pour simuler de tels schémas, une simulation dite mixte est nécessaire. Pour ce faire nous
avons utilisé l’outil de Mentor Graphics qvpro. Bien qu’il y ait du VHDL comportemental
dans le schéma, cette simulation est temporelle.
5.2 CARTE PAMETTE
Pamette, dérivée de PAM (détaillé dans le premier chapitre), est une carte à base de FPGAs
XC4010E, qui comptent 400 (20*20) CLBs par composant. Cette carte, qui se place sur le bus
PCI d’un ordinateur du commerce, est composée de 5 FPGAs. Comme illustré sur la
figure 68, quatre des FPGAs de la Pamette sont dédiés à l’utilisateur et le cinquième à la
gestion du bus PCI (PIF) [Shand 98]. Le PIF peut communiquer avec les deux FPGAs
utilisateur usrlca0 et usrlca1 via un bus de 36 bits nommé EBus (east bus). Les deux autres
FPGAs, usrlca2 et usrlca3, ne communiquent avec le PIF qu’en passant par le usrlca0 et
usrlca1. La Pamette dispose aussi d’un bus de 2 bits qui relie les 5 FPGAs entre eux.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 4 : Applications100
Les horloges de la Pamette son
tous les FPGAs. Le signal Clks
PLL (Phased-Locked Loop).
MotorolaTM MC88915T qui, en
dont la fréquence est le double
sortie d’un générateur de fréqu
avec un pas d’environ 0.5%. E
Comme la sortie de ce générat
logicielle, pour être arrêté, exéc
permet aux utilisateurs de trou
d’une application sur la Pamette
12 Exécuté à double pas signifieimpulsions séparées par la péd'arrêt.
Figure 6
pcilca
sram
usrlca0
usrlca1
usrlca2
usrlca3
PMC
ou
Connecteur
d’une secondee
ClkusrClksys
EBus
PCIhorlog
t au nombre de deux : Clksys et Clkusr, et sont distribuées à
ys est une copie de l’horloge PCI retrouvée grâce à une boucle
Pour effectuer cette fonction, la Pamette utilise un circuit
outre, peut être programmé pour générer un signal en phase
de celle du PCI. Le signal Clkusr, quant à lui, est issu de la
ence offrant une plage de fréquences de 400KHz à 100MHz
n effet, cette horloge n’est pas en phase avec celle du PCI.
eur repasse dans le PIF, Clkusr peut être configuré, de façon
uté pas à pas ou exécuté à double pas12. L’option double pas
ver empiriquement la fréquence maximale de fonctionnement
.
qu'au lieu de générer une impulsion d'horloge on génère deuxriode courante de Clkusr, après quoi l'horloge retourne à l'état
PMC : PCI Mezzanine Card
8 : Architecture de la carte Pamette
sram dram
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Chapitre 4 : Applications 101
6 CONCLUSIONNous avons présenté dans ce chapitre plusieurs filtres de TBNI avec leurs descriptions Apply
et les architectures correspondantes générées par PERCIP. Grâce à la propriété de
reconfigurabilité des FPGAs, PERCIP génère des architectures "taillées sur mesure". En effet,
les architectures générées pour les filtres linéaires de TBNI sont fonction des coefficients du
filtre. A titre d’exemple, l’architecture systolique d’un masque 3*3 sans tenir compte des
valeurs des coefficients, présente un coût de 907 CLBs, or une architecture du même type,
générée pour le filtre de Sobel décrit par la figure 49, présente un coût de 169 CLBs, soit un
gain d’environ 80%.
Le portage de PERCIP sur la Pamette n’est pour l’instant pas achevé. Cependant, les travaux
actuels continuent dans ce sens. Nous avons, par ailleurs, rencontré plusieurs problèmes lors
de ce portage. L’un d’eux est la Regénération de l’horloge PCI avec la boucle PLL qui ne
converge pas sur certains ordinateurs du marché.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Conclusion 102
CONCLUSION ET PERSPECTIVESNous avons présenté dans cette thèse l’environnement PERCIP, qui en partant d’une
description, en un langage orienté traitement d'images, d’une application TBNI, génère une
architecture décrite en VHDL structurel. L’objectif principal de cet environnement est
d’assurer la synthétisabilité du VHDL généré. Par ailleurs, PERCIP ne remplace nullement les
synthétiseurs du commerce. En effet, le code généré doit être traité par une chaîne de CAO
électronique classique, avant de configurer la plate-forme d'implémentation. Comme plate-
forme, nous utilisons la carte Pamette. Par ailleurs, le portage de PERCIP n’est pour l’instant
pas encore achevé. Cependant, les travaux actuels continuent dans ce sens.
Deux choix de moyen de description des architectures générées se présentaient au début de ce
travail : le choix d’un langage de description de matériel tel que le VHDL ou celui d’une
description dans un format intermédiaire spécifique à une technologie particulière, tel que le
format XNF ou LCA de Xilinx. Bien que le second choix permette d’effectuer une meilleure
adéquation algorithme/granularité, il entraîne un surcroît de travail, notamment le
développement d’une ou de plusieurs parties d’un compilateur de silicium (synthétiseur,
routeur, etc.), bien maîtrisé par ses constructeurs. En outre, les formats intermédiaires sont
peu compréhensibles et spécifiques au constructeur de composants. Aussi, avons-nous opté
pour le VHDL, langage standard accepté par la majorité des outils de CAO du commerce.
Pour la description des applications TBNI, nous avons choisi un langage procédural : Apply.
Ayant choisi une approche procédurale, le problème de parallélisation s’est posé. Nous
l’avons alors contourné en fixant au préalable des modèles d’exécution appariés à l’ensemble
des algorithmes considérés : le modèle systolique et le modèle FIR. Cette approche présente
l’avantage d’être simple à mettre au point, cependant elle limite le nombre d’algorithmes pris
en compte. Cette limitation n’est, par ailleurs, pas un grand handicap, puisque nous avons
restreint le domaine d’application au TBNI. Le modèle systolique présente une caractéristique
intéressante, la modularité, qui incite à générer des architectures massivement parallèles, une
perspective envisageable à la veille de l'apparition de FPGA de 1000.000 équivalents portes.
La mise au point d’environnement de génération d'architectures tel que PERCIP retrouve ainsi
tout son intérêt.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Conclusion 103
Apply est un langage dédié au TBNI. Naturellement, il est inadéquat pour la description des
algorithmes du niveau intermédiaire et du haut niveau, telle que la Ligne de Partage des Eaux
(LPE) ou l’érosion et la dilatation [Vincent 90]. Il serait intéressant d’étendre le langage
Apply pour pouvoir décrire de tels algorithmes, même en envisageant d'utiliser une plate-
forme d'implantation hybride, composée d'une partie reconfigurable (à base de circuits
FPGAs) et d'une partie programmable à base de processeurs à granularité large tels que les
DSPs.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Annexe 1 : Syntaxe du langage Apply 104
ANNEXE 1
SYNTAXE DU LANGAGE APPLYPour faciliter la maîtrise d’Apply, ses développeurs ont volontairement choisi une syntaxe
fortement liée à celle du langage standard ADA ; sans pour autant en extraire un sous-
ensemble. La syntaxe originale de ce langage, telle qu’elle a été présentée dans [Hamey 89],
est présentée ci-dessous.
procedure : := procedure function_name ( function_args ) is
variable_declarations
begin
statements
end function_name;
function_name : := name
function_args : := function_argument [, function_argument ]*
variable_declarations : := [ var_list : type; ]*
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Annexe 1 : Syntaxe du langage Apply 105
statements : := [ statement; ]*
name : := alpha [alpha | digit]*
function_argument : :=
|
|
var_list : in type
[border border_type ]
[sample ( integer_list ) ]
var_list : out type
var_list : const type
var_list : := name [ , name ]*
type : :=
|
array ( range [ , range ]* ) of elementary_type
elementary_type
statement : :=
|
|
|
assignment_stmt
if_stmt
for_stmt
while_stmt
Alpha : := A | B | C | D | E | F | G | H | I | J | K | L | M
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Annexe 1 : Syntaxe du langage Apply 106
| N | O | P | Q | R | S | T | U | V | W | X | Y | Z
digit : := 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
border_type : := integer_expr | mirrored
integer_list : := integer [, integer ]*
range : := integer_expr . . integer_expr
elementary_type : :=
|
sign_type object
object
assignment_stmt : := scalar_varc := expr
if_stmt : :=
|
if bool_expr then statements end if
if bool_expr then statements else statements end if
for_stmt : := for variable in range loop
statements
end loop
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Annexe 1 : Syntaxe du langage Apply 107
while_stmt : := while bool_expr loop statements end loop
integer_expr : :=
|
|
|
integer_expr binary_op integer_expr
!integer_expr
( integer_expr )
integer
integer : := [ sign ] digit [ digit ]*
sign_type : := [ signed | unsigned ]
object : :=
|
|
byte
integer
real
scalar_var : :=
|
variable
variable ( subscript_list )
exp : :=
|
expr binary_op expr
!expr
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Annexe 1 : Syntaxe du langage Apply 108
|
|
|
|
( expr )
pseudo_function ( expr )
variable ( subscript_list )
variable
bool_expr : :=
|
|
|
|
|
|
|
|
|
bool_expr and bool_expr
bool_expr or bool_expr
not bool_expr
( bool_expr )
expr < expr
expr <= expr
expr = expr
expr >= expr
expr > expr
expr /= expr
binary_op : := + | - | * | / | ^ | “ | ” | &
sign : := + | -
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Annexe 1 : Syntaxe du langage Apply 109
pseudo_function : := Name
subscript_list : := expr [, expr ]*
number : := integer [ . [ digit ]* ]
Les notations [X], [X]* et X := X1 | X2 signifient :
[X] : X élément optionnel (peut se répéter 0 ou 1 fois)
[X]* : X peut se répéter 0, 1 ou plusieurs fois
X := X1 | X2 : X peut être X1 ou X2
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Lexique110
ABREVIATIONS
APR : Automatic Place and Route
ASIC : Application Specific Integrated Circuits
BNET : Base NETwork
CCM : Custom Computing Machine (machine de calcul personnalisable)
CLB : Configurable Logic Block
Clksys, Clkusr : respectivement horloge système et horloge utilisateur
DEC-PRL : Digital Equipment Corporation’s Paris Research Laboratory
DoD : Department of Defense
DSP : Digital Signal Processor (processeur de traitement de signal)
FIR : Finite Impulse Response
FPGA : Field Programmable Gate Array
GOPS : Giga Opérations Par Seconde
INET : Internal NETwork
IOB : Input/Output Block
LCA : Logic Cell Array
LDG : Logic Description Generator
LUT : Look Up Table
MFLOPS : Million d’opérations flottantes par seconde
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Lexique 111
MIPS : Million d’Instructions Par Seconde
PAM : Programmable Active Memories
PE : Processeur Elémentaire
PERCIP : Programming Environment on Reconfigurable Components for Image Processing
PIF : PCI Interface FPGA (FPGA dédié au bus PCI)
RTL : Register Transfer Level
SRC : Supercomputing Research Center
TBNI : Traitement Bas Niveau d’Image
UAL : Unité Arithmétique et Logique
usrlca{0, …, 3} : FPGA utilisateur {0, …, 3}
VHDL : VHSIC Hardware Description Language
VHSIC : Very High Speed Integrated Circuits
XNF : Xilinx Netlist Format
YUPPIE : Yorktown Utra-Parallel Polymorphic Image Engine
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Bibliographie112
BIBLIOGRAPHIE
[Aho 91] A. Aho, R. Sethi et J. Ullman, « COMPILATEURS Principes, techniques
et outils », édité par InterEditions, Paris, 1989.
[Airiau 90] R. Airiau, J. M. Berge, V. Olive et J. Rouillard, « VHDL : du langage à la
modélisation », Presse Polytechnique et Universitaire Romandes, 1990.
[Alves 94] M. Alves de Barros, « Traitement Bas Niveau d’Images en Temps Réel et
Circuits Reconfigurables », Thèse de Doctorat de l’Université Paris XI,
1994.
[Annaratone 87] M. Annaratone, E. Arnould, T. Gross et al., « The Warp Computer:
Architecture, Implementation, and Performance », IEEE Transactions on
Computers, Vol. C-36, No.12, 1987.
[Astola 90] J. Astola, P. Haavistto, Y. Neuvo, «Vector Median Filters », Proceeding of
the IEEE on multidimensional signal processing, Vol. 78, No. 4, avril
1990.
[Bechon 89] C. Bechon, « Description temps réel des algorithmes du traitement du
signal dans le langage SIGNAL : un exemple », Thèse de Doctorat de
l’Université de Rennes, 1989.
[Buell 96] D. A. Buell, J.M. Arnold, W.J. Kleinfelder, « Splash 2, FPGAs in a custom
computing machine », IEEE Computer Society Press, Los Alamitos, 1996.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Bibliographie 113
[Chin 88] D. Chin, J. Passe, F. Bernard et al., « The Princeton Engine: A Real-Time
Video System Simulator », IEEE Transactions on consumer Electronics,
34(2), pp 285-297, mai 1988.
[Chou 93] C. J. Chou, S. Mohanakrishnan, J. B. Evans. « FPGA implementation of
digital filters », In Proc. Int. Conf. Sig. Proc., Application and Technology,
pp 80-88, 1993.
[Caspi 87] P. Caspi, N. Halbwachs, D. Pilaud et al., « Lustre : a declarative language
for programming synchronous systems », Proc. of the 14th Annual ACM
Symposium on Principles of Programming Languages, pp. 178-188,
janvier 1987.
[Demassieux 91] N. Demassieux, «Architectures VLSI pour le traitement d’images : une
contribution à l’étude du traitement matériel de l’information », Thèse de
Doctorat de l’Ecole Nationale Supérieure des Télécommunications, Paris
1991.
[Duff 78] M.J. Duff « Review of the CLIP Image Processing System » In Proc.
National Computer Conference, pp 1055-1060, juin 1978.
[Evans 93] J. B. Evans, « An efficient FIR filter architecture », IEEE Int. Symp.
Circuits and Syst., pp 627-630, 1993.
[Fisher 87] A.L. Fisher, P.T. Highman, T.E. Rockoff, « Architecture of a VLSI SIMD
Processing Element », Proc. IEEE Conference on Computer Design : VLSI
in Computers and Processors., pp 324-327, octobre 1987.
[Fisher 88] A.L. Fisher, P.T. Highman, T.E. Rockoff, « Scan Line Array Processors:
Work in Progress », In Proc. Image Understanding Workshop, pp 625-633,
1988.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Bibliographie114
[Fornari 95] F. X. Fornari, « Optimisation du contrôle et implantation en circuits de
programmes ESTEREL », Thèse de Doctorat de l’Ecole des Mines de
Paris, 1995.
[Fountain 88] T. J. Fountain, K. N. Matthews, M. J. B. Duff, « The CLIP7A Image
Processor », IEEE transactions on Pattern Analysis and Machine
Intelligence. Vol. 10, No. 3, 1988.
[Hamey 89] L. G. H. Hamey, J. A. Webb, I-C. Wu, « An Architecture Independent
Programming Language for Low-Level Vision », Computer Vision
Graphics Image Processing, Vol. 48, pp 246-264, 1989.
[Hanifi 95] D. Hanifi, M. Shawky, « Adaptation de la structure de calcul d'un réseau de
neurones de type CMAC à une implantation matérielle », revue
Automatique Productique et Informatique Industrielle (APII), INIST-
CNRS, numéro spécial Réseau de Neurones, février 1995.
[Hanifi 97] D. Hanifi, M. Shawky, « Hardware Implementation of a Two Mode
Correlator for an Intelligent Ultrasound Meter », SICICA'97 (IFAC),
Annecy, juin 1997.
[Hanifi 98] D. Hanifi, M. Shawky, « Comparaison entre différentes implémentations
systoliques des opérateurs de pré-traitement d’image », AAA98 En
traitement du signal et images, pp 167-172, Saclay, janvier 1998.
[Hardouin 98] C. Hardouin, M. Shawky, « Débruiteur d’images numériques, solution en
composants reconfigurables », Rapport de projet de fin d’études,
Université de Technologie de Compiègne, février 1998.
[Horaud 93] R. Horaud, O. Monga, « Vision par ordinateur », Edition HERMES,
Paris, 1993.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Bibliographie 115
[Juvin 88] D. Juvin, J. L. Basille, H. Essafi et al., « Sympati2, a 1.5d processor array
for image applications », In EUSIPCO Signal Processing IV : theories and
application, pp 311-314, North Holland, 1988.
[Lavenier 89] D. Lavenier, « MicMacs : un réseau systolique linéaire programmable pour
le traitement des chaînes de caractères », Thèse de Doctorat de l’Université
Rennes I, juin 1989.
[Levine 95] J-R. Levine, T. Mason, D. Brown, « Lex & Yacc », Editions O’Reilly
International Thomson, 1995.
[Lim 93] Y. C. Lim, J. B. Evans, B. Liu, « An Efficient Bit-Serial FIR Filter
Architecture », Internet, avril 1993.
[Li 89] H. Li, M. Maresca, « Polymorphic-Torus Architecture for Computer
Vision », IEEE Transactions on Pattern Analysis and Machine
Intelligence, 11(3), pp 233-243, mars 1989.
[Maresca 88] M. Maresca, M.A. Lavin, H. Li, « Parallel Architectures for Vision »
Proceedings of the IEEE, 76(8), pp 970-981, août 1988.
[Mohanakrishnan 93] S. Mohanakrishnan, J. B. Evans, « Automatic Implementation of FIR
Filters on Field Programmable Gate Arrays », Under review, IEEE Signal
Processing Letters, octobre 1993.
[Quinton 89] P. Quinton, Y. Robert, « Algorithmes et architectures systoliques », Edition
MASSON, 1989.
[Schmitt 88] L.A. Schmitt, S.S Wilson, « The AIS-5000 Parallel Processor », IEEE
Transaction on Pattern Analysis and Machine Intelligence, 10(3), pp 320-
330, mai 1988.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Bibliographie116
[Shand 98] M. Shand, « PCI Pamette user-area interface for firmware v1.9 »,
(http://www.research.digital.com/src/pamette/Download.html), 1998.
[Shawky 96] M. Shawky, D. Hanifi, « Hardware implementation of an Adaptive CMAC
Neural Network », MicroNeuro 96, 5th Int'l Conf. on Microelectronics for
Neural Networks and Fuzzy Systems, Lausanne, Suisse, mars 1996.
[Shawky 98] M. Shawky, D. Hanifi, L. Bourdon et al., « Defining a fine grain execution
model in reconfigurable components », Reconfigurable Architecture
Workshop 98, Allemagne, mars 98.
[Touati 97] H. Touati, « PamDC: a C++ Library for the Simulation and Generation of
Xilinx FPGA Designs»,
(http://www.research.digital.com/src/pamette/Download.html), 1997.
[Vincent 90] L. Vincent, « Algorithmes morphologiques à base de files d’attente et de
lacets. Extension aux graphes », Thèse de Doctorat de l’Ecole Nationale
Supérieure des Mines de Paris, mai 1990.
[Vuillemin 95] J. Vuillemin, P. Bertin, D. Roncin et al., « Programmable Active
Memories: Reconfigurable Systems Come of Age », IEEE Transactions on
VLSI systems, 1995.
[Wallace 89] R. S. Wallace, J. A. Webb, I-C. Wu, « Machine-Independent Image
Processing : Performance of Apply on Diverse Architectures », Computer
Vision, Graphics and Image Processing, Vol. 48, pp 265-276, 1989.
[Xilinx 94] « The Programmable Logic Data Book », Xilinx, San Jose, CA, USA,
1994.
Générateur d’architecture pour plate-forme reconfigurable dédié au traitement d’image
Bibliographie 117
[Zhou 95] F. Zhou, P. Kornerup, « A High Speed Hough Transform Using
CORDIC »,
(http://www.imada.ou.dk/Research/Preprints/Abstracts/1995/27.html),
1995.