à mohamed shawky pour m'avoir patiemment …shawky/hanifi/rapport_these_hanifi.pdf · 3.2...

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


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.


Chapitre 1 : Traitement d'image et architectures parallèles et reconfigurables 3

CHAPITRE 1

TRAITEMENT D’IMAGE ET

ARCHITECTURES PARALLELES

ET RECONFIGURABLES



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.


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’imag
image 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



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.


Chapitre 1 : Traiteme

m
image m x
ré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



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].


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



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



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


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



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.


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
Q
RD

F

D
IN
am

Q

F

G

AB
C D E
0

M

1

UX
D Q
RD

0

M

1

UX

F

D
IN
G

VARIABLESLOGIQUES

ENTREEDES DONNEES

DI

1 (AUTORISE)

VERROUILLAGED’HORLOGE

EC

HORLOGE
K
RESETDIRECT

R

0 (INHIBE)

ille XC3000
RESETGLOBAL
X

Y

SORTIESDU CLB

14



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.


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

’
Ordinateur
apitre 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’
Ou
Out

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 à


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
adr
S
adr
adrS

adrW

Figure 10 : Architecture du DECPeRLe-1

17

isins. Les 4

t également

uration de 2

ut de cette

FPGA. En

é le goulot

, comparé à



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



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


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


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
9
M
M
11

M

1

M

5
12
M

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
interfac
contrôle

Bus VSB
Bus VME
Figure 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



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


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)
X0
Extension

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
SBu
SIMD

SBus

RBus

Figure 13 : Architecture de Splash 2

23


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
Canal
Canal B

Canal

Mémoire

rec

XL

o

XR

36

25

32

36

25

nfigurabl

32

7

e

32

36

36

Entrée

externedresses
A
Données

Sortie

xterne

s

Extension

du SBus

Bus SIM

RBus

Figure 15 : Architecture de la carte d’interface

24



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



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



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



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.



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.



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



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


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



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.



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


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


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


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




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



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



"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



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,


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.


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.


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 dimension
de description : VHDL et Apply 44


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,1
P(1,0

P(1,0

P(1,1)

P(0,1
P(1,1
DL 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



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.


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



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.


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.



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



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.


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


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èse
nnement 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



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.



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



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.


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


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+1
58


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


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

*
W
ERCIP

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


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 X1
W3
W2 W1
Figure 39 : Architecture du réseau systolique

0

PTn : Point n

61



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



(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


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

+

*

+

*

+

*
M
X4X4X3X3X2X2
X1 X
T6
B
A2

A3

B3

A1

B1

0

Figure 40 : Utilisation du réseau pour le calcul simultané de deux filtres

Y

PT

64


+

*

+

*

+

*

2 1

Y

PT1 PT3

PT7PT8

1

M

M

M

M

MM

M

M
X4X3X3X3X2X

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 X2
C2

A2

B2

A

B

C3

B1

C1

A

65

E

de

sur

rés

la

des

les

ues

ux


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 W1
Y

66



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


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.



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



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é.


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 à


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).


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



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.


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.


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


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



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


Chapitre 4 : Application

Figure 51 :
Description VHDL de l’architecture systolique de la
composante 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


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



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


Figure 53 : Code VHDL de l’architecture FIR de la composante verticale du filtre de Sobel

C




entity SobelVertical is



downto 0);


downto 0);

vert : out std_logic_vector(15

downto 0));

end SobelVertical;

architecture FIR of SobelVertical is


-- REG8

component REG8


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);


downto 0);


downto 0);

signal ADD_1_1_O : std_logic_vector(15

downto 0);


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);


downto 0);


downto 0);


downto 0);


downto 0);

81


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
11
13
2 4
tions

e

5

Figure 54 : Filtrage médian d’une imag

Image original
Traitement
Image traité


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
B
re 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>
Comparateu
Figure 55 : Schéma logique de l’unité de comparaison et d’échange (UCE)

83


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
2
A

5

pp

3

4

6

lica

7

tions

8
9
2

4
8
e

4

Figure 57 : Contre-exempl


Chapitre 4 : Applica

Figure 58 :
Description Apply du filtre médian en adoptant la méthode de
dé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


M M)
inimg(1,-1)

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,1
comp<

mux0
1
)
si(1
MEDIAN 1D

MEDIAN
MEDIAN
MEDIAN

si(0
si(-1
Median

Architecture du filtre médian générée par PERCIP en adoptant la

méthode de décomposition


C


entity Median2D is



downto 0);

inimg0 : in std_logic_vector(7

downto 0);


downto 0);

Mediane : out std_logic_vector(7

downto 0));

end Median2D;

architecture archi of Median2D is


-- REG8

component REG8


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;











-- Sorties des multiplexeurs

87


-- 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_O);

M_3_1 : REG8 port map (CLK, inimgP1,

M_3_1_O);


M_3_2_O);


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);


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 5
MUX_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
A
B

E

Max(A,B

Min(A,B)

UC

4

3

4

3
8 4 13
8

8

1

8

7

8

7
13 3 7
13

4

13
7
4

Figure 61 : Principe du tri-bulle pour N=5

PIXEL

89


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,0
inimg(1,1)
inimg(0,1 inimg(-1,1)
UCE
UCE
2
UCE UCE
Median

Figure 62 : Architecture du médian 2D avec tri en adoptant une optimisation

Médian
UCE



( ∞→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.


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


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


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





entity MedianHybride is



downto 0);

inimg0 : in std_logic_vector(7 downto

0);


downto 0);

Mediane : out std_logic_vector(7

downto 0));

end MedianHybride;

architecture archi of MedianHybride is


-- REG8

component REG8



signal M2 : std_logic_vector(7 downto 0);

signal M_1_1_O : std_logic_vector(7 downto

0);


0);


0);


0);


0);


0);

-- Sorties des comparateurs





signal CMP 1SN1SN1 O : std logic;


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 manuelle
de quelques filtres de TBNI

Applications 97



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



(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.



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
Clkusr
Clksys

EBus
PCI
horlog

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



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é.


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.


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.


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; ]*



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



| 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



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



|

|

|

|

( 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 : := + | -



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


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


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


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.


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.


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.


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.


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.

http://www.research.digital.com/src/pamette/Download.html)



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.


à mohamed shawky pour m'avoir patiemment …shawky/hanifi/rapport_these_hanifi.pdf · 3.2...

Documents