See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/266087568

DRUM: une unité reconfigurable intégrée sur plateforme multiprocesseurs

hétérogène

Conference Paper · October 2003

CITATIONS READS

0 81

4 authors, including:

Sumit Ahuja B. Pottier

33 PUBLICATIONS   212 CITATIONS   
Université de Bretagne Occidentale
137 PUBLICATIONS   582 CITATIONS   
SEE PROFILE
SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Morpheus European Project View project

PERSEPTEUR View project

All content following this page was uploaded by B. Pottier on 26 September 2014.

The user has requested enhancement of the downloaded file.

 RENPAR’15 / CFSE’3 / SympAAA’2003
La Colle sur Loup, France, 15 au 17 octobre 2003

DRUM : une unité reconfigurable intégrée sur plateforme

multiprocesseurs hétérogène
Sumit Ahuja, Love Kothari, Erwan Fabiani et Bernard Pottier

Équipe Architectures et Systèmes,

Université de Bretagne Occidentale,
U.F.R. des sciences et techniques,
20 av. Victor Le Gorgeu,
29200 Brest
fabiani@univ-brest.fr

Résumé
Cet article présente une proposition d’unité architecturale reconfigurable pour plateforme multiproces-
seurs hétérogène intégrée. Une unité DRUM (Dynamically Reconfigurable Unit for an Heterogeneous
Multiprocessor) est composée de 2 blocs reconfigurables, l’un dédié au contrôle, l’autre dédié aux calcul,
d’une RAM pour stocker des reconfiguration et tamponner les entrées/sortie, et d’un large chemin de
données entre ces éléments. Nous détaillons l’architecture et le fonctionnement de cette unité et mon-
trons comment elle permet de résoudre le problème connu d’alimentation des unités reconfigurables, et
pourquoi elle se prête bien à la reconfiguration dynamique. Un exemple de mise en oeuvre d’application
de traitement d’image (filtre moyenne) est présenté pour illustrer l’échange des données et l’adaptation
des critères de compilation d’opérateurs en fonction des contraintes physiques et contextuelles.

Mots-clés : Architecture reconfigurable, multiprocesseurs hétérogène, calculs flots de données, SOC

1. Introduction

Les architectures de machines à usage général sont conçues avant tout pour obtenir des performances
acceptables pour une grande variété d’applications : l’adéquation entre l’architecture et l’application
détermine le niveau de performance pour un problème particulier. Une application qui requière plus
de puissance de calcul qu’une machine généraliste ne peut lui en offrir doit être implémentée sur une
architecture spécifique.
Une caractéristique commune à la plupart des applications de calcul intensif est qu’elles passent la ma-
jorité de leur temps d’exécution dans un noyau réduit de leur code. Ainsi les machines reconfigurables
(implémentées sur FPGA ou Datapath) sont utilisées pour accélérer l’exécution des algorithmes, par le
portage des portions de calcul intensif sur le support reconfigurable [9, 14, 3, 16, 8, 2, 6, 13].
Drum (Dynamically Reconfigurable Unit for an Heterogeneous Multiprocessor) est une unité architectu-
rale composée de 2 blocs reconfigurables couplés destinée à être utilisée en tant qu’accélérateur matériel
des calculs. L’un de ces blocs reconfigurables est utilisé en tant que bloc de calcul, et l’autre en tant que
bloc de contrôle pour piloter les calculs et les flots de données. Ces unités sont destinées à être intégrées
dans des plateformes multiprocesseurs hétérogènes de type SOC et permettre la gestion de modèles
applicatifs de haut-niveau, tels que les calculs par flots, les boucles, les réseaux réguliers, etc...
Dans la suite nous présentons le modèle de plateforme dans lequel s’intègre une unité Drum et nous la
mettons en perspective des travaux antérieurs. Puis nous détaillons l’architecture d’une unité Drum, en
montrant les critères qui ont dirigé sa conception. Ensuite nous présentons les mécanismes de base pour
le fonctionnement d’une unité Drum. Enfin nous évoquons l’aspect compilation des opérateurs sur une
unité à travers un exemple, avant de conclure.
 Station de travail Station de travail Station de travail Station de travail
Co−processeur
CPU CPU
CPU CPU
UF

Mémoire Mémoire
cache
Mémoire Mémoire cache Unité de calcul
associée Unité de calcul indépendante
Cache cache
Interface
Interface Interface d’E/S
d’E/S d’E/S Interface
d’E/S

A B C D

F IG . 1 – Modèles d’utilisation de support reconfigurable de calcul : (A) unité fonctionnelle, (B) co-
processeur, (C) unité de calcul associée, (D) unité de calcul indépendante

1.1. Travaux antérieurs

Un grand nombre de travaux ont portés sur le couplage d’architectures reconfigurables à des micro-
processeurs (voir S. Hauck [13]). Pour utiliser efficacement de telles machines, les microprocesseurs
effectuent généralement le contrôle des boucles et des alternatives, et le support reconfigurable réalise
les calculs intensifs parallélisés. Ces couplages peuvent avoir différentes natures :
1. Le support reconfigurable peut être uniquement utilisé pour fournir des unités fonctionnelles re-
configurables au sein d’un processeur hôte [16, 13] (voir fig. 1.A). Cela permet de conserver un en-
vironnement de programmation traditionnel, avec l’ajout d’instructions spécialisées qui peuvent
changer dans le temps.
2. Une unité reconfigurable peut être utilisée comme un co-processeur [9, 1, 14, 3] (voir fig. 1.B). Un
co-processeur reconfigurable dispose généralement de plus de ressources de calcul qu’une unité
fonctionnelle, et est capable de réaliser des calculs sans le contrôle constant du processeur hôte.
3. Une unité de calcul reconfigurable [8, 2, 6, 5] s’utilise comme un processeur additionnel dans un
système multiprocesseurs (voir fig. 1.C). Le cache de données du processeur hôte n’est pas visible
par l’unité de calcul reconfigurable. Il y a un délai de communications plus important entre le
processeur hôte et le support reconfigurable (configuration, entrées/sorties).
4. Finalement, le type de support reconfigurable le plus faiblement couplé est celui d’une unité de
calcul reconfigurable indépendante externe [4, 15](voir fig. 1.D). Ce type de support reconfigurable
communique assez peu fréquemment avec un éventuel processeur hôte. Ce modèle est similaire
à celui d’un réseau de stations de travail, où les calculs peuvent être exécutés sur de longues
périodes de temps sans trop de contrôle direct.
La principale différence entre ces modèles concerne l’intégration du support reconfigurable. L’intégration
permet une utilisation intensive en raison du coût réduit des communications. Cependant le support
reconfigurable est incapable de fonctionner pendant des périodes de temps significatives sans l’in-
tervention du processeur hôte, et la quantité de ressources logiques disponibles est souvent relative-
ment limitée. Les modèles les moins intégrés permettent plus de parallélisme dans l’exécution des pro-
grammes, mais souffrent d’un coût plus important des communications. Pour les applications qui re-
quièrent une grande quantité de communications, cela peut réduire ou même annuler l’accélération des
calculs obtenue sur le support reconfigurable.

1.2. Unité de calcul reconfigurable pour multiprocesseurs

Les deux premiers modèles architecturaux présentés plus haut peuvent fonctionner en tant qu’unité de
calcul indépendante (UCI) d’un système multiprocesseur hétérogène organisé comme sur la figure 2.A .

2
 addresses addresses
UCI Mem Mem UCI

Réseau de transfert de données

R
Bloc de
A Bloc de
Calcul
M Contrôle
UCI Mem Mem UCI données données
Accélérateur matériel

addresses
contrôle

données
Unité Drum
E/S (haut débit) Mem Mem UCI

E/S (bas débit) Mem Mem Vers mem. ext. µP Mémoire

Mem Mem Mem Mem

Processeur système Mem Mem Mem Mem

Réseau d’interconnexions

A B
F IG . 2 – (A) Modèle de système multiprocesseur hétérogène. (B) Architecture d’un noeud de calcul
intégrant une unité Drum

Ce système intégré sur puce dispose d’une variété d’unités de calcul, de ressources de communications
entre ces unités de calculs, de mémoires caches, de canaux d’entrées/sorties et d’un processeur système
pour le contrôle de la puce. Ce type d’architecture vise a remplacer la conception de circuits spécifiques
par la fourniture de programmes reconfigurables dans certains segments du marché, lorsque le faible
nombre d’unités à produire ne justifie pas le coût d’un circuit spécifique et/ou qu’une mise à disposition
rapide est primordiale.
Ce système est composé de ressources de calcul qui sont connectées par un réseau extensible et adap-
table, l’idée étant de disposer d’un circuit hiérarchisé avec du routage. Ce réseau est utilisé pour le trans-
fert de données dans le système de la mémoire externe vers une UCI, d’une UCI vers une UCI, d’une UCI
vers les entrées/sorties ou la mémoire locale, et pour l’échange de données entre le processeur système
et les UCI. Le processeur système peut non seulement synchroniser et ordonnancer les unités de calcul
mais il virtualise aussi les unités de calcul, contrôle les mémoires internes, réalise les fonctions de gestion
des tâches et tend à améliorer les performances générales du système de par son contrôle de l’ensemble
du réseau de communications. Les UCI réalisent des calculs sur les données reçues via le réseau (avec
l’aide du processeur système). Les données sont reçues sous la forme de paquets dans la mémoire lo-
cale de chaque UCI. Le modèle d’exécution dans cet environnement multiprocesseurs est basé sur des
files d’E/S, mises en oeuvre dans les mémoires locales, liées à chaque opérateur (ou processus) : Ceci
afin que la puissance de calcul puisse être en adéquation avec les données envoyées sur le noeud de
calcul, quelque soit la discontinuité de débit du réseau. Ce modèle n’est réaliste que si l’on dispose
d’un environnement de programmation bien hiérarchisé en couches (depuis la description haut-niveau
du programme jusqu’à la logique bas-niveau) et automatiquement adaptable à tout type d’architecture
cible. C’est le cas de l’environnement Madeo [11], qui permet : (1) la définition de programme en lan-
gage haut-niveau ou la description de modèles de composants spécifiques (2) la synthèse logique (3) la
modélisation et la génération automatique d’outils de conception pour architectures reconfigurables.

2. Principes de base et architecture d’une unité DRUM

Les capacités de traitement de Drum sont basées sur la programmation d’opérateurs dédiés spécifiques
et l’utilisation du parallélisme massif. L’architecture (voir fig. 2.B) est composée de 2 blocs reconfigu-
rables couplés : un bloc reconfigurable est utilisé en tant que support de calcul, et l’autre sert à contrôler
l’ensemble des calculs et des flots de données sur le bloc de calcul. Ces deux blocs sont nommés par la
suite bloc de calcul et bloc de contrôle. La technologie choisie est de type FPGA dotée d’un mécanisme

3
particulier qui permet un accès direct aux registres de données et aux registres de configuration, sans
passer par les blocs d’entrées/sorties (IOB), à l’image du mécanisme “FastMap” implanté sur les XC6200
[10]. Les registres de données désignent les éléments de mémorisation auxquels sont connectés les blocs
logiques. Les registres de configuration désignent les mémoires configurant la logique et le routage du
support reconfigurable.
Une unité Drum est intégrée dans un noeud de calcul relié au réseau, qui comprend une mémoire et un
microprocesseur. Nous ne faisons pas d’hypothèse précise sur le rôle de ce microprocesseur : il peut être
absent et sa puissance est fonction de l’intensité du couplage avec l’unité Drum
Deux principales caractéristiques distinguent cette proposition d’architecture :
– Jusqu’à présent, un processeur hôte devait gérer la reconfiguration du support reconfigurable et les
communications entre celui-ci et la mémoire [12], ce qui entraı̂nait un coût important en nombre de
cycles du processeur. De plus, le programme devait manipuler les mécanismes bas niveau du support
reconfigurable, ce qui occasionnait aussi une grande perte de temps. Dans notre architecture un bloc
reconfigurable est utilisé pour piloter toute ces tâches à la place du processeur hôte.
– Un large chemin de données (de l’ordre du Kbits) est prévu pour le transfert de données et de confi-
gurations entre la RAM et le bloc de calcul et inversement, piloté par le bloc de contrôle.
Les différents composants de cette architecture sont les suivants :
– Bloc reconfigurable de calcul : ce bloc étant dédié uniquement au calcul, il doit être plus performant
qu’un circuit FPGA standard et permettre un contrôle plus facile. Ainsi la logique doit être optimisée
pour le calcul et les ressources de routage réduites pour viser une basse consommation. De plus il
faut un accès simplifié aux registres de données et de configuration en lecture/écriture, la possibilité
de reconfiguration partielle pour permettre l’exécution simultanée de processus, et des données de
configuration concises.
– Bloc reconfigurable de contrôle : ce bloc doit pouvoir à la fois contrôler les flots de données et les
calculs. Il doit être doté d’une partie figée qui provoque son amorçage à la demande du processeur
hôte et l’activation des transferts de données et des processus (configurations). Ce bloc s’occupe de
l’empaquetage/dépaquetage des données, de la gestion des files d’E/S, des interconnexions avec le
bus système ou des appareils extérieurs, et de la réactivité au contrôle provenant du processeur hôte. Il
gère également l’adressage des données et doit permettre de disposer d’opérateurs spécifiques pour le
pré ou post-traitement des données. Enfin, il réalise l’ensemble des transferts entre les bancs mémoires
de l’unité. Le bloc de contrôle peut être vu comme un support matériel dédié, ou des composants
configurés sur un support reconfigurable à grain fin.
– Mémoire (RAM) : la mémoire intégrée doit réaliser des transferts et des stockages de données rapides
et efficaces, grâce à un accès rapide et une grande largeur des mots mémoire. Elle est destinée à stocker
des configurations et des paquets de données.
– Chemin de données : les interconnexions entre la RAM, le bloc de contrôle et le bloc de calcul sont
réalisées par l’intermédiaire d’un large chemin de données pour l’amélioration des performances
dans le cas de l’exécution concurrente de processus. Sa taille est de l’ordre d’un Kbits, pour facili-
ter également le swap rapide de configurations.
– Des unités spécifiques : prévues pour le décalage, la génération de masque, ou l’interfaçage avec la
mémoire de configuration.
L’unité Drum apporte donc les facilités suivantes :
– La gestion de la configuration du bloc de calcul devient simple et rapide : le bloc de contrôle peut lire
et écrire directement dans les registres de configuration. Dotés de mécanismes simples, il est ainsi ca-
pable de mettre en oeuvre l’évolution du partitionnement spatial entre les différents processus (confi-
gurations), calculé et commandé par le microprocesseur du noeud de calcul ou le processeur système
de la plateforme. Cette mise en oeuvre s’appuie sur des primitives telles que le décalage de configu-
ration ou le swap de configuration via la RAM, grâce à la largeur du chemin de données.
– La gestion des E/S n’influe pas sur les performances du bloc de calcul : comme le bloc de contrôle
peut lire et écrire directement dans les registres de données du bloc de calcul, il n’est pas nécessaire
d’utiliser des blocs d’E/S et du routage sur le bloc de calcul pour l’échange des données. Cela permet
donc d’optimiser l’architecture de routage du bloc de calcul. L’alimentation simultanée de plusieurs
processus est rendue possible par la largeur du chemin de données, qui peut être partitionné entre
les processus, sans congestion de routage ni délais importants. L’unité est donc adaptée à la mise en

4
 E/S extérieures




 m.e. 


 


 




 





 
séquenceur
d’adresses




 


 


 




 





 



  


 


 



 





 


 état 

 

 
système
m.e. Registre de calcul
RAM Bloc de contrôle Bloc de calcul
Bus système

F IG . 3 – Utilisation de files pour l’entrée et la sortie des paquets.

oeuvre de systèmes GALS (Globalement Asynchrone, Localement Synchrone).

– L’empaquetage des données : dans le modèle de plateforme, les données circulent sous forme de
paquet. Puisqu’une unité Drum est capable de gérer plusieurs processus simultanément, la struc-
turation en paquet doit être conservée jusqu’au dernier moment (comme elle indique le processus
destinataire). De plus il est évident que l’empaquetage des données a aussi pour but leur compres-
sion. Ainsi, le bloc de contrôle va dépaqueter les données (qui auront été stockées dans la RAM) et
alimenter les processus, avec un débit plus important comparativement à une réception de données
“prêtes à l’emploi” via le réseau. On obtient donc une disjonction entre la circulation des données sur
le réseau système et les communications avec le bloc de calcul, ce qui est nécessaire pour l’application
d’un modèle de communication par flot.

3. Fonctionnement d’une unité DRUM

Dans cette partie sont présentés les principaux mécanismes de fonctionnement d’une unité Drum : la
gestion des E/S, les opérations de base et les macro-opérations.
La figure 3 montre le mécanisme qui permet d’envoyer et de recevoir des données, que ce soit en pro-
venance du bus local ou des E/S d’un appareil extérieur. Les données sont présentées sous forme de
paquets caractérisés par l’identification du processus concerné et leur numéro. Ces paquets sont gérés
par des machines à états qui mettent également à jour les états système de l’unité Drum. Ces machines
à état sont implémentées en logique reconfigurable ou sous la forme de micro-contrôleurs, pour réaliser
la sélection de données et le pré ou post traitement des données. Un paquet entrant dans une unité est
caractérisé par une source, un code d’identification du processus (pid), et un numéro de séquence. Le
processeur système met à jour dynamiquement dans chaque noeud de calcul les adresses de continua-
tion des paquets de données traitées en fonction du pid et de la source. La structuration des données à
l’intérieur des paquets est dépendante de l’application.
L’état système permet d’associer les processus configurés sur le bloc de calcul avec les données reçues
et envoyées, les états des calculs et les erreurs éventuelles. Selon l’état système, les machines à états
peuvent accepter ou rejeter les paquets arrivant dans l’unité. L’état système est géré comme un en-
semble de registres accédé par les composants de contrôle du bloc et le microprocesseur associé. Une
représentation de ces données est une table dont les entrées sont associées aux processus locaux et aux
mécanismes utilisés pour la prise de décision dans l’unité.
Les opérations de base comprennent la génération de masque concernant les registres de configuration
ou de données du bloc de calcul qui ne doivent pas être modifiés, le décalage de bits sur le bloc de
contrôle, les opérations logiques opérants sur des registres de données ou de configuration, la génération
du signal d’horloge, ainsi que la lecture/écriture de configurations et de données masquées vers la
mémoire ou le bloc de calcul.

5
 A B C
3 Dépaquetage de
la configuration 4 Reconfiguration
2 Dépaquetage des données
RAM RAM Bloc de contrôle données et
 


 
 
RAM Bloc de contrôle Bloc de calcul
Bloc de contrôle








Bloc de calcul Paquets contrôle
 


 
 
X
m.c.
à états 












X



X
m.c.
à états
X
m.c.
à états


X


Chargement de la Chargement des Transert des résultats en mémoire

configuration a partir 2 paquets a partir 1 Mémoire
de la mémoire
vers la RAM 1 Ordre de chargement de
la configuration "X"
de la mémoire
vers la RAM
Mémoire µP Mémoire

X X
1 to 10^6 do: X contrôle
principal

F IG . 4 – (A) Chargement (Reconfiguration) du bloc de calcul avec l’aide du bloc de contrôle. (B) Tam-
ponnage : sauvegarde des paquets de données dans la RAM et transfert vers le bloc de calcul. (C) Ali-
mentation : les calculs sont en cours sur le bloc de calcul et les données sont fournies par le bloc de
contrôle.

Les Macro-opérations regroupent le support pour le swap de configuration, le paquetage et le dépa–

quetage des données, la reconfiguration dynamique basée sur un contexte partiel, etc... . Ces macro-
opérations sont composées de nombreuses opérations de base éventuellement répétées. Par exemple, le
swap de configuration nécessite la lecture itérative d’une colonne de registres de configuration et son
écriture dans la RAM ou le bloc de calcul. Le bloc de contrôle supervise alors l’adresse de provenance et
de destination des données de reconfiguration.
Le fonctionnement d’une unité Drum peut être caractérisé par 4 étapes suivantes :
1. Le chargement de la configuration (fig. 4.A). La configuration associée à un traitement est transférée
de la mémoire principale vers la RAM (si elle ne s’y trouvait pas déjà), et ensuite est chargée dans
le bloc de calcul par le biais du bloc de contrôle, après dépaquetage.
2. Le tamponnage des données (fig. 4.B). La profondeur de tamponnage est fonction de l’amor-
tissement souhaité des discontinuités de débit du réseau système, et de la quantité de données
nécessaire au démarrage des calculs.
3. L’alimentation courante du processus par la fourniture des données nécessaires et du contrôle (fig.
4.C). Les calculs débutent, les communications de données et de contrôle étant supervisées par le
bloc de contrôle, via un micro-contrôleur. Les résultats peuvent être envoyés simultanément sous
la forme de paquets vers la mémoire principale.
4. La gestion de l’espace pour un fonctionnement correct des différents processus : en cas de manque
de place pour implémenter plusieurs processus sur le bloc de calcul, le swap de configuration est
réalisé selon la priorité des processus.

4. Compilation pour une unité Drum

La production de processus câblés sur Drum est réalisée par la définition de composants ’objets’ assu-
rant l’ambivalence d’un interface logiciel comportemental de haut niveau couplé aux outils de synthèse
logique et de synthèse architecturale [7].
La définition d’un programme pour une unité Drum comporte deux aspects : le choix de structuration
et de présentation des données aux opérateurs de calcul, et la mise en oeuvre des opérateurs sur le
bloc de calcul. Ces deux aspects sont discutés et illustrés par l’exemple d’un filtre moyenne. Ce filtre,
comme la plupart des algorithmes de traitement d’image, nécessite l’application répétée d’un même
calcul sur l’ensemble de l’image. Il est destiné à réduire les variation d’intensité entre des pixels d’un
voisinage et consiste à remplacer chaque pixel par la valeur moyenne des pixels voisins (lui y compris),
dans une fenêtre carrée de dimension N, avec N impair. De par leur aspect régulier et parallélisable, les
temps d’exécution de ce type de traitement peuvent être drastiquement réduits par leur implémentation
matérielle. Cependant la problématique de mise en oeuvre matérielle est dominée par les restrictions

6
 transfert vers les Image
registres de calcul
résultat partiel zone 1 zone 2
S E
fenêtre
op2 op4 7x7 pixels

op1 op3 2
1
bloc de contrôle bloc de calcul
registres 8 bits
recouvrement de zones
A B
F IG . 5 – (A)Le contenu de la file d’entrée et écrit dans les registres de données du bloc de calcul colonne
par colonne et deux fenêtres avec leurs opérateurs associés travaillent simultanément sur une colonne
de données. (B) mécanisme de fenêtre glissante pour le partitionnement des données.

de débit d’E/S pour la communication des données. Concrètement il n’est pas possible de stocker les
images entières sur la mémoire intégrée sur puce.
L’unité Drum est particulièrement bien adaptée à la résolution de ce problème. En effet, on peut disposer
d’un recouvrement complet entre les calculs (réalisés sur le bloc de calcul) et la gestion des E/S (réalisée
sur le bloc de contrôle). Le pilotage d’un tel flot de données est réalisable de la manière suivante :
d’abord nous supposons que l’image a été partitionnée en plusieurs zones verticales et qu’une ligne
de cette zone est envoyée à l’unité sous la forme d’un paquet. En fonction de la taille du voisinage,
les lignes (en nombre suffisant pour le démarrage) sont stockées en RAM et ensuite transférées sur le
bloc de calcul (voir fig. 5.A). On procède ensuite par décalage pour alimenter les opérateurs. Cela est
comparable à une fenêtre glissant ligne par ligne dans une direction horizontale (voir fig. 5.B). Pendant
les calculs une nouvelle ligne est transférée dans la RAM. Une fois que la fenêtre glissante a atteint la fin
de la zone, les résultats sont extraits et les calculs commencent avec la ligne suivante.
L’implémentation de ces opérateurs doit être conditionnée par les spécifications requises et le contexte
d’utilisation. Ces informations comprennent le débit de l’interface, la latence requise pour l’opération,
la taille des tampons, la disponibilité des ressources de calculs, les performances souhaitées (fréquence,
surface, consommation) des opérateurs, ... . Pour adapter la compilation des opérateurs aux contraintes
physiques et temporelles, on dispose de différents degrés de liberté :
– le nombre d’opérateurs travaillant en parallèle, ainsi que le niveau de calculs partagés par ces opérateurs :
dans notre cas le compilateur Madeo permet de fusionner automatiquement ces calculs partagés [11].
– le niveau de pipelinage et, en relation étroite, le caractère parallèle ou série de l’alimentation des
opérateurs.
– le découpage des opérateurs en sous-modules, travaillant simultanément ou swappés alternativement
avec un stockage des résultats intermédiaires dans la RAM
– le niveau de précision : dans le cas précis du filtre moyenne, on peut choisir de faire une division
partielle après chaque somme d’une ligne de la fenêtre, au lieu de diviser après la somme totale de
tous les pixels. Cela introduit une approximation (+1 ou -1), mais entraı̂ne une réduction importante
de la taille de l’opérateur : en effet, le compilateur Madeo opère sur des données typées par le nombre
de valeurs prise et la division est accompagné de la troncature du résultat (puisque l’on manipule des
pixels), ce qui réduit évidemment le nombre de valeurs et donc la taille de la logique générée.

5. Conclusion

Nous avons présenté l’architecture d’une unité reconfigurable, située à la confluence des FPGA et des
multiprocesseurs, dont le principe de base est la séparation en deux blocs reconfigurables distincts,
l’un optimisé pour les calculs, et l’autre supervisant le contrôle pour décharger le processeur hôte de

7
 ces tâches. Cette unité est une partie d’un modèle général de plateforme multiprocesseurs hétérogène
intégrée, dont les communications sont basées sur le modèle flot de donnée et sur le paquetage des
données. Nous avons montré que l’unité Drum, de part son architecture, la structure physique de ses
composants reconfigurable et ses mécanismes de fonctionnement est particulièrement bien adaptée à
une approche “système” de la gestion de la reconfiguration dynamique et également au tamponnage
des données. Le statut du réseau et du couplage au réseau reste un problème ouvert.
La programmation pour des unités tels que DRUM peut se faire selon différents modèles. Les proces-
sus communiquant répondant au modèle CSP permettent une traduction presque immédiate vers le
matériel. Les calculs flots de données apportent des possibilités de reconditionnement permettant à la
fois de séparer les traitements en étape, en choisissant l’unité la mieux adaptée à une étape particulière.
Ils se prêtent également bien aux transformations proposées par les compilateurs.
Dans l’état actuel du projet, nous disposons d’une ébauche de simulateur permettant de représenter les
programmes sous forme de graphes de tâches échangeant par tampons sur un modèle de plateforme.
La construction matérielle d’une unité Drum n’est pas planifiée. Cependant une partie des concepts de
ce modèle se trouvent dans un composant en cours de réalisation.

Bibliographie
1. C. Rupp, M. Landguth, T. Garverick, E. Gommersall, H. Holt, J. Arnold and M. Gokhale. – The
NAPA Adaptive Processing Architecture. In : IEEE Symposium on FCCM. – Napa, avril 1998.
2. Callahan (T. J.), Hauser (J. R.) et Wawrzynek (J.). – The Garp architecture and C compiler. Computer,
vol. 33, n˚ 4, avril 2000.
3. Caspi (E.), Chu (M.), Huang (R.), Yeh (J.), Wawrzynek (J.) et Dehon (A.). – Stream computations or-
ganized for reconfiguration execution (score). In : 10th International Workshop on Field-Programmable
Logic and Applications, FPL’2000. – Villach, août 2000.
4. D. Demigny (M. Paindavoine) et Weber (S.). – Architecture à reconfiguration dynamique pour le
traitement temps réel des images. Technique et Science de l’information, vol. 18, n˚ 10, décembre 1999.
5. David (R.), Chillet (D.), Pillement (S.) et Sentieys (O.). – Dart : A dynamically reconfigurable architec-
ture dealing with future mobile telecommunication constraints. In : 9th Reconfigurable Architectures
Workshop (RAW 2002). – Fort Lauderdale, avril 2002.
6. Ebeling (C.), Cronquist (D. C.) et Franklin (P.). – RaPiD - Reconfigurable Pipelined Datapath. In :
6th International Workshop on Field-Programmable Logic and Applications. – Darmstadt, septembre 1996.
7. Fabiani (E.), Gouyen (C.) et Pottier (B.). – Intermediate level component for reconfigurable plat-
forms. In : Synthesis, Architectures and Modeling of Systems (SAMOS 3). – Samos, juillet 2003.
8. Goldstein (S. C.), Schmit (H.), Budiu (M.), Cadambi (S.), Moe (M.) et Taylor (R. R.). – Piperench : A
reconfigurable architecture and compiler. Computer, avril 2000.
9. Hauser (J.R.) et Wawrzynek (J.). – Garp : A MIPS processor with a Reconfigurable Coprocessor. In :
IEEE Symposium on Field-Programmable Custom Computing Machines. – Los Alamitos, 1997.
10. Kean (T.). – Xc6200 fastmap processor interface. In : 7th International Workshop on Field-Programmable
Logic and Applications, FPL’97. – Londres, septembre 1997.
11. Lagadec (L.), Pottier (B.) et Villellas-Guillen (O.). – An lut-based high level synthesis framework for
reconfigurable architectures. In : Domain-Specific Embedded Multiprocessors : Systems, Architectures,
Modeling, and Simulation, éd. par Bhattacharyya (S.), Deprettere (E.) et Teich (J.). – New-York, 2002.
12. Raimbault (F.), Lavenier (D.), Rubini (S.) et Pottier (B.). – Fine grain parallelism on an MIMD ma-
chine using FPGAs. In : IEEE FCCM’93. – Napa, 1993.
13. S. Hauck, T.W. Fry (M.M. Hosler) et Kao (J.P.). – The chimera reconfigurable functional unit. In :
IEEE Symposium on Field-Programmable Custom Computing Machines, FCCM’97. – Napa, 1997.
14. T. Miyamori (K. Olukotun). – A quantative analysis of reconfigurable coprocessors for multimedia
applications. In : IEEE Symposium on Field-Programmable Custom Computing Machines. – Napa, 1998.
15. Vuillemin (J.), Bertin (P.), Roncin (D.), Shand (M.), Touati (H.) et Boucard (P.). – Programmable active
memories : Reconfigurable systems come of age. IEEE Transactions on VLSI, vol. 4, n˚ 1, mars 1996.
16. Wazlowski (M.), Agarwal (L), Lee (T.), Smith (A.), Lam (E.), Athanas (P.), Sliverman (H.) et Ghosh
(S.). – Prism-ii compiler and architecture. In : IEEE Workshop on FPGAs for Custom Computing Ma-
chines. – Napa, 1993.

View publication stats