a Reconfiguration Dynamique - Le2i - CNRS

U.F.R. Sciences et Techniques, Mathématiques, Informatiques, AutomatiqueÉcole Doctorale Informatique Automatique Electronique Electrotechnique MathématiquesDépartement de formation Doctorale Électronique ÉlectrotechniqueExploration multicritèresd’architectures àReconfiguration DynamiqueTHÈSEprésentée et soutenue publiquement le 15 Décembre 2004pour l’obtention duDoctorat de l’université Henri Poincaré – Nancy 1(spécialité Instrumentation et Micro-Électronique)parPhilippe BRUNETComposition du juryRapporteurs : Professeur Elbey Bourennane Université de BourgogneProfesseur Eric MartinUniversité de Bretagne SudExaminateurs : Professeur Bernard Lepley Université de MetzProfesseur Serge WeberUniversité Henri Poincaré, Nancy-IMaître de conférence Yves Berviller Université Henri Poincaré, Nancy-ILaboratoire d’Instrumentation Électronique de NancyFaculté des Sciences - 54506 Vandoeuvre-lès-Nancy

RemerciementsJ’adresse mes remerciements à Monsieur Elbey Bourennane, Professeur à l’université de Bourgogneainsi qu’à Monsieur Eric Martin, Professeur à l’université de Bretagne Sud, qui m’ont faitl’honneur d’accepter de juger cette thèse en qualité de rapporteurs.Je remercie Monsieur Bernard Lepley, Professeur à l’université de Metz pour avoir accepté departiciper au jury.Je tiens à remercier Mr Mustapha Nadi pour m’avoir accueilli dans son laboratoire ainsi que MrSerge Weber, mon directeur de thèse, pour m’avoir accordé sa confiance et accueilli dans sonéquipe.Je remercie Mr. Yves Berviller pour son soutien, sa disponibilité ainsi que pour l’excellence desconseils qu’il a pu m’apporter durant l’encadrement de mes travaux.Je remercie également Mr. Camel Tanougast pour son aide et son sens du détail qui ont donnéelieu à tant de discussions constructives.Je remercie tous mes collègues et membres du LIEN pour l’aide ou les conseils qu’ils ont pum’apporter à un moment ou un autre. Que ce soit pour l’accomplissement de cette thèse, pourles enseignements que j’ai donné lors du mon monitorat ou tout simplement pour l’ambianceagréable qu’ils ont pu apporter lors de chaque journée de travail.Je tiens à remercier ma famille et mes amis pour leurs ”Et cette thèse ? ca avance ?” maiségalement pour leurs ”tu travail sur quoi exactement ?”.Enfin, je me permet de terminer ces remerciements par une attention particulière à Audrey pourson soutien permanent tout au long de cette période.Philippe BrunetOctobre 2004i

Je dédie cette thèse à mes parents :Maguy et Jacques.iii

Table des matièresRésumé 1Table des figures 3Chapitre 1 Introduction1.1 Introduction Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Restriction et limites du domaine d’étude . . . . . . . . . . . . . . . . . . . . . . 101.2.1 Architectures ciblées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2.2 Les applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3 Problématique du partitionnement en Reconfiguration Dynamique . . . . . . . . 111.4 Organisation du manuscrit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Chapitre 2 État de l’art2.1 Définition de la Reconfiguration Dynamique . . . . . . . . . . . . . . . . . . . . . 132.2 Les Architectures pour la Reconfiguration Dynamique . . . . . . . . . . . . . . . 152.2.1 Architectures étudiées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.2 Les systèmes reconfigurables à fonctionnement statique . . . . . . . . . . 172.2.2.1 Limitations des systèmes à reconfiguration statique . . . . . . . 172.2.3 Systèmes et micro-systèmes reconfigurables à fonctionnement dynamiqueà grain fin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.3.1 ARDOISE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.3.2 ATMEL 94K . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.2.3.3 OneChip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2.3.4 Limitations des systèmes à reconfiguration dynamique . . . . . . 262.2.4 Systèmes et micro-systèmes reconfigurables à fonctionnement dynamiqueà grain épais ou mixte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2.4.1 Virtex II Pro X . . . . . . . . . . . . . . . . . . . . . . . . . . . 28v

Table des matières2.2.4.2 KressArray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.2.4.3 Colt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.2.4.4 FIPSOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.2.4.5 Systolic Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.2.4.6 DART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.2.4.7 NAPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.2.4.8 RAMPASS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.2.4.9 X.P.P. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.2.5 Caractéristiques des systèmes reconfigurables dynamiquement . . . . . . . 442.2.5.1 Accélération des traitements . . . . . . . . . . . . . . . . . . . . 442.2.5.2 Tampon d’entrée . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.2.5.3 Réduction des durées de reconfiguration . . . . . . . . . . . . . . 452.2.5.4 Gestion dynamique de l’horloge . . . . . . . . . . . . . . . . . . 482.2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.3 Nécessité d’un partitionnement optimal . . . . . . . . . . . . . . . . . . . . . . . 522.3.1 Aspect ”Conception de circuits” . . . . . . . . . . . . . . . . . . . . . . . . 522.3.2 Aspect ”Développement d’applications” . . . . . . . . . . . . . . . . . . . 532.4 Méthode et outils de partitionnement pour la Reconfiguration Dynamique . . . . 542.4.1 Revue critique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542.4.1.1 Programmation des réseaux reconfigurables grain épais . . . . . 542.4.1.2 Mapping de type FPGAs . . . . . . . . . . . . . . . . . . . . . . 552.4.1.3 Autres approches . . . . . . . . . . . . . . . . . . . . . . . . . . 562.4.1.4 Mappage temps réel . . . . . . . . . . . . . . . . . . . . . . . . . 582.4.1.5 Exploration de l’espace de conception . . . . . . . . . . . . . . . 582.4.1.6 ÉPICURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592.4.1.7 JBits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612.4.1.8 MADEO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622.4.2 Analyse des outils et direction de recherche . . . . . . . . . . . . . . . . . 642.4.2.1 Un circuit - un outil . . . . . . . . . . . . . . . . . . . . . . . . . 642.4.2.2 Mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642.4.2.3 Lisibilité - Assistance . . . . . . . . . . . . . . . . . . . . . . . . 64Chapitre 3 Modélisation3.1 Axes de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.1.1 Besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.1.2 Représentation de l’application . . . . . . . . . . . . . . . . . . . . . . . . 67vi

3.1.3 Représentation de la technologie . . . . . . . . . . . . . . . . . . . . . . . 683.1.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683.2 Modélisation de L’architectures cible . . . . . . . . . . . . . . . . . . . . . . . . . 693.2.1 Justification de la cible FPGA . . . . . . . . . . . . . . . . . . . . . . . . 693.2.2 Modélisation et détermination des paramètres technologiques . . . . . . . 703.2.2.1 Evaluation de la vitesse de reconfiguration - Temps de reconfiguration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.2.2.2 Evaluation des ressources nécessaires pour les opérateurs . . . . 723.2.2.3 Estimation des performances des opérateurs . . . . . . . . . . . 743.2.2.4 Interconnexions - Taux moyen lié au routage K moy . . . . . . . . 793.2.3 Bibliothèque caractérisée . . . . . . . . . . . . . . . . . . . . . . . . . . . 793.3 Modélisation de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803.3.1 Opérateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803.3.2 Dépendances de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813.3.3 Evaluation des ressources nécessaires à une partie du chemin de données . 813.4 Contrôle des reconfigurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833.4.1 Type de contrôleur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 833.4.1.1 Contrôleur logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . 833.4.1.2 Contrôleur matériel . . . . . . . . . . . . . . . . . . . . . . . . . 843.4.1.3 Contrôleur mixte . . . . . . . . . . . . . . . . . . . . . . . . . . . 843.4.1.4 Complexité du contrôleur de reconfiguration . . . . . . . . . . . 843.4.2 Contrôle à ordonnancement fixe . . . . . . . . . . . . . . . . . . . . . . . . 853.4.3 Contrôle à ordonnancement conditionné et évolutif . . . . . . . . . . . . . 86Chapitre 4 Partitionnement sous contrainte de temps4.1 Rappels - Travaux précédents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894.1.1 Méthodologie première . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894.1.2 Cadre applicatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 894.1.2.1 Approche conception de circuits . . . . . . . . . . . . . . . . . . 894.1.2.2 Approche implantation d’application . . . . . . . . . . . . . . . 904.1.3 Mise en oeuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904.1.4 Apport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 904.2 Prise en compte de la bande passante dans le partitionnement . . . . . . . . . . . 924.3 Fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.3.1 Fonctionnement de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.3.2 Optimisation de la surface logique et/ou de la bande passante. . . . . . . 94vii

Table des matières4.3.3 Génération du contrôleur du partitionnement . . . . . . . . . . . . . . . . 954.4 Exemple I : Détecteur de contours . . . . . . . . . . . . . . . . . . . . . . . . . . 974.4.1 Présentation de l’algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . 974.4.2 Résultats donnée par DAGARD . . . . . . . . . . . . . . . . . . . . . . . 974.4.3 Résultats d’implantation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974.4.4 Bilan et discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 984.5 Exemple II : cryptage AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004.5.1 Présentation Générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004.5.2 L’algorithme AES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1004.5.3 Plate-forme reconfigurable ARDOISE . . . . . . . . . . . . . . . . . . . . 1034.5.4 Partitionnement temporel en reconfiguration dynamique . . . . . . . . . . 1034.5.4.1 Modélisation et détermination des paramètres technologiques . . 1034.5.4.2 Estimation des performances des opérateurs . . . . . . . . . . . 1034.5.4.3 Graphe flot de données de l’algorithme AES . . . . . . . . . . . 1034.5.4.4 Détermination du partitionnement . . . . . . . . . . . . . . . . . 1044.5.4.5 Résultats d’implantation du partitionnement . . . . . . . . . . . 1064.5.4.6 Implantation sur la plate-forme ARDOISE . . . . . . . . . . . . 1104.5.4.7 Analyse de l’implantation . . . . . . . . . . . . . . . . . . . . . . 1124.5.5 Implantation par Synthèse architecturale des Partitions 2, 3, 4 et 5 . . . . 1154.5.5.1 Résultats d’implantation . . . . . . . . . . . . . . . . . . . . . . 1154.5.6 Gestion et implantation des boucles de traitement. . . . . . . . . . . . . . 1184.5.6.1 Déroulement de la boucle . . . . . . . . . . . . . . . . . . . . . . 1184.5.6.2 Implantation de boucle par synthèse architecturale . . . . . . . . 1214.5.6.3 Implantation de l’algorithme AES avec optimisation de boucle . 1214.5.7 Bilan et discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1234.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Chapitre 5 Exploration multicritères5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1275.2 Critère d’optimalité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1275.2.1 De nouvelles contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1275.2.2 De nouveaux outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1285.2.3 Un compromis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1285.2.4 Critères retenus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1295.2.5 Surface Logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1295.2.5.1 Bande Passante . . . . . . . . . . . . . . . . . . . . . . . . . . . 130viii

5.2.5.2 Temps d’exécution . . . . . . . . . . . . . . . . . . . . . . . . . . 1305.2.5.3 Activité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1305.3 Exploration de l’espace de partitionnement . . . . . . . . . . . . . . . . . . . . . 1325.3.1 Définition du graphe flot de données . . . . . . . . . . . . . . . . . . . . . 1345.3.1.1 Caractérisation des opérateurs . . . . . . . . . . . . . . . . . . . 1345.3.1.2 Caractérisation des branches . . . . . . . . . . . . . . . . . . . . 1345.3.2 Exploration des possibilités de partitionnement. . . . . . . . . . . . . . . . 1355.3.2.1 Énumération des possibilités architecturales . . . . . . . . . . . . 1355.3.2.2 Exploration des possibilités architecturales . . . . . . . . . . . . 1355.3.2.3 Classification des partitionnements . . . . . . . . . . . . . . . . . 1375.3.3 Exemple théorique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1385.4 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1395.5 DagARD 2 : structures utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Chapitre 6 Conclusion6.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1456.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Annexe A Autres Architectures 149A.1 Les systèmes reconfigurables à fonctionnement statique . . . . . . . . . . . . . . . 149A.1.1 EVC1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149A.1.2 HOT II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149A.1.3 PCI - PAMETTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151A.1.4 SPACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151A.2 Systèmes et micro-systèmes reconfigurables à fonctionnement dynamique à grainfin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152A.2.1 MOD ARD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152A.2.2 Triscend E5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154A.2.3 DISC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156A.2.4 Garp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157A.2.5 DPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157A.3 Systèmes et micro-systèmes reconfigurables à fonctionnement dynamique à grainépais ou mixte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158A.3.1 DP-FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158A.3.2 MATRIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159ix

Table des matièresA.3.3 RAW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160A.3.4 REMARC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161A.3.5 CHESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163A.3.6 DReAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163A.3.7 CS2000 Chameleon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164A.3.8 RaPiD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165A.3.9 PipeRench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165A.3.10 CHIMAERA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167Annexe B Contrôleur Verilog, Algorithme AES 171Bibliographie 173x

Résumé1

RésuméJours après jours, les nouveaux circuits reconfigurables dynamiquement apportent plus desouplesse et de possibilités quant à la mise en oeuvre d’algorithmes divers et variés. Si lesprogrès sont significatifs en ce qui concerne le matériel, leur mise en oeuvre de manière efficacesuscite bien des interrogations tant la souplesse qu’ils apportent donne aux développeurs unvaste champ de solutions répondant à leurs besoins. Ainsi, bien que les circuits reconfigurabledisponibles aujourd’hui soient issus des plus grandes entreprises du domaine, celles-ci semblentne pas avoir inclu les méthodes et outils nécessaires à la bonne gestion de leurs composants.Le but de ce travail est de fournir un outil permettant une exploration globale des possibilitésoffertes par la reconfiguration dynamique lors de l’implantation d’un algorithme.Nous proposons un outil permettant de guider le développeur de circuits en lui donnant lesperformances de l’implémentation de son application suivant différents scénari proposés.L’aboutissement est alors de permettre une mise en oeuvre plus rapide, plus simple et moinscontraignante de la reconfiguration dynamique qui aujourd’hui encore peut paraître complexeaux nouveaux venus dans le monde du reconfigurable.Abstract :Days after days, new dynamically reconfigurable circuits provides more flexibility and possibilitiesto implement various algorithms. If progress is significant with respect to the hardware,an efficient implementation is hard to define according to this new flexibility. It provides to thedevelopers a vast field of solutions meeting their needs. Today, available reconfigurable circuitsfrom the main FPGA companies do not have efficient methods and tools necessary for a goodmanagement of these components.The goal of this work is to provide tools allowing a complete exploration of the possibilitiesoffered by dynamic reconfiguration for the implementation of an algorithm. We can thusgive to the developers an overview of the performances that one or another kind of splittingits application will achieve. The result is then to allow a faster, simpler and less constrainingimplementation using the dynamic reconfiguration which still appear complex to a beginner inthe world of reconfigurable computing.2

Table des figures2.1 Architecture ARDOISE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2 Kit complet ARDOISE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3 Flux de données sur ARDOISE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.4 Architecture simplifiée d’un AT94K. [Atm99c] . . . . . . . . . . . . . . . . . . . . 242.5 Illustration conceptuelle du système Onechip [Wit95] . . . . . . . . . . . . . . . . 252.6 Illustration conceptuelle étendue du système Onechip [Jac98] . . . . . . . . . . . 262.7 Virtex2 CLB [Xil04c] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.8 Virtex2 : demi slice [Xil04c] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.9 Vue d’ensemble du Virtex II Pro X[Xil04b] . . . . . . . . . . . . . . . . . . . . . 302.10 Intégration du coeur de processeur IBM®PowerPC—405[Xil04b] . . . . . . . . . 312.11 La rDPA[HK95] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.12 DNode du Systolic Ring [PIL03] . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.13 Architecture du Systolic Ring [PIL03] . . . . . . . . . . . . . . . . . . . . . . . . 342.14 Architecture DART [PIL03] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.15 DART : structure du DPR [PIL03] . . . . . . . . . . . . . . . . . . . . . . . . . . 362.16 NAPA ”ToggleBus” [RLG + 98] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.17 Structure du processeur NAPA [RLG + 98] . . . . . . . . . . . . . . . . . . . . . . 372.18 Synoptic de RAMPASS [CVBC03] . . . . . . . . . . . . . . . . . . . . . . . . . . 382.19 le bloc RAC [CVBC03] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.20 Matrice XPP[BV03] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.21 élément ALU du XPP[BV03] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.22 Gestion des reconfiguration de la matrice XPP[BV03] . . . . . . . . . . . . . . . 432.23 Fonctionnement d’un tampon d’entrée . . . . . . . . . . . . . . . . . . . . . . . . 452.24 Principe du masquage par un fonctionnement ping-pong . . . . . . . . . . . . . . 472.25 Principales plates-formes d’application du calcul reconfigurable . . . . . . . . . . 492.26 Vue globale de la méthodologie ÉPICURE . . . . . . . . . . . . . . . . . . . . . . 603.1 Illustration de la structure d’une cellule logique de la technologie ATMEL l’AT40K 733

Table des figures3.2 Les différents modes de configuration d’une cellule logique AT40K . . . . . . . . 743.3 Cellule Virtex. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753.4 Illustration de la durée de traitement d’un opérateur cascadé avec propagation deretenue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763.5 Illustration de la durée de traitement d’un opérateur cascadé synchronisé . . . . 773.6 Illustration de la durée d’un opérateur non cascadé et non synchronisé . . . . . . 773.7 Contrôleur de configurations à ordonnancement fixe. . . . . . . . . . . . . . . . . 854.1 Insertion de DAGARD dans le flot de conception. . . . . . . . . . . . . . . . . . . 934.2 Principe d’obtention du nombre de partitions. . . . . . . . . . . . . . . . . . . . . 944.3 Principe de création des partitions. . . . . . . . . . . . . . . . . . . . . . . . . . . 944.4 Principe du raffinement du partitionnement. . . . . . . . . . . . . . . . . . . . . . 954.5 Illustration de la taille du chemin de données dans DAGARD. . . . . . . . . . . . 964.6 Machine d’état du contrôleur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964.7 Schéma de principe de l’algorithme AES . . . . . . . . . . . . . . . . . . . . . . . 1024.8 Schéma général du chemin de données de l’algorithme AES. . . . . . . . . . . . . 1024.9 Légende du Graphe flot de données de l’algorithme AES . . . . . . . . . . . . . . 1044.10 Graphe flot de données de l’algorithme AES . . . . . . . . . . . . . . . . . . . . . 1054.11 Partitionnement automatique de l’algorithme AES obtenu avec DAGARD . . . . 1074.12 Graphe flot de données détaillé de la macro de cryptage des textes . . . . . . . . 1084.13 Partitionnement raffiné de l’algorithme AES . . . . . . . . . . . . . . . . . . . . . 1094.14 Vue de la première partition sur AT40K. . . . . . . . . . . . . . . . . . . . . . . . 1114.15 Graphe flot de données de la première partition. . . . . . . . . . . . . . . . . . . 1124.16 Graphe flot de données des partitions 2, 3, 4 et 5. . . . . . . . . . . . . . . . . . . 1134.17 Graphe flot de données de la partition 1 en vue d’une implantation sur ARDOISE.1144.18 Schéma de principe du contrôleur de données de la 1ère partition de l’algorithmeAES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1144.19 Schéma de l’étape 2 avec le contrôleur pour lire et enregistrer les données. . . . . 1164.20 Partition obtenue par synthèse architecturale. . . . . . . . . . . . . . . . . . . . . 1174.21 Cryptage de la clé. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1184.22 Structure de la première partition. . . . . . . . . . . . . . . . . . . . . . . . . . . 1194.23 Schéma de la boucle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1194.24 (a) découpe la boucle couche par couche. (b) cascade des boucles. . . . . . . . . . 1204.25 Illustration de la méthode de déroulement de boucle. . . . . . . . . . . . . . . . . 1214.26 Comparaison des deux algorithmes. . . . . . . . . . . . . . . . . . . . . . . . . . . 1224.27 Graphe flot de données de la partition 1 avec multiplexeur-démultiplexeur en vued’une implantation sur ARDOISE. . . . . . . . . . . . . . . . . . . . . . . . . . . 1224

5.1 vue générale du graphe flot de données sous DAGARD. . . . . . . . . . . . . . . 1315.2 Vue Générale d’un SoC configurable dynamiquement. . . . . . . . . . . . . . . . 1325.3 Intégration de DAGARD dans le flot de conception. . . . . . . . . . . . . . . . . 1335.4 Vue graphique des possibilités de partitionnement. . . . . . . . . . . . . . . . . . 1365.5 Seconde vue graphique des possibilités de partitionnement. . . . . . . . . . . . . 1375.6 Graphe flot de données théorique pris comme exemple. . . . . . . . . . . . . . . . 1395.7 Flot de traitement du GFD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142A.1 Architecture du calculateur reconfigurable EVC1 . . . . . . . . . . . . . . . . . . 150A.2 Architecture du système HOT II . . . . . . . . . . . . . . . . . . . . . . . . . . . 150A.3 PCI Pamette [Sha99b] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152A.4 Système SPACE2 [Gun97] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153A.5 Architecture MOD ARD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154A.6 Architecture simplifiée du E5 [Tri98] . . . . . . . . . . . . . . . . . . . . . . . . . 155A.7 Le système DISC [WH96] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156A.8 Schéma bloc de Garp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158A.9 Vue d’ensemble de l’architecture de DP-FPGA[Ye04] . . . . . . . . . . . . . . . . 159A.10 Vue d’ensemble d’un bloc de chemin de données[Ye04] . . . . . . . . . . . . . . . 159A.11 Matrix BFU[MD96] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160A.12 Architecture de RAW[WTS + 97] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161A.13 Structure systolic à six processeurs[WTS + 97] . . . . . . . . . . . . . . . . . . . . 161A.14 Architecture Remarc[MO98] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162A.15 Coprocesseur Remarc[MO98] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162A.16 Nanoprocesseur Remarc[MO98] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163A.17 Principe de l’architecture CHESS[MSK + 99] . . . . . . . . . . . . . . . . . . . . . 164A.18 Matrice DReAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165A.19 le RPU de DReAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166A.20 le RAP de DReAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167A.21 Architecture Chameleon [Eur] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167A.22 Cellule de l’architecture RaPiD [ECF + 97] . . . . . . . . . . . . . . . . . . . . . . 168A.23 Architecture du circuit Chimaera [HFHK97] . . . . . . . . . . . . . . . . . . . . . 169A.24 Logic Block du RA Chimaera [HFHK97] . . . . . . . . . . . . . . . . . . . . . . . 1695

Table des figures6

Chapitre 1Introduction1.1 Introduction GénéraleL’effervescence dans le domaine des systèmes embarqués, systèmes sur puces et toutes lesapplications multimédia pour matériel de poche (PDA, téléphones portables, baladeurs MP3etc.) a relancé la quête de solutions architecturales alternatives en opposition avec les méthodesclassiques d’intégration. Si dans bien des cas la solution du processeur à usage général, voir duDSP, répond aux besoins les plus basiques, la miniaturisation à outrance des systèmes ajoutéeaux besoins d’évolutivité et d’intégration technologique toujours plus importants des nouveauxoutils de communication conduit à vouloir dépasser les limites des systèmes classiques. En effet,concentrer un codeur-décodeur GSM, un décodeur MP3, un contrôle d’affichage d’écrancouleur 16 bits, une machine JAVA, une communication bluetooth, des jeux et bien d’autreschoses encore dans un téléphone est possible grâce à une production massive permettant les recoursà la fabrication d’ASICs. Si les ASICs apportent ici la solution à une intégration toujoursmaximale par rapport au progrès technologique du moment, c’est au détriment des coûts fixeset de la consommation statique qui ne font qu’augmenter en fonction de la surface du circuitmais également avec la finesse de gravure. Ainsi, même les ASICs atteignent ici une nouvellelimite : la consommation statique au mm 2 . Ajoutons leur un très faible degré de flexibilité ainsique des temps et des coûts de développement élevés et la solution ne devient viable que pourun nombre restreint d’utilisations. Le recours aux FPGAs est alors envisagé car ils disposentd’une grande flexibilité et des performances intermédiaires entre les DSPs et les ASICs, avec untemps de mise en oeuvre également réduit par rapport à ces derniers. Le FPGA dispose donc dequalités intermédiaires à celles des DSPs et des ASICs. Second inconvénient majeur, la surfacelogique nécessaire à la réalisation d’une application sur FPGA est approximativement dix foiscelle nécessaire à la réalisation de la même application sur un ASIC en technologie ”STANDARDCELL” et cent fois celle nécessaire en technologie ”FULL CUSTOM” [BHHN98, Deh98, Cat02].7

Chapitre 1. IntroductionC’est dans ce contexte que la reconfiguration dynamique des circuits FPGA apporte denouvelles possibilités.Depuis plusieurs années, la reconfiguration dynamique de circuits de type FPGA est envisagéecomme un nouveau paradigme pour la réalisation de machines de traitement numériquede l’information. Bien que le concept soit déjà relativement ancien [EV62], la démocratisationde circuits FPGA de forte densité d’intégration et à mémoire de configuration volatile conduità un regain d’intérêt pour cette approche. L’objectif principal est de pouvoir profiter des performancesque procure le câblage des opérateurs tout en conservant la flexibilité des traitementsque permet une machine programmée [CH02]. Les premières utilisations étaient surtout orientéesvers l’accélération de certains traitements qui se prêtaient bien à la parallélisation spatiale. Celaa conduit à une multitudes d’architectures de coprocesseurs plus ou moins étroitement couplésà un processeur traditionnel [BRM + 99, BAK96, BDH + 97, CHW00, Deh96a, GS98, SSB + 00,JTY + 99, KHN97, MSK + 99, RS02, VBR + 96, WH98, Wit95, ZN00]. Des méthodologies de partitionnementont également été proposées [CMS98, CA97, LW99, PB99].Dès les débuts de la reconfiguration dynamique, le L.I.E.N (Laboratoire d’InstrumentationÉlectronique de Nancy) s’est impliqué dans cette technologie prometteuse. Les premiers travauxont montré d’une part que nous sommes tributaire de la technologie disponible et d’autrepart qu’il n’existait peu ou pas d’outils dédiés à l’exploitation de la reconfiguration dynamique.Une méthodologie mettant en oeuvre cette dernière faisait donc défaut, malgré plusieurs étudestraitant des problèmes de gestion de la reconfiguration dynamique. Or, cette problématique apparaissaitcomme une nécessité dans le but de gérer et d’automatiser le calcul reconfigurable. C’estce qui nous a poussé à réfléchir à l’élaboration de méthodes d’implantation en reconfigurationdynamique. Pour cela, plusieurs interrogations devaient être considérées. Combien de partitions ?Comment choisir les partitions pour réaliser la décomposition en reconfiguration dynamique desalgorithmes à implanter ? Il s’agissait donc de déterminer une méthodologie de partitionnementen reconfiguration dynamique d’une application. Ces questions ont été le sujet de thèse traité parMr. Camel Tanougast [Tan01]. Cette thèse à permis de développer une première méthodologiede partitionnement restreinte à certaines conditions particulières ( application sous contraintede temps, permettant une minimisation de la surface logique nécessaire à l’implantation d’algorithmeen reconfiguration dynamique, applicable à une application décrite sous forme de grapheflot de données). Néanmoins, le partitionnement induit un certain nombre de modifications dansles caractéristiques de l’algorithme à implanter. C’est dans le but de prendre en compte toutesces modifications, avant même l’implantation, ainsi que d’automatiser cette tâche, que ce travailde thèse à été réalisé.Nous disposons donc d’une quantification de l’apport de la reconfiguration dynamique surla réduction de surface que l’on peut atteindre avec une application et une technologie donnée.Nous nous devons d’ajouter une prise en compte plus globale des contraintes apportées par8

1.1. Introduction Généralela reconfiguration dynamique et étendre les possibilités de sorte à intégrer des graphes flot dedonnées non-réguliers etc...9

Chapitre 1. Introduction1.2 Restriction et limites du domaine d’étude1.2.1 Architectures cibléesComme nous allons le voir dans le chapitre 2, les circuits et systèmes dédiés ou simplementcapables de reconfiguration dynamique commencent à être nombreux. Ils apportent tous leursoriginalités, leur conception de la reconfiguration, leur domaine de prédilection pour lequel ils ontété conçus. Nous ne pouvons évidement pas prétendre apporter une méthode de partitionnementuniverselle, s’adaptant à toutes ces architectures si différentes. C’est pourquoi nous nous attachonsà définir une méthodologie valable pour la plus grande partie des systèmes reconfigurablesaujourd’hui disponibles : les FPGAs commerciaux. De par leur régularité et leur souplesse, ilssont d’ailleurs les meilleurs candidats à l’étude des possibilités offertes par la reconfiguration dynamique.D’autres composants (commerciaux ou non) possèdent également ces caractéristiquesde régularité. Le manque de disponibilité de ces composants ne nous permet pas de mener notreétude avec ceux-ci. Néanmoins, ils sont potentiellement utilisables par notre méthode dès lorsque nous pouvons caractériser en temps et en surface n’importe quel opérateur nécessaire à uneimplantation.1.2.2 Les applicationsCompte tenu du type de circuit que nous avons retenu, toutes les applications ne sont plus debonnes candidates pour notre étude. En effet, bien que les délais de reconfiguration des FPGAssoient de plus en plus courts, ils continuent à faire partie intégrante des préoccupations premièrelors de l’utilisation de la reconfiguration dynamique dès lors que la contrainte de temps devientun peu plus sévère. En conséquence, il est bien connu que les applications les plus adéquate àêtre traitées en reconfiguration dynamique sur FPGA sont celles qui s’appliquent à des blocs dedonnées de taille conséquente [DPW98a], de sorte à minimiser les temps de reconfiguration faceau temps de traitement. De plus les applications de type flot de données offrent une plus grandefacilité de partitionnement que celles qui comportent une quantité importante de contrôle. Ainsi,notre domaine applicatif est celui du traitement d’image. La taille des images, la régularitédes traitements, les traitements de type flot de données en font le domaine le plus adapté àla reconfiguration dynamique sur FPGA. Malheureusement (ou heureusement), l’électroniquemoderne ne se compose pas que de traitement d’image. C’est pourquoi nous avons cherchéà voir l’intérêt de notre travail lorsque celui sort légèrement de sont domaine de référence ets’attaque au traitement de signal de type crytpographie (4.5).10

1.3. Problématique du partitionnement en Reconfiguration Dynamique1.3 Problématique du partitionnement en Reconfiguration DynamiqueD’après les restrictions et limites du domaine d’étude présentées précédemment, nous cherchonsdonc à partitionner une application unique dans deux cas précis :1. optimiser son implantation sur une plateforme existante.2. optimiser les ressources nécessaires à la réalisation d’une architecture pour son exécution.Dans le premier cas, la plateforme existe et ses ressources sont fixées. L’application devradonc être capable de se contenter de ces ressources existantes, et tenter d’en tirer le meilleurparti. Dans le second cas, les ressources seront ”taillées” aux besoins de l’application. Néanmoins,dans un soucis de réduction de coûts, d’espace, de consommation électrique, une optimisationest nécessaire et le partitionnement a un grand potentiel pour répondre à ce problème.Dans ces deux cas, la tâche consiste alors à faire le bilan des ressources nécessaires à l’applicationet à évaluer les différentes contraintes induites par différents partitionnements. Seul lespartitionnements qui prennent moins de ressources que la plateforme cible pourront être priseen compte dans le premier cas.Les contraintes et ressources qui font l’objet de toute notre attention sont :– Surface logique nécessaire à l’implantation de l’application.– Besoins maximum en bande passante mémoire entre le FPGA et la mémoire de stockagedes données intermédiaire.– Temps de calcul des blocs de données.– Consommation électrique de l’architecture pour cette implantation.Ainsi, nous avons pour but d’optimiser ces quatre principaux paramètres. Comme nous pouvonsle constater, certains de ces paramètres peuvent agir les uns contre les autres. En effet, le tempsde traitement, lié à la fréquence de travail du circuit, va modifier directement la puissanceélectrique de celui-ci, ainsi que la bande passante mémoire nécessaire au système. De même,la dynamicité de l’application (fréquence de reconfiguration) va influencer fortement à la foisle temps de calcul et la surface logique nécessaire à la réalisation de l’application. Évoluant defaçon parfois contradictoire, ces paramètres montrent ainsi que l’optimisation absolue n’existepas. Nous avons donc à réaliser un compromis de tout nos besoins et contraintes afin d’obtenirl’implantation qui nous semble la plus ”intelligente”. Nous nous attacherons donc par la suite àla simplification et à l’aide à la recherche de cette implantation intelligente.11

Chapitre 1. Introduction1.4 Organisation du manuscritCette thèse est structurée de la manière suivante. Le chapitre 2 constitue un bref état de l’artde la reconfiguration dynamique. Ce chapitre débutera par une définition de la reconfigurationdynamique. Nous passerons ensuite en revue les diverses architectures dédiées à la reconfigurationdynamique sur FPGA. Nous expliquerons la nécessite du partitionnement optimal et ce quecela sous entend. Nous terminerons ce chapitre par une présentation des méthodes et outils departitionnement pour la reconfiguration dynamique existant et présenterons ici les améliorationsque nous apportons.Le chapitre 3 présente la modélisation que nous faisons de l’application à implanter. Commentcelle-ci est décrite en graphe flot de données. Nous présenterons également la modélisation del’architecture cible et comment la caractérisation de celle-ci est faite. Enfin, nous parlerons ducontrôleur de reconfigurations.Le chapitre 4 situe l’approche adoptée pour le partitionnement de graphe flot de donnéesréguliers répondant à une contrainte de temps d’exécution de l’application. Ceci est en continuitédirecte avec le travail de Camel Tanougast [Tan01]. Ce chapitre débutera donc par un rappelsur les travaux précédents. Nous présenterons ensuite la prise en compte de la bande passantedans le partitionnement que nous avons ajouté à cette méthode. Suivra alors la présentation del’outil développé de sorte à automatiser cette méthode de partitionnement : DagARD. Enfin,une partie ”exemples de réalisations” clôturera ce chapitre.Le chapitre 5 présente la méthode d’exploration multi-critères. Cette méthode adresse lesapplications du type graphe flot de données non-régulier. On y trouve dans un premier tempsune définition de l’”optimalité” d’une application et sont implantation en fonction de besoinsspécifique. Nous présenterons ensuite l’exploration de l’espace de partitionnement en détail, puisson intégration à DagARD. Enfin, un exemple théorique d’application clôturera également cechapitre.Le chapitre 6 tiendra lieu de conclusion finale. Nous discuterons et dresserons le bilan de nosétudes. Les perspectives de ce travail ainsi que les améliorations à apporter seront abordées enfin de chapitre.12

Chapitre 2État de l’art2.1 Définition de la Reconfiguration DynamiqueLa Reconfiguration Dynamique est un sujet porteur depuis quelques années dans le mondede l’électronique et du calcul reconfigurable. Néanmoins, tous les acteurs de ce domaine n’ontpas la même définition ou la même vision de ce qu’est la Reconfiguration Dynamique.D’après le Dictionnaire Universel Francophone ©[DIC]les termes Configuration et Dynamique sont définis ainsi :Configuration (nom féminin) :1. Surface extérieur d’un corps, qui le limite et lui donne la forme qui lui est propre. Configurationd’un terrain.2. CHIMIE : Arrangement des atomes d’une molécule qui ne peut être modifié par librerotation.3. INFORMATIQUE : Ensemble des éléments (matériel et logiciel) dont est constitué unsystème. Procéder à la configuration d’une machine.Dynamique (adjectif et nom féminin) :– adjectif :1. Relatif aux forces, et aux mouvements qu’elles engendrent.courant électrique (par opposition à électricité statique).Électricité dynamique :2. Figuré. Qui manifeste une force, une puissance engendrant un mouvement. Art dynamique.3. Figuré. Qui manifeste de l’énergie, de l’entrain, de la vitalité.Un chef d’équipe dynamique.13

Chapitre 2.État de l’artAvec de telles définitions, définir la Reconfiguration Dynamique n’est pas une chose aisée.La communauté semble plutôt d’accord sur le terme ”Reconfiguration”. La reconfigurationdésignant le fait qu’une architecture matérielle quelconque soit capable de changer de forme /fonction lors de divers traitements, ceci dès lors que ce changement ne se fait pas uniquementlors de la mise sous tension (configuration simple). Ainsi, le FPGA moderne est reconfigurable etpeut changer de configuration à n’importe quel moment. Plus encore, il arrive que le processeursoit considéré comme reconfigurable puisque d’un cycle à l’autre il peut exécuter différentesopérations. Ce cas est plutôt discutable étant donnée la définition énoncée précédemment : l’architecture de traitement ne change pas de forme à proprement parler contrairement à unereconfiguration de FPGA même si elle change bien de fonction.Les choses se compliquent lorsqu’il s’agit de s’accorder sur la signification de ”Dynamique”.Cette fois-ci, le processeur apparaît effectivement très dynamique puisque chaque cycle apporteune nouvelle action. Néanmoins, c’est bien l’exécution qui est ici très dynamique et nonla reconfiguration.Le cas du FPGA ainsi que des architectures reconfigurable diverses n’est pas vraiment simpleà trancher. Au delà même du support architectural, la qualification de dynamique provient plusde l’application qui donne au traitement un caractère plus ou moins dynamique. ”Plus ou moinsdynamique”. Toute la difficulté de comparaison se trouve dans cette phrase. De l’application quinécessite une reconfiguration à chaque donnée à celle qui se contente de reconfiguer en fin detraitement, comme pour exécuter une autre tâche, toutes ces applications prétendent à l’appellationdynamique. Il n’est pas vraiment utile de tergiverser sur le bien fondé de cette appellationdans tel ou tel cas. C’est pourquoi il sera considéré par la suite que :Toute architecture permettant une modification de sa structure de traitement desdonnées à tout moment est une architecture reconfigurable dynamiquement. Ceciquel que soit le degré d’utilisation de cette propriété et quel que soit le temps dereconfiguration.14

2.2. Les Architectures pour la Reconfiguration Dynamique2.2 Les Architectures pour la Reconfiguration DynamiqueLes architectures reconfigurables à base de FPGA ou autres ressources reconfigurables sontutilisées pour accélérer l’exécution d’algorithmes demandant un puissance de calcul importante.Elles sont soit couplées à un processeur pilotant les reconfigurations à plus haut niveau et exécutantd’autres tâches moins intensives, soit autonomes. Dans ce cas, un contrôleur a pour tâche degérer le fonctionnement de l’application ainsi que les reconfigurations du système. Le contrôleurpeut d’ailleurs parfois faire partie intégrante du FPGA implanté de façon statique alors que lereste de ce même FPGA est utilisé en reconfiguration dynamique partielle. Le couplage est uncritère très employé pour la classification des architectures reconfigurables. Dans certains cas,le FPGA tiens rôle de coprocesseur adaptable à volonté et est étroitement lié au processeurprincipal. A l’extrême, ces deux entités peuvent se trouver dans la même puce (Xilinx VirtexPRO). Plus loin de ce couplage extrême, la logique reconfigurable fait parfois partie d’un ensembled’unités de calcul hétérogènes partageant un même bus ou se trouvant au sein d’un réseaud’interconnexion commun. D’autres architectures ont pris le parti d’utiliser une surface logiquereconfigurable répartie dans différents cluster ou chemins de données auxquelles le contrôleurde l’architecture fera appel comme des unités de traitements spécifiques. Dans toutes les architecturesque nous allons présenter par la suite, le grain de l’architecture (c’est à dire la tailleminimale des données traitées par les opérateurs/cellules de l’architecture) est aussi un facteurimportant, et certainement un des meilleurs critères de classification. Nous allons dans ce chapitrecommencer par nous attacher aux architectures reconfigurables de façon statique. Celle-cidéjà plus anciennes ont posées un certain nombre de concepts que les architectures actuellesont assimilées et dépassées. Nous nous intéresserons ensuite aux architectures reconfigurablesdynamiquement. Cette présentation sera partagée en deux groupes d’architectures : un premiergroupe constitué d’architectures disposant d’un grain de traitement fin, un second grouped’architectures disposant d’un grain de traitement plus épais ou mixte. Nous tenterons ensuited’extraire les caractéristiques générales de ces architectures reconfigurables dynamiquement etnous présenterons un bilan général de cet état de l’art.2.2.1 Architectures étudiéesLe tableau 2.1 illustre l’ensemble des architectures qui ont fait l’objet d’une étude bibliographique.C’est une présentation rapide de ces architectures où sont données les points clés etspécificités de celles-ci. Néanmoins, dans le but d’alléger la lecture de ce manuscrit, seules lesarchitectures dont le nom apparaît en GRAS seront immédiatement présentées. Les autres sontaccessibles en Annexe A. Cette sélection à été réalisée de manière à conserver les architecturesles plus récentes, en adéquation avec nos travaux, ou présentant une spécificité plus forte que lesautres.15

Chapitre 2.État de l’artTab. 2.1 – Vue générale des architectures étudiéesNom Comm. Dyn. Grain µproc. SpécificitéEVC1 [TSC94] © ✗ fin ✗ Accélérateur SUNHOT II [Tan01] © ✗ fin ✗ Plateforme PCIPAMETTE [Sha99b] ✗ ✗ fin ✗ Accélérateur Plateforme PCISPACE [Gun97] ✗ ✗ fin ✗ Accélérateur station Alpha XC6216MOD ARD ✗ ̌ fin ✗ Plateforme LIEN, Masquage[Gue97]des temps de reconfigurationARDOISE ✗ ̌ fin ̌ Plateforme AT40K[Bou00]commune (TI,TS)TriscendE5 [Tri98] © ✗ fin ̌ 1 er SoC configurable commercialAT94K [Atm99c] © ̌ fin ̌ 1 er SoC reconfigurable commercialDISC [WH95] ✗ ultra fin lui-même Flux linéaire, sur Clay, TI RT.DPGA [Deh96b] ✗ ultra fin ✗ Multicontexte(4 avec cache)GARP [HW97] ✗ ̌ fin ̌ Unité reconfigurable sur puceONECHIP [Jac98] ✗ ultra fin ̌ configuration = instructionVirtex II [Xil04b] © ̌ Mixte ̌ Système-FPGA hétérogène, leaderDP-FPGA [Ye04] ✗ ̌ 1-4 ✗ chemin de donnée reconfigurablesKressArray [HK95] ✗ ̌ épais ✗ maillage de rDPU sans routageColt [HWA93] ✗ rtr 1-16 ✗ Config. dans l’entête du flotMATRIX ✗ ̌ multi embarqué Matrice reconfigurable[MD96]d’ALUs et MémoiresRAW [WTS + 97] ✗ ̌ réseau, 8 réseau Réseau configurable de MIPSREMARC [MO98] ✗ ̌ 16 MIPS II Matrice de nanoprocesseursCHESS ✗ offline 4 ✗ Matrice de switch[MSK + 99] HP rapide Multi et ALUs intercallésDReAM [BPG00] © ̌ 8,16 ✗ Mat. de RPU pour la communicationChameleon [Eur] © ̌ épais RISC32 Processeur de communicationFIPSOC © ̌ épais 8051 RA(multicontextes) et RAA[SID](Analogique RA)RaPiD ✗ 16 ✗ 15 pipelines 1-D reconfigurables[ECF + 97]Générateur automatique d’adresses.PipeRench ✗ ̌ 128 ✗ pipelines reconfigurables[SSB + 00] (1 pipeline en 1 cycle )Systolic Ring ✗ ̌ épais ✗ Structure circulaire(DNode)[STB + 02] 16 et matricielle (couches)DART [DCPS02] ✗ ̌ épais ✗ Communication 3G, 6 DPRNAPA ✗ ̌ épais Risc32 fort couplage[RLG + 98]RA-processeurCHIMAERA [HFHK97] ✗ ̌ fin R4000 opcode = configurationRAMPASS ✗ ̌ Partagé ✗ Contrôle ET partie[CVBC03] op./Ctrl opérative reconfigurableXPP © ̌ épais ✗ RD, calcul parallèle,[BV03]Network on Chip16

2.2. Les Architectures pour la Reconfiguration Dynamique2.2.2 Les systèmes reconfigurables à fonctionnement statiqueLes architectures ci-dessous décrivent les systèmes reconfigurables statiques. Ces cartes accélératricespossèdent un faible couplage avec le système hôte de contrôle. De génération plusancienne, elles ont posées les bases de la reconfiguration dynamique actuelle. Elles présententtout de même pour la plupart d’entre elles, un potentiel pour la reconfiguration dynamique maisqui s’avère bridé pour différentes raisons et les maintient dans une classe de fonctionnementplutôt statique. Nous les évoquons principalement pour des raisons historiques.Ces architectures sont par exemple :EVC1 (voir Annexe A.1.1 page 149)HOT II (voir Annexe A.1.2 page 149)PCI - PAMETTE (voir Annexe A.1.3 page 151)SPACE (voir Annexe A.1.4 page 151)2.2.2.1 Limitations des systèmes à reconfiguration statiqueParmi les accélérateurs présentés précédemment, certains possèdent des possibilités de fonctionnementdynamique. En effet, le mode de fonctionnement dynamique à l’aide de FPGA esttout à fait possible avec de tels systèmes ou architectures. Cependant l’application de ce modede fonctionnement n’est pas viable pour exécuter certains types de traitement en temps réel.Ceci est dû au fait que ces systèmes présentent plusieurs inconvénients de nature technologiqueou architecturale en plus de leur faible degré de couplage entre le module reconfigurable et leprocesseur.Si nous prenons le cas de EVC1, nous constatons que cette carte n’est pas destinée autraitement intensif en temps réel avec reconfiguration dynamique pour deux raisons. D’abord leFPGA utilisé est d’une taille plutôt réduite, et ce d’autant plus que la logique de contrôle duSBUS doit être implantée dans le FPGA lui-même si l’on veut faire communiquer la station etle co-processeur. Ensuite, et c’est la principale raison, le délai de reconfiguration minimum, qui,selon la taille du FPGA, va de 14,25 ms à 26,35 ms (mode série à 12,5 MHz), n’est pas négligeablesi l’on veut exploiter la reconfiguration dynamique. Avec la technologie employée (XC4000), nousaurions pu espérer pratiquer la RD si une solution architecturale (tel que le système MOD ARDA.2.1 page 152) avait été prise en compte lors de la conception de ce système pour s’affranchirde ces durées excessives de reconfiguration.De même, le système HOT II n’est pas adapté pour la reconfiguration dynamique. Car, enplus des durées de reconfiguration pénalisantes dues à la technologie de l’architecture (XC 4000),cette carte souffre de problèmes de conception qui introduisent des difficultés, qu’il faut gérer enplus de celles de l’application elle-même. Par exemple, chaque port de communication partage un17

Chapitre 2.État de l’artbus avec une banque de mémoire, ce qui interdit les accès concurrents à ces deux ressources. Pourle traitement de données bas niveau en temps réel, c’est un problème majeur. En effet, la phasede désynchronisation et d’acquisition simultanée des données souvent nécessaire au traitementdu flot de données participe à la stratégie de traitement dynamique. Ainsi, cette carte censéeêtre adaptée au traitement d’un flot de données en temps réel, ne permet pas une réorganisationde ce dernier pour faciliter le traitement en RD. De plus l’accès depuis le microprocesseur centrals’effectue par l’intermédiaire du FPGA, d’où l’utilisation de ressources internes supplémentaires,et d’un bus déjà partagé entre une banque de mémoire et un port de communication. On constateici, que la conception du système n’as pas été réfléchie pour réaliser à la fois du traitement surflot à grand débit (tel que le traitement bas niveau d’images) et effectuer plusieurs configurationsau cours d’un traitement.Dans le cas de PAMETTE, son utilisation pour le traitement d’images en temps réel avecreconfiguration dynamique est tout à fait possible. Cependant cette carte ne se suffit pas à ellemême. En effet, des moyens supplémentaires sont nécessaires. Les pixels seraient alors fournispar une carte d’acquisition vidéo au travers du bus PCI. Dans ce cas, contrairement à HOTII la désynchronisation - acquisition et le traitement peuvent se faire grâce aux deux mémoiresstatiques qui peuvent être utilisées en alternance. Leur taille limitera alors celle des images à 128Ko au maximum. Quant aux données de reconfiguration, elles peuvent partager le bus PCI avecles pixels. Enfin les images résultats peuvent être acheminées vers les connecteurs d’extension.Nous pouvons donc prévoir un mode dynamique avec ce système, mais la carte telle qu’elle seprésente n’est pas suffisante à sa mise en oeuvre puisqu’elle nécessite au minimum un moduled’entrée et éventuellement un module de sortie des connecteurs d’extensions. Concernant lesdurées allouées à la reconfiguration, contrairement aux systèmes EVC1 et HOT, ici l’emploi deFPGAs en alternance permet de combler les temps non avantageux de reconfigurations de latechnologie utilisée.On peut également considérer SPACE2 comme un système reconfigurable statique avec despossibilités dynamiques plutôt qu’un véritable système reconfigurable dynamiquement. En effet,contrairement aux cartes précédentes, la puissance de calcul fournie par les 160000 portes logiquesélémentaires de cette architecture est importante, d’autant plus que le XC6216 se prête bien à uneexploitation de la reconfiguration dynamique [Xil96]. En effet, la technologie utilisée ici fournitdes temps de reconfigurations plus faibles que les systèmes précédents et offre une possibilitéde reconfiguration partielle. Cependant, pour exploiter ces avantages en cours de traitement,l’architecture doit disposer de ressources pour stocker des résultats entre deux étapes de calcul.Or, les 32 bits proposés par SPACE2 pour relier les huit XC6216 avec les banques de mémoire,semblent trop petits par rapport au nombre d’opérateurs qu’il est possible d’implanter. Ainsi,pour le traitement d’images notament, la puissance est suffisante, mais la bande passante étroitevers la mémoire devient un problème pour appliquer de la reconfiguration dynamique. En fait, la18

2.2. Les Architectures pour la Reconfiguration Dynamiqueconception de cette architecture repose principalement sur la possibilité d’assembler des cartesentre elles, ce qui augmente la puissance de calcul mais pas la densité fonctionnelle [Wir97]. Onconstate là, que le principal tort de cette architecture est une mauvaise définition de la classedes applications visées. Remarquons également que la production de l’XC6200 (circuit pionnierde la reconfiguration partielle) à des fins commerciales, a été abandonnée.Le mode de fonctionnement dynamique à travers la reconfiguration dynamique des FPGAsest donc tout à fait possible, en principe, avec certains de ces systèmes. Cependant son exécutionconcrète n’est pas viable pour des traitements temps réel sur flot de données avec de tellesarchitectures. En effet, on peut constater que la non possibilité de calcul reconfigurable dynamiqueavec les FPGAs repose principalement sur des temps de reconfigurations élevés ou uneconception qui n’a pas pris en compte ce concept. C’est pourquoi, ces systèmes reconfigurableseffectuent principalement des implantations statiques d’algorithmes.Ces circuits figurent parmi les premiers grands systèmes reconfigurables de nôtre domaine.L’augmentation de la densité d’intégration et des fréquences de travail, l’intégration de nouvellestechnologies et les problèmes propre de ces architectures ont permis l’arrivée de nouvelles architectureplus performantes mais parfois plus ciblés également. Ce sont ces architectures qui vontêtre présentées maintenant.2.2.3 Systèmes et micro-systèmes reconfigurables à fonctionnement dynamiqueà grain finDans cette catégorie d’architecture, nous trouvons une bonne partie de systèmes plus récentsque les précédents. Ils se distinguent soit par un couplage plus fort entre la surface reconfigurableet le système hôte/de contrôle, soit par une architecture pensée pour être résolument plusdynamique que celles des systèmes présentés précédemment ou dédiés à des traitements plusciblés.2.2.3.1 ARDOISELe projet ARDOISE (Architecture Reconfigurable Dynamiquement Orientée Image, Signalet Embarquable) a pour but d’élaborer et de concevoir un système reconfigurable exploitantpleinement la reconfiguration dynamique des FPGAs. Les grandes lignes de l’architecture d’AR-DOISE ont été définies au sein du GDR ISIS GT7, auquel le L.I.E.N participe.Une synthèse de ladescription et de la conception du projet ARDOISE a été ensuite présentée [DPW98b, Bou00].A l’opposé des développements mettant en oeuvre des dizaines de FPGA en reconfigurationstatique pour approcher les performances de super-calculateurs : SPLASH [ABD92] ou PeRLe-1[Ber93] par exemple, ARDOISE est de dimension modeste et a l’ambition d’offrir à faible coûtune solution pour le traitement d’images bas niveau.19

Chapitre 2.État de l’artLa figure 2.1 présente l’architecture générale du système ARDOISE. Elle est composée dedeux entités GCC (Gestion des Configurations et Communications) et MARD (Module Ardoise).Les traits en grisé épais représentent les bus utilisés pour la configuration. Les traits fins représententles bus d’échange de données. Une unité de gestion d’adresses, séparée et implantée dansun des FPGAs, est associée à chaque bus. Les chiffres indiquent la largeur des bus de données.Le premier prototype est constitué de 3 MARD et d’un GCC. Le GCC peut configurer dynamiquementles MARD en fonctionnement autonome ou par liaison à un DSP quelconque. Unbus commun aux MARD permet d’échanger des informations avec le DSP soit par ses liens soitpar son bus de données. Il a donc pour rôle la gestion de la configuration et la connexion àune architecture classique (processeur ou DSP). Le FPGA de GCC assure une grande souplessede réalisation de ces échanges. Les MARD (cartes filles) sont cascadables et ont des rôles différentset spécifiques. Les deux modules MARD extrêmes sont deux Gestionnaires de T amponsd’I mages (GTI). Ils ont plusieurs modes de fonctionnement dont celui permettant de désynchroniserou restituer le flot vidéo entrant et sortant. Le module central correspond à l’unitéde calcul que l’on nomme UTGV (unité de traitement à grande vitesse). C’est dans ce derniermodule que s’effectuent les traitements en reconfiguration dynamique. Ainsi, un des scénariopossibles consiste à acquérir l’image N+1 dans GTI1 en 40 ms, à extraire l’image N-1 traitée deGTI2 et à traiter l’image N à l’aide du module UTGV. Pour ce faire, ce dernier module peutêtre reconfiguré afin d’appliquer à l’image N, plusieurs algorithmes successifs. D’un point de vuepratique, il n’y a aucune différence matérielle entre un GTI et une UTGV, un GTI est en quelquesorte une UTGV sous-utilisée. Actuellement, il s’agit de la configuration minimale, encore queles GTI d’entrée et/ou sortie peuvent être optionnels, puisqu’il est possible de cascader plusieursUTGV. Pour une application donnée, la gestion des entrées-sorties est dans la plupart des casfigée. Les GTI utilisent dans ce cas une reconfiguration statique et seule la pénalité temporelle dereconfiguration dynamique de l’unité de calcul est à prendre en compte. Les mémoires tamponsauraient pu être rendues directement accessibles par l’unité de calcul (sans traversée des FPGAdes GTI) grâce à des tampons trois états sur les bus d’adresse et de donnée. On aurait ainsiminimisé les temps d’accès mémoire de l’unité de calcul. Cependant, dans la plupart des cas,les accès aux données sont réguliers (balayages lignes, colonnes, etc.), un mécanisme de pipelinepeut donc facilement être mis en oeuvre pour annuler le coût de traversée des GTI. Pourles accès aléatoires, il est possible soit d’utiliser la mémoire locale de l’unité de calcul, soit demettre en oeuvre des mécanismes de cache dans les GTI. La solution retenue possède l’avantagede renforcer la modularité de l’architecture. En effet, les GTI et l’unité de calcul possèdent lamême architecture ce qui autorise une conception modulaire et cascadable. Plusieurs unités decalcul peuvent être insérées entre les GTI.Les FPGAs retenus pour réaliser les MARD sont des AT40K40 d’ATMEL [Atm]. Ils disposentau maximum de 384 connexions d’entrées-sorties, de 2300 blocs logiques et de 16K bits de20

2.2. Les Architectures pour la Reconfiguration DynamiqueFig. 2.1 – Architecture ARDOISEmémoire interne. En interne, outre les liaisons orthogonales entre cellules, il existe des liaisonsdiagonales qui permettent de réaliser efficacement des multiplieurs. Par exemple un multiplieur8x8 occupe 64 cellules et fonctionne sans pipeline à la fréquence de 40 MHz. Des FPGAs de tailleplus modeste peuvent être utilisés pour la réalisation des GTI compte tenu de la faible complexitédes gestionnaires d’adresse à implanter. Actuellement, un prototype matériel de ARDOISE aété réalisé et testé. La figure 2.2 présente une photographie du kit ARDOISE complet. Commeon peut le constater, ce kit s’est enrichi d’un MARD d’un genre différent puisque ce quatrièmemodule (module supérieur) fait office de carte mère. A cela s’ajoute également une carte DSPcommerciale équipée d’un DSP Sharc. Le MARD mère a pour rôle de piloter les configurationssuccessives des MARD inférieurs, gérer la décompression de configurations, communiquer avecla carte DSP. La carte DSP quand à elle permet d’assurer différents rôles : une gestion plus hautniveau de l’architecture ARDOISE, une programmation simplifiée d’ARDOISE, etc. Si cettecarte DSP permet de simplifier le développement et la communication avec ARDOISE, ellen’est néanmoins pas indispensable à son fonctionnement. Le FPGA est associé à deux mémoires21

Chapitre 2.État de l’artlocales. Les opérateurs de l’algorithme seront implantés dans le FPGA. Les résultats partielsseront stockés dans les mémoires locales pendant les traitements ou les reconfigurations. Nouspouvons constater que, comme pour le système MOD ARD, une procédure de désentrelacementdu flot de données vidéo entrant ou une réorganisation de ces données a été pris en compte pourl’élaboration d’ARDOISE. Cette procédure est nécessaire pour l’élaboration d’un système dédiéà la reconfiguration dynamique en traitement d’images temps réel.Fig. 2.2 – Kit complet ARDOISEUn fonctionnement possible du Gestionnaire des Tampons d’Images (GTI) d’ARDOISE estson utilisation pour conditionner les entrées vidéo dans le traitement images grâce à des mémoirestampons. En effet, dans le cas d’acquisition d’images monochromes, les données E/S sont acquiseset restituées sur 8 bits à 10 MHz en utilisant respectivement les mémoires B1 et B2 (figure 2.3).Les données peuvent être réorganisées avant stockage dans B1 pour faciliter les traitementsultérieurs. Pendant ce temps, l’UC exploite pour un premier traitement la trame précédentestockée dans la mémoire A1 (tampon d’entrée) et écrit ses résultats dans A2 à une cadencepouvant atteindre 40 MHz. A la fin du premier traitement, l’UC est reconfigurée. Un deuxièmetraitement exploite les résultats du premier traitement présent dans A2 et écrit ses résultatsdans A1. On procède de la même façon pour les traitements suivants. A la fin de l’ensembledes traitements, un signal de synchronisation trame est attendu et le rôle des mémoires A et Best échangé. Il est aussi possible d’effectuer entrées et sorties du côté A et ainsi de bénéficier22

2.2. Les Architectures pour la Reconfiguration Dynamiqued’un débit mémoire double côté B en utilisant le mode b décrit ci-dessus. L’organisation retenuepermet aussi en modifiant les configurations des GTI de traiter plusieurs trames simultanémentet ainsi d’effectuer de la détection de mouvement ou de la vision stéréoscopique.Fig. 2.3 – Flux de données sur ARDOISECependant les GTI ne permettent pas à l’UTGV d’accéder directement à leurs zones mémoires.Ceci est dû principalement à un nombre insuffisant de broches entrées /sorties des FPGAutilisés pour la conception de cette architecture. Les premiers tests d’utilisation de la configurationdynamique sur plusieurs exemples ont validé l’architecture retenue. Les performancesglobales de l’architecture ont été estimées et montrent la faisabilité d’une segmentation de traitementd’images temps réel, incluant des opérateurs de filtrage (filtres Nagao ou Deriche), dedétection de contours (gradient), suppression des maxima locaux du gradient, de fermeture descontours et de l’étiquetage des régions, en 32 ms pour des images 512x512 [Bou00]. Dans cetexemple, sept configurations sont nécessaires pour l’application de la segmentation. Ainsi unfiltrage de Deriche est exécuté en 8 ms (2 passes) sur ARDOISE alors qu’il faut 40 ms sur unPentiumII cadencé à 400 MHz. En ce qui nous concerne, nous avons implémenté d’autres algorithmesde traitement d’images sur l’un des prototype de carte fille et nous avons montré leurfaisabilité en reconfiguration dynamique tout en respectant une contrainte temps réel (traitementen moins de 40 ms) en vue de leur exécution sur ARDOISE [TBW01].23

Chapitre 2.État de l’art2.2.3.2 ATMEL 94KLe composant Atmel 94K est également un système intégré commercialisé faisant partie desFPSLIC (in Field Programmable System Level Integrated Circuit). Ce circuit possède sur lamême puce un micro-contrôleur RISC avec une architecture Harvard (mémoire d’instruction etmémoire de données séparées), développant une puissance de 30 MIPS à 12 MHz (nommé AVR),une mémoire de 36 Ko et un FPGA de la famille AT40K (figure 2.4) [Atm99c].Fig. 2.4 – Architecture simplifiée d’un AT94K. [Atm99c]Une partie des entrées/sorties du réseau programmable sont directement connectées au busd’adresses et de données du micro-contrôleur, ce qui permet d’initialiser les registres de contrôled’un opérateur et de lancer un traitement. A la fin de l’exécution, le micro-contrôleur est éventuellementsollicité par des lignes d’interruption, afin qu’il vienne prélever des résultats sur lebus de données. D’autre part, les 4 Ko de mémoire exclusivement réservés aux données sontpartagés entre le FPGA et le micro-contrôleur, offrant un autre moyen de communication. Enfin,les broches d’entrée/sortie affectées au FPGA permettent, par exemple, l’acquisition et letraitement d’un flot de données.Au niveau méthode de développement d’applications pour l’AT94K, une application réaliséeavec ce circuit est développée et validée en 3 étapes, sans recourir à une carte de développement.24

2.2. Les Architectures pour la Reconfiguration DynamiqueDans un premier temps une programmation et une mise au point du programme pour le microcontrôleurseul sont réalisées. Ensuite la conception et la mise au point des opérateurs matérielsseuls sont effectuées. Enfin, une co-simulation du programme et des opérateurs matériels estpossible. Au niveau de sa surface reconfigurable, l’AT94K reprend toutes les fonctionnalités del’AT40K [Atm99c]. Le réseau peut donc être reprogammé en totalité ou en partie, par l’intermédiairedu contrôleur de configuration. Ce dernier permet également au micro-contrôleur dereprogrammer lui-même le FPGA.2.2.3.3 OneChipOnechip est une architecture d’une machine de calcul personnalisé (CCM : custom computemachine) qui couple fortement par intégration un processeur logique fixe, une matrice (surface)logique reconfigurable (reconfigurable logic array) et de la mémoire dans un unique circuit. Cesystème correspond à un processeur à jeu d’instruction virtuel [Wit95]. Il reprend le principe ducache de configuration tel que A. DEHON l’a décrit dans sa thèse [Deh96b], pour reconfigurerun réseau logique couplé à un processeur de type RISC, tous deux placés sur la même puce. Lesystème Onechip permet de programmer très facilement des instructions spécifiques sans avoirbesoin d’un décodage d’instructions complexe. Pour permettre au processeur et à la matricereconfigurable de s’exécuter simultanément, le modèle de programmation assure un contrôleet une gestion de la mémoire du système. Le premier système proposé par Wittig combinaitsimplement le processeur et un FPGA sur un unique circuit (figure 2.5) [Wit95]. Ce qui a aboutiaux mêmes limitations au niveau des accès mémoires que les systèmes présentés précédemment.Fig. 2.5 – Illustration conceptuelle du système Onechip [Wit95]C’est pourquoi, J. Jacob proposa ensuite une extension du système Onechip initialementproposé par Wittig en y intégrant également de la mémoire pour former un unique circuit[Jac98]. En effet, en plus d’un couplage élevé entre la zone reconfigurable et le processeur, leFPGA doit avoir une grande bande passante mémoire et un large stockage local. L’avantaged’utiliser une puce unique est que les limitations de broches ne sont pas une contrainte, celapermet un large accès mémoire avec un faible temps de latence. Il est intéressant de noter qu’il25

Chapitre 2.État de l’artexiste des travaux de recherche sur l’intégration de processeur et de mémoire. On peut citerle projet IRAM (Intelligent RAM) à l’université de Berkeley [Pro]. De plus, J. Jacob a étudiéégalement l’interface entre le processeur et le FPGA. Il a mis au point des mécanismes pourrendre le chargement d’une instruction virtuelle complètement transparente à l’utilisateur. Leconcept système étendu de Onechip devient alors celui présenté en figure 2.6. Le système Onechipétendu présente alors des temps de reconfigurations courts.Fig. 2.6 – Illustration conceptuelle étendue du système Onechip [Jac98]On peut également citer les architectures :MOD ARD (voir Annexe A.2.1, page 152)TriscendE5 (voir Annexe A.2.2, page 154)DISC (voir Annexe A.2.3, page 156)Garp (voir Annexe A.2.4, page 157)DPGA (voir Annexe A.2.5, page 157)2.2.3.4 Limitations des systèmes à reconfiguration dynamiqueLa limitation de tels systèmes ou circuits est la plus part du temps due à l’insuffisance de mémoirespour stocker les résultats intermédiaires entre les configurations au cours du traitement.Ceci entraîne des besoins en mémoire externe. On aboutit alors à un nombre de reconfigurationsmoins élevé à cause des durées d’accès externe à ces blocs de mémorisations. D’autre partles principaux inconvénients de tels circuits sont les interfaces entre le processeur et le moduleintégré FPGA. En effet, des études ont montré que l’interface interne figée d’un tel systèmeest préjudiciable pour espérer atteindre un nombre de reconfigurations permettant d’aboutir àdes systèmes ultra-dynamiques [Deh96b]. Pour répondre à cette limitation, il s’agit de pouvoirredéfinir au cours du traitement ces différentes interfaces pour adapter les échanges selon les26

2.2. Les Architectures pour la Reconfiguration Dynamiqueapplications. D’où l’idée de réaliser des microprocesseurs reconfigurables à l’aide de technologiesreconfigurables qui permettent de redéfinir en permanence la zone reconfigurable et les interfacesexistantes entre les modules le constituant.La reconfiguration dynamique a suscité un vif engouement à travers le monde et de nombreuseséquipes de recherche mènent actuellement des travaux sur ce thème. De nouvellessolutions pour élaborer des systèmes ultra-dynamique apparaissent. Or, comme nous l’avonsdéjà signalé, les circuits FPGA actuels ne constituent pas la meilleure solution (de part leurtemps de reconfiguration élevé) pour réaliser de la RD ultra-dynamique mais il n’y a pas véritablementd’autres alternatives, à moins de construire son propre composant. C’est pourquoi,certains n’ont pas hésité à concevoir leurs propres circuits adaptés à la reconfigurationdynamique [Deh96a, Wit95, CSR + 99]. Ainsi, plusieurs architectures principalement baséessur des FPGAs ou sur des composants hybrides sont réalisées (avec des niveaux de couplageentre les éléments constituant les systèmes reconfigurables différents) pour tenter de mettre enoeuvre ce concept ultra-dynamique. Les innovations portent sur les problèmes d’utilisation dela mémoire [Jac98, NRW95], l’intégration de cache de reconfiguration [Sal98, SV98], l’architecturedes cellules [SP95], etc. Pour surmonter les contraintes des durées de reconfigurationspénalisant la conception de systèmes dynamiques, certains ont conçu des microprocesseurs reconfigurablessur FPGA, exploitant à outrance leur possibilité de reconfiguration dynamique[WH95, Deh96a, Wit95]. L’objectif étant de partager les tâches des différents traitements entreune zone logique reconfigurable et une zone logique fixe (processeur) pour accélérer les calculs enperfectionnant l’interface entre ces différents modules fonctionnels constituant de tels systèmes.Ce qui aboutit à un degré élevé de couplage entre ces différents éléments intégrés et permet auprocesseur de gérer la reconfiguration de la matrice logique grâce à des instructions spécifiques.2.2.4 Systèmes et micro-systèmes reconfigurables à fonctionnement dynamiqueà grain épais ou mixteLe calcul reconfigurable semble être plus à l’aise sur des architectures gros grains que surdes architectures plus fines de type FPGAs. Avec un chemin de données plus larges que lebit, les architectures à grain fin sont moins efficaces à cause de leurs trop large surface deroutage et leur faible ”routabilité”. Tant que le calcul porte sur des chemins de données réguliers,l’utilisation de chemin de données reconfigurables (rDPUs) est extrêmement plus efficace quel’utilisation de cellules logiques classiques type FPGA. Les architectures à grain épais fournissentdes opérateurs au niveau cellules (configurable function blocks : CFBs), des chemins de donnéesde niveau ”mot” et des interconnexions de routage des chemins de données très efficaces et d’untrès bon rendement en surface. Le bénéfice majeur de ces architectures est une réduction massivede la mémoire de configuration nécessaire ainsi que du temps de reconfiguration. Cela conduit27

Chapitre 2.État de l’artégalement à une simplification drastique de la complexité de l’opération de placement routage descomposants. Plusieurs architectures vont être présentées. Certaines d’entre elles présentent dessolutions ”multi-grains”, où les granularités plus épaisses peuvent être obtenues en empaquetantcertaines ressources : exemple 4ALUs de 4 bits chacune formant une ALU de 16 bits.2.2.4.1 Virtex II Pro XFPGA de haute densité, le Virtex II atteint les 8 millions de portes logiques équivalentes(XC2V8000 : 104,832LCs) avec jusqu’à 1108 ports d’entrée/sortie (Package FG1152 et FG1517).Les améliorations pour ce FPGA sont les suivantes :– Nouveau design du CLB (Fig. 2.7)– Bancs mémoire de plus grande taille( jusqu’à 3Mbits de mémoire embarquée (BlockRAM))– Multiplieurs intégrés (jusqu’à 168 multiplieurs 18x18 bits)– Gestion des horloges par DCM (Digital Clock Manager)(jusqu’à 12)– Capacité de routage améliorée (Active Interconnect Technology)– Permet l’implantation du processeur MicroBlaze—32-bit@125 MHz– Temps de configuration @66MHz : 55,04 msFig. 2.7 – Virtex2 CLB [Xil04c]L’implantation de ressources réparties à grain épais (multiplieurs) ainsi que de mémoirespermet d’accélérer considérablement l’exécution des traitements lorsque ceux-ci peuvent en tirerparti. C’est pour répondre au traitement sur des données de plus en plus larges que detelles améliorations ont été apportées. Les multiplieurs sont en effet des éléments très pénalisant28

2.2. Les Architectures pour la Reconfiguration DynamiqueFig. 2.8 – Virtex2 : demi slice [Xil04c]du point de vue des performance lorsqu’ils sont implantés de façon classique sur FPGA. Bienque disposant toujours d’une surface logique à grain fin, cette architecture est orientée vers letraitement sur des mots larges et non pas uniquement sur des bits.Le Virtex II Pro X (Fig. 2.9)est le circuit haut de gamme Xilinx. Il bénéficie de la technologieet de la densité d’intégration du Virtex II mais embarque également des composants particuliersqui sont :– un Tranceiver RocketIO—X Multi-Gigabit(MGT)– Deux coeurs de processeur RISC IBM®PowerPC—405Le transceiver RocketIO X est un émetteur/récepteur série programmable. Il peut travailleren mode full-duplex à des vitesses comprises entre 2.488 Gb/s et 10.3125 Gb/s.Le Virtex II ProX peut embarquer de 8 à 24 transmetteurs de ce type.Le coeur de processeur IBM®PowerPC—405 (Fig. 2.10) est un coeur de processeur RISC 32 BitsPowerPC 405D5 en technologie 0, 13µm dérivé du coeur de processeur IBM PowerPC 405D4. Ilpeut atteindre 300MHz tout en maintenant une faible consommation. Le Virtex II Pro X peutaccueillir jusqu’à quatre de ces coeurs de processeur (XC2VP125).Exemple du XC2VP125 Package FF1704 :29

Chapitre 2.État de l’artFig. 2.9 – Vue d’ensemble du Virtex II Pro X[Xil04b]Logic Cells 125’136BRAM(Kbits) 10’008multipliers (18x18) 556Digital Clock Management Blocks 12Config(MBits) 42,78PowerPC Processors 4Max 3.125 Gbps RocketIO Transceivers 24Cette architecture extrêmement ”fournie” a été créée dans le but de répondre à tous typesde traitements avec la plus grande souplesse possible. La reconfiguration dynamique est parfaitementpossible même si la structure complexe de ce circuit vient ajouter des contraintessupplémentaires à cette reconfiguration : en effet le circuit est découpé en colonnes à l’intérieurdesquelles la reconfiguration est possible. La contrainte réside dans le fait qu’il n’est pas possiblede configurer un bloc dans la colonne de taille inférieur à une ”frame” [Xil04a]. La taille d’une”frame” dépendant du circuit considéré (Tab. 2.2).2.2.4.2 KressArrayLe KressArray [HK95, Krea] est un maillage de rDPU (reconfigurable DataPath Unit) physiquementconnecté les uns aux autres : aucune surface de routage nécessaire. En 1995, il a30

2.2. Les Architectures pour la Reconfiguration DynamiqueFig. 2.10 – Intégration du coeur de processeur IBM®PowerPC—405[Xil04b]été publié comme ”rDPA” (reconfigurable DataPath Architecture, Figure 2.11). Le nom ”KressArray”est arrivé plus tard. Le KressArray est un réseau super systolique. Ses interconnexionssont de types différents : multiples connexions unidirectionnelles et/ou bidirectionnelles du plusproche voisin, bus de retour horizontaux ou verticaux de longueur totale ou partielle, un uniquebus global reliant tous les rDPUs (également pour les configurer). Chaque rDPU peut-être utilisépour le routage uniquement, comme un opérateur, ou encore comme opérateur avec un routagesupplémentaire du chemin de données. Un premier KressArray 32-bits incluant une unité decontrôle additionnel pour le MoM-3 Xputer supporte tous les opérateurs du langage C.Le Kress Array a ensuite été décliné en une famille de circuits. Les composants de cette famillepeuvent différer par leur structure de communication ainsi que par la structure du rDPU. Cesdifférentes structures permettent ensuite l’optimisation de certains opérateurs plus complexes :multiplication parallèle ou séquentielle, MAC (Multiply-Accumulate) grâce à un ou plusieursrDPUs.Grâce au nouvel environnement Xplorer [HHHN00, Kreb], les rDPUs supportent égalementd’autres opérateurs incluant les branchements, les boucles ”while” et les boucles ”do-while”. Les31

Chapitre 2.État de l’artTab. 2.2 – Virtex-II : Temps de configuration et taille des Frames ([Xil04a] page 309)Frame Total No. Approx. Approx. Approx.Device No. of Length in Configuration of bits SelectMAP Serial JTAGFrames Bits Bits (including Download T. Download T. Download T.header) (50 MHz) ms (50 MHz) ms (33 MHz) msXC2V40 404 832 336,128 338,976 0.84 6.72 10.19XC2V80 404 1472 594,688 598,816 1.49 11.89 18.02XC2V250 752 2112 1,588,224 1,593,632 3.97 31.76 48.13XC2V500 928 2752 2,553,856 2,560,544 6.38 51.08 77.39XC2V1000 1104 3392 3,744,768 4,082,592 9.36 74.90 113.48XC2V1500 1280 4032 5,160,960 5,170,208 12.90 103.22 156.39XC2V2000 1456 4672 6,802,432 6,812,960 17.01 136.05 206.13XC2V3000 1804 5312 9,582,848 10,494,368 23.96 191.66 290.39XC2V4000 2156 6592 14,212,352 15,659,936 35.53 284.25 430.68XC2V6000 2508 7872 19,742,976 21,849,504 49.36 394.86 598.27XC2V8000 2860 9152 26,174,720 26,194,208 65.44 523.49 793.17flots d’entrées/sorties provenant et allant vers la matrice peuvent être transférés par le bus globalvers les ports extérieurs de la matrice ou vers d’autres rDPUs (adressable individuellement grâceà un générateur d’adresses). Le KressArray supporte également la reconfiguration dynamiquepartielle.2.2.4.3 ColtLe Colt combine les concepts du FPGA et des calculs sur flots de données (sous forme Networkon Chip. C’est un pipenet [HWA93] 16 bits. Le flux de données comporte, dans l’entête, lesdonnées de configuration pour le routage ainsi que pour les fonctionnalités des PEs (ProcesseursÉlémentaires) rencontrés. Le Colt est constitué d’un maillage de IFUs 16 bits( InterconnectedFunctional Units), d’un crossbar(réseau d’interconnexion), un multiplieur d’entiers, et de sixports de données. Chaque IFU contient une ALU, un registre à décalage permettant les multiplicationset les calculs sur nombre flottant, une unité de décision pour les branchements duflot, des unités de retard optionnelles pour la synchronisation de pipelines.2.2.4.4 FIPSOCFIPSOC (FIeld-Programmable System-On-Chip) par SIDSA [SID] embarque un contrôleur8051, un RA (reconfigurable array) et un RAA (reconfigurable analog array). La matrice reconfigurable( RA 8x12, 8x16, 16x16) est une matrice de ”digital macro cells” (DMC) qui inclut une32

2.2. Les Architectures pour la Reconfiguration DynamiqueFig. 2.11 – La rDPA[HK95]table de correspondance 4 entrées, 4 bascules de mémorisation, un additionneur 4 bits, une mémoire16x4 bits,etc. Le RAA, matrice analogique reconfigurable, est constitué de ”configurableanalog blocks” (CAB) utilisables comme amplificateurs différentiels, comparateurs, convertisseursetc. Le RA est multi contextes et contient ainsi 2 mémoires de configurations supplémentaires.Le démarrage du composant peut-être effectué depuis une mémoire RAM externe enmode parallèle (comme le fait le contrôleur 8051), en série depuis une PROM externe, où via unport série RS232. Le FIPSOC est prévu pour être utilisé comme un émulateur d’ASIC pour leprototypage rapide.2.2.4.5 Systolic RingLe Systolic Ring [STB + 02] est un circuit reconfigurable offrant différentes spécificités. Il nes’appuie pas sur un réseau d’interconnections de type maillage classique. On peut néanmoinsprésenter le ”DNode” comme son élément de calcul de base(Fig.2.12). Ce DNode est constituéd’une ALU + multiplieur 16 bits cablé, d’une banque de registres 4x16 bits et d’un chemin33

Chapitre 2.État de l’artFig. 2.12 – DNode du Systolic Ring [PIL03]de données optimisé sur 16 bits également. Les données affluent de DNode en DNode de façoncirculaire sur une couche du systolic ring. Toutes les connections entres DNodes se faisant autravers de switchs. Ces switchs permettent également une entrée/sortie du flux de données ouun communication avec les couches adjacentes du systolic ring.(Fig.2.13)Fig. 2.13 – Architecture du Systolic Ring [PIL03]34

2.2. Les Architectures pour la Reconfiguration Dynamique2.2.4.6 DARTL’architecture DART [DCPS02] est une architecture reconfigurable dynamiquement multigrainorientée ”applications mobiles 3G”. Elle est de constitution complexe et hiérarchisée. Auniveau le plus élevée, elle est constituée de ”clusters” (Fig. 2.14) indépendants qui partagentun contrôleur de tâches, un contrôleur d’entrées/sorties ainsi que trois mémoires dédiées auxdonnées, aux instructions et aux configurations.Clusters L’architecture de chaque clusters (Fig. 2.14) est constituée de six chemins de donnéesreconfigurable horizontaux(DPR1 à DPR6 (Fig. 2.15)) à grain épais, réunis par un réseausegmenté et alimentés par un contrôleur. On trouve également un espace mémoire pour les données,une mémoire pour les configurations et un FPGA (grain fin) également alimenté par lecontrôleur cité précédemment.DPR Chacun des DPRs (Fig. 2.15) est constitué d’un réseau multi-bus flexible connectantdeux registres, deux multiplieurs et deux ALUs avec registres de synchronisation. Ces unitéssont reconfigurables dynamiquement et accèdent par ce même réseau aux données stockées dansquatre mémoires locales gérées chacune par un contrôleur.Reconfiguration Deux modes de reconfiguration sont disponible et permettent une utilisationefficace des DPRs en fonction du type de tâche à réaliser.Reconfiguration Hardware(HW) : Permet une reconfiguration totale et flexible du DPR,on cherche ici à optimiser le travail sur des données régulières.Reconfiguration Software(SW) : Permet une configuration rapide (1cycle) pour le traitementd’applications irrégulières. Dans ce cas la flexibilité est limitée, les opérations sontuniquement de type Lecture-Modification-Écriture. Le DPR se comporte ici comme unDSP.L’utilisation de ces deux modes de reconfiguration autorise l’exécution de traitements critiquesde toutes sortes.2.2.4.7 NAPALe National Adaptive Processing Architecture (NAPA, Fig. 2.17) est constitué de :1. Un processeur logique adaptatif (ALP) toujours associé à un processeur scalaire à usagegénéral appelé processeur à instructions fixées (FIP). L’ALP et le FIP ont accès à un mêmeespace mémoire partagé. Pour la première implémentation du processeur NAPA, le FIPest un RISC 32 bits qui requièrent moins de 10 % de la surface de silicium total.35

Chapitre 2.État de l’artFig. 2.14 – Architecture DART [PIL03]Fig. 2.15 – DART : structure du DPR [PIL03]2. Une interface dédiée est disponible entre l’ALP et le FIP ce qui permet d’atteindre unmaximum de performances. Cela permet d’augmenter le jeu d’instructions du FIP sanscompromettre sa compatibilité actuelle et permet également une reconfiguration rapide del’ALP. Ce mécanisme est appelé contrôleur de pipeline reconfigurable (RPC) et les fonctionsdu coprocesseur disponibles dans le FIP sont appelées jeu d’instructions du pipelinereconfigurable (RPIS).3. Une interface de calcul parallèle. Il s’agit d’une architecture d’interconnexion appelée ToggleBus(Fig. 2.16). Chaque processeur NAPA dispose d’une interface ToggleBus Transceiver(TBT).4. Une organisation mémoire fortement couplée au FIP. La première implémentation du processeurNAPA contient trois mémoires embarquées ainsi qu’une interface générale pour lesmémoires de type ROM, SRAM et DRAM.5. Un réseau de bus pipeline 32 bits (PBA, Pipeline Bus Array) ainsi qu’une interface pourbus pipeline (PBI) pour les ALPs. Cette interface permet aux ALPs de faire des transfertsde données concurrents vers des unités de calcul dédiés à travers le PBA et ainsi atteindredes performances élevées en termes de bande passante.36

2.2. Les Architectures pour la Reconfiguration DynamiqueFig. 2.16 – NAPA ”ToggleBus” [RLG + 98]Fig. 2.17 – Structure du processeur NAPA [RLG + 98]2.2.4.8 RAMPASSLe RAMPASS (Reconfigurable and Advanced Multi-Processing Architecture for futureSilicon System) est une architecture qui vise à s’adapter à différents types de traitements dedonnnées (SIMD, MIMD, VLIW). C’est une architecture reconfigurable asynchrone particulièrecomposée de deux parties principales reconfigurables (Fig. 2.18) :– La première dédiée au contrôle des applications appelée RAC (Reconfigurable ArrayControl),– La seconde dédiée au calcul appelée RAO (Reconfigurable Array of Operators).Le RAC (Fig. 2.19) permet d’implanter des graphes d’états. Ces graphes permettent decontrôler l’exécution de la partie opérative (RAO). Le RAO communique également des événementsau RAC de façon à commander les transitions d’un état au suivant par exemple.Durant l’exécution, les graphes d’états contenus dans le RAC sont continuellement remis àjour. Le RAC est en ce sens auto-reconfigurable puisque les graphes eux même peuvent commanderla mise en place d’autres graphes d’états.37

Chapitre 2.État de l’artFig. 2.18 – Synoptic de RAMPASS [CVBC03]Pour un état du graphe, une instruction est associée et envoyée au RAO lorsque cet étatdevient actif. Les transitions entre états sont commandées par les acquittements des instructionschargées dans le RAO.Fig. 2.19 – le bloc RAC [CVBC03]Cette architecture n’est malheureusement pas encore opérationnelle. La partie RAC a faitl’objet d’une description détaillée, mais la partie RAO reste à concevoir. L’architecture complèteest donc très attendue tant les concepts qu’elle manipule sortent de l’ordinaire des circuits38

2.2. Les Architectures pour la Reconfiguration Dynamiquereconfigurables actuels.2.2.4.9 X.P.P.X. P. P. est une matrice configurable commerciale. Le coeur de X. P. P. est une matriced’éléments configurables. Cette matrice est basée sur un nombre réduit de ”processing elements”différent(PE)(figure 2.20). Les ALU-PEs (jaune) permettent les calculs basiques(figure 2.21).RAM-PE (orange) pour le stockage des données. I/O (bleu) permettent de connecter les élémentsinternes à la mémoire externe ou aux différents ports d’entrées sorties. Le contrôleur deconfiguration charge les programmes dans la matrice.Cette structure très simple permet à la matrice une programmation et un placement desalgorithmes aisés. Le modèle de X. P. P. permet de définir la taille des arrangements des P. E.sen fonction des besoins de l’application. De plus, la taille des chemins de données et des A.L.Uspeut être défini entre 8 et 32 bits.Fig. 2.20 – Matrice XPP[BV03]Élements ALU Les éléments ALU intègrent des objets de fonctionnalités différentes :1. ALU : ALU deux entrées/sorties permettant les fonctions typiques d’un DSP comme lamultiplication, addition, comparaison, décalage. Toutes ces opérations sont réalisées en uncycle d’horloge.2. BREG(Back Register) : cet élément procure un routage vertical du chemin ainsi qu’uneALU. L’ALU peut être utilisée pour une addition, un décalage, une tâche de normalisation,39

Chapitre 2.État de l’artetc.3. FREG(Forward Register) : routage de proximité dans la direction verticale de haut enbas, une ALU spécialisée réalise les opérations de routage du flux de données telles que lemultiplexage et la permutation. Le FREG introduit un retard d’un cycle.4. Canaux de données : le réseau de communication permet des connexions point à point ainsique point à multi-points entre les sorties et les entrées de différents éléments. Jusqu’à huitcanaux de données sont disponibles pour chaque direction horizontale. Les commutateursaux extrémités des lignes peuvent relier le canal au canal de l’élément voisin.Fig. 2.21 – élément ALU du XPP[BV03]Élements RAM les éléments de RAM (ALU-PEs) sont disposés sur les bords de la matriceet sont quasiment de nature identique au PE-ALU, toutefois l’élément ALU est remplacé parune mémoire.La RAM double port possède deux ports séparés pour permettre des opérations de lectureset d’écriture indépendantes. La RAM peut être configurée en mode FIFO (pas besoin d’adressesd’entrées) ou en RAM avec neuf adresses d’entrées ou plus. Le modèle IP permet de définir lacapacité de stockage. Les valeurs typiques vont de 512 à 2k mots.BREG, FREG et canaux de données sont identiques à ceux présents dans les PE-ALU.BREG et FREG peuvent être configurés pour construire un générateur d’adresses linéaire.Ainsi,des accès DMA (direct memory acces) vers ou depuis la RAM peuvent être obtenus avecun seul PE-RAM. Plusieurs PE-RAM peuvent être combinés pour réaliser une mémoire plusimportante avec un espace d’addressage continu.40

2.2. Les Architectures pour la Reconfiguration DynamiqueÉléments d’entrées sorties I/O les éléments d’entrées sorties sont connectés aux canauxhorizontaux. L’élément standard d’entrée/sortie fournie deux modes différents :– Streaming : deux ports par élément I/O son configurés en entrées ou sorties. L’acquisitionde groupe de données par le XPP est réalisée par un protocole asynchrone. Ainsi les fluxde données externes (par exemple d’un convertisseur A/D) ne doivent pas être synchronesde l’horloge de XPP.– RAM : une sortie fournie l’adresse de la RAM externe, l’autre est un port de donnéesbidirectionnel. Les mémoires statiques externes synchrones sont directement connectéesau port d’adresses, de données et de contrôle du signal. La taille maximale de la mémoireexterne dépend de la largeur du bus de données du X. P. P. (exemple : 16 Mmots pourl’architecture 24 bits)L’élément I/O peut aussi affecter ses deux ports aux paquets d’événements sur un bit. Lecomposant X. P. P. standard fournie quatre éléments I/O avec un interfaçage externe en 3,3 V.Pour la réalisation de SoCs, il est possible de connecter des bus aux canaux horizontaux du X.P. P.le contrôleur de configuration le contrôleur de configuration (microcontrôleur) adressetoutes les tâches de configuration sur la matrice. Initialement, il lit les configurations via uneinterface externe depuis une S-RAM, dans son cache interne. Puis, il charge la configuration(opcodes, routage des canaux et constantes) dans la matrice. Dès qu’un PE est configuré, ilcommence à travailler si une donnée est disponible. Ensuite, le contrôleur de configuration chargeles sous séquences de configuration dans la matrice. Le système d’exploitation local assure quel’ordre séquentiel des configurations est maintenu sans blocages.Implantation d’algorithmes Dérivé d’un graphe flot de données, les algorithmes sont directementimplantés sur la matrice. Les noeuds du graphe définissent directement la fonctionnalitéet l’opération de l’ALU ou des autres éléments, tandis que les arcs définissent les connexions entreles éléments. Une telle configuration demeure statique sur la matrice pendant que les paquetsde données traversent les opérateurs.Traitement de données Le X. P. P. est conçu pour simplifier la tâche de programmation etpour permettre au compilateur de haut niveau d’utiliser le potentiel du traitement parallèle deX. P. P. à son maximum. La fonctionnalité du X. P. P. la plus importante supportant ceci est lamanipulation de paquets (”packet handling”). Contrairement aux FPGAs qui transférent leursdonnées de registres en registres à chaque coup d’horloge, le X.P.P. transfère des paquets dedonnées. Ces paquets de données contiennent un mot de processeurs (ex : 24bits) et sont créés,à la sortie des objets, dès que les données sont disponibles. De là, ils se propagent aux entrées41

Chapitre 2.État de l’artreliées. Si plus d’une entrée est connectée à la sortie, le paquet est dupliqué. De plus, un objetdu X. P. P. commence son calcul seulement lorsque tous les paquets qui lui sont nécessaires sontdisponibles en entrée. Si un paquet ne peut être exécuté, le pipeline stagne jusqu’à ce que celuicisoit enfin exécuté. Il s’agit ici d’un mécanisme de contrôle matériel, ce mécanisme assure lefonctionnement correct de l’algorithme en toutes circonstances et le programmeur n’a pas besoinde faire attention aux retards de pipeline dans la matrice ni de savoir comment synchroniserles données pour un flux de données externes asynchrones. Pour empêcher les bulles dans lespipelines fonctionnant en parallèle, les compilateurs du X. P. P. manipulent automatiquementl’équilibrage des pipelines. Cette manipulation des paquets par le X. P. P. en fait un processeurprogrammable. C’est un avantage important par rapport aux architectures orientées matérielles.Transmission d’évènements Beaucoup d’algorithmes exigent des décisions qui sont baséessur des résultats des calculs courants. Pour soutenir ceci, XPP fournit une transmission d’événements.Les événements sont également manipulés comme des paquets, comparables aux paquetsde données, avec la seule différence, que seulement un bit de données est transféré. Les événementsproviennent des opérations PE-ALU (par exemple comparaison) ou des ports externes.Ces événements peuvent être utilisés comme des entrées pour les fonctions de l’ALU (exemple :retenue, commande de décalage) ou bien peuvent autoriser ou non une opération d’une ALU.Afin de commander l’écoulement des paquets de données par la matrice, les événements peuventégalement supprimer des paquets ou orienter des flots de paquets au moyen d’opcodes du FREG.Plusieurs événements peuvent être combinés dans les LUT du BREG - ceci permet des structuresplus complexes de commande et des machines d’état plus petites.Reconfiguration Dynamique Beaucoup d’algorithmes sont trop complexes pour s’adaptersur une matrice donnée. Dans le passé, la seule possibilité était d’ajouter des composants additionnel.Le XPP est conçu pour permettre la reconfiguration rapide de la matrice. Contrairementaux FPGAs, qui exigent des mémoires de configuration de l’ordre du Mbits, XPP a besoin seulementde quelques Kbits pour une configuration complète. En outre, le processus de configurationdu XPP est synchronisé avec les données qui affluent dans la matrice. Par conséquent des algorithmescomplexes (tels que le MPEG) peuvent être coupés en plusieurs partitions, qui sontcalculées séquentiellement. Les RAM internes conservent les données entre les configurations.Cependant, pour une exécution optimale, le nombre de données qui sont calculées dans uneconfiguration, doit être aussi élevé que possible (par exemple équivalente à la taille des RAMinternes) afin de réduire au minimum l’effet de la latence provoquée par les reconfigurations.Enoutre de petites parties de la matrice peuvent être modifiées sans nécessiter l’arrêt des autrescalculs configurés dans la matrice. Même des registres simples tels que les registres d’entréedes ALUs peuvent être modifiés tandis que la matrice calcule d’autres données. C’est utile si42

2.2. Les Architectures pour la Reconfiguration DynamiqueFig. 2.22 – Gestion des reconfiguration de la matrice XPP[BV03]des constantes d’un algorithme telles que des coefficients doivent être remplacées. La programmationde l’ordre des configurations est semblable à une machine d’état en NML 1 . Le flot deconfiguration peut être commandé par des résultats des calculs de la matrice sous forme depaquets d’événements. En outre la configuration différentielle permet l’échange de constantes oud’autres paramètres des configurations en fonctionnement(par exemple échange des coefficients).L’exemple (figure 2.22) montre un ordonnancement conditionnel typique de configuration. Lareconfiguration dynamique étend la gamme des instructions des microprocesseurs conventionnelsà l’exécution de graphes flot de données plus complexes.On peut également citer les architectures :DP-FPGA (voir Annexe A.3.1, page 158)MATRIX (voir Annexe A.3.2, page 159)RAW (voir Annexe A.3.3, page 160)REMARC (voir Annexe A.3.4, page 161)1 NML(native mapping language) est un langage de description structurée très simple exploitant toutes lesfonctionnalités du X. P. P.43

Chapitre 2.État de l’artCHESS (voir Annexe A.3.5, page 163)DReAM (voir Annexe A.3.6, page 163)Chameleon (voir Annexe A.3.7, page 164)RaPiD (voir Annexe A.3.8, page 165)PipeRench (voir Annexe A.3.9, page 165)CHIMAERA (voir Annexe A.3.10, page 167)2.2.5 Caractéristiques des systèmes reconfigurables dynamiquementA partir des architectures précédentes, on constate que l’exploitation de la reconfigurationdynamique n’est rendue possible qu’après avoir considéré un certain nombre de contraintes. Cesdernières sont d’une part de nature matérielle (technologie existante) et d’autre part liées auxcaractéristiques et à la diversité des algorithmes de traitement à mettre en oeuvre. Aussi, laconnaissance des algorithmes à implanter est d’une importance capitale pour la définition etla quantification des besoins d’une architecture reconfigurable dynamiquement. Elle permet dedimensionner les ressources de calcul, de dénombrer les types de mémoires nécessaires, ainsi queleurs nombres et leurs débits d’entrée/sortie.2.2.5.1 Accélération des traitementsDans beaucoup de domaine d’applications (comme le traitement du signal et des images), lesFPGAs sont capables d’atteindre des fréquences de travail nettement supérieures à la fréquenced’arrivée des données. Il peut exister alors un rapport élevé entre la fréquence de travail etla fréquence d’acquisition. Autrement dit les FPGAs employés pour concevoir une chaîne detraitement, sont très largement sous-exploités par rapport à la vitesse d’arrivée des données.Ce phénomène s’aggrave, au fur et à mesure que les performances des FPGAs s’améliorent.L’accélération des traitements est donc possible et va permettre de libérer un temps précieux pourreconfigurer le circuit et réaliser d’autres traitements. L’accélération des calculs n’est possiblequ’à partir du moment où l’on désynchronise la fréquence d’acquisition et la fréquence de travail[HYES97, BDKK98]. Nous devons donc prévoir un mécanisme de désynchronisation entre lesystème d’acquisition et le système de calcul.2.2.5.2 Tampon d’entréeL’étape de désynchronisation peut être assurée par un tampon d’entrée. Dès lors rien n’empêchede traiter les données à la cadence maximale, ce qui libère du temps avant l’arrivée denouvelles données pour effectuer des étapes de reconfiguration. Nous pourrons alors imposer destraitements plus rapides dans le module ou l’unité chargée d’effectuer les différents calculs ou44

2.2. Les Architectures pour la Reconfiguration Dynamiquetraitements en reconfiguration dynamique. La procédure de désynchronisation s’effectue grâceà des mémoires adressées en alternance à des cadences différentes (figure 2.23). L’une à la cadenced’entrée des données et l’autre à celle des traitements. Ce tampon d’entrée présente unautre intérêt pour un système RD. En effet, en pratique la reconfiguration dynamique s’effectueplutôt entre deux blocs de données car avec les FPGAs actuels il est impensable de reconfigurertotalement les circuits en une seule période d’acquisition de données.Fig. 2.23 – Fonctionnement d’un tampon d’entréeLa parade imaginée consiste à traiter les échantillons par paquets, plutôt que de manièreindividuelle. En procédant ainsi, le temps perdu pour chaque reconfiguration est amorti surle volume de données [Gue97]. Pour certaines applications, la nature des traitements et desdonnées dicte la taille des données à choisir. Par exemple dans le domaine d’application dutraitement d’images, on choisit souvent une taille de bloc de données multiple entier du nombreexact de pixels de l’image (taille de l’image, trame, lignes, etc.) et identique à chaque étape detraitement. En pratique on portera une grande attention à ce choix, car il détermine le nombrede reconfigurations possibles de l’implantation RD des opérateurs. Il est important de remarquerque cette désynchronisation entre acquisition et traitement a l’inconvénient d’introduire un délaide latence supplémentaire afin de constituer le paquet de données à traiter. Il s’agira alors, pourcertaines applications, de savoir si ce temps de latence est préjudiciable ou non.2.2.5.3 Réduction des durées de reconfigurationLes systèmes exploitant la reconfiguration dynamique des FPGAs nécessitent une duréeallouée aux reconfigurations tout en respectant les contraintes temps réel. Cela suppose un minimumde soutien de la part du matériel pour réduire la durée des calculs (traitement à accélérer)45

Chapitre 2.État de l’artet minimiser l’impact du délai nécessaire à la reconfiguration. Au niveau composant, pour obtenirdes durées de reconfiguration plus courtes, les fabricants de FPGA ont rendu possiblela reconfiguration partielle de leur circuit. Cela permet de ne reconfigurer que les différencesentre deux étapes successives, et par ce biais de réduire le volume des données et leur durée dechargement.Une autre solution possible pour réduire le temps de reconfiguration est d’introduire plusieursplans de configurations couplés à un mécanisme pour basculer rapidement d’une configurationà une autre [San98, FFM + 99, Deh96b]. La mémoire de configuration est alors constituée deplusieurs zones capables d’être permutées quasi instantanément. Ainsi pendant que l’une commandele plan logique, les autres sont modifiées pour contenir les configurations futures. Lerecours à des algorithmes classiques de gestion de priorité entre les configurations, permet dedécider quelle configuration doit être remplacée [Jac98]. Cet ajout de plans de configurationsa forcément un coût. Actuellement, la surface de silicium occupée par la mémorisation de laconfiguration représente environ 10% de la surface totale [Deh96b]. D’un point de vue système,on peut apparenter cette alternative à l’introduction d’un cache au sein du composant FPGA(masquage de la durée de configuration de l’étape future). Une page de cache correspond alorsà une configuration matérielle.Le masquage des délais de reconfiguration à travers un fonctionnement en ping-pong estl’une des principales solutions proposées pour réduire les durées de reconfigurations de façonarchitecturale. En effet, les premiers FPGAs disponibles avaient des temps de reconfigurationd’un peu moins d’une dizaine de millisecondes. De plus, la reconfiguration partielle n’était alorssupportée principalement que par deux familles de FPGA, le Clay de National Semiconductor[Nat93], le CAL d’Algotronix [Kea89], tous deux non disponibles. Pour toutes les autres, étantdonné des contraintes de temps sévères, il était difficile d’exploiter la reconfiguration dynamiquesans utiliser un mécanisme de masquage des délais de reconfiguration. Aussi une solution architecturalea été imaginée pour masquer le temps de programmation. Cette technique reposesur la configuration en alternance de plusieurs zones logiques reconfigurables. Ainsi, chaque planlogique (dans notre cas un FPGA) du système est associé à un double, de manière à configurerl’un, pendant que l’autre travaille. Il s’agit alors d’un fonctionnement ping-pong. Cette solutiona été proposée et mise en oeuvre par H. GUERMOUD au LIEN avec l’emploi de deux circuitsFPGAs [Gue97]. La figure 2.24 illustre le mécanisme de cette reconfiguration avec masquage.Pendant qu’une partie du circuit réalise le traitement des données, l’autre partie est en phase dereconfiguration et vice et versa. Il est à remarquer que ce principe mobilise quelques ressourcesspécifiquement destinées à l’aiguillage des données sur les différents composants de l’architecture.Plusieurs considérations sont à prendre en compte. En général, pour chaque étape de reconfiguration- traitement, la durée de reprogrammation est inférieure à la durée de calcul, alors lesdonnées ne connaissent pas de temps mort et sont constamment sollicitées pour un traitement.46

2.2. Les Architectures pour la Reconfiguration DynamiqueFig. 2.24 – Principe du masquage par un fonctionnement ping-pongDe leur point de vue tout se passe comme si les reconfigurations étaient instantanées puisqueles délais de reconfigurations sont alors masqués. Ainsi, en doublant le nombre de FPGA, onsupprime les délais de reconfiguration. On peut alors, au lieu d’utiliser un FPGA d’une capacitéC1 avec des temps de reconfigurations élevés utiliser deux FPGAs de capacité C1/2 mettanten oeuvre un processus de masquage au cours du traitement (figure 2.24). Cela s’apparente àun composant utilisant de la reconfiguration partielle sur une des moitiés de sa surface logique.Ce procédé autorise plus de flexibilité au niveau des durées de reconfiguration. Évidemment,rien n’empêche que les deux composants fonctionnent simultanément en effectuant des traitementsparallèles. On peut également imaginer implanter sur chacun d’entre eux la moitié d’untraitement (si la granularité de l’algorithme le permet). Il est à noter que cette procédure nedouble pas la quantité de mémoire de configuration. En effet, quelque soit la procédure utilisée(RD partielle ou non, par cache interne ou non, par masquages ou sans, etc.) les configurationssont les mêmes pour une application donnée, seul change leur ordre et leur lieu ” géographique” d’exécution qui peuvent être différents.La principale complexité de ce procédé est la gestion simultanée de deux plans logiquesdistincts. Nous réduisons les durées de reconfigurations au détriment d’une logique de contrôlede basculement entre les plans masqués bien plus complexes. Aujourd’hui, le masquage destemps de programmation par doublement du nombre de FPGA, ne se justifie plus dans le casdu traitement de gros blocs de données tels que des images, grâce d’une part à l’améliorationdes interfaces de configuration des FPGA et l’arrivée de technologie à reconfiguration partiellerapide, d’autre part à l’évolution de leurs performances qui deviennent de plus en plus élevées.47

Chapitre 2.État de l’artEn effet, le coût inévitable de la durée de reprogrammation est largement amorti sur le volume dedonnées à traiter d’une part et d’autre part la contrainte de temps reste la même pour des vitessesde traitement plus rapide. Par contre, ce n’est pas vrai pour toutes les applications qui nécessitentde reconfigurer les FPGA très souvent, comme par exemple les processeurs à jeux d’instructionsvirtuels [WH95]. Pour de telles applications, le masquage du délai de reconfiguration est une réellenécessité et les réponses apportées se situent alors aussi bien au niveau composant, avec entreautres l’utilisation de caches de reconfiguration [SV98, Sal98, TCE + 95] qu’avec des solutionsarchitecturales de masquage.2.2.5.4 Gestion dynamique de l’horlogeNous avons vu comment la reconfiguration dynamique, en dissociant la fréquence de travailde la fréquence d’acquisition des données, permettait d’accélérer les traitements et par la mêmed’améliorer l’utilisation des FPGA. Cependant nous avions utilisé une hypothèse simplificatricequi consistait à dire que tous les algorithmes que nous souhaitions implanter travaillaient à lamême fréquence limite, imposée par la technologie employée. En réalité, le chemin critique varied’un traitement à l’autre, il en résulte une cadence de travail maximale, propre à chaquealgorithme. Aussi, pour bénéficier de la meilleure accélération des traitements, une architecturereconfigurable dynamiquement doit disposer d’une variété de fréquences ou de programmationde la fréquence afin d’adapter la période d’horloge de calcul au chemin critique de l’étape à implanter.En pratique, cela nécessite l’emploi de programmateur ou de synthétiseur de fréquenceainsi que de clock drivers pour alimenter les éléments du système. Or, l’un des problèmes majeursdans les systèmes reconfigurables, est la génération de signaux d’horloges qui doivent s’adapterde manière très rapide afin de ne pas compromettre l’exploitation de la reconfiguration. Eneffet, la difficulté majeure reste le moyen d’avoir un temps de stabilisation d’une synthèse defréquence inférieure au temps mis pour reconfigurer le système au cours d’une étape. Dans lecas contraire la rapidité de traitement sera fonction de la vitesse à laquelle l’horloge est obtenue.C’est à dire que la durée des traitements est tributaire du temps de stabilisation du réseau dedistribution de signaux d’horloge. Il faut donc trouver un moyen pour que le temps de stabilisationd’une fréquence soit inférieure au temps de reconfiguration de l’étape considérée. De plus,la conception d’un système reconfigurable doit prendre en compte les retards, les phénomènesde propagations et de déformations que peuvent subir les signaux d’horloges entre les différentsmodules synchrones d’un système. Par conséquent la distribution de tel signaux doit faire l’objetd’une étude rigoureuse pour ne pas tomber dans les limitations en fréquence de fonctionnementdu système. Actuellement, outre un réseau fiable de distribution d’horloge, la meilleure solutionpour éviter ce problème consiste à utiliser des méthodes de synthèse de fréquence interne enexploitant des macro multiplieur ou diviseur de fréquence à partir d’une fréquence de référence48

2.2. Les Architectures pour la Reconfiguration Dynamique[Les99].2.2.6 ConclusionLes systèmes reconfigurables, fondés et conçus sur l’évolution des FPGAs, sont des systèmesnumériques qui possèdent une structure matérielle non figée dans laquelle une redéfinition ducircuit est possible à tout moment. A la différence des machines séquentielles classiques, ellesproposent une programmation dynamique de portes logiques (ou processeurs élémentaires) permettantde construire une infinité d’architectures sur un même support physique. Ainsi, une ouplusieurs architectures spécifiques peuvent être câblées et s’activer en fonction des besoins. Grâceà la logique reprogrammable, l’idée d’un système modifiant et optimisant son architecture enfonction d’une application donnée ou d’un algorithme particulier se concrétise et prend forme.A travers une description succincte caractérisant les systèmes reconfigurables, on perçoit quele concept de reconfiguration est d’autant plus important que la partie reconfigurable est prochedu microprocesseur et parfois même constituée de microprocesseurs. En effet, associé à ce niveaude couplage, les systèmes reconfigurable peuvent être classés selon différentes formes defonctionnement dynamique. La reconfiguration devient alors un élément clé, voire critique, pourexploiter efficacement ce type d’architecture. La figure 2.25 résume, suivant les modes de reconfigurations,les besoins en terme de reconfiguration des trois types d’architectures reconfigurablesénumérés précédemment.Fig. 2.25 – Principales plates-formes d’application du calcul reconfigurableUn accélérateur reconfigurable est en général configuré une fois, au début de l’application.A l’inverse, une architecture à base d’unités reconfigurables l’est en permanence en cours dereconfiguration. Le co-processeur reconfigurable se situe entre ces deux alternatives.Nous avons vu que de multiples architectures reconfigurables existent. La plupart à montréeque sur un bon nombre d’applications les performances obtenues étaient très honorables.En plus des besoins technologiques (temps de reconfigurations courts, faible latence descommunications et accès mémoire par un degré élevé de couplage), d’autres besoins doivent49

Chapitre 2.État de l’artêtre pris en considération. En particulier certaines spécifications architecturales en considérantles applications visées. En effet, l’étude d’algorithmes caractéristiques de la classe d’applicationvisée est primordiale dans une démarche d’adéquation algorithme-architecture. Car les systèmesreconfigurables visent rarement une seule application. Ils possèdent une architecture matériellefigée qui est dédiée à une catégorie d’applications aux besoins similaires : puissance de calcul,type et nombre de mémoires. Celle-ci est ensuite spécialisée pour une application particulière,par le chargement de données de configuration dans les composants logiques reprogrammables.C’est pourquoi, la mise en oeuvre de la reconfiguration dynamique sur un système nécessite desconnaissances et une étude préalable du champ d’application visé.Cependant cette idée de modifier la structure du circuit au cours de l’exécution des calculs,pose un certain nombre de problèmes dont les solutions sont à la fois d’ordre matériel et logiciel.Au niveau matériel plusieurs solutions technologiques et architecturales existent ou sont proposéespour la mettre en oeuvre. Nous avons présenté plusieurs d’entre elles pour mettre en oeuvrela reconfiguration dynamique. Par contre au niveau méthodologique et outils de conception intégrantla reconfiguration dynamique les avancées sont beaucoup plus récentes. En effet, il y aune insuffisance des outils de développement. Les plus classiques, n’apportent rien à la gestionde la reconfiguration dynamique. Car, les outils sont encore trop liés à l’approche conceptionASIC. Des outils dédiés aux architectures reconfigurables ont également fait leur apparitionmais ne sont valables que pour une architecture précise. On constate alors que la mise en oeuvrede la reconfiguration dynamique est à l’initiative du concepteur, puisque les outils proposésne prennent pas en charge la mise en oeuvre et la gestion de la reconfigurabilité. La prise encompte de la reconfiguration dynamique de manière transparente par les outils suppose la miseau point de nouvelles méthodes. C’est pourquoi, tout en s’attachant à l’évolution technologiqueil est intéressant de réfléchir sur une méthodologie d’implantation en reconfiguration dynamiqueen s’assurant que celle-ci puisse s’adapter à l’évolution technologique. Nous avons détaillé lesdifférentes formes temporelles et spatiales que peut avoir l’étape de partitionnement en reconfigurationdynamique. Cette dernière consiste en un découpage de l’architecture à implanteren partitions et à les répartir selon un séquencement ou un ordre dépendant de l’algorithme.Cette phase de décomposition pour effectuer des étapes reconfigurées est primordiale pour uneimplantation optimisée et judicieuse d’une application en RD. La difficulté principale est d’optimiserl’utilisation des ressources matérielles. Car, en général, selon les objectifs que l’on s’estfixé (minimisation du temps de calcul, des ressources, de la bande passante mémoire nécessaireou de la consommation du circuit), c’est une étape qui n’est pas toujours optimisée.Le développement d’une méthodologie du calcul reconfigurable est étroitement lié à la structuredes architectures reconfigurables. C’est pourquoi le développement d’une méthode pourréaliser la reconfiguration dynamique devra tenir compte des caractéristiques et des contraintesdes surfaces logiques cibles. Il s’agira alors d’extraire automatiquement les sections critiques50

2.2. Les Architectures pour la Reconfiguration Dynamique(data-path) et de réaliser leur implantation par une description matérielle faisant appel à lareconfiguration dynamique. Cette phase peut s’apparenter à une technique de compilation pourune architecture reconfigurable. Cependant, elle ne peut aboutir sans l’élaboration d’une méthodologied’implantation RD. Cette approche permet de poser des problèmes d’optimisation pourdimensionner au mieux les implantations.Dans notre cas il s’agira de savoir comment exploiter la reconfiguration dynamique pour lessystèmes embarqués. Plusieurs questions doivent alors être soulevées. Quel(s) critère(s) ou quelleméthode utiliser pour arriver systématiquement à un partitionnement en RD de l’algorithme àimplanter ? Dans ce cas comment et à quel niveau de description doit être réalisée la décompositiondes algorithmes à implanter en RD afin d’optimiser l’adéquation existant entre architectureet algorithme ? Des réponses permettront de situer l’emploi de la reconfiguration dynamique visà vis d’autres méthodes de conception de système.51

Chapitre 2.État de l’art2.3 Nécessité d’un partitionnement optimalDans l’optique d’adresser la mise en oeuvre de systèmes supportant la reconfiguration dynamique,et plus particulièrement les systèmes à base de FPGAs, nous nous devons de définirun certain nombre de critères d’optimisation des futures architectures/implantations. En effet,quelque soit la tâche pour laquelle la reconfiguration dynamique est envisagée, celle-ci va subirun bouleversement important par rapport à une implantation classique et statique. Le résultatdu traitement doit être identique au final. Mais le fonctionnement est plus complexe et va requérirun certain nombre de précautions. Ces précautions aurons pour but de faire en sorte que legain apporté par la reconfiguration dynamique ne se paie pas au prix fort en terme de ressourcesexternes à la surface logique reconfigurable.Au delà même de ces ressources, l’utilisation de la reconfiguration dynamique sous contraintede temps peut nécessiter une augmentation de la fréquence de travail qui va automatiquementaugmenter la puissance électrique nécessaire de l’application. Cette augmentation en fréquenceest étroitement liée au nombre de reconfigurations envisagé et à la sévérité de la contrainte detemps que doit respecter le traitement des données.La reconfiguration dynamique a pour ambition d’améliorer l’efficacité des systèmes logiques,mais cette amélioration ne doit pas se faire au détriment des composants annexes.Pour cela, il est nécessaire de distinguer le cas de la conception d’un circuit supportantla reconfiguration dynamique du cas du développement d’une application sur une architectureexistante supportant la reconfiguration dynamique. Nous allons donc étudier cela dans les partiessuivantes.2.3.1 Aspect ”Conception de circuits”Lors de la conception d’une architecture destinée à recevoir une application particulière,l’idée d’ajouter le support de la reconfiguration dynamique peut être guidée par bien des raisonsdifférentes, et principalement par une réduction de la surface logique nécessaire à la futureapplication. Dans ce cas, la surface logique de la future plateforme (carte de développementou SOC) doit être calculée de sorte à assurer le bon déroulement de cette application, de sesreconfigurations successives, offrir une bande passante suffisamment élevée vers l’extérieur dela plateforme ou vers les mémoires externes à la partie reconfigurable, etc. Nous pouvons doncrésumer l’optimisation de la future application ainsi que de la plateforme l’accueillant commeune minimisation globale de toutes les ressources nécessaires à la plateforme : surface logiquereconfigurable, mémoires tampons, bande passante mémoire, consommation électrique, etc. Cetteoptimisation sur différents critères ne peut se faire sans une vue globale de l’application ainsique des ressources logique qui vont accueillir cette application. Connaissant ceux-ci, il seraalors possible de calculer les possibilités envisageables et mesurer l’impact de la reconfiguration52

2.3. Nécessité d’un partitionnement optimaldynamique sur les besoins de la plateforme.2.3.2 Aspect ”Développement d’applications”Contrairement au cas précédent, nous considérons ici l’implantation d’une application surune plateforme préexistante. Il est donc inutile de chercher à minimiser à la cellule près lesbesoins en logique reconfigurable puisque ce paramètre est fixé par avance (contrainte de surfacelogique fixe). Par contre, dès lors qu’un partitionnement satisfait à la taille disponible, le but estalors de minimiser les autres critères caractéristique de l’application.53

Chapitre 2.État de l’art2.4 Méthode et outils de partitionnement pour la ReconfigurationDynamiqueToutes les architectures présentées précédemment ne peuvent obtenir de bons résultats lorsde mises en pratique sans le support d’outils adaptés à leurs spécificités. La possibilité de modifierla structure de traitement à différents moments, s’adapter à différentes contraintes, évoluer enfonction des besoins ne se fait pas sans une augmentation de la complexité de mise en oeuvre.Les méthodes et outils adaptés à ces nouveaux besoins ont donc une importance capitale :permettre une mise en oeuvre aisée et performante de la reconfiguration dynamique de sorte àamener cette souplesse et cette puissance de calcul des milieux de recherche où elle est née, aumilieu industriel. Lors des premiers travaux sur les architectures reconfigurables, seul l’aspectpuissance de calcul et reconfigurabilité était prédominant. Puis, face à la lourdeur de mise enoeuvre, l’idée de concevoir des outils dédiés a fait son chemin. Aujourd’hui, non seulement ladualité plateforme de développement / outil dédié est évidente, mais les architectures qui sontpensées et élaborées en ce moment même, le sont conjointement à leurs futurs outils de miseen oeuvre. Cette prévision en amont des outils est une voie qui devrait permettre d’atteindrede bien meilleurs résultats en matière de conception conjointe lors de l’exploitation futur desplateformes. Cela permet également une mise en oeuvre plus rapide des premiers prototypes.La suite de ce chapitre présente les différentes méthodes et outils destinés à la mise en oeuvrede la reconfiguration dynamique, ainsi que le cadre de nos travaux et la présentation de notrecontribution à ce domaine.2.4.1 Revue critique2.4.1.1 Programmation des réseaux reconfigurables grain épaisLe mode de programmation des réseaux reconfigurables est grandement dépendant de leurstructure et de leur granularité, et diffère par le niveau du langage de programmation. PourMATRIX, et REMARC, la programmation se fait au niveau assembleur. Certaines de ces architecturesoffrent au concepteur un outil graphique de placement et routage manuel. D’autresoffrent un flot de conception automatique depuis une description HDL ou autre langage hautniveau. Les environnements diffèrent par leur approche de la technologie de mapping, de routageet de placement. La technologie de mapping est beaucoup plus simple pour les architectures grosgrains que pour les FPGAs. Les approches sont :– un mapping direct, où les opérateurs sont mappés directement sur les processeurs élémentaires,avec un processeur élémentaire pour chaque opérateur.– utilisation d’une librairie additionnelle de fonctions qui ne sont pas implémentées directementpar un processeur élémentaire.54

2.4. Méthode et outils de partitionnement pour la Reconfiguration Dynamique– des processus d’ajustement plus sophistiqués capable de réaliser plusieurs opérateurs surun seul processeur élémentaire (grâce aux outils pour FPGAs modifiés/Générateurs demacros).Le compilateur de RAW fait exception à cela. Il réalise un partitionnement puisque son processeurélémentaire est un coeur RISC.Pour le placement des opérateurs, l’architecture a un impact important. GARP utilise un algorithmed’ajustement par arbre.L’utilisation d’algorithmes plus gourmands est uniquementenvisageable pour des réseaux linéaires (PipeRanch), ou pour des réseaux de communicationhaut niveau (RAW).Le routage est également fait suivant différentes approches. Dans plusieurs cas, le routage n’estpas fait dans une phase supplémentaire mais intégré dans la phase de placement et fait à lavolée. Une première approche (KressArray) utilise un algorithme simple de connexion avec leplus proche voisin. Un autre (RAPID) utilise l’algorithme pathfinder [Ea95] développé pour leroutage des FPGAs.Programmation en assembleur :la programmation des architectures à grain épais en assembleurest comparable au code de configuration des FPGAs.Outils pour REMARC : l’outil de programmation permet une programmation concurrentedu processeur RISC (en C) et du réseau reconfigurable en ajoutant des instructions assembleurà REMARC. Le compilateur génère alors le code assembleur du processeur RISC incluant lesinstructions spécifiques de REMARC.2.4.1.2 Mapping de type FPGAsles algorithmes pour le mapping des FPGAs sont bien connus (VPR [BR97], PathFinder[ME95], etc.[SR99, CD00, ZCW00, LS88]) et peuvent souvent être utilisés directement pourles architectures à grain épais comme CHESS, Colt, KressArray, RaPiD. La qualité du placementet du routage ont un impact massif sur les performances de l’application. Mais grâce aufaible nombre de processeurs élémentaires, cette tâche est beaucoup moins complexe pour cesarchitectures que pour les FPGAs et la complexité de calcul se voit diminuée de façon drastique.DPSS : (DataPath Synthesis System)[HK95] génère le code de configuration pour les premièresversions du KressArray. Il est capable d’utiliser un sous-ensemble du code C.55

Chapitre 2.État de l’artKressArray Xplorer : le KressArray Xplorer [HHHN00, Kreb] est un explorateur de plateformereconfigurable ainsi qu’un outil de mapping supportant la famille de circuits reconfigurablesKress Array. Il intègre les outils auparavant disponible dans DPSS tout en y ajoutant denombreuses fonctions pour répondre aux nouvelles possibilités de la famille KressArray complète.Le KressArray Xplorer fournit :– Une exploration des performances des différents composants KressArray pour une applicationdonnée.– Un compilateur transformant le code C en graphes acycliques– Une estimation de l’architecture minimale nécessaire pour l’application donnée.– Un mapper pour le KressArray– Un ordonnanceur optimisant les transferts de données vers et depuis le KressArray.– Un analyseur dont le rôle est de mettre en évidence les goulots d’étrangelement.– Un éditeur permettant la modification manuelle des opérations réalisées précédemment(optimisations, mappage, etc.)– Un générateur/simulateur HDL (génération de code Verilog) une fois l’architecture duKressArray définie.– Un ”Générateur de Modules” pour le rDPU fait partie des projet.Colt : les outils pour Colt acceptent une description de type flot de données pour un placementutilisant un algorithme génétique et un routage par un algorithme glouton(greedy). L’entête duflot de données comporte les données de configuration et de routage des fonctionnalités desprocesseurs élémentaires rencontrés.RaPiD : la programmation est réalisée grâce au langage RaPiD-C, un langage dérivé dulangage C auquel ont été ajoutées des extensions (comme un mécanisme de synchronisation,l’identification de la première et de la dernière itération d’une boucle). Il permet de spécifierexplicitement le parallélisme, les mouvements de données et leur partitionnement.CHESS :un compilateur a été implémenté acceptant les sources J. H. D. L.. Ce compilateurgénère la netlist de CHESS.2.4.1.3 Autres approchesOutils pour NAPA : Le NAPA C [GS98] est un langage C ainsi qu’un compilateur pourl’architecture NAPA. Le langage NAPA C utilise des directives pragmatiques pour spécifier lanature des variables (software (FIP) ou registre FPGA(ALP) ainsi que l’endroit où seront effectuésles calculs (exécution logicielle sur le FIP ou chemin de données sur l’ALP). Le compilateurNAPA C réalise une analyse sémantique du code ainsi annoté et va générer conjointenement56

2.4. Méthode et outils de partitionnement pour la Reconfiguration Dynamiquele code exécutable du processeur combiné au bitstream de la partie logique reconfigurable.Lesoptimisations du compilateur incluent notamment des déroulements de boucles.La compilation du code C destiné au processeur RISC est sous-traitée pas le compilateurSUIF [Wa94]. La synthèse de la partie FPGA est pour sa part traitée par l’outil de synthèse dechemins de données MARGE [GKMK96].NAPA C supporte l’exécution de chemins de données réguliers sur l’ALP et le compilateurreconnait les ”fonctions ALP” comme de nouvelles instructions pour le processeur RISC.Outils pour GARP : GARP utilise un compilateur C basé sur SUIF [Wa94] pour générerle code pour le processeur MIPS hôte. Ce code contient les données de configuration pour lasurface reconfigurable. L’outil propriétaire Gamma [CW98] réalise le mappage du graphe flôt dedonnées sur GARP. Après optimisation, les données de configuration de la surface reconfigurablesont assemblées est liées au code objet C du processeur hôte.Outils pour RAW : Les outils pour RAW incluent un compilateur C basé sur SUIF ainsique des mécanismes d’ordonnancement dynamique temps réel comme les prédictions de branchements,les caches de données, les exécutions spéculatives, l’ordonnancement dynamique du code.Le compilateur s’acquitte des tâches d’allocation des ressources, exploitation du parallélisme,ordonnancement des communications, la génération du code. Le projet RAW recherche plus unfonctionnement parallèle qu’un fonctionnement reconfigurable et ne parvient pas à trouver unbon algorithme de mapping automatique [Nag01].Outils pour PipeRench[Ga99, BG99] : l’outil pour PipeRench utilise le langage DILSingle-Assignement Language (SAL) comme point d’entrée. Le compilateur commence par alignerles modules, dérouler les boucles, et générer un programme séquentiel (straight-line SAprogram (SAP)). Après optimisation et après avoir découpé ce programme en morceaux quitiennent sur les différentes tuiles de PipeRench, un algorithme de placement routage est exécuté.C SIDE : les outils de développement pour la famille d’architecture Chameleon CS2000 [Eur]incluent un compilateur C GNU pour le processeur hôte RISC, un synthétiseur HDL pour lapartie reconfigurable, un simulateur, un debugger de type C ainsi qu’un vérificateur. eBIOS(eConfiguration Basic I/O Services) est une sorte de système d’exploitation, servant d’interfaceentre le processeur RISC et la surface reconfigurable. C Side est plus une boîte d’outils qu’unco-compilateur.Aucune information n’est disponible quant à la compilation ou mappage d’applications pour57

Chapitre 2.État de l’artFIPSOC.2.4.1.4 Mappage temps réelDes composants (comme le Virtex de Xilinx, la partie reconfigurable de l’architecture CS2000de Chameleon et d’autres encore) sont reconfigurable dynamiquement. Une telle caractéristiquemodifie considérablement les possibilités d’optimisation d’une application au moment de saconception. En dehors des deux circuits énoncés précédemment, l’aide apportée aux concepteursà ce moment-là reste extrêmement faible.2.4.1.5 Exploration de l’espace de conceptionCertains environnements de développement ont pour but unique la compilation. Le butdes DSEs (design space explorers) est de choisir ou de proposer une ou plusieurs solutionspour optimiser différentes contraintes pour l’application finale ou pour son implantation sur uneplate-forme existante. Les systèmes d’aide à la conception sont des DSEs interactifs donnant desconseils pendant l’écoulement du flot de conception. Un certain nombre de DSEs évitent l’étapede génération et fournissent seulement des prévisions à partir d’une base de données (librairie).Les DSEs non-interactif produisent automatiquement une solution basée sur la connaissance decertaines règles.Design Space Explorers(DSEs) : les assistants interactifs de conception les plus connussont DPE, Clio (pour les VLSI) et DIA. Incluant un prédicateur d’effets ainsi qu’un générateurde propositions, DPE (Design Planning Engine) [Ka91] (employant un système expert),Clio [La92] (utilisant une hiérarchie de modèles) et DIA (Datapath-Intensif ASICs ) [Ga98](visant le niveau comportemental semi-custom d’ASIC et basé sur la connaissance experte encapsulée),produisent un flot de conception sous forme schématique, un graphe flot de données,ou un layout à partir de spécifications de surface, période de fonctionnement, puissance électriqueet d’autres contraintes. Il permet ainsi une amélioration des critères de surface, consommationélectrique, etc.DTSE. Pour les systèmes manipulant de larges données, les optimisations locales habituellesconduisent à une dégradation des performances de l’exécution souvent du fait de conflits d’accès.L’augmentation de la puissance consommée par les circuits à été estimée entre 10 et 100%.L’augmentation de la fréquence de fonctionnement des logiciels a pour sa part été estimée auxalentours de 35% [Va, Oa99]. Pour une exploration globale, l’utilisation d’un ordonnancementdirigé par les conflits (conflict-directed ordering (CDO)) [Wa99] a été proposée [Ca] commeune extension de l’établissement forcé de l’ordonnancement (force-directed scheduling (FDS))58

2.4. Méthode et outils de partitionnement pour la Reconfiguration Dynamique[Pa89]. Au lieu de travailler sur un graphe de flot des signaux d’accès (SAFG)[Wa99], un graphiquemultidimensionnel des conflits (MD-CG.) est employé pour généraliser l’algorithme CDO(G-CDO) pour l’exploration des transferts et stockages de données (Data Transfert and StorageExploration (DTSE)) [Na95, Ca98].Platform Space Explorers (PSE) : un PSE sert à trouver une plateforme à surface reconfigurableou à réseau de processeurs optimale pour un domaine d’application en optimisant la taillede ce réseau(/cette surface), la largeur des chemins de données, la fréquence des processeurs, lenombre d’ALUs et d’unités de calcul, la taille des mémoires locales, les données et les tailles descaches d’instruction, la largeur de bande passante locale, la latence d’interconnexion, le tempsde calcul total, la capacité de la mémoire, etc... La programmation/configuration d’application(HW ou SW) n’est finalement pas une partie d’exploration, mais peut servir à l’évaluation de laplateforme.Les trois exemples suivant sont non-interactifs : le DSE [ea] pour RAW [WTS + 97] comportantun modèle analytique, ICOS (Intelligen Concurrent Object-oriented Synthesis) [Ha99] utilisedes techniques orientées objet et logique flou. Enfin, DSEMMP, DSE pour des processeurs multimédia[ea99] (DSE for MultiMedia Processor) vise la synthèse automatique d’une plateformemultiprocesseur en se basant sur des descriptions de système, des contraintes d’exécution,etc.DSEMMP a pour point de départ le partage de la mémoire d’un processeur Intel Strong-ARMSa-110.2.4.1.6 ÉPICUREÉPICURE est une nouvelle méthodologie globale(Fig.2.26) basée sur la coopération dedifférents outils adaptés à la conception de solutions systèmes logiciel/matériel reconfigurableembarqués [ACD + 03].Les points principaux sur lesquels repose ÉPICURE sont :– Un méthodologie de spécification aidant la mise en oeuvre du contrôle du système et desreconfigurations matérielles.– Des outils d’exploration et d’estimation pour le parallélisme et la synthèse architecturale.– Une méthode de partitionnement logiciel/matériel basée sur un algorithme génétique (intervenantsur les délais, la surface et la consommation électrique)– Un modèle d’interfacage dédié (logiciel/matériel) qui permet une abstraction des communicationsentre un processeur standard et un composant reconfigurable.Ce projet est également le fruit d’une collaboration entre différents laboratoires de recherchepublic et privé sous l’égide du Ministère de la recherche (projet RNTL). Ainsi, chacun apporteson expertise dans les différents aspects que regroupe ÉPICURE. 59

Chapitre 2.État de l’artFig. 2.26 – Vue globale de la méthodologie ÉPICUREFlot de conception ÉPICURE : ÉPICURE est basé sur trois étapes distinctes (Fig.2.26).La première étape est la spécification de l’application dans un modèle d’exécution permettantd’adresser le contrôle ainsi que le flot de données afin de pouvoir en tirer les opportunités dereconfiguration et d’accélération matérielles. La spécification est faite grâce à Esterel Studio[Est]. Au niveau de spécification le plus faible, Esterel fait appel à des procédures C.La seconde étape d’ÉPICURE est réalisée par l’outils Design Trotter [MKDP03] qui utiliseles procédures C précédemment citées et en tire la courbe ressources FPGA/Cycles processeur.Ces courbes permettent alors de dégager différentes solutions pour la future implémentation.La troisième étape part d’un ensemble de solutions logiciel/matériel et consiste à choisir60

2.4. Méthode et outils de partitionnement pour la Reconfiguration Dynamiqueune implantation en fonction des contraintes de performance, surface, consommation en tirantavantage de la reconfiguration.Esterel Studio se charge alors de générer le code C de la partie logicielle. Les procéduresréalisées de façon matérielle sont appelées par l’interface ICURE qui contrôle les changementsde configuration du FPGA ansi que les communications logiciel/matériel.Estimation architecturale : Cette estimation se base sur une description HCDFG (Hierarchicalcontrol data flow graph) de l’application. Ce HCDFG se compose de différents HCDFGs etCDFGs eux même composés au plus fin niveau de description de DFGs. Les DFGs représententalors uniquement des calculs ou des transferts de données.Grâce à cette décomposition, différentes métriques sont appliquées aux DFGs afin de lescaractériser (taux de transfert de données/calculs, proportion de test dans l’ensemble des calculs,parallélisme moyen, réutilisation des données). Les résultats de ces métriques sont alors utiliséspour calculer ces mêmes métriques pour chaque niveau de granularité supérieure.Suite à cela, le concepteur peut sélectionner manuellement différentes solutions prometteusespour une implantation logicielle ou matérielle. Il est guidé dans ce choix par les résultats desdifférentes métriques calculées précédemment. Celles-ci lui indiquent alors la pertinence d’unchoix ou d’un autre.Partitionnement logiciel/matériel : Le rôle de cette partie est l’allocation et l’ordonnancementde tâches de sorte à minimiser le temps d’exécution total, tout en prenant en compte lespossibilités de reconfiguration dynamique de l’unité de calcul matérielle.Ce partitionnement est donné par un algorithme génétique. Celui-ci réalise une explorationde l’espace de conception en générant différentes implantations des tâches sur le processeur ainsique sur le FPGA. La solution est évaluée en fonction du temps d’exécution total de l’algorithme.Résultats annoncés : ÉPICURE est une méthode fortement automatisée qui semble obtenirun résultat probant pour peu que le concepteur ait décidé de concevoir une architecture du typeprocesseur/FPGA en utilisant l’interface ICURE. Cela semble donc une très grande avancée dansl’aide à la conception de circuits avec utilisation des possibilités de reconfiguration dynamique.ÉPICURE demeure en développement dans les différents laboratoires participant à ce projet.2.4.1.7 JBitsLe JBits SDK de Xilinx contient un ensemble d’outils et d’API qui permettent la création debitstreams pour les FPGAs Virtex de Xilinx à partir de code Java. Un debugger graphique appeléBoardScope est inclus. Il permet de contrôler l’intérieur du composant lors de son fonctionnement.BoardScope peut également être employé comme simulateur si le matériel est indisponible.61

Chapitre 2.État de l’artJBits permet donc l’utilisation et la réalisation d’applications en reconfiguration dynamique.C’est un outil de développement intéressant qui fourni des classes et méthodes JAVA spécifiquespour le placement, le routage, la reconfiguration. Malheureusement, il n’est d’aucune aide auconcepteur quand à l’évaluation des possibilités offertes par la reconfiguration dynamique.2.4.1.8 MADEOMADEO est une chaîne de CAO générique pour les architectures reconfigurables développéeà l’Université de Brest (Université de Bretagne Occidentale, UBO).Elle a pour objectifs de favoriser la réutilisation d’outils et d’applications (portabilité), le dimensionnementd’architectures pour un jeu d’applications, le choix ouvert d’arithmétiques.Pour cela, elle utilise une approche modulaire : disjonction outils/architectures et applications/plagesde données.Cette partie de MADEO est nommée MADEO FET.MADEO FET : MADEO FET est la partie haut niveau de MADEO. Dans MADEO FET,le code est symbolique, fonctionnel et non typé.Le code est situé dans une classe :– Les opérations portant sur des objets utilisent une évaluation classique– Certaines opérations sont structurantes (appels fonctionnels)Le typage est donc extérieur et le résultat est contextuel.Compilation du code de haut niveau :La compilation respecte l’écriture du code puis des optimisations sont réalisées. Chaqueopération produit un noeud et ces noeuds peuvent être hiérarchiques.Cette hiérarchie peut être manipulée (suivant des annotations ou à la main) en fonction ducontexte.Les optimisations sont classiques : factorisation, suppression de code mort, propagation deconstantes, etc...L’ajout essentiel à ce niveau est l’inférence de type.L’inférence de type propage les types d’entrée, calcule ces types en sortie des opérateurs(d’opérations en opérations). Un type est une énumération de valeurs possibles.Synthèse logique– Chaque noeud connaît sa ”table de vérité”– Les valeurs peuvent être encodées62

2.4. Méthode et outils de partitionnement pour la Reconfiguration Dynamique– On obtient un PLA (Programmable Logic Array) à minimiser– La synthèse logique repose sur SIS (UC Berkeley)[gro]L’objectif de MADEO est de permettre une portabilité transparente. Pour cela les outilsde bas niveaux doivent être à même d’implémenter les circuits optimisés, fournir un retourd’information aux outils précédents, offrir une API stable.Pour répondre à cela, MADEO est équipé d’une partie bas-niveau : MADEO-BET.Madeo-Bet : MADEO-Bet permet de définir une représentation unifiée des différentes architecturespossibles. Il définit également un ensemble d’outils agissant sur cette représentation. Ilgarantit que toute architecture est représentable, que la description de l’architecture reste unprocédé léger et rapide pour la compilation, que les outils sont efficaces (grâce à l’utilisationd’algorithmes reconnus).Un langage de description de la cible permet de décrire les différents éléments de l’architectureainsi que sa représentation.Ces éléments architecturaux sont de deux types :– Structuration hiérarchique (pavage, composite)– Elément atomique (fonctions, canaux, multiplexeurs, référence à des objets déjà décrits,...)Les outils sont définis de manière génériques– Visualisation / Commande– P&R (Lee, PathFinder)– Floorplanning / Tracé régulier– Diverses métriques– Interfaçage matériel– Simulation à différents niveaux– Prospection architecturale.Ces outils se spécialisent en fonction du modèle d’architecture et constituent un cadre ouvert dedéveloppement.Pour la prospection architecturale, il est possible de faire varier les architectures de façon programméeou par des annotations dans le programme. On peut alors déclencher des P&R etcollecter les résultats.Pour conclure, Madeo garantit :– un fort degré de réutilisation des outils.– des temps et coûts de développement réduits.– une portabilité du code source des applications (y compris encapsulant une sémantiquemétier).63

Chapitre 2.État de l’art– une optimisation automatique des circuits.– la prise en charge d’architectures nouvelles / de technologies émergentes (moléculaires,QCA, ...).– la définition d’arithmétiques arbitraires (RAID / reedsolomon GF16, Turbo Code enGF128).Madeo est un cadre de développement ouvert.2.4.2 Analyse des outils et direction de recherche2.4.2.1 Un circuit - un outilLa plupart des outils présentés précédemment sont des outils dédiés à un circuit spécifique.Bien que cette approche permette en générale une meilleure prise en charge des spécificités dechaque circuit, cela demande également un travail supplémentaire aux développeurs qui devrontapprendre à utiliser un nouvel outil pour chaque nouveau type de circuit reconfigurable.D’autres outils, utilisent des solutions basées sur une librairie d’opérateurs pour chaquetechnologie FPGA. Ces outils sont ainsi beaucoup plus génériques et sont en mesure d’adresserdifférents circuits de familles et de constructeurs différents. Cette technique permet également depouvoir intégrer des circuits comportant des unités de calcul plus complexes (ALU, processeurs)dès lors que l’on est en mesure de caractériser les opérateurs mappées sur ces unités de calcul.2.4.2.2 Mise en oeuvreLe support des composants reconfigurables dynamiquement lorsqu’il existe concerne principalementla compilation et/ou le placement routage du circuit. Ainsi, l’utilisateur doit déjà avoirfait ses choix quand à l’utilisation de la reconfiguration dynamique sur son circuit. L’outil arrivealors en fin du processus de développement pour mettre en oeuvre le circuit.Ces outils représentent le support minimum fournis avec les circuits et ne demandent engénéral plus grande réflexion quant aux aspects spécifiques de la reconfiguration dynamique. Ilsemble donc raisonnable de s’appuyer sur ces outils pour les phases d’implantation et de routageet rechercher plus en amont les optimisations qui seront le fruit de la RD à proprement parler.2.4.2.3 Lisibilité - AssistanceL’autre problème rencontré par certains outils automatiques pour les circuits reconfigurablesest le manque de lisibilité des solutions offertes par le composant utilisé. En effet, partant parexemple d’un code C, celui-ci est transformé, optimisé, partagé entre différentes unités de calculreconfigurable ou non, tout ceci sous le contrôle du développeur. Mais cette progression, d’étapeen étape, laisse à l’écart des solutions qui dans certains cas auraient pu être intéressantes au64

2.4. Méthode et outils de partitionnement pour la Reconfiguration Dynamiquefinal. Toutes les optimisations ne vont pas dans le même sens et finissent bien souvent par porterpréjudice à d’autres critères (exemple : fréquence de fonctionnement / consommation électrique).C’est dans ce domaine que nous voulons apporter réellement notre aide aux concepteurs.En effet, nous voulons guider le concepteur dans le processus d’implantation en lui fournissantla plus grande lisibilité quant aux possibilités offertes pas la RD. Cela nécessite une prise encompte globale des conséquences d’un partitionnement sur l’implantation future.65

Chapitre 2.État de l’art66

Chapitre 3Modélisation3.1 Axes de rechercheLa reconfiguration dynamique telle que nous l’entendons et nous l’utilisons généralement estla reconfiguration dynamique sur circuits FPGAs. Nous avons vu dans le chapitre précédent quele calcul reconfigurable était beaucoup plus large que cela. Des circuits spécifiques développésdans un but de recherche et supportant une forme de reconfiguration dynamique ont étés crééset peuvent prendre différentes forme. De la matrice FPGA classique, au réseau d’interconnexionde processeurs en passant par les architectures hybrides disposant de différentes formes d’unitésde calcul, toutes ces approches demandent un savoir faire particulier pour les mettre en oeuvre.Ainsi, même si certains composants commerciaux très répandus permettent la reconfigurationdynamique (exemple : le composant Virtex de Xilinx), cette dernière semble plus présente dansle domaine de la recherche que dans l’industrie.3.1.1 BesoinsNous cherchons à définir les méthodes qui permettent de tirer le meilleur d’une technologieen exploitant ses propriétés de reconfiguration dynamique. Pour cela nous devons être capablede manipuler une représentation de notre application sur une technologie donnée. Il apparaîtdonc nécessaire d’avoir une représentation de l’application ainsi qu’une représentation de latechnologie elle même.3.1.2 Représentation de l’applicationComme nous l’avons signalé en introduction, notre domaine d’étude est principalement letraitement d’image. Nous avons donc à représenter des applications de type flot de données.D’autres domaines que la reconfiguration dynamique modélisent des applications afin d’analyserou modifier certaines de leurs caractéristiques. Les outils de synthèse architecturale par67

Chapitre 3. Modélisationexemple ont besoin d’une représentation des applications qu’elles ont pour but d’optimiser.Pour ces outils comme pour d’autres, la représentation la plus utilisée est le graphe flotde données. Même si toutes n’utilisent pas les graphes flot de données comme point d’entrée,elle l’utilisent très largement pour manipuler les architectures (Gaut [MSHD93, JCM00], Épicure[ACD + 03], etc.). Cette représentation est un graphe dans lequel les noeuds du graphe constituentles opérateurs arithmétiques et logiques, et les arcs du graphe constituent les dépendances dedonnées. Nous avons ainsi une représentation conjointe des données et des traitements qui leurssont appliqués.Cette représentation permet une visualisation simple de l’application, un parcours de l’applicationde façon structurée, une déclinaison des opérateurs en macro-opérateurs ou même entâches. Une telle représentation facilite l’utilisation et la manipulation d’objets et de méthodesinformatiques et permettra une transition facilitée entre une méthodologie et un outil.Divers programmes plus ou moins complexes permettent de transcrire des applications d’unlangage haut niveau ou bas niveau vers des graphes flot de données.Enfin, cette représentation est suffisamment abstraite pour permettre de travailler sur différentstypes d’objets. En effet, même si nous visons en premier lieu les FPGAs, rien ne nousempêche de caractériser une application ainsi représentée sur une matrice de processeurs élémentairespar exemple. La représentation de l’application est alors la même, seule la caractérisationde la technologie est modifiée.Tous ces atouts font du graphe flot de données un choix de représentation judicieux.3.1.3 Représentation de la technologieLa représentation de l’application a pour but de permettre une analyse des possibilités offertespar l’utilisation de la reconfiguration dynamique sur une cible technologique donnée. Lesperformances de l’implantation de l’application dépendent des caractéristiques techniques decette technologie. Ces caractéristiques de la technologie utilisée doivent donc faire l’objet d’unemodélisation afin de nous permettre de prévoir les performances que l’on peut attendre de notreapplication.3.1.4 BilanLe choix qui vient d’être fait concernant la représentation de nos applications, implique quela modélisation de l’application doit se faire par rapport aux éléments constituant le grapheflot de données : les opérateurs et les dépendances de données. Mais la représentation de latechnologie devra également modéliser des caractéristiques plus globales comme sa vitesse dereconfiguration.La modélisation de l’application et de la technologie cible est donc un point primordial68

3.2. Modélisation de L’architectures ciblepour la mise en oeuvre de nos travaux sur le partitionnement d’application en reconfigurationdynamique. En effet, il s’agit ici de concentrer les connaissances nécessaires et suffisantes àl’évaluation correcte des performances d’une application, ou d’un morceau d’application. Cettemodélisation doit permettre une caractérisation suffisamment précise de la future applicationsans pour autant nécessiter les longues tâches de placement et de routage de l’application.Dans ces conditions, il est nécessaire d’extraire les paramètres essentiels à la caractérisationde l’application et de l’architecture cible. Ce sont ces paramètres et la façon dont nous lesobtenons/calculons qui vont être présentés ici.3.2 Modélisation de L’architectures cibleAfin de définir les besoins d’une application lors de son implantation sur un matériel quelconque,il est nécessaire de caractériser le matériel ciblé. En effet, c’est de cette caractérisationde la technologie que sera issu la caractérisation de l’application. Il est ainsi important de savoirquelles quantités de ressources logiques seront nécessaires à l’implantation des opérateurs élémentairesconstituant notre application, les performances en matière de temps d’exécution, detemps de reconfiguration, atteinte par cette technologie dans le but d’en tirer le meilleur pournotre future application.3.2.1 Justification de la cible FPGANous avons vu que le choix d’une technologie est primordial si l’on souhaite réaliser la reconfigurationdynamique dans de bonnes conditions. C’est à dire en assurant le meilleur rendementpossible par une minimisation des ressources d’implantation qui est une étape primordiale pourla conception de système embarqué. Aujourd’hui nous trouvons d’un côté des circuits aux capacitésd’intégration très grandes, qui utilisent le silicium principalement pour implanter desressources de calcul et de mémorisation, tels que le Stratix. De l’autre, on découvre des composants,comme l’AT40K, l’AT6000 ou le XC6200, qui offrent des fonctionnalités destinées àfaciliter l’exploitation de la reconfiguration dynamique, au détriment de la surface allouée auxressources logiques de calcul [Xil96, Atm, ATM99b]. La force de ces circuits de petite taille(environ 50000 portes logiques élémentaires), réside dans leur vitesse de programmation et leurpossibilité de reconfiguration partielle. Mis à part ce nombre restreint de FPGA, la majoritéd’entre eux possède des vitesses de configuration relativement faibles, et n’autorise que la reconfigurationdynamique totale du circuit (XC4000, Apex, etc.). Le XC6200 et l’AT6000, avec leClay de National Semiconductor (FPGA très proche de l’AT6000) sont les trois circuits FPGApionniers de la reconfiguration dynamique partielle [Nat93, Xil96, ATM99a]. Le premier reposesur un accès aléatoire à la mémoire de configuration interne avec bus d’adresses et bus de données(FASTMAP). Les seconds mettent en oeuvre une simple liaison parallèle sur laquelle transitent69

Chapitre 3. Modélisationadresses et données à haut débit. L’AT40K (circuit plus récent) reprend ces deux techniques,puisqu’il supporte la reconfiguration dynamique partielle quel que soit le mode de programmationchoisi. De plus, l’ensemble de ces circuits, conçus pour la reconfiguration dynamique, ont desvitesses de reconfiguration plutôt élevées par rapport à la majorité des FPGAs disponibles deleur génération. Il y a deux raisons à cela. La première est qu’ils disposent d’une grande largeurd’accès à la RAM de configuration et la seconde est qu’ils permettent une fréquence d’écrituredans la RAM de configuration élevée. Par exemple le XC6200 de Xilinx dispose d’une largeur de32 bits pour une fréquence d’écriture de 16,66 MHz. Tandis que l’AT6000 de Atmel possède unelargeur de 8 bits pour une fréquence de 12,5 MHz. Quand à la série AT40K du même fabricantelle dispose d’une largeur de 8 ou 16 bits avec une fréquence de 33 MHz (vitesse de configurationproche du XC6200). Actuellement le XC6200 et le Clay ne sont plus disponibles. Tandis quel’AT6000 possède une vitesse de reconfiguration deux fois moins rapide que la famille AT40K dumême fabricant. C’est pourquoi, le choix de la technologie cible pour réaliser nos implantationss’est porté au départ sur l’AT40K, circuit disponible sur la plateforme ARDOISE dont nouspossédons une version.Tab. 3.1 – Vitesses et possibilités de reconfiguration de certains circuits FPGAFamille de circuits Exemple de Tailles Possibilité de Vitesse de reconfig. Délai de reconfiguration.circuit (Portes) RD partielle en Mportes/s (ms)XC4000 (XILINX) XC4044XL 45600 Non 0,59 73,55Virtex (XILINX) XCV200E 63504 Oui 23,81 2,67Apex (ALTERA) EPFK20K100 53248 Non 7,39 7,21AT40K (ATMEL) AT40K40 45000 Oui 83,39 0,54La famille Virtex permet également la reconfiguration dynamique partielle. Cependant,contrairement à ce qui avait été fait pour le XC6200, Xilinx n’a pas mis l’accent sur cettetechnique et la considère plutôt comme une possibilité. De plus sa vitesse de configuration estmoins rapide que celle de l’AT40K. Par conséquent, si nos premier travaux se sont portés exclusivementsur la technologie Atmel, nous avons ensuite caractérisé la technologie Virtex afin demontrer le caractère générique de notre méthode.La suite de ce chapitre présente donc en détail la modélisation de la technologie AT40K. Lesrésultats sont présentés en même temps que ceux obtenus pour la technologie Virtex mais lesdétails sur Virtex ne sont pas exposés par soucis de clarté.3.2.2 Modélisation et détermination des paramètres technologiquesIl s’agit de déterminer, à partir de la technologie utilisée, les paramètres t max , K m , V c ainsiqu’une évaluation de la consommation en ressources logiques des principaux opérateurs arithmétiqueset logiques utilisés dans la majorité des chemins de données. t max est le temps d’exécution70

3.2. Modélisation de L’architectures ciblede l’opérateur le plus lent de l’algorithme. K m est la valeur moyenne liée à un taux d’occupationconstant pour chaque étape. V c et la vitesse de reconfiguration.3.2.2.1 Evaluation de la vitesse de reconfiguration - Temps de reconfigurationLa vitesse de reconfiguration est exprimée en surface logique par unité de temps. En pratiqueelle est proportionnelle à la fréquence de reconfiguration et au nombre de cellules logiques dans leFPGA. Nous exprimons, pour une technologie donnée, la vitesse de reconfiguration par l’équationsuivante :V C = C maxT G(3.1)C max est le nombre de cellules logiques dans le FPGA. T G est le temps pour reconfigurerglobalement le FPGA. Chaque durée de configuration dépend de la quantité utilisée de celluleslogiques pour chaque étape. Nous exprimons la surface en terme de cellules logiques du FPGAutilisé (Cells). Nous définissons C j comme le nombre de Cells nécessaire pour la jème étape.Dans notre cas, la capacité de 819 Cells de l’ AT40K20 conduit à un temps de reconfigurationtotal inférieur à 0.6 ms à 33MHz avec 8 bits de données de configuration [Atm]. Nous obtenonspour la vitesse de configuration une valeur d’environ 1365 cell /ms. Ainsi, nous pouvons évaluerle temps de configuration de la jème étape par :T RECj = C jV C(3.2)Dans notre cas, la technologie AT40K utilisée permet de réaliser de la reconfiguration totaleou partielle. Il en est de même pour la technologie Virtex, sous certaines contraintes tout demême : le plus petit élément reconfigurable partiellement est une frame de largeur 1bit et de lahauteur total du composant. Dans la pratique, il est donc nécessaire de reconfigurer l’ensembled’une ”master frame” (colonne complète de l’architecture Virtex). La reconfiguration partielleoffre la possibilité pour chaque nouvelle configuration de générer les données de configurationlimitées aux ressources exploitées (Cells). En effet, le nombre de données de configuration dépendde la quantité des ressources utilisées. En pratique, pour chaque implantation, le fichier deconfiguration et sa taille sont obtenus par l’outil de développement. Dans notre cas, à traversles outils Compress Bitstream, Windowed Bitstream, les fichiers de données de configurationgénérées sont limités aux ressources exploitées pour une ou plusieurs implantations successives.Le temps de configuration d’une implantation dépend alors de la taille du fichier de configuration.C’est pourquoi, le temps de reconfiguration T RECj d’une implantation sur un circuit donné peutêtre également obtenu par la relation suivante :T REC = N BF C(3.3)71

Chapitre 3. ModélisationN B est le nombre de données de configuration d’une implantation (taille du fichier de configuration(bitstream) en nombre de bits) et F C est la fréquence de configuration ou de chargementdes fichiers de configurations.3.2.2.2 Evaluation des ressources nécessaires pour les opérateursL’étude de la structure des cellules logiques de la technologie utilisée permet l’évaluationdu nombre de cellules nécessaires pour réaliser chaque opérateur du GFD. Nous décrivons cidessousune évaluation de différents opérateurs avec la technologie Atmel AT40K. Mais avantcela, dans un premier temps, nous décrivons la structure des cellules logiques pour ensuitepouvoir préciser comment nous évaluons les opérateurs. Les FPGAs sont généralement bienadaptés aux opérateurs pipelinés complexes qui s’organisent sous la forme de traitements sur unfaible nombre de bits (calcul arithmétique, logique, etc.). En général, ils possèdent des LUT à 4entrées/1 sortie, qui sont bien adaptées à l’implantation d’opérateurs à faible nombre d’entréesmais au séquencement complexe. Par contre au delà de quatre variables d’entrée, l’opérateur seretrouve éclaté sur plusieurs cellules et souffre de cet éparpillement. Plusieurs cellules sont alorsutilisées pour implanter l’opérateur et des ressources de routage externe sont nécessaires, ce quiaura pour conséquence d’augmenter les temps de propagation.Le FPGA AT40K possède des cellules logiques constituées par deux générateurs de fonctionsayant chacun trois entrées indépendantes (figure 3.1). Les générateurs de fonctions ne sont autresque des mémoires LUT de 1 bit sur une profondeur de 8. Ces deux LUT à 3 entrées et une sortiepeuvent être vues comme une seule LUT à quatre entrées et une sortie [Atm]. A partir de cestables, n’importe quelle fonction booléenne de quatre variables peut être réalisée. Elles sontaussi dotées de générateurs de retenue rapide. Ceux-ci permettent d’augmenter efficacementles performances et optimise l’implantation des additionneurs, soustracteurs, accumulateurs,comparateurs et compteurs. Chaque cellule possède une seule bascule formant ainsi la partieséquentielle. Les deux sorties de ces LUT peuvent être multiplexées vers une bascule D. Cesbascules sont indispensables à un bon taux de pipeline, synonyme en général d’une accélérationdes traitements (figure 3.1).Le réseau de routage a un rôle stratégique, parfois plus encore que la structure des cellules.En effet, il irrigue la matrice de cellules logiques, dans les directions horizontales et verticalesavec les signaux à traiter. Il doit à la fois être dense et rapide. Le réseau de routage de l’AT40Krepose sur plusieurs niveaux hiérarchiques de routage [Atm]. On trouve un réseau pour leslongues distances entre les secteurs (un secteur correspond à une matrice de cellules 4 2 ) et unautre réseau pour les liaisons proches. Enfin, un réseau de bus local relie toutes les cellules d’uneligne ou d’une colonne appartenant au même secteur. Ce réseau permet des communicationsbidirectionnelles directes avec les huit cellules voisines, utiles pour propager des retenues d’une72

3.2. Modélisation de L’architectures cibleFig. 3.1 – Illustration de la structure d’une cellule logique de la technologie ATMEL l’AT40Kcellule à sa voisine ou implanter des multiplieurs. L’ensemble de ces lignes qui quadrillent lecircuit horizontalement et verticalement, sont régulièrement découpées par des répéteurs quiconnectent ou non les segments entre eux.Le coeur des cellules AT40K peut être configuré en plusieurs modes (figures 3.2). Ces différentesconfigurations permettent de réaliser différents opérateurs dont nous évaluons l’implantationde la manière suivante (tableau 3.2) : Un opérateur cascadé (additionneur, soustracteur,etc.) D bits, nécessite D Cells (D+1 pour un opérateur synchronisé pour la mémorisation d’uneretenue). Le même nombre de cellules est nécessaire pour un opérateur non cascadé D bits (multiplexeursynchronisé ou non, un registre de synchronisation, fonction booléenne, etc.). En effet,comme pour les additionneurs et les soustracteurs, les cellules logiques de l’AT40k permettentde traiter un bit (avec ou sans mémorisation) ou de mémoriser un bit, la taille en nombre decellules requises sera donc égale au nombre de bits des opérandes.L’évaluation que nous proposons est valable uniquement pour les traitements de type cheminde données et non des traitements de type contrôle. Nous avons réalisé une estimation de certainsopérateurs arithmétiques et logiques sur la technologie Xilinx. Cette dernière utilise une structurede cellule logique différente de celle de Atmel. Pour le Xilinx, l’élément de base est le CLB(Configurable Logic Bloc). La figure 3.3 montre la structure d’un CLB Xilinx.A partir de la structure d’un CLB, nous estimons les ressources et performances des opérateurs.Pour les circuits Virtex de Xilinx, chaque CLB contient 2 slices soit quatre LUT à quatre73

Chapitre 3. ModélisationFig. 3.2 – Les différents modes de configuration d’une cellule logique AT40KTab. 3.2 – Estimations des ressources d’ opérateurs logiques et arithmétiques avec la technologieAT40KOpérateur D bits synchronisé Nombre de cellulesMultiplication ou division par 2k 0Additionneur ou soustracteur D+1MultiplexeurDComparateur 2.DValeur absolueDRegistre de synchronisation supplémentaireDentrées. C’est à dire que pour réaliser un même opérateur tel qu’un multiplexeur 4 bits, il faututiliser 4 cellules pour Atmel et seulement 1 CLB pour Xilinx. Le tableau 3.3 montre des estimationsdes ressources nécessaire à la réalisation d’opérateurs logiques et arithmétiques avec lestechnologies Virtex.3.2.2.3 Estimation des performances des opérateursLe temps d’exécution d’une étape dépend à la fois du temps d’exécution maximal de l’opérateurmis en oeuvre et du routage entre les différents opérateurs ou cellules exploitées dans cetteétape. Ces temps dépendent de l’indice de vitesse du circuit, de la taille des données à traiter(nombre de bits) et des temps de propagation dûs au routage. Il faut donc pouvoir évaluer letemps d’exécution d’un opérateur et celui lié au routage. En général, les chemins de données de74

3.2. Modélisation de L’architectures cibleFig. 3.3 – Cellule Virtex.Tab. 3.3 – Estimation des ressources d’opérateurs logique et arithmétiques sur technologie VirtexOpérateur D bits synchronisé Nombre de cellulesMultiplication ou division par 2k 0Additionneur ou soustracteur ESUP P (D/4 + 1)MultiplexeurESUP P (D/4)ComparateurESUP P (D/2)Valeur absolueESUP P (D/4)Registre de synchronisation supplémentaire ESUP P (D/4)La fonction ESUP P (X) étant la fonction non linéaire qui renvoie la valeur entière directementsupérieur à X.75

Chapitre 3. Modélisationnos applications (traitement d’images) reposent principalement sur des opérateurs logiques etarithmétiques de type registres de synchronisation, additionneurs, soustracteurs , multiplexeurset comparateurs synchronisés ou non, etc. C’est pourquoi nous évaluons principalement ce typed’opérateurs.Multiplication et division par puissance de deux : Ces opérations correspondent à despermutations de liaisons lors du routage et ne consomment aucune ressource logique. Les tempsde propagation correspondants seront considérés comme négligeables. En pratique ces tempssont inclus dans la propagation dûs au routage (3.2.2.4).Opérateurs synchronisés ou non à propagation de retenue : Ces opérateurs cascadéssont des opérateurs de types additionneurs, soustracteurs ou additionneurs/soustracteurs. Lescellules logiques de l’AT40k permettent de traiter un bit (avec ou sans mémorisation) pources opérations, la taille en nombre de cellules requises sera donc égale au nombre de bits desopérandes. Les temps de propagation t 0 pour ces opérateurs peuvent être exprimés en fonctiondu temps de propagation induit par une cellule et du temps dû au routage inter-cellules pour lapropagation de la retenue. Pour un opérateur D bits (figure 3.4), on évalue son temps d’exécutionlogique t 0 par :t 0 = D.T C + (D − 1).T R (3.4)D est le nombre de cellules en cascade. T R est le temps de routage entre cellules d’un mêmeopérateur. T C est le temps de propagation d’une cellule par retenue. Les valeurs de ces paramètrespour la famille AT40K sont précisées en 3.2.2.2.Fig. 3.4 – Illustration de la durée de traitement d’un opérateur cascadé avec propagation deretenue76Pour un opérateur cascadé D bits synchronisé (figure 3.5), avec l’utilisation des bascules

3.2. Modélisation de L’architectures cibleinternes aux cellules, on évalue le temps d’exécution logique t 0 à :t 0 = D.(T C + T R ) + T SET UP (3.5)T SET UPd’une cellule logique.est le temps de prépositionnement requis par la bascule de mémorisation interneFig. 3.5 – Illustration de la durée de traitement d’un opérateur cascadé synchroniséOpérateurs non cascadés synchronisés ou non : Nous pouvons estimer les opérateursélémentaires logiques non cascadés au nombre d’entrées inférieur ou égal à 4 . Quelque soit lataille des données, le temps d’exécution de ces opérations correspond simplement à un temps detraversée ou/et un temps de prépositionnement d’une cellule logique (figure 3.6).Fig. 3.6 – Illustration de la durée d’un opérateur non cascadé et non synchroniséDans le cas d’opérateur non cascadé synchronisé ce temps correspondra à la somme de cesdeux paramètres T C et T SET UP . On trouve principalement parmi ces opérateurs :77

Chapitre 3. ModélisationMultiplexeurs(à deux entrées de type BUS) : Les temps de propagation t0 pour cesopérateurs ne dépendent pas de la taille des opérandes (sauf si la taille est supérieure au nombrede cellules contenues dans une ligne ou colonne). Le temps de propagation d’un multiplexeursynchronisé peut donc être estimé grâce à l’équation 3.6.t 0 = T C + T SET UP (3.6)Registres de synchronisation : Ces registres permettent soit de retarder les données (convolution),soit de resynchroniser les données lors d’un traitement en pipeline. Les temps de propagationt0 pour ces opérateurs ne dépendent pas de la taille des opérandes. Le temps de propagationd’un registre peut donc être estimé également par l’équation 3.6.L’analyse des données du constructeur [Atm] permet de déduire les caractéristiques de diverstypes d’opérateurs. La même démarche est effectuée pour estimer les comparateurs, opérateursvaleurs absolues, etc. Cependant, comme nous souhaitons effectuer des implantations pipelinées,nous considérons uniquement l’estimation des opérateurs synchronisés.Nous résumons dans les tableaux 3.4 et 3.5 les temps d’exécution de ces différents opérateurslogiques et arithmétiques pour les technologies AT40K et Virtex.Tab. 3.4 – Temps d’exécution des opérateurs synchronisés (AT40k)Opérateur D bitsTemps d’exécutionMultiplication ou division par 2k 0Additionneur ou soustracteurD.(TC + TR)+TSetupMultiplexeurTC + TSetupComparateur(2.D-1).(TC) + 2.TR+TSetupValeur absolueD.(TC + TR) + TSetupRegistre de synchronisation supplémentaireTC + TSetupTab. 3.5 – Temps d’exécution des opérateurs synchronisés (Virtex)Opérateur D bitsTemps d’exécutionMultiplication ou division par 2k 0Additionneur ou soustracteurD/4.(T C + T R) + T SetupMultiplexeurT C + T SetupComparateur((D/2) − 1).(T C) + 2.T R + T SetupValeur absolue(D/4).(T C + T R) + T SetupRegistre de synchronisation supplémentaireT C + T Setup78Remarques : En pratique, la mise en oeuvre des opérateurs évalués n’est pas toujours obtenue

3.2. Modélisation de L’architectures cibleà partir de l’ utilisation de macros paramétrables disponibles dans l’outil de développement. Eneffet, IDS ne permet pas toujours d’obtenir des performances optimales à la fois en termesde fréquences et de ressources exploitées (par rapport à l’estimation des ressources nécessaires)pour la réalisation d’une implantation donnée. Certaines macros sont des blocs hiérarchiquementfigés. Ce qui entraîne une impossibilité pour l’étape du Mapping à utiliser les ressources logiquesdisponibles et exploitables dans les Cells des macros. Cela est en particulier vrai pour des basculesdisponibles dans des Cells de macros dont seule la logique est utilisée (ex : additionneur). Lerésultat est une augmentation des ressources de routages et par conséquent une diminution desfréquences de fonctionnement.3.2.2.4 Interconnexions - Taux moyen lié au routage K moyL’un de nos principaux problèmes soulevés pour la fiabilité de notre méthode concerne lestemps de routage. En effet, l’évaluation de la décomposition d’une implantation nécessite ladétermination du temps de routage de chaque étape. Nous cherchons à évaluer le pourcentagedu temps alloué au routage à partir du taux d’occupation en ressources logiques. Il apparaîtpour des traitements de types chemin de données, que le temps de routage est proportionnel àcelui des différents temps de routage de chaque décomposition. C’est à dire que nous avons, pourun taux d’occupation donné, un temps dû au routage quasi constant. Nous pouvons considérerceci comme un heuristique se rapportant à une connaissance générale obtenue par expérience.Ici, l’argument justifiant la valeur du coefficient K est obtenu par expérimentation. Pour desapplications de type chemin de données constitué principalement d’opérateurs arithmétiques etlogiques synchronisés ou non nous estimons le paramètre K à une valeur constante de 1.5.3.2.3 Bibliothèque caractériséeGrâce à la caractérisation de la technologie ciblée présentée précédemment, nous sommesen mesure de créer toute une bibliothèque comportant les différents opérateurs élémentairesnécessaires à la réalisation d’une application. Outre l’AT40K ATMEL, la technologie VIRTEXa également été caractérisée et utilisée dans la suite de notre travail.Nous allons donc maintenant nous appuyer sur ces bibliothèques afin de modéliser notreapplication en vue d’une estimation de ses caractéristiques et des possibilités offertes par lareconfiguration dynamique.79

Chapitre 3. Modélisation3.3 Modélisation de l’applicationLa modélisation de l’application est basée sur un modèle de type graphe flot de données(GFD) dénoté ici par G(V,D). Dans un tel modèle, V = {v 1 , ..., v n } constitue l’ensemble desnoeuds du graphe. Ceux-ci sont en fait les opérateurs élémentaires ou des macros opérateursde l’application . D = {d 1 , ..., d n } est l’ensemble des arcs du graphe. Ces arcs représentent lesdépendances de données entre les opérateurs qu’ils relient.3.3.1 OpérateursLa modélisation des opérateurs du graphe flot de données est issu de la modélisation desopérateurs sur la technologie ciblée. Chaque opérateur élémentaire de l’application est ainsi créécomme une instance d’un opérateur de base (additionneur, multiplexeur,...), dérivée d’un de cesopérateurs (opérateurs sur 12bits, 13bits,...), ou bien entièrement redéfini en fonction des sescaractéristiques et des caractéristiques technologiques primaires :– D (la taille maximale de la données à traiter),– T C (temps de propagation des fonctions logiques dans une cellule (temps de traversée d’unecellule logique)),– T R (temps de propagation du routage entre les cellules logiques (délai de routage intraopérateur)),– T SET UP (temps de pré positionnement des registres contenus dans les cellules logiques).Pour un circuit de la famille AT40k en version -2 alimenté en 5V nous obtenons les valeurssuivantes pour ces différents paramètres : T C = 1,7 ns ; T R = 0,17 ns et T SET UP = 1,5 ns [ATM].Pour un circuit de la famille Virtex XCV200E en version -6 nous obtenons les valeurs suivantespour ces différents paramètres : T C = 0,7 ns ; T R = 10 ns et T SET UP = 0,6 ns [XILV2].Chaque instance d’opérateur dispose de ses données propres. Le graphe flot de données estalors représenté de façon schématique. Les informations concernant un opérateur sont concentréesdans une structure comprenant les éléments suivants :struct SOpType{CString nom;CString text;byte nbsrc;byte nbdest;// Nom de l’opérateur// Texte affiché sur le graphe// Nombre de sources de l’opérateur (entrées)// Nombre de destinations de l’opérateur (sorties)byte *taillesrc; // Taille (en bits) de chaque entréebyte *tailledest;// Taille (en bits) de chaque sortieint *src;int *dest;byte forme;// Tableau des liens de chaque entrée// Tableau des liens de chaque sortie// Identifiant de la forme graphique de l’opérateur80

3.3. Modélisation de l’application};CString formule; // Formule de calcul du temps de traversée de l’opérateurCString fcells;// Formule de calcul des ressources utilisées par l’opérateurOn peut retrouver dans cette structure, le nombre d’entrées et de sorties de l’opérateur, etpour chacune d’elles la taille des données est le numéro d’identification de l’arc (bus) sur lequelelles transitent. On trouve également des formules permettant de calculer le temps de traverséede l’opérateur ainsi que la surface nécessaire à son implantation. Ces formules sont conservéesde façon littérale et leurs valeurs sont calculées en fonction des besoins.3.3.2 Dépendances de donnéesLes dépendances de données sont représentées par les arcs du graphe flot de données. Chaquearc est une structure de données contenant les informations suivantes :struct SArc{};CPoint dest_point; // position de l’opérateur destination des données,CPoint src_point;byte taille;// position de l’opérateur source des données,// taille des données en transit sur ce bus.Un tel arc peut donc permettre d’identifier l’opérateur source et l’opérateur destination desdonnées qu’il représente tout comme un opérateur permet d’identifier les arcs auxquels il estconnecté par un numéro d’identification unique.3.3.3 Evaluation des ressources nécessaires à une partie du chemin de donnéesAyant évalué le nombre de cellules nécessaires pour réaliser chaque opérateur du GFD, nouspouvons maintenant évaluer les ressources logiques nécessaires pour chaque étape potentiellede la future application en reconfiguration dynamique à partir du graphe flot de données. Enpratique, parce qu’il y a des ressources de routage limitées, certaines cellules sont utilisées pourle routage. Cela implique que les ressources nécessaires pour une application sont généralementplus élevées que la valeur donnée en 3.7 :k∑∀j, C j ≥ C V i (3.7)l et k sont les indices marginaux des opérateurs {v 1 , ..., v k } présents physiquement dansl’étape j du graphe flot de données G(V,D) modélisant le chemin de données. C vi est la surface81i=l

Chapitre 3. Modélisationde l’opérateur. Par la suite, dans nos évaluations nous ne prenons pas en compte les cellulesconsommées pour le routage afin de répondre dans certaines situations à l’insuffisance du réseaude routage. De même, le temps d’exécution des opérateurs retenus pour cette partie d’applicationest exprimé par l’équation :∀j, t max = kmaxi=l (t 0i) (3.8)Le temps de propagation lié au routage est pris en compte de façon intrinsèque via l’utilisationdu taux moyen lié au routage intervenant dans chaque opérateur (K moy ).82

3.4. Contrôle des reconfigurations3.4 Contrôle des reconfigurationsUne fois le travail préliminaire du partitionnement effectué, on réalise les différentes partitionsqui vont constituer notre application. La reconfiguration dynamique demande alors une attentionsupplémentaire. Afin d’obtenir un déroulement correct de notre application, nous devons ajouterun contrôleur de reconfiguration qui assurera le chargement des différentes partitions sur la cibleau moment voulu. Il est important de soigner sa réalisation de sorte que le gain apporté parla reconfiguration ne soit pas annulé par le contrôleur. Ce contrôleur devra s’acquitter de deuxtâches essentielles :1. Assurer la reconfiguration de la cible.2. Synchroniser l’envoi et la réception des données.La partie la plus importante de ce travail est le contrôle des reconfigurations.Le contrôle du flux est évidement indispensable. Mais celui-ci peut également faire partie de laconfiguration de chaque partition et ainsi faire l’objet à chaque fois d’une optimisation en fonctiondes changements intervenant sur le flux. Dans le cas où le flux demeure identique entre chaquepartition, il devient alors plus judicieux d’adjoindre cette partie de contrôle au gestionnaire dereconfiguration. En définitive, le contrôleur final pourra donc être implanté de façon logicielle,matérielle ou mixte.3.4.1 Type de contrôleurEn fonction de la plateforme utilisée, plusieurs possibilités s’offrent au concepteur pour laréalisation du contrôleur de reconfiguration. Si la plateforme ou le composant visé le permet, leconcepteur peut avoir le choix d’implanter le contrôleur de façon logicielle , de façon matérielleou encore de façon partagée entre logiciel et matériel. Plusieurs points peuvent nous guider dansce choix.3.4.1.1 Contrôleur logicielSi le composant (ou la plateforme) reconfigurable ne supporte pas la reconfiguration partielle,on veillera à conserver la surface logique pour les implantations elles-mêmes. Le contrôleur seraalors implanté de façon logicielle, et commandera le chargement des partitions et éventuellementle transfert des données sur la surface reconfigurable.Il est également possible que la surface reconfigurable ne serve que d’accélérateur de calcul.Dans ce cas, c’est encore une application logicielle qui fera appel aux différentes partitions dontelle à besoin de façon ponctuelle.L’autre avantage d’un contrôleur logiciel est de permettre une plus grande complexité dansl’ordonnancement des partitions.83

Chapitre 3. Modélisation3.4.1.2 Contrôleur matérielL’autre possibilité est évidement de créer un contrôleur matériel. Celui-ci pourra alors êtreimplanté de différentes façons.La première est de l’implanter sur un autre composant de la plateforme. Si par exemplecette plateforme (ou ce composant) dispose de plusieurs unités de calcul reconfigurable, l’uned’elles sera dédiée au contrôle des autres et ne sera donc configuré qu’à la mise sous tension del’application.La seconde solution s’applique aux composants permettant une reconfiguration dynamiquepartielle de leur surface logique. Dans de telles conditions, on pourra implanter le contrôleur surle circuit de façon statique. Il sera configuré au départ de l’application et assurera ensuite laconfiguration des autres partitions sur la partie reconfigurable resté libre du même composantgrâce à la reconfiguration dynamique partielle.Cette seconde solution est la plus en accord avec les choix que nous avons fait jusqu’icien matière de recherche. L’AT40K supporte la reconfiguration dynamique partielle et le kitARDOISE permet donc de tester ces concepts. Nous allons donc détailler cette possibilité dansla suite de ce chapitre.3.4.1.3 Contrôleur mixteComme bien souvent, le concepteur conserve la possibilité de partager le contrôleur entrelogiciel et matériel. On peut par exemple imaginer un contrôleur matériel simple gérant uniquementle transfert des données des mémoires à la surface logique, et une partie logicielle qui ellese contenterait de charger les configurations elle-même.3.4.1.4 Complexité du contrôleur de reconfigurationSuivant le type d’application réalisée, la complexité du contrôleur peut varier. En effet, certainesapplications n’ont pas besoin d’une machine d’état complexe pour assurer le chargementde partitions toujours identiques, de façon cyclique. Pour ces applications nous proposons doncun contrôleur à ordonnancement fixe présenté en 3.4.2. Dans d’autres cas, l’ordonnancementpeut-être amené à changer dynamiquement. Le contrôleur doit alors savoir quelle est la partitionsuivante parmi celles dont il dispose. Il peut aussi avoir à modifier lui même cet ordonnancementafin de répondre à un besoin de l’application, ou simplement pour augmenter l’efficacitédu traitement. Pour ces ordonnancements plus complexes, nous proposons un contrôleur à ordonnancementconditionné et évolutif en 3.4.3.84

3.4. Contrôle des reconfigurations3.4.2 Contrôle à ordonnancement fixeLe contrôleur dans le cas d’un ordonnancement fixe a pour rôle de charger les différentsbitstreams correspondant aux différentes partitions chacun à leur tour, une fois l’exécution dela partition en place terminée.De plus, il contrôle les signaux d’écriture/lecture des bancs mémoires dans le but de permuterles données inter-configurations. L’architecture des circuits FPGA privilégie un sens pour lapropagation des données, or dans notre cas, le sens est renversé à chaque partition. Cela nécessited’amener les données lues dans la mémoire du ”bon” coté puis d’aller écrire les données traitéespar la partition dans la mémoire de ”sortie”. Ces différents chemins de données (correspondant àun adressage ping-pong des mémoires) qui connectent la mémoire aux différentes entrées/sortiesdu FPGA sont inclus dans la configuration de chaque partition (contrainte de placement sur lesentrées/sorties). Pour que le système fonctionne en reconfiguration dynamique, il est nécessairede réaliser un contrôleur spécifique. Ce contrôleur peut lire/écrire les données dans les mémoirestemporaires et autoriser le chargement de la configuration suivante.Le contrôleur nécessite deux compteurs pour adresser les mémoires (taille du compteur égaleà sup(log 2 N) si les blocs regroupent N mots de données) , une machine à état pour le contrôlede la reconfiguration et des accès en lecture/écriture et un registre et un compteur (contenantchacun sup(log 2 n) bits) qui stockent respectivement le nombre de partitions (n) et le numérode la partition courante. Ce contrôleur est représenté sur la figure 3.7.Fig. 3.7 – Contrôleur de configurations à ordonnancement fixe.Un tel contrôleur demeure donc d’une complexité faible et sont implantation reste raisonnableen terme de surface logique.Nous avons réalisé l’implantation d’un tel contrôleur permettant l’adressage d’images auformat 512x512 (2 compteurs 18 bits) ainsi qu’une machine d’état constituée de 5 états pourles reconfigurations. Il nécessite également un registre de 4 bits contenant le nombre total departitions (pouvant donc aller jusqu’à 16 partitions), un compteur indiquant le numéro de lapartition courante, un comparateur 4 bits et une bascule pour indiquer alternativement quelle85

Chapitre 3. Modélisationmémoire est en lecture/écriture.Cette implantation a été réalisée sur un FPGA de la famille AT40K ATMEL. La surfacelogique nécessaire à cette l’implantation est de 50 cellules logique.3.4.3 Contrôle à ordonnancement conditionné et évolutifCe type de contrôleur est plus adapté aux traitements de flots de données non réguliers. Nousentendons par ”non réguliers” des traitements conditionnés par les données elles même et/ou parles résultats des traitements précédents.Un gain de surface important peut être réalisé lorsque les différents traitements à effectueren fonctions des précédentes conditions présentent des exclusions mutuelles.Dans ces conditions, il est alors possible de ne configurer que les branches qui doivent êtreexécutées. Le fonctionnement devient alors très dynamique et chaque nouvelle branche est reconfigurédès lors qu’elle est nécessaire.Ce fonctionnement identique à une reconfiguration tâche par tâche présente l’inconvénientd’interrompre le flot de traitement. Par conséquent, la reconfiguration même si elle est effectuéerapidement va tout de même nécessiter la mise en mémoire tampon des données, ainsiqu’une nouvelle passe de traitement. Imaginons que la nouvelle branche configurée ne présenteque quelques opérateurs logiques susceptible d’être ajoutés dans la configuration précédente, letraitement global sera ainsi quasiment double du fait de cette interruption du pipeline.Par conséquent, une connaissance ou une prédiction des traitements à effectuer sur le fluxest un facteur de gain important. En effet si un chemin de données est fortement prédominantpar rapport à d’autres, il est alors envisageable de configurer la surface logique avec ce cheminde données complet. Lorsque les données viennent à demander une modification du traitement,on peut alors provoquer une reconfiguration de la matrice. Le pipeline est alors interrompu dede façon moins systématique et l’accélération du calcul est plus importante.Pour permettre un tel fonctionnement, une connaissance statistique du traitement est nécessaire.Celui-ci peut être obtenu par profiling de l’application et des données. Ainsi, le partitionnementsera choisi de sorte à minimiser les reconfigurations sur les chemins les plus probables,maintenant ainsi un pipeline le plus long possible.Lors du changement du chemin de données, il est alors possible de reconfigurer la fin dunouveau chemin de donnée en conservant les résultats précédents.Malheureusement, rien ne garantie qu’un chemin de données soit prédominant dans le calcul,ni même que (si il existe) celui-ci demeure prédominant au cours du temps.Afin de s’adapter au mieux à de tels changements et d’éviter une perte des performances,nous proposons un contrôleur adaptatif. Celui-ci, en plus de contrôler le chargement des diversesconfigurations les unes après les autres, a pour tâche de collecter les statistiques concernant86

3.4. Contrôle des reconfigurationsl’exécution des différentes branches de l’algorithme afin de choisir parmi les partitions dont ildispose, celles qui permettrons d’obtenir les meilleurs performances.Parmi les partitions envisageables, il est alors judicieux de conserver plusieurs d’entre ellescontenant diverses combinaisons des branches de traitement. Ainsi, suivant l’évolution statistiquede l’exécution des branches, les partitions configurées tour à tour peuvent changer.87

Chapitre 3. Modélisation88

Chapitre 4Partitionnement sous contrainte detemps4.1 Rappels - Travaux précédentsCette partie est la suite logique des travaux menés par Mr Camel Tanougast lors de sa thèse[Tan01].4.1.1 Méthodologie premièreCes recherches ont permis de développer une première méthologie de partitionnement souscontrainte de temps à appliquer aux graphes flot de données.On cherchait alors à minimiser prioritairement la surface logique nécessaire à l’implantationd’une architecture grâce aux possibilités de reconfiguration dynamique des FPGAs.4.1.2 Cadre applicatifLe cadre d’utilisation qui avait été choisi était le traitement d’images, ceci pour les raisons quiont déjà été expliquées précédemment (régularité des traitements, traitements par blocs). La méthodede partitionnement s’est attachée à montrer son efficacité dans ce cadre particulier. Cetterestriction a permis de mettre en avant des gains important en matière de surface d’implantationpour de tels algorithmes (division par quatre du nombre de cellules logiques nécessaires).4.1.2.1 Approche conception de circuitsDans une approche de conception de plateforme, la méthodologie est parfaitement viable. Eneffet, on recherche à minimiser les besoins matériels que l’on devra plus tard mettre en oeuvrepour permettre à une application de fonctionner avec un nombre de cellules le plus réduit possible.L’émergence des SOCs et plus largement des besoins actuels en matière d’applications89

Chapitre 4. Partitionnement sous contrainte de tempsembarquées donne à cette approche toute sa légitimité. Le coût de fabrication du circuit estdiminué du même ordre de grandeur que le gain surfacique obtenu par la reconfiguration dynamique.Malheureusement, ce gain est à mettre en rapport avec une augmentation de la puissanceélectrique du circuit due à l’augmentation de la vitesse de traitement.4.1.2.2 Approche implantation d’applicationLa seconde approche envisageable est celle qui consiste à vouloir utiliser une plateformedéjà existante et supportant la reconfiguration dynamique. Cette fois-ci le but de la méthodede partitionnement est différent. Il n’est plus de réduire au maximum la surface nécessaire àl’implantation d’une application mais d’en permettre la réalisation. En effet, dans le cas oùl’application visée nécessite plus de ressources que ce qu’offre la plateforme, la reconfigurationdynamique permet d’augmenter virtuellement la surface logique disponible. Grâce à une accélérationdes traitements, l’application une fois partitionnée sera exécutée en plusieurs passes surcet espace logique restreint. On comprend bien ici que le problème qui se limitait auparavant àune implantation sous contrainte de temps, est quelque peu modifié. Si la contrainte de tempsreste un élément clé du problème, la minimisation à tout prix de la surface logique est , dans cecas, remise en cause. Il est inutile de vouloir découper une application en dix si la découper enquatre se révèle suffisant. Dans ce cas précis, la méthode développée perd un peu de son efficacité.Certe l’utilisation de la reconfiguration est maximal, mais la surface logique disponible estmal exploitée.4.1.3 Mise en oeuvreBien que la méthode soit tout à fait pertinente, elle nécessitait un travail important de la partdu concepteur. Elle demande une caractérisation des différents opérateurs de l’application, puisune annotation du graphe flot de données relatif à cette application. Ce long travail bien qu’ilsoit bénéfique au final apparaîtra certainement trop fastidieux pour un concepteur qui voudraitse lancer dans l’utilisation de la reconfiguration dynamique pour la première fois.4.1.4 ApportSuite à ces travaux, nous voyons d’ores et déjà les limites du champs d’action de la méthodologiedéveloppée par Mr Camel Tanougast. Nous avons donc décidé dans un premier tempsd’étendre ce champ d’action afin d’augmenter l’efficacité de la méthode mais également dans lebut de simplifier sa mise en oeuvre.C’est pourquoi la suite de ce chapitre s’intéresse dans un premier temps à une prise encompte de la bande passante dans le partitionnement. Cela permet de ne pas tout miser sur uneminimisation des ressources logiques lors du partitionnement. On évitera ainsi de partitionner90

4.1. Rappels - Travaux précédentsde façon trop simpliste et on limitera les besoins en bande passante vers les mémoires tamponsutilisées lors du calcul, entre les différentes configurations.Dans un second temps nous verrons l’automatisation de la méthode que nous avons mise enplace avec la réalisation d’un outil logiciel.Le chapitre suivant est quant à lui dédié à une autre vision du partitionnement et s’éloignede la méthodologie première.91

Chapitre 4. Partitionnement sous contrainte de temps4.2 Prise en compte de la bande passante dans le partitionnementComme nous venons de le voir dans la section précédente, il nous semble important de faireplus qu’une minimisation des besoins en matière de ressources logiques. Le partitionnementd’une application en plusieurs passes va nécessiter le transfert de données vers des mémoirestampons externes. Suivant l’endroit où sera ”coupée” l’application pour créer ces partitions, lataille de ces données ne sera pas la même. C’est pourquoi nous allons intégrer la mesure de cettebande passante afin d’éviter la création d’un goulot d’étranglement vers les mémoires tamponsentre les reconfigurations.Ainsi, nous proposons un outil prenant en compte l’aspect reconfiguration dynamique desFPGAs et permettant de spécifier les caractéristiques d’une architecture reconfigurable : SoCou plateforme à base de FPGA . L’objectif est de trouver la meilleure adéquation entre uneapplication et son implantation sur cette plateforme. Cet outil qui repose sur notre méthodede partitionnement temporel original vise deux objectifs : minimisation des ressources logiquesnécessaires à une implantation sous contrainte de temps et minimisation locale de la bande passante.En effet, utiliser la RD peut conduire à une augmentation des besoins en bande passante,en consommation d’énergie, en mémoire temporaire. Notre outil appelé DAGARD (DécoupageAutomatique de Graphes pour Architectures Reconfigurable Dynamiquement) permet de réaliserle découpage d’une application complète représentée sous forme d’un graphe flot de données(GFD) en plusieurs sous applications successivement exécutées par la surface logique visée grâceà la RD. Il s’insère dans le flot de conception d’une application (Fig 4.1).La prochaine section présente le fonctionnement de la méthode de partitionnement temporel.Les sections suivantes présentent des exemples d’utilisation. La section 4.6 apporte notreconclusion ainsi que nos perspectives quant à cette approche.92

4.3. FonctionnementFig. 4.1 – Insertion de DAGARD dans le flot de conception.4.3 FonctionnementLe fonctionnement de DAGARD repose sur la méthode de partitionnement, développée parMr Camel Tanougast lors de sa thèse [Tan01], qui recherche le découpage d’une application enun maximum de sous applications de tailles aussi proches que possible. Il délivre un nombre departitions n réalisable sous une contrainte de temps donnée. Connaissant n, DAGARD permetd’envisager deux stratégies différentes. La première minimise la surface nécessaire à l’applicationen créant des partitions de tailles égales et tente ensuite de minimiser les besoins en bande passanteinduit par le découpage. La seconde a le fonctionnement inverse : minimisation de la bandepassante mémoire puis un raffinement tente d’égaliser les surfaces des différentes partitions.4.3.1 Fonctionnement de baseLe pseudo algorithme fig.4.2 présente la structure de l’automatisation du partitionnement. Ilpermet de déduire le nombre de partitions réalisable ainsi que la surface moyenne de chaque partition.Il utilise pour cela le graphe flot de données, ainsi que les diverses contraintes d’applicationet architecturales.La vitesse de reconfiguration du FPGA V, la taille des blocs de données à traiter N et letemps total T accordé au traitement permettent de connaître n, le nombre de reconfigurations93

Chapitre 4. Partitionnement sous contrainte de tempsV, N, T = constantes //contraintes diversesG ⇐ DF G //saisie du GFDC ⇐ 0 //Surface totale nécessaireT O ⇐ 0 //Temps de l’opérateur le plus lentPOUR chaque noeud Ni de GT O ⇐ max(T O, Ni.ti) //temps d’exécution maximumC ⇐ C + Ni.Surface //calcul de la surface totaleFIN POURn ⇐ T/[(N.T O) + C/V ] // calcul de n et CnCn ⇐ C/nFig. 4.2 – Principe d’obtention du nombre de partitions.(que nous somme certains de pouvoir exécuter en satisfaisant les contraintes de temps), ainsique Cn, la surface FPGA minimale nécessaire à l’application partitionnée en n étapes. Toutes lesinformations technologiques (le temps d’exécution de chaque opérateur (ti), la surface nécessaireà son implantation (Ni)) sont issues d’une librairie caractéristique de la technologie FPGA viséepar l’application (exemples : Atmel, Xilinx, etc.). La modélisation de cette technologie a étéprésentée en 3.2.4.3.2 Optimisation de la surface logique et/ou de la bande passante.L’accumulation des opérateurs successifs du GFD en partant de son sommet jusqu’à l’obtentiond’une surface supérieure ou égale à Cn définit la première partition. Les suivantes sontréalisées de la même façon en réinitialisant le cumul de surface, ceci jusqu’à la fin du GFD. Lepseudo algorithme de création des partitions est représenté par la figure 4.3.P1, P2, ..., Pn⇐ partitions videsPOUR i DE 1 A nC ⇐ 0Tant que C≤ CnAjoute(Pi, Noeud(G))C ⇐ C + Noeud(G).SurfaceSupprime(G, Noeud(G))Fin TantqueFIN POURFig. 4.3 – Principe de création des partitions.94

4.3. FonctionnementNous utilisons ici la librairie d’opérateurs de la technologie ciblée pour déterminer la surfacenécessaire à l’implantation de chacun des opérateurs, leur temps de traversé ainsi que la tailledes données qu’ils traitent. L’accumulation s’effectue de façon à répondre aux dépendances dedonnées du GFD. Un raffinement du découpage permet dans la mesure du possible de diminuerles besoins en bande passante vers l’extérieur du FPGA. Le pseudo algorithme de ce raffinementest donné par la figure 4.4.entier k, minbp ;k ⇐ Sep ;(Lieu de séparation entre Pi et Pi+1) ;minbp ⇐ somme bus(k) ;POUR j de 1 à Espace de recherche FAIRE :SI minbp > somme bus(k+j) FAIRE :Sep ⇐ k+j ;minbp ⇐ somme bus(k+j) ;FIN SISI minbp > somme bus(k-j) FAIRE :Sep ⇐ k-j ;minbp ⇐ somme bus(k-j) ;FIN SIFIN POURFig. 4.4 – Principe du raffinement du partitionnement.Ce code, par une légère variation du lieu de découpage du graphe (limitée et paramétré parEspace de recherche), permet de diminuer la bande passante nécessaire tout en conservant unehomogénéité des partitions convenable.La seconde stratégie proposée est une recherche de tous les niveaux du GFD pour lesquelsla bande passante est minimale. Cette information est obtenue lors du parcours du GFD enaccumulant à chaque niveau les informations de taille de données contenues dans chacun desarcs qui relient les opérateurs du graphe (Figure 4.5).Une fois ces minimums référencés, on peut utiliser ceux qui réalisent le découpage le plushomogène (en terme de surface) de l’application. L’ensemble de ces informations est représentésur DAGARD.4.3.3 Génération du contrôleur du partitionnementConnaissant les partitions, la génération d’un contrôleur exécutant ces partitions en RD etgérant les mémoires de stockage des données intermédiaires est aisée (Figure 4.6).Le contrôleur présenté ici est constitué d’une simple machine d’état (voir ”Contrôleur à95

Chapitre 4. Partitionnement sous contrainte de tempsFig. 4.5 – Illustration de la taille du chemin de données dans DAGARD.Fig. 4.6 – Machine d’état du contrôleur.ordonnancement fixe”, section 3.4.2). Le transitions sont provoquées par la fin des traitementsdes partitions ainsi que par la fin des chargements des configurations. Dès qu’une partitionarrive à son terme, elle provoque une transition de la machine d’état vers un état suivant quipermettra le chargement de la partition suivante. A la fin du chargement, une nouvelle transitionde la machine d’état commandera le début des traitements de la nouvelle partition fraichementconfigurée, et ainsi de suite.96

4.4 Exemple I : Détecteur de contours4.4. Exemple I : Détecteur de contours4.4.1 Présentation de l’algorithmeRappelons que notre domaine de prédilection est le traitement d’image. La régularité et lataille des données à traiter dans ce domaine en fait un champ d’application privilégié pour lareconfiguration dynamique. En effet, des blocs de données de taille importante permettent deminimiser le ”coût relatif” des temps de reconfiguration par rapport aux temps de traitement.L’algorithme utilisé comme test est un détecteur de contours en temps réel. Les contraintesde temps sont donc celle d’une période image : 40 ms, et les blocs de données sont les pixels :512 2 .Le découpage par Dagard propose un découpage en ”3,273” configurations. Cela signifie quenous sommes certain de pouvoir réaliser un découpage en trois étapes. Nous prenons en compteles temps de routage et temps d’exécution ”pire cas” dans notre évaluation. Fort de cela, nousavons également demandé une estimation pour un découpage en quatre partitions du mêmealgorithme dont l’implantation a été réalisée par la suite et dont les résultats sont présentésdans la section suivante.4.4.2 Résultats donnée par DAGARDen 4.1.DAGARD donne une estimation de surface de 991 cellules au total et la répartition présentéeTab. 4.1 – Estimation de surface et fréquence de travail de chaque partitionPartition Surface Fréquence maximale1 220 cell. 36,37 MHz2 241 cell. 22,56 MHz3 243 cell. 22,56 MHz4 277 cell. 22,56 MHzL’estimation du temps de calcul de chaque partition est présenté dans le Tableau 4.2.4.4.3 Résultats d’implantationNous avons réalisé l’implantation de l’algorithme en suivant le découpage recommandé parDAGARD. La surface totale des partitions obtenues est alors de 1008 cellules logiques. Larépartition et les fréquences de travail sont présentées par la Table 4.3.Les temps de calcul de chaque partition sont présentés dans le Tableau 4.4.97

Chapitre 4. Partitionnement sous contrainte de tempsTab. 4.2 – Estimation des temps d’exécution/reconfiguration de chaque partition.Partition Reconfiguration Traitement Total1 161 µs 7,2 ms 7,361 ms2 176 µs 11,62 ms 11,796 ms3 178 µs 11,62 ms 11,798 ms4 203 µs 11,62 ms 11,865 msTotal : 42,82 msTab. 4.3 – Ressources et fréquences de travail de chaque partition.Partition Surface Fréquence maximale1 225 cell. 36,9 MHz2 241 cell. 25,84 MHz3 248 cell. 25,84 MHz4 294 cell. 26,45 MHzTab. 4.4 – Temps de reconfiguration et d’exécution de chaque partition.Partition Reconfiguration Traitement Total1 173 µs 7,1 ms 7,273 ms2 180 µs 10,15 ms 10,33 ms3 180 µs 10,15 ms 10,33 ms4 190 µs 9,91 ms 10,10 msTotal : 38,033 ms4.4.4 Bilan et discussionNous avons réalisé l’automatisation d’une méthode de partitionnement pour la reconfigurationdynamique temps réel sur FPGA. Ce partitionnement automatique permet une utilisationde la surface du FPGA beaucoup plus intense (à fréquence plus élevée) et donc une réduction desbesoins en surface logique par rapport à une application statique. Ce mode de fonctionnementpeut se révéler très utile pour des applications sur systèmes embarqués où la surface logiques’avère être un élément critique. En effet, notre outil fournit les caractéristiques matérielles nécessairesà l’implantation optimale d’une application (taille de la matrice FPGA, besoins enmémoire temporaire, bande passante mémoire). Nous testons ici notre outil (Tableau 4.5) lorsd’une utilisation ”idéale” : c’est à dire lorsque l’application visée est une bonne candidate à uneimplantation en reconfiguration dynamique. De plus, nous nous sommes contenté d’une implantationsur l’architecture Ardoise. Afin d’obtenir un test plus exhaustif de notre méthode, la98

4.4. Exemple I : Détecteur de contourssection suivante présente l’implantation d’un algorithme ”moins idéal”, toujours sur ARDOISEmais également sur la technologie Virtex de Xilinx.Tab. 4.5 – Écart entre estimation et implantation finalePartition Estimation Implantation Écart1 220 225 2,3%2 241 241 0,0%3 243 248 2,1%4 277 294 6,1%Total 991 1008 1,7%99

Chapitre 4. Partitionnement sous contrainte de temps4.5 Exemple II : cryptage AES4.5.1 Présentation GénéraleLe but de ce travail est l’implantation en reconfiguration dynamique, selon notre méthodede partitionnement présentée précédemment, d’un algorithme possédant un niveau de contrôleplus important qu’un algorithme typiquement ”chemin de données”. Le choix s’est porté sur unalgorithme de cryptage ”AES”.L’objectif de ce travail est de mettre en évidence les besoins, les considérations à prendrepour des algorithmes autres que tout ”chemin de données” lors d’une implémentation en reconfigurationdynamique. Ensuite, il s’agit d’évaluer les conditions pour lesquelles la reconfigurationdynamique est une solution viable par rapport à d’autres approches telle que la synthèse architecturale.Dans une première section, nous présentons l’architecture du cryptage AES. Dans une secondesection l’implantation de l’algorithme selon le partitionnement automatique est décritepour les technologies FPGA ATMEL et XILINX. Nous présenterons les résultats expérimentauxdes implantations réalisées. A partir de ces expérimentations, des solutions sont proposéesconcernant l’implémentation en reconfiguration dynamique de boucles de traitement de l’algorithme.Ensuite une implémentation de type synthèse architecturale est réalisée. Cette dernièrepermet une comparaison par rapport à l’implantation en reconfiguration dynamique. Enfin, nousconclurons sur les résultats obtenus selon les approches considérées.4.5.2 L’algorithme AESL’algorithme AES (Advanced Encryption Standard) Rijndael est un standard de cryptagesymétrique [AES04] destiné à remplacer le DES (Data Encryption Standard) qui est devenu tropfaible (cryptage fonctionnant avec des clés de 56 bits) au regard des besoins de cryptage actuels.Cet algorithme possède les caractéristiques suivantes :– AES est un standard, donc libre d’utilisation, sans restriction d’usage ni brevet.– c’est un algorithme symétrique.– c’est un algorithme de chiffrement par blocs.– il supporte différentes combinaisons ([longueur de clé]-[longueur de bloc] : 128-128, 192-128et 256-128 bits).En termes décimaux, ces différentes tailles possibles signifient concrètement :– 3, 4e 38 clés de 128-bit possibles.– 6, 2e 57 clés de 192-bit possibles.– 1, 1e 77 clés de 256-bit possibles.100

4.5. Exemple II : cryptage AESPour avoir un ordre d’idée, les clés DES ont une longueur de 56 bits (64 bits au total dont 8pour les contrôles de parité), ce qui signifie qu’il y a approximativement 7, 2e 16 clés différentespossibles (2 56 ). Cela nous donne de l’ordre de 10 21 fois plus de clés 128 bits pour l’AES que declés 56 bits pour le DES. En supposant que l’on puisse construire une machine qui peut casserune clé DES en une seconde (donc qui puisse calculer 2 56 clés par seconde), alors cette machinemettrait encore 149 000 milliards d’années pour casser une clé AES. Pour conclure, on voit quele standard AES répond aux mêmes exigences que le DES, mais il est également beaucoup plussûr et flexible que son prédécesseur. Du point de vue de nos objectifs, le choix de cet algorithmerepose sur les caractéristiques suivantes :– présente une structure contenant des boucles de traitement nécessitant une grande rapiditéde traitement.– flexibilité d’implémentation : taille de clés et de blocs différents selon l’application visé.– hardware et software : il est possible d’implémenter l’AES aussi bien sous forme logicielleque matérielle (câblé).– simplicité de son architecture.Si l’on se réfère à ces critères, on voit que l’AES est un algorithme particulièrement appropriépour les implémentations embarquées qui suivent des règles beaucoup plus strictes en matièrede ressources, puissance de calcul, taille mémoire, etc. C’est sans doute cela qui a poussé lemonde de la téléphonie 3G (3ème génération de mobiles) à adopter l’algorithme pour son schémad’authentification ”Millenage”. L’algorithme Rijndael [AESa] procède par blocs de 128 bits, avecune clé de 128 bits également. Chaque bloc subit une séquence de 5 transformations répétées 10fois. La figure 4.7 illustre son principe de fonctionnement.– Addition de la clé secrète (par un ou exclusif).– Transformation non linéaire d’octets : les 128 bits sont répartis en 16 blocs de 8 bits, euxmêmesdispatchés dans un tableau 4x4. Chaque octet est transformé par une fonction nonlinéaire S.– Décalage de lignes : les 3 dernières lignes sont décalées cycliquement vers la gauche : la2ème ligne est décalée d’une colonne, la 3ème ligne de 2 colonnes, et la 4ème ligne de 3colonnes.– Brouillage des colonnes : Chaque colonne est transformée par combinaisons linéaires desdifférents éléments de la colonne (ce qui revient à multiplier la matrice 4x4 par une autrematrice 4x4). Les calculs sur les octets sont réalisés dans le corps fini GF (2 8 )[RS].– Addition de la clé de tour : A chaque tour, une clé de tour est générée à partir de la clésecrète par un sous-algorithme (dit de cadencement). Cette clé de tour est ajoutée par unou exclusif au dernier bloc obtenu.Le schéma général de l’algorithme AES est représenté sur la figure 4.8.101

Chapitre 4. Partitionnement sous contrainte de tempsFig. 4.7 – Schéma de principe de l’algorithme AESFig. 4.8 – Schéma général du chemin de données de l’algorithme AES.102

4.5. Exemple II : cryptage AESLe mode opératoire du cryptage suit un ordre rigoureux. Premièrement il génère et crypte lesclés. Ensuite il crypte les messages ou textes (plaintext) parties par parties. En pratique, crypterles textes est un processus complexe. A l’intérieur de chaque partie les données sont traitées 8bits par 8 bits. Chaque macro reçoit 32 bits de texte et 32 bits de clé déjà cryptés.4.5.3 Plate-forme reconfigurable ARDOISENos implémentations sont réalisées sur la plate-forme ARDOISE (Architecture ReconfigurationDynamiquement Orientée Image et Signal Embarqué) (section 2.2.3.1). Mais afin de testernotre travail sur d’autres technologies FPGA, nous développerons également l’implantation surtechnologie Virtex.4.5.4 Partitionnement temporel en reconfiguration dynamique4.5.4.1 Modélisation et détermination des paramètres technologiquesA partir de données techniques disponibles pour les architectures ATMEL AT40K et XilinxVIRTEX2, une modélisation de chacune de ces technologies est réalisée. Cette modélisation estprésentée au chapitre 3.Les technologies AT40K de ATMEL et Virtex de XILINX permettent de réaliser de la reconfigurationtotale ou partielle. Elles offrent la possibilité pour chaque nouvelle configurationde générer les données de configuration limitées aux ressources exploitées.4.5.4.2 Estimation des performances des opérateursDe même, l’étude de la structure des cellules logiques de la technologie utilisée (voir section3.2.2) permet l’évaluation du nombre de cellules nécessaires pour réaliser chaque opérateur duGFD.Ces caractérisations permettent d’estimer les fréquences et ressources nécessaires pour l’exécutiond’une partition. En effet, le temps d’exécution d’une partition implantée dépend à la foisdu temps d’exécution maximal des opérateurs mis en oeuvre et du routage entre les différentsopérateurs ou cellules exploitées dans cette étape.4.5.4.3 Graphe flot de données de l’algorithme AESLa figure 4.10 présente l’architecture de l’algorithme AES sous forme de graphe flot dedonnées détaillé. A l’intérieur de chaque partie les données sont traitées 8 bits par 8 bits. Chaquemacro reçoit les 32 bits de texte et les 32 bits de la clé crypté. La fonction SBOX correspondà quatre tables de codage d’entrées 8 bits et de sortie 8 bits. La figure suivante (4.9) donne lalégende relative à la figure 4.10.103

Chapitre 4. Partitionnement sous contrainte de tempsFig. 4.9 – Légende du Graphe flot de données de l’algorithme AES4.5.4.4 Détermination du partitionnementDAGARD exécute la méthode de partitionnement considéré de manière automatique. Lepartitionnement est obtenu à partir de la contrainte de temps de l’algorithme. Nous considéronsun traitement de données à un débit de 10 Moctets/s. Ce qui correspond au traitement de blocsde données N = 100000 octets en 10 ms.A partir d’une saisie du GFD et de la technologie FPGA utilisée, DAGARD déterminede manière automatique le nombre de partitions, les performances attendues et les ressourcesnécessaires à l’implantation de l’algorithme considéré. Le tableau 4.6 résume ces données pourla technologie FPGA ATMEL AT40K. Ainsi, à partir de la taille des données à traiter et desopérateurs saisis dans DAGARD, nous obtenons une surface totale de 3661 cellules, un tempsd’exécution global de 13,47 ns et un nombre de partitions égal à 5.DAGARD a découpé le chemin de données en cinq partitions. Le tableau 4.7 fournit uneestimation automatisée de chaque partition avec la technologie Atmel. La taille des partitionsainsi que la bande passante mémoire (Fréquence x taille des données) nécessaire par partitionsont décrites. Il est à noter que la taille des données en sortie de la première partition n’est pas104

4.5. Exemple II : cryptage AESFig. 4.10 – Graphe flot de données de l’algorithme AES105

Chapitre 4. Partitionnement sous contrainte de tempsTab. 4.6 – Estimation des ressources d’implantation en RD sur AT40KEstimation du nombre Temps d’exécution Nombre d’étape de Nombre moyen detotal de cellules opérateur te max (ns) reconfiguration cells/étapes3661 13,47 5 732entièrement utilisée pour la partition suivante. Nous avons donc une bande passante plus faibleen entrée et en sortie pour les partitions suivantes.Tab. 4.7 – Estimation des partitions de l’algorithme AES sur technologie AtmelNuméro Nombre Fréquence Taille Taille B.P. B.P.de de maximale des entrées des sorties nécessaire nécessairepartition Cellules (Hz) (en bits) (en bits) en entrée en sortie1 812 7.424 e+7 130 129 9.653 e+9 9.577 e+92 832 9.259 e+7 129 64 11.94 e+9 5.925 e+93 672 9.259 e+7 64 32 5.925 e+9 2.963 e+94 672 9.259 e+7 64 32 5.925 e+9 2.963 e+95 672 9.259 e+7 64 52 5.925 e+9 2.963 e+9La figure 4.11 présente le partitionnement automatisé de l’algorithme AES obtenu par DA-GARD. Les macros de cryptage de textes 32x 32 bits sont identifiées. La Figure 4.12.présente legraphe flot de donnée détaillé de cette macro de traitement saisi dans DAGARD.Le partitionnement proposé par DAGARD ne prend pas en compte la gestion des boucles detraitement. C’est pourquoi le partitionnement initialement proposé n’est pas réalisable puisqu’ilchevauche une boucle de traitement (voir figure 4.23). Un raffinement manuel de la premièrepartition s’impose. Cette dernière est agrandie afin qu’elle englobe la boucle de traitement initialementdécoupé par le premier partitionnement. La table 4.8 détaille l’estimation du partitionnementraffiné pour la technologie ATMEL AT40K. La figure 4.13 présente le raffinementdu partitionnement initial.4.5.4.5 Résultats d’implantation du partitionnementNous avons implémenté sur cible AT40k et Virtex le partitionnement raffiné obtenu avecDAGARD. L’outil de synthèse utilisé est Précision Synthesis de Mentor Graphics. Les figures 4.15et 4.16 représentent successivement les graphes flot de données de la partition 1 et des partitions2, 3, 4 et 5. Les tableaux 4.9 et 4.10 montrent les résultats d’implantation du partitionnementfinal avec 128 bits d’entrée respectivement pour les technologie ATMEL et XILINX.106

4.5. Exemple II : cryptage AESFig. 4.11 – Partitionnement automatique de l’algorithme AES obtenu avec DAGARD107

Chapitre 4. Partitionnement sous contrainte de tempsFig. 4.12 – Graphe flot de données détaillé de la macro de cryptage des textesTab. 4.8 – Estimation des partitions raffinés. (128bits, AT40K)Numéro Nombre Fréquence Taille Taille B.P. B.P.de de maximale des entrées des sorties nécessaire nécessairepartition Cellules (Hz) (en bits) (en bits) en entrée en sortie1 973 7.424 e+7 130 128 9.651 e+9 9.503 e+92 673 9.259 e+7 64 32 5.925 e+9 2.963 e+93 672 9.259 e+7 64 32 5.925 e+9 2.963 e+94 672 9.259 e+7 64 32 5.925 e+9 2.963 e+95 672 9.259 e+7 64 32 5.925 e+9 2.963 e+9108

4.5. Exemple II : cryptage AESFig. 4.13 – Partitionnement raffiné de l’algorithme AES 109

Chapitre 4. Partitionnement sous contrainte de tempsTab. 4.9 – Implantation des partitions (128 bits) sur AT40K.Numéro de partition Nombre de Cellules Fréquence maximale (MHz)1 1185 11.252 665 12.533 665 12.534 665 12.535 665 12.53Tab. 4.10 – Implantation des partitions (128 bits) sur Virtex.Numéro de partition Nombre de CLBs Fréquence maximale (MHz)1 423 65,12 320 77,83 320 77,84 320 77,85 320 77,8On constate que l’estimation des résultats attendus des partitions est cohérente avec lesrésultats d’implantation. La figure 4.14 montre le placement routage automatique de la premièrepartition sur technologie ATMEL obtenu avec l’outil IDS. On peut distinguer les quatre modulesSBOX.4.5.4.6 Implantation sur la plate-forme ARDOISELa plate-forme ARDOISE possède un bus d’entrée de données et un bus de sortie de donnéesde 52 bits. Elle possède également un bus de données de taille 32 bits entre le FPGA et lesmémoires sud ou nord (en plus des bus d’adresses). Pour implanter l’algorithme AES nous avonsbesoin d’un bus d’entrée de données supérieur à 128 bits. Nous avons donc un nombre insuffisantde broches d’entrées/sorties sur le FPGA utilisé dans la plate-forme. Par conséquent unpartitionnement avec une taille de données 128 bits d’entrées n’est pas faisables sur ARDOISE.C’est pourquoi un étage de registre en entrée sérialisant les 128 bits d’entrées en 32 bits doit êtreintégré dans la partition 1. Cette sérialisation est gérée par un contrôleur qui assure l’acquisitiondes données d’entrées par mots de 32 bits et assure la gestion du stockage des données intermédiairesde la première partition dans une mémoire tampon d’ARDOISE. Nous ajoutons doncde la latence au traitement au profit d’un réduction drastique de la bande passante. La figure4.17 représente le graphe flot de données modifié de la première partition en vue d’une implan-110

4.5. Exemple II : cryptage AESFig. 4.14 – Vue de la première partition sur AT40K.tation sur la plate-forme ARDOISE. La figure 4.18 présente le principe de la gestion de donnéesde la première partition sur ARDOISE. Le contrôleur a été réalisé par description Verilog. Sadescription comportementale est disponible en annexe BLes partitions 2, 3, 4 et 5 (figure 4.16) peuvent être implémentées dans la plate forme AR-DOISE sans modification de leur graphe flot de données. En effet, la bande passante disponiblesur ARDOISE est largement suffisante pour mettre en oeuvre ces partitions. Ainsi, les donnéesde clé de cryptage sont stockées dans une mémoire tampon 32 bits d’ARDOISE (résultats de lapremière partition), tandis que les entrées de données ”Plaintext” 32 bits arrivent du bus d’entrées52 bits. Le tableau 4.11 donne les résultats d’implantation obtenus sur ARDOISE pourl’algorithme AES.Tab. 4.11 – Implantation des partitions (32 bits) sur AT40K.Numéro de partition Nombre de Cellules Fréquence maximale(MHz)1 1535 9.382 665 12.533 665 12.534 665 12.535 665 12.53111

Chapitre 4. Partitionnement sous contrainte de tempsFig. 4.15 – Graphe flot de données de la première partition.Le tableau 4.12 donne les résultats attendus dans le cas d’une implantation sur technologievirtex avec les contraintes externes de l’architecture ARDOISE.Tab. 4.12 – Implantation des partitions (32 bits) sur Virtex.Numéro de partition Nombre de CLBs Fréquence maximale(MHz)1 464 65.12 320 77.83 320 77.84 320 77.85 320 77.84.5.4.7 Analyse de l’implantationGain en Densité Fonctionnelle : Si on considère les résultats du partitionnement sur technologieATMEL, nous avons la spécification suivante de la plate- forme pour réaliser l’algorithmeAES :- 1185 cellules logiques.112

4.5. Exemple II : cryptage AESFig. 4.16 – Graphe flot de données des partitions 2, 3, 4 et 5.- Bus de données de 130 bits.Si nous comparons l’implantation proposée par la méthode de partitionnement en RD avecune implantation statique de l’algorithme, nous pouvons évaluer le gain en ressources matérielles.En effet, une implantation statique nécessite 3661 cellules logiques. Nous avons donc un gainen densité fonctionnelle de plus de 3. C’est à dire, que notre approche permet d’exécuter l’algorithmeavec un tiers seulement des ressources logiques nécessaires à une implantation globale del’algorithme. Au niveau bande passante, nous avons besoin de la même taille de bus de données,c’est à dire 130 bits.Si nous comparons l’implantation RD effectuée sur ARDOISE par rapport à une implantationstatique de l’algorithme, nous obtenons un gain en densité fonctionnelle de plus de 2,3.C’est à dire, que notre approche permet d’exécuter l’algorithme avec deux fois moins de celluleslogiques qu’une implantation globale de l’algorithme. De même, au niveau bande passante, uneimplantation globale nécessite une taille de bus pour les données d’entrées de plus de 128 bits.L’implantation réalisée sur ARDOISE utilise pour les données deux bus de 32 bits.113

Chapitre 4. Partitionnement sous contrainte de tempsFig. 4.17 – Graphe flot de données de la partition 1 en vue d’une implantation sur ARDOISE.Fig. 4.18 – Schéma de principe du contrôleur de données de la 1ère partition de l’algorithmeAES.114

4.5. Exemple II : cryptage AESIl est à noter qu’une implantation statique n’est pas réalisable sur la plate-forme ARDOISEétant donnée la quantité de ressources nécessaires (ARDOISE dispose de 2034 cellules logiques).Choix de la reconfiguration dynamique :Nous constatons, mise à part la première partition, que les quatre autres partitions correspondentà des traitements parallèles et peuvent être exécutées en même temps ou dans un ordrealéatoire. En effet, celles-ci sont identiques : seules les données à traiter diffèrent. Une implantationen RD des partitions 2, 3, 4 et 5 ne semble donc pas judicieuse. Une reconfiguration entreces partitions augmente le temps alloué à la reconfiguration de la matrice FPGA sans aucunemodification de l’architecture de traitement. Il est donc plus intéressant d’exécuter ces dernièrespartitions par une synthèse architecturale. C’est l’objet du paragraphe suivant.4.5.5 Implantation par Synthèse architecturale des Partitions 2, 3, 4 et 5Les partitions 2, 3, 4 et 5 traitent les données textes cryptés par blocs de 32 bits en quatreétapes. Ces quatre étapes ont les mêmes structures. Seul les entrées et les sorties de donnéessont différentes. Ainsi, il n’y a aucun intérêt à reconfigurer les mêmes opérateurs et les mêmesstructures. A partir de l’analyse du graphe flot de données, on peut ajouter un contrôleur afinde gérer les différentes données à traiter et de les stocker correctement en mémoire.La partition 1 correspond à la partition 1 de l’implantation en RD. Cette partition utiliseégalement un contrôleur pour réduire la bande passante d’entrée afin de l’adapter à uneimplantation sur ARDOISE (figure 4.17).Pour éviter que les mêmes partitions soient reconfigurées sur le FPGA, un contrôleur a étéajouté à la partition 2 comme la montre la figure 4.19. Cette partition peut remplacer à elleseule les trois autres partitions successives. Ce contrôleur assure l’adressage, la commande, lalecture et le stockage des données. Ce contrôleur a été développé de façon comportementale enlangage Verilog. Ainsi, cette approche permet de réduire la durée de traitement en évitant desreconfigurations entre les partitions 2, 3, 4 et 5.La figure 4.20 illustre le graphe flot de données de la partition obtenue.4.5.5.1 Résultats d’implantationNous avons réalisé l’implantation en ”reconfiguration et synthèse architecturale” sur la plateformeARDOISE. C’est-à-dire que l’implantation ne possède plus que deux partitions. La premièrecorrespond à la partition représentée dans la section précédente. La deuxième partitionréalise celle présentée ci-dessus. Cette partition est illustrée figure 4.20. Les tableaux 4.13 et 4.14présentent successivement les résultats d’implantation sur ARDOISE de l’algorithme AES parreconfiguration et synthèse architecturale pour les technologies ATMEL et XILINX.115

Chapitre 4. Partitionnement sous contrainte de tempsFig. 4.19 – Schéma de l’étape 2 avec le contrôleur pour lire et enregistrer les données.Tab. 4.13 – Implantation des partitions (32 bits) sur AT40K.Numéro de partition Nombre de Cellules Fréquence maximale(MHz)1 1535 9.382 954 11.69Tab. 4.14 – Implantation des partitions (32 bits) sur Virtex.Numéro de partition Nombre de CLBs Fréquence maximale(MHz)1 464 65.12 360 77.8116

4.5. Exemple II : cryptage AESFig. 4.20 – Partition obtenue par synthèse architecturale.117

Chapitre 4. Partitionnement sous contrainte de temps4.5.6 Gestion et implantation des boucles de traitement.Fig. 4.21 – Cryptage de la clé.Dans l’algorithme AES le plus important est de crypter la clé. La clé d’entrée est sur 128 bits.En effet, on peut comprendre facilement que les clés de sorties sont composées par la générationde base key et le cryptage par parties de 32 bits de expand key (Figure 4.21).Il n’est pas nécessaire de découper toutes les boucles, surtout si les boucles ne prennent pasbeaucoup de ressources. Elles n’ont donc pas énormément d’influence sur le partitionnementfinal. Le plus important est que ces boucles soient au moins présentes dans une des partitions.4.5.6.1 Déroulement de la boucleLa boucle principale inclue une succession de boucles cascadées. Le contrôleur permet degérer cette succession de traitements.Pendant le traitement des algorithmes AES, les cinq partitions seront découpées par DA-GARD, en essayant de conserver des partitions le plus homogène possible. En pratique, la premièrepartition est plus grande que les autres partitions parce qu’elle contient le générateurde base key et de expand key. Le dernier générateur expand key est composé d’une boucle quicontient les quatre autres petites boucles. La figure 4.22 montre la structure de la première118

4.5. Exemple II : cryptage AESFig. 4.22 – Structure de la première partition.partition. La petite ellipsoïde contient le générateur de base key et la grande ellipsoïde contientle générateur de expand key. Les petites parties circulaires sont les petites boucles qui sontcontenues dans la grande boucle.Fig. 4.23 – Schéma de la boucle.La figure 4.23 montre une boucle typique composée par un cycle et un contrôleur. Le nombrede cycles est donné par le contrôleur. Le dernier cycle exporte les résultats. Une boucle entièredoit toujours être considérée comme une suite de cycles en cascade. C’est-à-dire qu’on découpele cycle couche par couche, on met ensuite en cascade toutes les couches en les déroulant dans lemême plan (fig. 4.24). On pourra par la suite faire un partitionnement avec les méthodes définiesprécédemment.119

Chapitre 4. Partitionnement sous contrainte de tempsFig. 4.24 – (a) découpe la boucle couche par couche. (b) cascade des boucles.Bien que dérouler la boucle permette un partitionnement, un déroulement de boucle nedevient viable pour une implantation en RD que si le nombre de cycles est raisonnable afin decontinuer à respecter la contrainte de temps.La figure 4.25 illustre le principe d’implantation d’un déroulement de boucle.En a : un algorithme avec une boucle trop importante, le nombre de cellules qui est utilisé danscet algorithme est supérieur à la surface maximum du FPGA.En b : la surface maximum de FPGA.En c : Tp est le temps d’implantation global, Tc est la contrainte de temps. On déroule laboucle qui est contenue dans l’algorithme. La nouvelle structure est plus grande que la structureoriginale, le nombre de cellules de la nouvelle structure est 2 fois plus grand que le nombrede cellules de la structure originale. On fait le découpage pour la nouvelle structure avec unesurface minimale, la nouvelle structure est découpée en 3 étapes, la surface de chaque étape estinférieure ou égal à la surface du FPGA. A la fin, la contrainte de temps a un rôle importantdans le système reconfigurable. Le temps d’implantation global pour implanter cette nouvellestructure est inférieur à cette contrainte.A partir de cet exemple on notera qu’on peut utiliser cette méthode uniquement dans le casoù le temps d’implantation global de la structure avec déroulement est inférieur à la contraintede temps.120

4.5. Exemple II : cryptage AESFig. 4.25 – Illustration de la méthode de déroulement de boucle.4.5.6.2 Implantation de boucle par synthèse architecturaleOn peut remplacer plusieurs boucles identiques par une seule boucle associée à une logiquede contrôle (synthèse architecturale) assurant la réutilisation de la même boucle pour réaliserl’ensemble des boucles initialement présentes dans le traitement. On peut par exemple utiliser desmultiplexeurs-démultiplexeurs pour réaliser cette synthèse architecturale. La figure 4.26 illustrele principe.4.5.6.3 Implantation de l’algorithme AES avec optimisation de boucleNous avons appliqué une synthèse architecturale pour réaliser plusieurs boucles contenuesdans la première partition des implantations présentées précédemment. Nous avons utilisé uncouple multiplexeur-démultiplexeur contenant une seule boucle dans le but de lui faire réaliserles quatre boucles initialement présentes dans la partition 1 (cf. figure 4.27).Le tableau 4.15 montre les résultats d’implantation de l’algorithme AES sur AT40K sans etavec synthèse architecturale.En comparant les deux résultats, le nombre de cellules ne diminue pas, parce que l’on autilisé des multiplexeurs dont la taille est plus grande que la taille de l’ensemble des bouclesinitiales ! En effet, les couples multiplexeur-demultiplexeur utilisent plus de ressources logiquesque l’ensemble des boucles. C’est pourquoi le nombre de cellules avec modification est supérieur121

Chapitre 4. Partitionnement sous contrainte de tempsFig. 4.26 – Comparaison des deux algorithmes.Fig. 4.27 – Graphe flot de données de la partition 1 avec multiplexeur-démultiplexeur en vued’une implantation sur ARDOISE.122

4.5. Exemple II : cryptage AESTab. 4.15 – Comparaison d’implantation des partitions.Partition Nombre de Cellules Fréquence maximale (MHz)Sans modifications 1535 9.38Avec modifications 1565 9.37au nombre de cellules sans modification. Dans notre cas une synthèse architecturale ne semblepas efficace.4.5.7 Bilan et discussionDans cette section nous avons présenté et détaillé l’implantation de l’algorithme de cryptageAES contenant des boucles de traitement. Pour implanter l’algorithme nous avons utilisé deuxméthodes. L’une exploitant entièrement la RD et la seconde utilisant la combinaison RD -synthèse architecturale.L’implantation en RD a été réalisée selon une méthodologie de partitionnement permettantd’optimiser les ressources logiques du FPGA. Nous avons réalisé le partitionnement del’algorithme AES à l’aide de l’outil DAGARD qui permet une exécution automatique de notreméthode. Le partitionnement final correspond à un partitionnement raffiné manuellement afinde surmonter les contraintes de boucles de traitement. A partir de ces résultats, nous obtenonsla spécification de l’architecture nécessaire à l’exécution de notre application avec la plus petitesurface logique reconfigurable possible.Nous avons déduit de cette première implémentation le besoin d’utiliser d’autres méthodesd’implémentation en complément de celle exploitant la reconfiguration. Nous avons réalisé uneimplantation qui réutilise les opérateurs déjà implantés pour exécuter certaines partitions aulieu de les reconfigurer entre deux partitions successives.Nous avons également proposé quelques pistes pour traiter les boucles de traitement aucours d’une implantation en RD. En effet, pendant le partitionnement temporel, nous pouvonstoujours négliger les petites boucles sauf celles qui chevauchent deux partitions.Lorsqu’une partition contient plusieurs boucles identiques (c’est à dire réalisant les mêmesopérations), il est possible d’insérer une logique de contrôle à l’une d’entre elles afin qu’elleréalise l’ensemble des boucles devant être présentes dans la partition considérée. Dans le cas oùune boucle se situe sur plusieurs partitions, un déroulement de cette boucle est nécessaire et sonimplantation s’exécute par synthèse architecturale entre les différentes partitions. Dans ce cascette partition demeure pendant toute la durée nécessaire à l’exécution de la boucle et peut donccorrespondre à une partie statique entre des partitions successives. Le seul critère qui devra êtrerespecté est que le temps global d’exécution reste conforme à la contrainte de temps imposée.123

Chapitre 4. Partitionnement sous contrainte de temps4.6 ConclusionNous venons de présenter une méthode d’aide à la conception/réalisation de circuits et d’applicationsprenant en charge la reconfiguration dynamique. L’outil qui est dérivé de cette méthodepermet de spécifier rapidement les besoins de l’architecture nécessaire à l’implantationd’un algorithme, au regard des différentes contraintes de temps et contraintes technologiques.Les deux exemples présentés sont issus de domaines d’applications différents. Néanmoins, aucuneoptimisation de ces algorithmes n’avait été entreprise préalablement à l’utilisation de notreoutil. De ces travaux nous pouvons retenir un point important :Comme nous pouvions nous en douter, la reconfiguration dynamique n’est pas la réponsemagique à tous les problèmes d’implantation. Elle permet effectivement d’augmenter virtuellementla surface logique disponible sur le composant reconfigurable. Elle permet ainsi de réaliserdes applications qui n’auraient put être implanté sur ce composant de façon statique. Mais lareconfiguration dynamique présente également un certain nombre de contraintes qui peuvent devenirtrès pénalisantes dans certains cas. Les contrôles et boucles de traitements en trop grandnombre ou de taille logique trop importante sont difficiles à mettre en oeuvre en reconfigurationdynamique. Leur caractère ”permanent” s’oppose par nature à une reconfiguration fréquente.De plus, nous avons ici utilisé une méthode de partitionnement adaptée aux applications detype graphe flot de données ”régulier”. De nombreuses applications présentent des changementsde traitements. Par exemple en fonction de la nature des données ou en fonction des résultatsdes calculs précédents. Nous pouvons dire que ces applications présentent des graphes flot dedonnées ”irréguliers” puisque ces données ne subiront pas toujours le même traitement. Remarquonségalement que le fait de changer la nature du traitement se traduit par l’exécution dedifférentes branches du graphe flot de données. Ces différentes parties du traitement s’excluentalors mutuellement : en fonction du résultat précédent, on va exécuter telle OU telle branchedu graphe.La reconfiguration dynamique a un rôle intéressant à jouer dans ce genre d’applications. Ellenous permet de modifier dynamiquement l’implantation du traitement présent sur le composant.Cela peu donc nous permettre d’avoir un circuit toujours en adéquation avec le traitement àeffectuer. Les conséquences attendues de la reconfiguration dynamique dans de telles applicationssont alors :– une réduction de la surface nécessaire à l’implantation de l’application : toutes les branchesexclues du traitement n’ont pas à se trouver sur le composant.– une réduction de la consommation électrique : les branches exclues du composant ne présententplus une consommation électrique inutile.– une plus grande flexibilité d’implantation de l’algorithme qui nécessite donc des outils pourguider le concepteur dans ses choix.124

4.6. ConclusionC’est vers ces nouvelles problématiques que nos travaux ont évolués. Ces travaux sont l’objetdu chapitre suivant.125

Chapitre 4. Partitionnement sous contrainte de temps126

Chapitre 5Exploration multicritères5.1 IntroductionLors de la conception d’un circuit, bien des critères permettent de définir si le circuit estoptimal ou non. Auparavant, optimiser une implantation sur FPGA pouvait sembler plus simple.En effet, le fait que le circuit soit configuré lors de sa mise sous tension uniquement, réduit lescritères à prendre en compte pour optimiser cette implantation. L’application est alors configuréedès le début du traitement et ne peut plus changer au cours de celui-ci. Les propriétés principalesde l’implantation sont alors le temps de traitement des données et la surface logique nécessaire àson implantation. Ces propriétés sont uniquement le fait de la technologie FPGA employée ainsique de la synthèse de l’application. Pour optimiser une implantation sur une cible technologiquedonnée, le seul moyen est alors de modifier l’algorithme lui même. La synthèse architecturale,le parallélisme, la profondeur de pipeline de l’architecture constituent les principaux moyensd’optimisation de la future implantation.5.2 Critère d’optimalité5.2.1 De nouvelles contraintesAujourd’hui, tous ces moyens restent disponibles. Mais à ceux-ci s’ajoute la possibilité degérer dynamiquement quelle partie de l’application sera implantée à un temps T, et quelle autrepartie le sera à un temps T +∆t [WH98, MY03, CLC + 02, GL99]. Cette possibilité de gérer dynamiquementl’utilisation de la surface logique disponible modifie profondément les propriétésde l’application générale. Le temps de traitement est modifié au gré de différentes reconfigurations.Le fait d’exécuter l’application en plusieurs partitions provoque une modification de labande passante mémoire nécessaire au stockage des données intermédiaires. Pour satisfaire àune éventuelle contrainte de temps, l’exécution de l’application en reconfiguration dynamique127

Chapitre 5. Exploration multicritèrespeut nécessiter une augmentation de la fréquence de travail. Il en résulte bien souvent uneaugmentation de la puissance électrique dissipée par le circuit.Nous adressons ici ces nouvelles contraintes. Nous considérerons par la suite que tout letravail d’optimisation de l’algorithme lui-même a été fait et nous nous attacherons uniquementà optimiser son implantation.5.2.2 De nouveaux outilsDans nos précédents travaux [BTBW03, TBWB03] présentés principalement dans les chapitres3 4, nous avons présenté une méthode et un outil permettant de minimiser la surfacelogique nécessaire à la réalisation d’une application dans le cadre de l’utilisation de la reconfigurationdynamique (RD) sur FPGA.Cette méthode a été validée par diverses applications dans le domaine du traitement d’images.Cette méthode basée sur l’utilisation de graphes flot de données (GFD) se contentait d’adresserdes applications régulières. Les graphes flot de données non réguliers (pouvant inclure différentschemins / tâches en fonction des données, en fonction des résultats précédents, etc.) ne pouvaientpas être analysés par cette précédente méthode.Maintenant, le but est de gérer les reconfigurations de la surface logique (de sorte à optimiserdifférent paramètres) dans le cas où nous ne savons pas quel chemin les données peuvent prendredans le GFD. Cela implique que nous ne connaissons pas forcément le chemin emprunté parun bloc de données à travers les différentes branches d’exécution constituant le graphe flot dedonnées représentant notre application.Des outils permettant de guider le concepteur dans la réalisation d’applications on été développés[MKDP03, Ka91, La92, Ga98]. Chacun apporte sa spécificité ou sont domaine de prédilection.Pour notre part, nous ne cherchons pas à proposer un partitionnement final. Plusgénéralement, nous donnons un aperçu des performances que chaque partitionnement possibleengendrera sur différents paramètres essentiels. C’est alors au concepteur de choisir celui quiconvient le mieux à ses besoins et présente la meilleure adéquation implantation en reconfigurationdynamique - architecture.5.2.3 Un compromisCompte tenu de toutes les possibilités offertes par la reconfiguration dynamique, ainsi que detous les bouleversements qu’elle peut entraîner lors de l’implantation d’une application, définirqu’une implantation ou une autre est optimale est sujet à discussion. En effet, une améliorationd’un des critères précédemment cités amènera certainement une dégradation d’un autre critère.Par exemple, réaliser de plus petites partitions afin de réduire la surface logique nécessaire àl’implantation de l’application nécessitera d’augmenter le nombre de reconfigurations et donc128

5.2. Critère d’optimalitéd’augmenter la fréquence de travail ou le temps de traitement. Ainsi la meilleure implantationsera le fruit d’un compromis entre les différentes améliorations apportées par la reconfigurationdynamique. En fonction des contraintes sur l’application, ce compromis peut changer en faveurde tel ou tel critère. Le fait que l’application se doive de répondre à une contrainte de tempsstricte impliquera, par exemple, d’accorder une plus grande importance au temps de traitement.Une application embarquée sur une plate-forme déjà existante devra répondre en priorité à unesurface logique maximale fixée.Dans ces conditions, notre réflexion nous a amené à prendre en compte l’ensemble des possibilitésoffertes par la reconfiguration dynamique. Nous apportons avant tout une vue d’ensemblede différentes façons de tirer parti de la reconfiguration dynamique. C’est ensuite au concepteurde définir l’importance accordée aux différents critères pris en compte. Une fois ces importancesrelatives définies, nous ajoutons à cette vue d’ensemble un classement des solutions reflétant leuradéquation avec les besoins du concepteur.5.2.4 Critères retenusAfin de répondre au mieux aux attentes d’un concepteur de systèmes, les critères retenussont :– La surface logique nécessaire à la réalisation de l’application.– La bande passante nécessaire entre le FPGA et la mémoire.– Le temps d’exécution maximum de l’application.– Le temps d’exécution statistique de la partition.– L’activité de l’application.Comme nous adressons des applications non régulières, nous ne savons pas quel chemin lesdonnées vont prendre. Par conséquent, les partitions sont réalisées de sorte à calculer différentschemins qui peuvent ne pas être utilisés à chaque passage des données. Est-ce une meilleuresolution que de perdre en surface logique pour implanter un chemin qui ne sera exécuté queoccasionnellement ou est-il préférable de perdre du temps en reconfigurations lorsque se présentecet improbable cas ? Notre exploration inclut toutes ces possibilités. Ces possibilités vontdifférer entre elles par les différentes valeurs que prendront les critères que nous avons présentésprécédemment. Ces critères changeront en fonction des choix de partitionnement.5.2.5 Surface LogiqueLa surface logique peut varier de celle correspondant à l’application complète implantéeen statique (surface maximale), jusqu’à la surface de la plus grosse entité du graphe (surfaceminimale).129

Chapitre 5. Exploration multicritères5.2.5.1 Bande PassanteCe paramètre représente les besoins en matière de transfert de données entre la surface reconfigurableet les mémoires externes. Ceux-ci sont amenés à varier en fonction du partitionnementde l’application et des données temporaires à sauvegarder entre les différentes partitions.Nous apportons deux caractérisations différentes de cette bande passante. La première prenden compte les besoins en bande passante lorsque toutes les données sortantes de la partitiondoivent être mémorisées. La seconde ne prend en compte que les données destinées à la partitionsuivante (lorsque celle-ci est connue à l’avance).En effet, si le chemin pris par les données n’est connu qu’à la fin des calculs de la brancheactuelle, nous devons conserver toutes les données temporaires concernant l’exécution de tousles chemins possibles jusqu’à ce que nous sachions lequel sera réellement exécuté. Dans ce casla bande passante maximale nécessaire prend en compte toutes les entrées-sorties de la branche.Dans le cas contraire, si la branche suivante est connue dès l’exécution de la branche actuelle(dans le cas de données contenant une entête), nous ne devons conserver en mémoire que lesdonnées concernant la branche suivante. Dans ce cas, la bande passante mémoire que nousprenons en compte est égale au besoin maximum entre la branche actuelle et les sous branches.5.2.5.2 Temps d’exécutionLe temps d’exécution ne peut être calculé puisque nous ne connaissons pas le chemin précisque vont suivre les données. Ce chemin pouvant d’ailleurs changer à chaque exécution. Afin depouvoir estimer et comparer les différences entre partitionnements en matière de temps d’exécution,nous apportons deux estimateurs différents du temps d’exécution.Le premier est le temps d’exécution le plus long de tous les chemins du graphe. Le secondest la somme des temps d’exécution de chaque chemin du graphe, modérée par la probabilitéd’exécution de chacune des branches.Ainsi, nous avons le temps d’exécution maximum de l’algorithme, et une estimation de sontemps d’exécution moyen. Ces deux temps prennent évidement en compte les temps de reconfigurationdes diverses partitions.5.2.5.3 ActivitéLe dernier critère que nous voulons mesurer est la consommation électrique de l’algorithme.Malheureusement pour donner une estimation précise de cette consommation nous avons besoind’une connaissance précise de l’implantation finale, de calculs plus longs et d’une connaissanceencore plus poussée de l’architecture cible.Nous ne voulons pas effectuer les opérations de placement et routage pour chaque possibilitéde partitionnement dans le seul but de donner cette estimation de la consommation. Notre but130

5.2. Critère d’optimalitéFig. 5.1 – vue générale du graphe flot de données sous DAGARD.est en fin de compte de donner des moyens de comparaison entre les consommations engendréespar les différents partitionnements plus que de donner leur valeur numérique exacte.En conséquence, nous avons choisi d’utiliser un estimateur que nous appelons l’ ”Activité”.Cette activité est la somme des bandes passantes mémoire de chaque partition du découpageenvisagé. Cette activité prend donc en compte la fréquence de travail de chaque partition et lataille des données traitées par chacune d’elles. Entre deux partitionnements différents, l’activitéva donc varier en fonction des différents découpages et non en fonction des traitements quirestent identiques quel que soit le découpage.131

Chapitre 5. Exploration multicritères5.3 Exploration de l’espace de partitionnementLes applications utilisant la reconfiguration dynamique ainsi que les systèmes sur puces fontpartie des plus hautes priorités dans les centres de recherche en électronique moderne. Ceci estessentiellement dû au fait que ces systèmes autorisent un nouveau paradigme dans le traitementdes données. La conception de systèmes embarqués peut tirer de nombreux avantages de l’utilisationde la reconfiguration temps réel (RTR) des composants logiques programmables (FPGA,..).Par exemple, nous pouvons utiliser la caractéristique de reconfiguration dynamique des FPGAspour instancier un opérateur uniquement lorsque celui-ci est nécessaire et ensuite récupérer lasurface logique qu’il occupait en vue d’un autre traitement. Actuellement, les systèmes embarquéssont constitués de divers composants hybrides. Ces SoCs (Systems on Chip) qui combinentune surface logique de type FPGA avec des composants ASICs ont fait de la reconfigurationmatérielle une solution viable et flexible pour les systèmes embarqués. Un chemin de donnéespeut-être implémenté sur une surface logique type FPGA alors que le contrôle est confié à unplus haut niveau, à un processeur ou un autre FPGA ou mieux encore, à une partie statiquede ce même composant. Ce genre d’implantation permet une grande flexibilité, adaptabilité etréutilisation des architectures.Fig. 5.2 – Vue Générale d’un SoC configurable dynamiquement.Malheureusement, la diversité et le manque de normes pour ces nouveaux systèmes conduisentà un faible support logiciel pour ces composants commerciaux. La première conséquence pourl’architecte est l’ignorance de toutes les possibilités offertes par ces nouveaux composants. Laseconde est le besoin de dépenser plus de temps pour développer une application utilisant lescapacités de reconfiguration dynamique du composant utilisé.Grâce à la reconfiguration dynamique, une application peut-être découpée (partitionnée) dedifférentes façons, en fonction de différents critères d’optimisation (surface logique, consommation,besoins en bande passante). Chaque partition correspond à un partage temporel du systèmereconfigurable dynamiquement. Mais le nombre de possibilités est vaste et les développeurs biensouvent ne veulent pas perdre leur temps à explorer l’ensemble de ces possibilités. De plus,l’optimisation selon certains critères peut conduire à la dégradation d’autres critères (exemple :132

5.3. Exploration de l’espace de partitionnementfréquence d’exécution / consommation électrique). Donc, l’implémentation finale sera le résultatd’un compromis de diverses optimisations.Afin de s’assurer de faire le bon choix et grâce à l’utilisation d’une librairie d’opérateurs caractérisésen fonction du composant ciblé, ainsi que quelques contraintes technologiques spécifiques,nous présentons une exploration complète des possibilités d’implémentation en reconfigurationdynamique offerte pour un graphe flot de données.Fig. 5.3 – Intégration de DAGARD dans le flot de conception.L’originalité de ce travail est que nous présentons une vue d’ensemble de toutes les possibilités,ce qui permet une comparaison entre ces dernières suivant divers paramètres significatifs(surface logique, bande passante mémoire, temps d’exécution, etc.). De plus, le concepteur peutdéfinir l’importance relative de chaque paramètre en fonction de ses besoins. Une connaissance133

Chapitre 5. Exploration multicritèresstatistique sur l’exécution de l’algorithme peut être prise en compte pour la décision de partitionnementfinal. Nous proposons un outil (adaptation de DAGARD aux GFDs non réguliers)qui s’insère dans le flot de conception de l’application. Cet outil aide et accélère le choix dupartitionnement afin de créer les reconfigurations successives de la surface logique du FPGA.5.3.1 Définition du graphe flot de donnéesDAGARD est basé sur une librairie d’opérateurs caractérisés qui dépend de l’architecturecible. Ces opérateurs sont des opérateurs bas niveau. Ils constituent les noeuds du graphe et lesdépendances de données entre ces opérateurs constituent les arcs du graphe. Il est égalementpossible de définir des macro-opérateurs dès lors que l’on est capable de les caractériser en termede temps d’exécution et de surface logique sur la cible technologique.5.3.1.1 Caractérisation des opérateursChaque opérateur du graphe flot de données est défini par son nom (représentant sa fonction),le nombre et la taille de ses entrées et sorties, son temps d’exécution (donné par une fonction dépendantede la taille des données manipulées et de la technologie), le nombre de cellules logiquesnécessaires à sa réalisation (donné par le même type de formule que le temps d’exécution), etquelques autres données (format graphique, textes affichés). Chaque opérateur peut être dérivéd’un opérateur existant ou entièrement créé. Pour caractériser le temps d’exécution et le nombrede cellules nécessaires à l’implantation de chaque partition du GFD, nous commençons par unecaractérisation de chaque opérateur de ce graphe pour une technologie FPGA donnée. Noussommes ainsi capable de calculer le temps d’exécution le plus élevé des opérateurs contenus dansle graphe, ainsi que la somme des cellules logiques nécessaires à la réalisation de l’application.Ce travail peut-être fait sur n’importe quelle technologie FPGA.La façon dont nous réalisons cette caractérisation est présentée en section 3.2.25.3.1.2 Caractérisation des branchesPour cette version de notre outil de partitionnement, nous avons choisi de ne pas couperl’algorithme à l’intérieur d’une de ses branches. Une telle branche peut être considérée commeun sous graphe régulier du graphe complet. Ainsi nous avons maintenant à caractériser chaquebranche du graphe comme nous l’avons fait précédemment pour les opérateurs qu’elle contient.Pour cela nous utilisons les opérateurs précédemment caractérisés et nous calculons les mêmespropriétés pour la branche complète (temps d’exécution, surface logique nécessaire). À ces propriétés,nous ajoutons des propriétés spécifiques qui permettront ensuite l’exploration des possibilitésde partitionnement : la bande passante mémoire nécessaire en entrée de la branche, labande passante mémoire la plus élevée vers une autre branche en sortie, la somme des bandes134

5.3. Exploration de l’espace de partitionnementpassantes mémoire vers d’autres branches en sortie, la probabilité d’exécution de ses branches.On crée ainsi une caractérisation complète de la bande passante. En fait, nous représentons lataille des bus en entrée et en sortie des branches. La bande passante réelle pourra être recalculéepar la suite dès lors que nous connaîtrons la fréquence de travail de la branche. Nous caractérisonsla bande passante nécessaire si nous connaissons par avance la branche qui sera exécutéeimmédiatement après mais également la bande passante nécessaire au stockage de toutes lesdonnées intermédiaires dans le cas où cette connaissance n’est pas disponible. La probabilitéd’exécution de la branche n’est pas calculée mais définie par l’utilisateur en fonction de sesconnaissances sur l’exécution des différentes branches de l’algorithme.5.3.2 Exploration des possibilités de partitionnement.5.3.2.1 Énumération des possibilités architecturalesPour réaliser une exploration complète des possibilités de partitionnement, nous devonsconstruire l’ensemble de toutes ces possibilités. Pour faire cela, nous commençons par la premièrebranche du graphe flot de données qui se doit d’être dans la première partition. Pour chaquesous branche, nous avons deux possibilités :– la sous branche est dans la partition actuelle.– la sous branche et dans une nouvelle partition.De plus, deux sous branches ne peuvent appartenir à une même nouvelle partition. Un algorithmerécursif permet alors de construire la liste de tous les partitionnements possibles répondant àces règles. Il en découle également que le nombre de possibilités de partitionnement est lié aunombre de branches contenues dans le graphe flot de données de la manière suivante :Nombre de partitionnements = 2 nb branches−1 (5.1)Bien entendu, toutes ces possibilités ne sont pas intéressantes. L’étape suivante est alors lecalcul de toutes les propriétés de ces différents partitionnements afin d’en autoriser l’explorationet la sélection.5.3.2.2 Exploration des possibilités architecturalesDu premier partitionnement qui correspond à une implémentation statique de l’algorithme(toutes les branches du graphe flot de données sont incluses dans une partition unique) audernier partitionnement possible qui est le plus dynamique de tous (chaque branche du grapheflot de données correspond à une nouvelle partition), nous allons calculer les propriétés de chaquepartition. Ces propriétés sont les mêmes que celles présentées précédemment pour les branches.Leur valeurs vont quant à elles changer en fonction de l’agencement des branches dans lesdifférentes partitions. Par exemple, si deux branches sont dans la même partition, la surface135

Chapitre 5. Exploration multicritèreslogique nécessaire pour la partition sera la somme des surfaces logiques de chacune des branches.La fréquence de travail correspondra à la plus faible fréquence de travail des deux branches.Nous n’aurons pas à prendre en compte la bande passante nécessaire entre ces deux branches.Ces dernières étant pipelinées dans la partition, les communications seront donc internes à lapartition et routées dans le circuit. Par contre, nous prendrons en compte les besoins en bandepassante mémoire des données entrantes et sortantes de la partition.Fig. 5.4 – Vue graphique des possibilités de partitionnement.Une fois cette étape accomplie, nous calculons les propriétés de chacun des partitionnementspossibles comme étant le maximum des besoins générés par ses partitions. Nous obtenons ainsiles caractéristiques de chacun des partitionnements possibles pour notre application en reconfigurationdynamique. Une fois de plus, ces caractéristiques sont : la surface logique nécessaireà l’implantation de l’application, la bande passante mémoire nécessaire, le temps d’exécutionmaximum de l’application, le temps d’exécution moyen de l’application (prenant en compte lesprobabilités d’exécution des branches), l’activité totale de la partition.L’exploration est facilitée par un affichage graphique de l’ensemble des paramètres précédemmentcalculés pour chaque partitionnement. Cet aperçu est disponible sous deux modesdifférents. Le premier mode est un ensemble de quatre graphiques représentant la surface lo-136

5.3. Exploration de l’espace de partitionnementFig. 5.5 – Seconde vue graphique des possibilités de partitionnement.gique nécessaire en abscisse ainsi que l’un des quatre autres critères en ordonnée. Le secondmodèle est une visualisation en forme de toile d’araignée. Chaque partitionnement constitue unpentagone pour lequel la distance entre le centre et un sommet est la représentation d’un descritères. Dans cette représentation, le pentagone le plus petit pourrait être le meilleur choix pourl’architecture si l’on accorde la même importance à chacun des critères. Durant le calcul des caractéristiquesde chacun des partitionnements, les différentes valeurs des critères sont enregistrésafin que l’architecte puisse y faire référence une fois qu’il aura effectué le choix de son partitionnement.Grâce à tout cela, le concepteur est capable de comparer et choisir selon différentscritères le partitionnement qui répondra le mieux à ses besoins. Afin d’identifier le partitionnementrépondant au mieux à ses besoins, une navigation à travers les différents partitionnementsest possible.5.3.2.3 Classification des partitionnementsUne autre solution pour trouver le partitionnement le plus adéquat est de réaliser un classementde toutes ces possibilités. Cette classification est faite pour chaque partitionnement possiblegrâce à la somme algébrique suivante :137

Chapitre 5. Exploration multicritèresEV = K 1 .Cell + K 2 .T + K 3 .T P + K 4 .BP + K 5 .Activ (5.2)Cette valeur représente la pertinence d’un partitionnement en fonction de l’importance accordéepar le concepteur à chaque paramètre. Le concepteur peut adapter cette classification despartitionnements en modifiant les facteurs de chaque paramètre intervenant dans cette évaluation(Ki). Il peut par exemple donner plus d’importance aux critères de surface logique qu’autemps d’exécution de l’algorithme.5.3.3 Exemple théoriquePour illustrer notre méthodologie, nous avons travaillé sur un exemple théorique (Figure 5.6).La structure proposée présente une non-régularité et la complexité qu’un algorithme réel pourraitposséder. Le but de cet exemple est de montrer la diversité des possibilités de partitionnement etl’efficacité de l’aide qu’apporte notre outil au concepteur pour faire les bons choix architecturaux.Cet exemple est constitué de branches de différentes tailles (surface logique), de bus d’entréessorties de tailles différentes, de différents temps de calcul et de différentes probabilités d’exécutiondes branches.D’après la méthodologie que nous venons de présenter, cet exemple composé de dix branches,va produire 512 partitionnements différents (2 nbbranches−1 ). Les figures 5.4 et 5.5 présentées précédemmentsont issues de cet exemple. Chaque partitionnement est représenté par son positionnementdans les différents graphiques.Il est possible de naviguer parmi ces partitionnements. La sélection de l’un d’eux met enévidence sa représentation dans les différents graphiques (affichage rouge).La sélection d’un point dans un graphique permet de mettre en évidence tous les partitionnementsayant le même couple de caractéristiques dans les autres graphiques. On obtient ainsi unmoyen de différencier ces partitionnements sur les autres caractéristiques que celles du graphiquepointé.On cherchera en général à minimiser les différents paramètres. Par conséquent, les partitionnementsles plus intéressants se trouvent proche de l’origine des différents graphiques.Le concepteur peut également vouloir faire un effort sur une caractéristique particulièrecomme par exemple la surface logique. Dans ce cas il choisira le partitionnement minimisant lesautres propriétés pour la surface logique minimale présentée par DAGARD.138

5.4. RésultatsFig. 5.6 – Graphe flot de données théorique pris comme exemple.5.4 RésultatsNous avons présenté une méthode accompagnée d’un outil permettant d’explorer les possibilitésofferte par le partitionnement d’une application grâce à la reconfiguration dynamique. Lesavantages et inconvénients des différentes possibilités sont rendus visibles d’un seul coup d’oeil,139

Chapitre 5. Exploration multicritèrespermettant ainsi au concepteur d’orienter l’optimisation de son application suivant les différentscritères retenus. Il peut ainsi trouver la meilleure adéquation entre l’architecture ciblée etl’implantation de son application en reconfiguration dynamique.Dans le cadre d’applications non-régulières, nous envisageons la possibilité de retenir plusieurspartitionnements. Le contrôleur de reconfiguration sera alors chargé de choisir en tempsréel lequel est le plus approprié en s’appuyant sur la fréquence d’exécution des différentesbranches de l’algorithme. La réalisation de ce contrôleur pourra être assignée à une partie statiquedu FPGA, à un autre circuit de contrôle ou encore à un microprocesseur gérant les tâchesà un plus haut niveau.Les étapes suivantes de notre travail sont une prise en compte des possibilités de partitionnementà l’intérieur des branches. Cela sera possible grâce à l’intégration de nos précédentstravaux. Nous prévoyons également une démonstration de notre méthode sur une applicationréelle. Celle-ci devrait donner lieu à plusieurs implantations illustrant la diversité des optimisationsenvisageables grâce à la reconfiguration dynamique.140

5.5. DagARD 2 : structures utilisées5.5 DagARD 2 : structures utiliséesDe la même façon que la méthode de partitionnement sous contrainte de temps, l’explorationmulti-critères à été intégrée à l’outil logiciel DagARD. Elle s’appuie sur les mêmes librairiesd’opérateurs, de contraintes et de technologies.Dagard traite des graphes flot de données. Pour cela, il utilise différentes types de donnéespour modéliser les opérateurs et dépendances de données du graphe. Il doit également intervenirsur des structures dérivées du graphe. Les plus pertinentes de ces variables, structures et classes,sont les suivantes :Les noeuds représentent les opérateurs, macro-opérateurs ou tâches du graphe.Les arcs représentent les dépendances de données entre les noeuds du graphe.Les branches regroupent un ensemble de noeuds dans une partie du graphe qui peut êtreconsidérée comme régulière.Les chemins tracent les différents chemins que peuvent suivre les données dans le graphe. Cesont les différents arrangements possible des branches du graphe.Les partitionnements représentent les possibilités d’ordonnancer les différentes branches dansdifférentes partitions.Noeuds et Arcs : Une liste des noeuds et des arcs est constituée. L’ajout d’un opérateurajoute un noeuds dans la liste des noeuds, chaque nouvelle liaison ajoute une entrée dans la listedes arcs. Donc chaque élément est accessible via la liste à laquelle il appartient et son numérod’entrée.Les structures noeuds et arcs sont liées dès lors qu’elles représentent un opérateur et sesdépendances de données. Pour cela la structure noeuds contient la liste des entrée arcs correspondantà ces entrées et sorties. De même, la structure arcs contient les numéros des deuxnoeuds(dans la liste des noeuds) dont elle représente la connection. Le programme peu ainsicheminer d’opérateur en opérateur dans la graphe.Branches : Les branches permettent de rassembler les caractéristiques d’un ensemble d’opérateursreprésentant un sous-graphe régulier du graphe flot de données général (Fig. 5.7a. (opérateurs)vers 5.7b.(branches)). Une liste des branches du graphe permet d’accéder à chacuned’elles par leur numéro.Chemins : Les chemins sont des listes de numéros de branches. Une telle liste de numéroscommence toujours pas la branche d’entrée du graphe. Les différents numéros permettent desuivre un chemin possible pour les données à travers le graphe (Fig. 5.7c.).141

Chapitre 5. Exploration multicritèresFig. 5.7 – Flot de traitement du GFD.Partitionnements : Comme décrit précédemment, l’ensemble des agencements possibles desbranches est calculé. Pour chacun de ces partitionnements, Dagard effectue le calcul du tempsnécessaire à l’exécution de chaque chemin afin de caractériser le temps de traitement maximumet statistique de l’algorithme pour le partitionnement considéré. Durant ce parcours, Dagardeffectue également la caractérisation de l’activité.142

5.5. DagARD 2 : structures utiliséesLes représentations sont construites une fois les caractéristiques de chaque partitionnementcollectées. A ce même moment, ces résultats sont sauvegardés sous forme ”texte” et référencéspar un numéro correspondant au partitionnement considéré.De même, le classement des partitionnements suivant les critères du concepteur est réaliséaprès cette collecte des caractéristiques des partitionnements.La recherche d’une solution peut alors se faire de deux façons différentes :– en parcourant la liste des partitionnements (ou la liste classée). Les caractéristiques dupartitionnement courant sont alors signalées en rouge sur les graphiques.– en pointant une valeur dans un des graphiques. Le logiciel affiche alors la liste des partitionnementscorrespondant à ces coordonnées.143

Chapitre 5. Exploration multicritères144

Chapitre 6Conclusion6.1 ConclusionsLe calcul reconfigurable est un domaine en pleine effervescence. Toutes les solutions fontl’objet d’études de la part des centres de recherche, aussi bien au niveau universitaire qu’auniveau industriel. L’intérêt du calcul reconfigurable est d’adapter la structure matérielle au calculou à la tâche à effectuer. Lors de l’exécution d’un calcul sur un processeur à instructions fixes,c’est le calcul(ou la tâche) lui même qui doit s’adapter à la structure de traitement. Cela nécessiteune décomposition du calcul en plusieurs étapes ce qui augmente le temps de traitement total.On obtient donc une efficacité beaucoup plus élevée grâce au calcul reconfigurable. Néanmoins,ce gain de performance est accompagné d’une augmentation de la complexité de mise en oeuvredu calcul reconfigurable.Notre travail se porte particulièrement sur la reconfiguration dynamique sur circuits FPGA.Les progrès de ces composants en terme de surface logique (nombre de portes logiques équivalentes),en temps de reconfiguration, en souplesse de reconfiguration (reconfiguration partielle)permettent de penser autrement les implantations d’applications sur ces composant. Ainsi, mêmesi la taille croissante de ces circuits nous laisse penser que toutes les applications peuvent tenirsur ”un gros FPGA”, c’est surtout en terme de souplesse, d’évolutivité, de consommation quela reconfiguration dynamique peut apporter un gain de performance. On pourra ainsi laisser decôté un traitement intervenant très rarement et ne le configurer que lorsque l’on en a besoin.On pourra donc soit utiliser un FPGA de plus petite taille et moins coûteux, soit éviter de fairefonctionner des opérateurs qui augmentent la puissance électrique du circuit et ne servent quetrès rarement.Si les atouts de la reconfiguration dynamique des FPGAs semblent évidents, il est toutefoisnécessaire de prendre en compte le surcoût de développement. L’utilisation de possibilités accrues145

Chapitre 6. Conclusionentraîne un besoin de méthodes et d’outils supportant ces nouvelles possibilités.Nous avons présenté deux méthodes répondant à certains de nos besoins.La première méthode permet une minimisation de la surface logique nécessaire à l’implantationd’une application régulière (traitements identiques quelque soit les données ou les résultats).Cette minimisation des ressources logiques nécessaires se fait de manière à respecter unecontrainte de temps de traitement, et s’attache à maintenir les besoins en terme de bande passanteentre le FPGA et la mémoire externe à un niveau minimum. Cette méthode a été validéepar plusieurs algorithmes et notamment l’algorithme de cryptage AES qui n’est pas un ”bon candidat”à priori pour la reconfiguration dynamique. Malgré cela, l’implantation en reconfigurationdynamique est possible et permet de réaliser un gain en surface logique qui peut se traduire directementpar un gain sur le coût du composant FPGA nécessaire à l’implantation de l’algorithme.Nous montrons également que la reconfiguration dynamique ne doit pas se substituer aux autresmoyens d’optimisation et principalement à la synthèse architecturale. Le meilleur résultat demeuranttoujours un compromis entre les différents apports de la reconfiguration dynamique etde la synthèse architecturale.La seconde méthode s’adresse aux algorithmes non-réguliers (dont les traitements peuventvarier en fonction des données ou des résultats précédents). Ces algorithmes peuvent être vuecomme un enchaînement de tâches. Ces tâches peuvent être configurées sur une même partitionou non. L’ordonnancement de ces tâches dans les partitions successives influe largement sur lesperformances finales de l’implantation. Notre méthode permet une prise en compte de tous cesordonnancements possibles et en dresse les caractéristiques principales (surface logique totalenécessaire, temps de traitement, bande passante maximale nécessaire, consommation relative deces différentes possibilités). Cette méthode, intégrée à notre outil informatique DagARD, permetune sélection rapide et visuelle des meilleures solutions de partitionnement suivant les critèresles plus importants aux yeux du concepteur.146

6.2. Perspectives6.2 PerspectivesDans le cadre d’applications non-régulières, nous envisageons la possibilité de retenir plusieurspartitionnements. Le contrôleur de reconfiguration sera alors chargé de choisir en tempsréel lequel est le plus approprié en s’appuyant sur la fréquence d’exécution des différentesbranches de l’algorithme. La réalisation de ce contrôleur pouvant être assigné à une partiestatique du FPGA, à un autre circuit de contrôle, ou encore à un microprocesseur gérant lestâches à un plus haut niveau.Les étapes suivantes de notre travail sont une prise en compte des possibilités de partitionnementà l’intérieur des branches. Cela sera possible grâce à l’intégration de nos précédentstravaux. Nous prévoyons également une démonstration de notre méthode sur une applicationréelle. Celle-ci devrait donner lieu à plusieurs implantations prouvant la diversité des optimisationsenvisageables grâce à la reconfiguration dynamique, comme nous l’avons fait pour notreméthode de partitionnement sous contrainte de temps.Nous prévoyons d’apporter une compatibilité de notre outil de partitionnement avec différentesapplications du flot de conception. Cette compatibilité en entrée comme en sortie permettrad’accélérer les temps de développement et de multiplier les exemples d’applications traitées parnotre méthode.Enfin, nous restons attentif aux évolutions des possibilités de traitement des circuits modernesafin de repousser toujours plus loin la complexité de mise en oeuvre de ces nouveaux concepts.Nous voulons ainsi donner au concepteur les moyens d’agir avec ces possibilités de la façon laplus efficace et intuitive possible.147

Chapitre 6. Conclusion148

Annexe AAutres ArchitecturesA.1 Les systèmes reconfigurables à fonctionnement statiqueA.1.1EVC1EVC1 (Engineer’s Virtual Computer) est un carte commercialisée destinée à accélérer lescalculs sur station de travail Sun [TSC94]. Elle se connecte par l’intermédiaire d’une interfaceSBUS. La carte contient un FPGA de la famille Xilinx 4000E [Xil98a] (XC4010E, XC4013E ouXC4020E) d’une densité approximative allant de 10000 à 20000 portes logiques élémentaires,ainsi qu’un connecteur d’extension auquel sont reliées 96 broches d’entrée-sortie (figure A.1). Lastation Sun a pour but, grâce à des routines écrites et exécutées en C, de charger les fichiersde configuration obtenus avec des outils de développements classiques (avec les outils propres àXilinx : Foundation, Alliance) sur la carte FPGA. Il n’y a pas de mémoire dans la version de base,mais une carte d’extension avec 2 Mega-octet de mémoire statique est disponible. Les calculssont cadencés par une horloge programmable, les fréquences disponibles allant de 360 KHz à100 MHz. Cette carte constitue un bon accélérateur matériel pour des applications logiciellesgourmandes en temps de calcul, telle que la simulation de phénomènes physiques complexes.A.1.2HOT IIHOT II, également commercialisée, s’annonce comme un système d’aide au développementd’applications temps réel. En effet, cette carte est une plate-forme d’évaluation contenant unFPGA (Spartan XCS40-4, 40000 portes [Xil98a]), un CPLD (XC95108-15, 2400 portes [Xil98a])et deux banques mémoire SRAM de 32 bits de large, totalisant 1 Mo (figure A.2). Deux mémoiressupplémentaires sont prévues pour reconfigurer le FPGA : une mémoire FLASH (128 Ko) etune mémoire SRAM de 128 Ko. La carte vient s’enficher sur un connecteur PCI d’un ordinateurcompatible PC.Comme pour l’EVC1, la gestion de l’interface se fait dans le FPGA lui même, cette fois-149

Annexe A. Autres ArchitecturesFig. A.1 – Architecture du calculateur reconfigurable EVC1Fig. A.2 – Architecture du système HOT IIci avec utilisation d’une macro logique de Xilinx (Xilinx LogiCore PCI Interface [Xil98b]). Audémarrage du PC, le CPLD étant déjà programmé, le FPGA se configure depuis la mémoireFLASH. Il charge la macro de gestion du port PCI, ainsi que toute la logique nécessaire pour quele microprocesseur central puisse accéder aux trois mémoires statiques de la carte. Ce dernier150

A.1. Les systèmes reconfigurables à fonctionnement statiquecopie alors le fichier de reconfiguration dans la mémoire cache, et les données à traiter dansles deux autres. Il déclenche ensuite la reconfiguration du FPGA qui charge les traitements eteffectue les calculs. Deux connecteurs d’extension 32 bits permettent le traitement d’un flotde données. Une horloge programmable fournit un signal d’horloge avec une fréquence variableentre 360 KHz et 100 MHz.A.1.3PCI - PAMETTECette carte fait suite aux travaux qui avait abouti aux cartes perle-0 et perle-1. Elle seconnecte à un compatible PC, par l’intermédiaire du bus PCI [Sha99a, Sha99b]. Elle est constituéede quatre FPGAs de la famille XC4000E qui sont groupés en une matrice 2x2, tandis qu’uncinquième sert de contrôleur. Il gère les communications avec le bus PCI, et se charge de reconfigurerles autres. Sa propre fonction, contenue dans une EPROM, peut être modifiée. Lechangement sera effectif au redémarrage. La matrice équivaut à 110000 portes logiques élémentaires,lorsqu’elle est équipée avec des XC4028EX. Deux mémoires statiques de 128 Ko viennentsoutenir les calculateurs, tandis que des connecteurs permettent d’ajouter des modules de mémoiredynamique. Ceux-ci seront gérés par un des FPGAs de calcul. Des extensions peuventêtre interfacées sur un côté du carré. La figure A.3 donne un schéma simplifié de PCI Pamette.PCI Pamette n’est pas dédiée à une application en particulier, elle peut aussi bien êtreutilisée comme accélérateur de calculs par le microprocesseur central, que comme plate-formede prototypage.A.1.4SPACECette architecture pour le traitement sur flot de donnée se présente sous la forme d’unecarte PCI 64 bits, sur laquelle sont montés huit FPGA XC6216 [Xil96] pour les calculs, deuxbanques de mémoire statique de bus 32 bits d’une capacité totale de 32 Mo, une horloge àquartz et un FPGA XC4025 pour le contrôle (figure A.4) [Gun97]. Deux connecteurs d’extensiondirectement reliés aux broches des FPGAs sont là pour permettre de connecter plusieurs cartesentre elles avec différentes topologies. L’ordinateur hôte, une station de travail Alpha de DigitalEquipment, accède aux deux banques de mémoire en parallèle pour un débit maximum théoriquede 200 Mbits/s. Il y range les données de reconfiguration des FPGAs, ainsi que d’éventuellesdonnées à traiter, avant de déclencher le XC4025. Ce dernier, qui a déjà été configuré depuisune EPROM au démarrage, va reconfigurer les XC6264, un par un. Les calculs peuvent alorsdémarrer. La mémoire de reconfiguration interne à chaque FPGA est également accessible parle microprocesseur de la station, soit pour le reconfigurer, soit pour initialiser des registres ourécupérer des résultats. Les traitements sont effectués à la fréquence fournie par un générateurprogrammable (de 0,015 Hz à 66 MHz) contenu dans le XC4025, et qui utilise un quartz externe.151

Annexe A. Autres ArchitecturesFig. A.3 – PCI Pamette [Sha99b]A.2 Systèmes et micro-systèmes reconfigurables à fonctionnementdynamique à grain finA.2.1MOD ARDAu cours de sa thèse menée au LIEN, H. GUERMOUD a réalisé un module reconfigurabledynamiquement [Gue97]. Le module MOD ARD est une architecture reconfigurable dynamiquementpour le traitement d’images. Il s’utilise conjointement à deux cartes électroniques, l’unegère le désentrelacement de l’image fournie par le système d’acquisition, le séquencement desreconfigurations et les communications avec le système hôte, tandis que l’autre fournit toutes lesmémoires nécessaires à la désynchronisation et resynchronisation des données avec le flot vidéo.La figure A.5 présente l’architecture MOD ARD. MOD ARD contient un FPGA XC4004A deXilinx, qui constitue le calculateur central (ou l’unité de traitement) sur lequel vont être séquencésplusieurs traitements pendant l’acquisition de l’affichage des résultats de l’image précédenteet l’image suivante. Chaque configuration des algorithmes qu’il doit réaliser est contenue dansune PROM série (XC 17128) différente et sera chargée à la demande, pour être appliquée àl’image en cours. Le FPGA lit les pixels depuis une première mémoire (mémoire vidéo 1), stocke152

A.2. Systèmes et micro-systèmes reconfigurables à fonctionnement dynamique à grain finFig. A.4 – Système SPACE2 [Gun97]ses données intermédiaires dans une deuxième (mémoire déchets) et range les résultats dansune troisième (mémoire vidéo 2). Ils seront ensuite entrelacés et envoyés vers une carte vidéod’affichage. Ces trois mémoires (vidéo et déchet) sont assurées par des mémoires double portsTMS55161. Deux FIFOs servent éventuellement à reconstituer des voisinages colonnes de troispixels. L’ensemble fonctionne sous le contrôle d’un autre FPGA (XC4004A) faisant office decontrôleur ou d’unité central.Cette architecture met en place plusieurs mécanismes, que nous présenterons dans le paragraphesuivant, dont la désynchronisation entre la fréquence de calcul et celle d’acquisition/restitution.Cette désynchronisation est une condition nécessaire à l’application de la reconfigurationdynamique. Dans le cas du traitement d’images, où le bloc de données à traiterest une image entière, cela présente un deuxième avantage : l’exploitation des temps morts dusignal vidéo qui sont perdus avec une architecture classique. La période de l’horloge de calcul estadaptée au chemin critique de chaque algorithme, afin de gagner un maximum de temps. Enfinl’utilisation du parallélisme de données augmente encore le débit et réduit la durée d’exécution153

Annexe A. Autres ArchitecturesFig. A.5 – Architecture MOD ARDtotale. Tous ces efforts permettent de reconfigurer le FPGA jusqu’à trois fois, pour cascaderplusieurs traitements et augmenter sa densité fonctionnelle. La distribution de signaux d’horlogeest assurée à travers un synthétiseur de fréquence. Il permet de diviser la fréquence et de la distribueraux différents modules dans le but d’effectuer des traitements à des vitesses différentespour exploiter pleinement le temps disponible pour le traitement. Il est important de noter quela fin de la spécification et l’élaboration de ce module correspond à l’arrivée sur le marché decircuit FPGA dédié à la RD (XC 6200, AT40K, etc.). C’est pourquoi sa conception repose surla technologie XC4000 [Xil98a].A.2.2Triscend E5Le composant E5 est un circuit commercialisé disposant d’un micro-contrôleur et d’un réseauprogrammable sur une même puce de silicium [Tri98]. Ce circuit fait partie des composants dela première génération de CSoC (Configurable System-on-Chip). Le E5 est un véritable systèmeintégré contenant un processeur 8032 amélioré, fournissant 10 MIPS à 40 MHz, une RAM de 64Ko et un FPGA. La figure A.6 illustre l’architecture simplifiée de ce circuit.Le FPGA repose sur des cellules comparables aux CLB du XC4000 [Xil98a]. C’est à dire des154

A.2. Systèmes et micro-systèmes reconfigurables à fonctionnement dynamique à grain finFig. A.6 – Architecture simplifiée du E5 [Tri98]cellules logiques à base de LUT 4 entrées / 1 sortie. Elles peuvent fusionner par deux afin desimuler une LUT à 5 entrée / 1 sortie, ou réaliser certaines fonctions logiques nécessitant de 6 à9 variables d’entrées. Une bascule D présent dans chaque cellule permet de pipeliner les calculs.En cas de besoin, les LUT peuvent être converties en mémoire vive distribuée à simple ou doubleport, avec gestion des conflits d’accès. Les opérateurs implantés sur le FPGA ont un accès directau bus de données et peuvent être mappés dans la mémoire du processeur, comme le seraient despériphériques classiques. Ils peuvent en outre commander des broches d’entrée/sortie. Au niveaudes outils, la méthode de développement d’applications pour le E5 mise en oeuvre avec l’outilFastChip, permet de piocher des opérateurs, les soft peripherals, dans une bibliothèque pour lesplacer n’importe où sur le réseau programmable. Ensuite, le développement du programme pourle processeur peut commencer [Tri98]. La bibliothèque de soft peripherals peut être étendueen développant ses propres opérateurs à l’aide d’outils classiques pour FPGA. La validationde l’ensemble s’effectue par co-vérification, en chargeant le code matériel du réseau et le codelogiciel du processeur sur le système intégré, à l’aide d’une carte de développement munie detoute la circuiterie nécessaire à l’exécution pas à pas du programme et à la lecture du contenudes registres et des mémoires. Cependant il n’est pas destiné à être reconfiguré dynamiquementpar le processeur inclu sur la puce. En effet, le réseau ne peut être reprogrammé qu’après la155

Annexe A. Autres Architecturesremise à zéro du 8032, empêchant ainsi ce dernier de séquencer les opérations.A.2.3DISCLe DISC, Dynamic Instruction Set Computer [WH95], est un processeur dédié au traitementd’images en temps réel. Il intègre une partie de contrôle fixe et une partie instruction reconfiguréedynamiquement. Ces deux parties sont implantées dans un unique FPGA reconfigurablepartiellement, un Clay de National Semiconductor [Nat93]. Pour simplifier la gestion spatialedes opérateurs sur le circuit, ses concepteurs, M.J. WHIRTHLIN et B.L. HUTCHINGS de l’Universitéde Brigham Young, ont imposé une architecture à une dimension. La figure A.7 illustrele système DISC.Fig. A.7 – Le système DISC [WH96]Un séquenceur est implanté au nord du FPGA, sur toute la largeur. Il pilote des bus decontrôles, d’adresses et de données, qui traversent le circuit du nord au sud. La zone reconfigurablerestée vide est destinée à accueillir les opérateurs. Ceux-ci, stockés dans une mémoireexterne, ont préalablement été placés et routés de façon à s’interfacer sur les bus lorsqu’ils sontchargés. Au cours du fonctionnement, le séquenceur place le code de l’opérateur dont il a besoin,sur les lignes de contrôle prévues à cet effet. Si l’instruction est présente dans le FPGA,elle se manifeste en renvoyant un signal, ce qui déclenche le traitement des opérandes. Sinon, leséquenceur charge l’opérateur correspondant depuis la mémoire externe. Ces instructions facilitentla gestion de la surface, car le séquenceur suppose que chaque instruction occupe toute lalargeur du circuit. Aussi il ne se préoccupe que de la direction verticale pour désigner la ou lesinstructions à écraser. Après un premier prototype réalisé en wrapping, un deuxième (DISC II)a été implanté sur une carte de développement de National Semiconductor avec trois FPGAs.156

A.2. Systèmes et micro-systèmes reconfigurables à fonctionnement dynamique à grain finA.2.4GarpL’architecture du processeur Garp combine un processeur MIPS avec une matrice de calculreconfigurable de type FPGA qui est utilisée pour accélérer certains calculs ou opérations. Lebut du projet Garp est donc d’intégrer une unité de calcul reconfigurable avec un processeurordinaire RISC pour former une unité reconfigurable sur puce [HW97]. La figure A.8 illustre leschéma bloc de Garp en montrant l’organisation de l’architecture à un haut niveau. Le coeurde Garp est un processeur ordinaire supportant l’ensemble d’instruction MIPS-II. On a ajoutéau processeur un module reconfigurable, correspondant à une matrice bi-dimensionnelle d’élémentsde calculs logiques interconnectés par un réseau de routage. La matrice reconfigurableest dédiée à la réalisation de calcul de chemin de données. L’utilisation du module reconfigurableest contrôlé exclusivement par un programme exécuté sur le processeur. Bien que leprogramme puisse être exécuté entièrement par le processeur sans se référer à la zone reconfigurable,certaines opérations pourront être complétées plus rapidement par cette dernière que parle processeur. On espère ainsi que pour certaines boucles ou opérations, le programme commutedes exécutions temporairement sur le module reconfigurable pour obtenir une accélération destraitements. Comme pour les systèmes précédents, la limitation principale d’un tel système restel’accès aux mémoires extérieures qui constitue un goulot d’étranglement et qui minimise par lamême le nombre de reconfigurations.A.2.5DPGAA. DEHON, du Massachussets Institute of Technology (MIT), a conçu un réseau logique programmabledédié au calcul de moyen et de haut niveau. Le DPGA, Dynamically ProgrammableGate Array [Deh96b, Deh96a], est un PGA à base de LUT, disposant d’un cache qui permetde charger une configuration pendant qu’une autre est en cours d’exécution. Pour ce faire, ilpropose de multiplier par quatre la profondeur de la LUT de chaque cellule. Un mot de sélectionpermet de choisir à l’échelle du circuit, la zone qui commande les cellules et les multiplexeurs.Les trois autres zones sont accessibles à un microprocesseur comme s’il s’agissait d’un banalemémoire statique. La reconfiguration du circuit est alors quasi-instantanée, ce qui est très utilepour les applications du type microprocesseur à jeux d’instructions programmables. Bien sûr, siune configuration nécessaire ne se trouve pas déjà dans le cache, on ne pourra échapper au délaide son chargement, mais un algorithme de gestion du cache adapté à l’application pourra êtreutilisé pour limiter ce phénomène. Par rapport à DISC, le cache du DPGA n’occupe que desressources mémoires, pas de ressources logiques et ne peut pas se reconfigurer partiellement.157

Annexe A. Autres ArchitecturesFig. A.8 – Schéma bloc de GarpA.3 Systèmes et micro-systèmes reconfigurables à fonctionnementdynamique à grain épais ou mixteA.3.1DP-FPGALe DP-FPGA (Datapath FPGA) a été réalisé pour implanter des structures de type cheminsde données réguliers. C’est un circuit de type FPGA composé à la fois d’une architecture grainfin et grain épais ( 1 et 4 bits). Sa matrice comprend trois types de composants : contrôle logique,chemin de données, et mémoire (Figure A.9).Le bloc chemin de données contient 4 unités de traitement 1 bit. Chaque unité de traitementcontient une LUT, une chaîne de retenue et un registre 4 bits. Le DP-FPGA dispose de ressourcesde routage séparé pour les données (horizontale, 4 bits) et les signaux de contrôle (verticale, 1bit) (Figure A.10).Un dernier type de ressources complémentaire est également disponible. Il s’agit d’un blocde décalage permettant des décalages d’un bit ou plusieurs bits.158

A.3. Systèmes et micro-systèmes reconfigurables à fonctionnement dynamique à grain épais ou mixteFig. A.9 – Vue d’ensemble de l’architecture de DP-FPGA[Ye04]Fig. A.10 – Vue d’ensemble d’un bloc de chemin de données[Ye04]A.3.2MATRIXLe MATRIX (Multiple ALU architecture with Reconfigurable Interconnect eXperiment)[MD96] est une matrice de BFUs (Basic Functional Units) 8 bits multi-grain avec un coeur159

Annexe A. Autres Architecturesde microprocesseur programmable incluant ALU, multiplieur, une mémoire de 256 mots de donnéeset d’instruction et un contrôleur qui peut générer un signal de contrôle local depuis la sortiede l’ALU. Avec ces caractéristiques, une BFU peut servir comme mémoire d’instruction, mé-Fig. A.11 – Matrix BFU[MD96]moire de données, registre et ALU, ou comme fonctions d’ALU indépendante. Les instructionspeuvent être acheminées à travers la matrice jusqu’à différentes ALUs. Le réseau de routagefourni trois niveaux de bus de 8 bits : 8 pour proches voisins, quatre connexions pour les secondsproches voisins, connexions directes de longueur 4 et les lignes globale.A.3.3RAWRAW (Reconfigurable Architecture Workstation)[WTS + 97] est une architecture constituéed’un processeur RISC composé d’un réseau de microprocesseurs type MIPS R2000 32 bits modifiés,chacun étant connecté à ses plus proches voisins(Figure A.12). Ces processeurs sont constituésd’une ALU, un pipeline à 6 étages, une unité a virgule flottante, un contrôleur, 32 fichiersde registre à usage général et 16 registres a virgule flottante, un cache mémoire local et 32 kbytede mémoire d’instruction SRAM. RAW permet à la fois l’utilisation d’un réseau statique (déterminéelors de la compilation) ou d’un réseau dynamique (déterminée en temps réel)(Figure.A.12). Les flots d’instructions ordonnancée de façon statique sont générées par le compilateur,cela déplace la responsabilité du fonctionnement dynamique au niveau du développement logiciel.Cependant, RAW laisse la possibilité de contrôler le flot en le rappelant dynamiquementsi le compilateur n’arrivait pas à fournir un ordonnancement statique. La multi-granularité deRAW est obtenue grace à l’utilisation spécifique des processeurs. Ainsi, pour des données detailles classiques, les processeurs sont utilisés de façon classiques. Pour des données plus fines160

A.3. Systèmes et micro-systèmes reconfigurables à fonctionnement dynamique à grain épais ou mixteFig. A.12 – Architecture de RAW[WTS + 97]Fig. A.13 – Structure systolic à six processeurs[WTS + 97]ou plus larges, une reconfiguration permet aux ALUs de traiter des opérations sur des motsplus larges ou encore de traiter plusieurs mots de largeur inférieur à la fois, comme le font lesinstructions Intel MMX par exemple. On obtient ainsi un grain de de calcul reconfigurable surune architecture de calcul parallèles.A.3.4REMARCREMARC (Reconfigurable Multimedia Array Coprocessor) est un accélérateur reconfigurableétroitement couplé à un processeur RISC MIPS-II. Il est constitué d’une matrice 8 x 8 de”nanoprocesseurs” 16 bits avec de la mémoire, relié à une unité de contrôle global. Les ressourcesde communication consistent en une connexion plus proche voisin des nanoprocesseurs ainsi que161

Annexe A. Autres Architecturesde bus horizontaux et verticaux 32 bits qui permettent également les émissions au processeurdans la même colonne ou lignes respectivement, ou, d’émettre une valeur de compteur programmeglobal à chaque cycle d’horloge à tous les nanoprocesseurs. REMARC supporte les opérationsde type SIMD et semble en mesure de supporter les opérations de type MIMD. C’est égalementune architecture combinant les atouts de la reconfiguration au calcul parallèle.Fig. A.14 – Architecture Remarc[MO98]Fig. A.15 – Coprocesseur Remarc[MO98]162

A.3. Systèmes et micro-systèmes reconfigurables à fonctionnement dynamique à grain épais ou mixteFig. A.16 – Nanoprocesseur Remarc[MO98]A.3.5CHESSLa matrice hexagonale CHESS (Fig.A.17) propose une structure de type plateau d’échecavec des lignes d’ALUs / boîtes d’Interconnections intercalées. Une mémoire embarquée detype RAM prend en charge les besoins élevés de mémoire. Les boîtes d’interconnexion peuventêtre converties en RAM 16 mots de 4 bits aux besoins. Cette RAM contenue dans les boîtesd’interconnexion peuvent aussi être utilisées comme table de correspondance (LUT) 4 entrées /4 sorties. Le tissus d’interconnexion de CHESS dispose de bus 4 bits segmentés de différenteslongueurs. Il se compose de 16 bus dans chaque ligne et colonne, 4 bus pour les liaisons localesenjambant une boite d’interconnexion, 4 bus de longueur 2, 2 bus de longueur 4,etc... Pouréviter les problèmes de congestion de routage, la matrice embarque également des blocs demémoire de 256 mots de 8 bits. La sortie d’une ALU peut également alimenter l’entrée deconfiguration d’une autre ALU, ainsi sa fonctionnalité peut-être changée en un cycle d’horlogelors du fonctionnement.A.3.6DReAMDReAM (Dynamically Reconfigurable Architecture for Mobile Systems)[BPG00] est une architectureorientée vers les prochaines générations de communication sans fil (Fig.A.18). C’estun circuit CMOS standard cell 0,35µm fabriqué par Mietec/Alcatel. Chaque RPU (Fig. A.19)163

Annexe A. Autres ArchitecturesFig. A.17 – Principe de l’architecture CHESS[MSK + 99]est constitué de 2 unités RAP (Reconfigurable Arithmetic Processing unit, Fig.A.20) 8 bits,d’un registre à décalage, un contrôleur, 2 mémoires RAM 16x8 bits doubles ports (utiliséescomme LUT ou FIFO), et un contrôleur de protocoles de communication. La matrice de RPUest connecté via un maillage de type plus proche voisin ainsi que des bus globaux segmentablepar des boîtes d’interconnexions.A.3.7CS2000 ChameleonLa société commerciale Chameleon System [Eur] présente la famille des circuits CS2000. Cescircuits sont des plates-formes RCP (reconfigurable communication processor) multiprotocolesmulti-application reconfigurable pour la télécommunication et la communication de données. Ilsembarquent un coeur de processeur RISC 32 bits, un contrôleur de mémoire complet,un contrôleurPCI, le tout connecté à une surface reconfigurable de 6, 9, ou 12 unités reconfigurables.Chaque unité reconfigurable est constituée de 7 rDPUs (chacune incluant une mémoire d’instructionde 8 mots), 4 blocs de mémoire locale de 128 X 32 bits, et 2 multiplieurs 16 X 24 bits.Les unités sont regroupées trois par trois en ”slice” comprenant également une mémoire localede 8 kbyte. Cette surface reconfigurable autorise de multiples flot de données indépendants etpeut-être reconfigurée en un seul cycle d’horloge.164

A.3. Systèmes et micro-systèmes reconfigurables à fonctionnement dynamique à grain épais ou mixteFig. A.18 – Matrice DReAMA.3.8RaPiDRaPiD ( Reconfigurable Pipelined Datapath [ECF + 97]) a pour but une accélération destâches de calculs intensifs très réguliers grâce à une surface reconfigurable 1-D dédiée à la miseen place de profonds pipelines. RaPiD-1 comporte 15 DPUs de 8 bits comprenant un multiplieurd’entiers (sortie sur 32 bits), 3 ALUs d’entiers, 6 ”datapath registres” à usage général et 3mémoires locales de 32 mots de 16 bits. Les ALUs peuvent être chaînées. Chaque mémoire disposed’un ”datapath registres” spécifiques. Le circuit est conçu pour atteindre les 100 MHz et peutêtre entièrement reconfigurée en 2000 cycles environ. Pour implanter les flux d’entrées/sorties,RaPiD dispose d’un générateur de flux avec un générateur d’adresse, optimisés pour les structuresde nids de boucles, le tous associé à des FIFOs. La séquence d’adresse pour le générateur estdéterminée lors de la compilation. Le routage et la configuration de RaPiD sont architecturésautour de plusieurs bus 16 bits parallèles segmentés qui traversent tout le circuit. La longueurde ses segments varie en fonction des pistes. Sur certaines pistes, des bus adjacents peuvent êtrefusionnés.A.3.9PipeRenchPipeRench [SSB + 00, Ga99] est également un accélérateur pour applications pipelinées, quifournit plusieurs étages de pipelines reconfigurables (”stripes”) et s’appuie sur une reconfigurationdynamique partielle rapide de ces pipelines ainsi qu’un ordonnancement des flux de configurationet de données en temps réel. PipeRench dispose d’une mémoire de configuration de 256 x1024 bits, une mémoire d’état (servant a sauvegarder l’état des différents registres courants dechaque étage de pipeline), une table de correspondance d’adresse (ATT : Address translation165

Annexe A. Autres ArchitecturesFig. A.19 – le RPU de DReAMtable), 4 contrôleurs de données, un contrôleur de bus mémoire et un contrôleur de configuration.L’architecture reconfigurable de PipeRench lui permet de reconfigurer un étage de pipelineà chaque cycle alors que les autres étages sont en cours d’exécution. Le circuit est constituéde plusieurs raies horizontale composées de PEs (Processeurs élementaires) interconnectés, deregistres, d’ALUs contenant des LUTs 3 entrées.Les ALUs contiennent également un registre àdécalage, une propagation de retenue, etc. Chaque raie fournit 32 ALUs de 4 bits chacune. Lecircuit complet est constitué de 28 raies. Les interconnexions de PipeRench sont formés d’interconnexionslocale à chaque raie, d’interconnexions locale globale entre chaque raie ainsi que de4 bus globaux.166

A.3. Systèmes et micro-systèmes reconfigurables à fonctionnement dynamique à grain épais ou mixteFig. A.20 – le RAP de DReAMFig. A.21 – Architecture Chameleon [Eur]A.3.10CHIMAERAL’unité fonctionnelle reconfigurable Chimaera (Fig. A.23) :Chimaera est une architecture couplant dans un même circuit un processeur hôte et uneunité fonctionnelle reconfigurable (RFU). Les travaux sur cette architecture portent principalementsur l’unité fonctionnelle reconfigurable. Dans le but de tester leurs résultats, les auteursont considéré l’utilisation comme processeur hôte d’un processeur MIPS R4000. La configurationde l’unité fonctionnelle est faite sous forme de code opérationnel (opcodes) désignant uneconfiguration matérielle de la matrice. Un système de cache des instructions permet de ne pasreconfigurer une opération si celle-ci est déjà en place. Dans le cas contraire, l’exécution du167

Annexe A. Autres ArchitecturesFig. A.22 – Cellule de l’architecture RaPiD [ECF + 97]programme par le processeur hôte est suspendue le temps de reconfigurer l’unité fonctionnelle.L’unité reconfigurable peut accéder directement aux registres du processeur ou via une copiede ces registres(Shadow Register File). L’unité reconfigurable est composée de lignes de 32 celluleslogiques chacune (pour un processeur 32 bits). Une cellule en colonne I sur la ligne 30 (parexemple) à accès aux I eme bits des registres R0-R8. La configuration des accès en lecture/écrituresur ces registres est définie par le code opérationnel. Chaque cellule (Fig. A.24)peut être utiliséecomme une LUTs à quatre entrées ou deux LUTs à trois entrées avec un mécanisme deretenue arithmétique. Elles ne comportent pas de registres ni de bascules, l’unité fonctionnellen’étant pas prévue pour accueillir un pipeline d’instructions. Ce comportement implique quechaque instruction doit être terminée par l’unité fonctionnelle reconfigurable avant de faire appelà une instruction suivante. Le temps de reconfiguration de l’unité fonctionnelle conjugué àce fonctionnement restrictif engendre donc une limitation forte de la puissance de calcul de cettearchitecture.168

A.3. Systèmes et micro-systèmes reconfigurables à fonctionnement dynamique à grain épais ou mixteFig. A.23 – Architecture du circuit Chimaera [HFHK97]Fig. A.24 – Logic Block du RA Chimaera [HFHK97]169

Annexe A. Autres Architectures170

Annexe BContrôleur Verilog, Algorithme AEScase (count)endcase3’h4 : beginend3’h3 : beginend3’h2 : beginend3’h1 : beginendaddS

Annexe B. Contrôleur Verilog, Algorithme AES172

Bibliographie[ABD92] J. Arnold, D. Buell et E. Davis : Splash ii. In 4thACM Symposium on parallelalgorithm and architectures, San Diego Californie USA, 1992.[ACD + 03] Michel Auguin, Karim Ben Chehida, Jean-Philippe Diguet, Xavier Fornari,Anne-Marie Fouilliart, Christian Gamrat, Guy Gogniat, Philippe Kajfasz etYannick Le Moullec : Partitioning and codesign tools & methodology for reconfigurablecomputing : the epicure philosophy. In Proceedings of the Third InternationalWorkshop on Systems, Architectures, Modeling Simulation (SAMOS03), Samos,Greece, July 2003.[AES04] http ://www.egs-howto.com/fr/securite/cryptographie aes.php, 2004.[Atm] Atmel Corporation. AT40k datasheet.[ATM99a] At6000 serie configuration. Technical report, Atmel Corporation, 1999.[ATM99b] At6000 serie datasheet. Rapport technique, Atmel Corporation, 1999.[Atm99c] Atmel Corporation. AT94K Field System Level Integrated Circuit (Advance information).Datasheet, 1999.[BAK96] D. Buell, S. M. Arnold et W. J. Kleinfelder : Splash 2 : Fpgas in a customcomputing machine. In IEEE Computer Society Press, Los Alamitos, CA., 1996.[BDH + 97] J. Burns, A. Donlin, J. Hogg, S. Singh et M. de Wit : A dynamic reconfigurationrun-time system. In IEEE Symposium on Field-Programmable Custom ComputingMachines, pages 66–75, 1997.[BDKK98] R. Bourguiba, D. Demigny, M. Karabernou et L. Kessal : Designing a newarchitecture for real time image analysis with dynamically configurable fpgas. InProc. IEEE IMACS Computational Engineering in Systems Applications, pages 739–743, Hammamet, Tunisia, 1998.[Ber93] P. Bertin : Mémoires actives programmables : conception, réalisation et programmation.Thèse de doctorat, Université Paris 7, 75005 Paris, 1993.[BG99] M. Budiu et S. C. Goldstein : Fast compilation for pipelined reconfigurablefabrics. In FPGA’99, pages 135–143, Monterey, February 1999.173

Bibliographie[BHHN98] J. Becker, R. Hartenstein, M. Herz et U. Nageldinger : Parallelization inco-compilation for configurable accelerators. In In proc. of Asia and South PacificDesign Automation Conference, ASP-DAC’98, Yokohama, Japan, 1998.[Bou00] R. Bourguiba : Conception d’une architecture matérielle Reconfigurable Dynamiquementdédiée au traitement d’images en temps réel. Thèse, Cergy Pointoise,2000.[BPG00] Juergen Becker, Thilo Pionteck et Manfred Glesner : Dream : A dynamicallyreconfigurable architecture for future mobile communication applications. In 10thInternational Conference on Field Programmable Logic and Applications, Villach -Österreich, 2000.[BR97] Vaughn Betz et Jonathan Rose : Vpr : A new packing, placement and routing toolfor fpga research. In Seventh International Workshop on Field Programmable Logicand Applications, pages 213–222, 1997.[BRM + 99] J. Babb, M. Rinard, C.A. Moritz, W. Lee, M. Frank, R. Barua et S. Amarasinghe: Parallelizing applications into silicon. In IEEE Symposium on Field-Programmable Custom Computing Machines, pages 70–80, 1999.[BTBW03] P. Brunet, C. Tanougast, Y. Berviller et S. Weber : Hardware partitioningsoftware for dynamically reconfigurable soc design. In IEEE Circuits, SystemsSociety’s Technical Committee on VLSI et on Communication, éditeurs : the 3rdIEEE International Workshop on System-on-chip for real time Applications (IW-SOC2003), Calgary, AB-Canada, 30 juin-2 juillet 2003 2003.[BV03] J. Beckker et M. Vorbach : Architecture, memory and interface technologieintegration of an industrial/academic configurable system-on-chip(csoc). in Proc.IEEE Computer Society Annual Symposium on VLSI (ISVLSI’03), pages 107–112,February 20-21 2003.[Ca] F. Cathoor et al. : Interactive co-design of high throughput embedded multimedia.In DAC 2000.[CA97] A.V. Chichkov et C.B. Almeida : An hardware/software partitioning algorithmfor custom computing machines. In Springer-Verlag, éditeur : Lecture Notes inComputer Science 1304 - Field-Programmable Logic and Applications, pages 274–283, Berlin, Germany, 1997.[Ca98] F. Cathoor et al. : Custom memory management methodology - exploration ofmemory organization f. embedded multimedia systems. Kluwer, 1998.[Cat02] Anthony Cataldo : Hybrid architecture embeds xilinx fpga core into ibm asics.In EE Times, page http ://www.eetimes.com/story/OEG20020624S0016, 24 june2002.174

[CD00][CH02][CHW00][CLC + 02][CMS98]Pak K. Chan et Martine D.F.Schlag : New parallelization and convergence resultsfor nc : A negotiation-based fpga router. In ACM/SIGDA, éditeur : InternationalSymposium on Field-Programmable Gate Arrays, February 2000.K. Compton et S. Hauck : Reconfigurable computing : A survey of systems andsoftware. ACM Computing Surveys, 34:171–210, June 2002.T.J. Callahan, J.R. Hauser et J. Wawrzynek : The garp architecture and ccompiler. In IEEE Comput., pages 62–69, 2000.K. Compton, Z. Li, J. Cooley, S. Knol et S. Hauck : Configuration relocationand defragmentation for run-time reconfigurable computing. IEEE Transactions onvery large scale integration(VLSI) systems, 10:209–220, June 2002.Douglas Chang et Malgorzata Marek-Sadowska : Partitioning sequential circuitson dynamically reconfiguable fpgas. In Proceedings of the 1998 ACM/SIGDAsixth international symposium on Field programmable gate arrays, pages 161–167,Monterey, California, United States, February 1998.[CSR + 99] P. Chow, S. O. Seo, J. Rose, K. Chung, G. Paez-Monzon et I. Rahardja :The design of an sram-based field-programmable gate array, part i : Architecture.In IEEE Transactions on VLSI systems, 1999.[CVBC03][CW98][DCPS02][Deh96a]S. Chevobbe, N. Ventroux, F. Blanc et T. Collette : Rampass : Reconfigurableand advanced multi-processing architecture for future silicon system. InProceedings of Samos III Workshop, July 2003.T.J. Callahan et J. Wawrzynek : Instruction-level parallelism for reconfigurablecomputing. In Springer Verlag, éditeur : FPL’98, pages 248–257, Tallinn, Estonia,August 31 - September 3. 1998.R. David, D. Chillet, S. Pillement et O. Sentieys : Dart : a dynamically reconfigurablearchitecture dealing with future mobile telecommunications constraints. InParallel and Distributed Processing Symposium., Proceedings International, IPDPS2002, pages 156 – 163, 15-19 Apri 2002.A. Dehon : Dpga utilization and application. In ACM/SIGDA Fourth InternationalSymposium on FPGAs, pages 115–121, February 1996.[Deh96b] A. Dehon : Reconfigurable Architectures for General-Purpose Computing. PhDThesis, MIT, 1996.[Deh98] A. Dehon : Comparing computing machines. In In Proc of the SPIE, volume 3526,pages 124–133, 98.[DIC]http ://www.francophonie.hachette-livre.fr/.175

Bibliographie[DPW98a] D. Demigny, M. Paindavoine et S. Weber : Architecture reconfigurable dynamiquementpour le traitement temps réel des images. Revue technique et Sciences del’information, (Numéro Spécial programmation des Architectures Reconfigurables),1998.[DPW98b] D. Demigny, M. Paindavoine et S. Weber : Architecture reconfigurable dynamiquementpour le traitement temps réel des images. Technique et Sciences del’information, 18(10):1087–1112, 1998.[ea] C. A. Moritz et al. : Hot pages : Software caching for raw microprocessors. InLCS-TM-599 MIT, éditeur : 1999, Cambridge, August.[Ea95] C. Ebeling et al. : Placement and routing tools for the tryptich fpga. In IEEETrans on VLSI Sytems 3, numéro 4, December 1995.[ea99] J. Kin et al. : Power efficient media processor design space exploration. In DAC’99,New Orleans, June 21-25 1999.[ECF + 97] Carl Ebeling, Darren C. Cronquist, Paul Franklin, Jason Secosky et StefanG. Berg : Mapping applications to the rapid configurable architecture. InKenneth L. Pocek et Jeffrey Arnold, éditeurs : IEEE Symposium on FPGAs forCustom Computing Machines, pages 106–115, Los Alamitos, CA, April 1997. IEEEComputer Society Press.[Est] http ://www.esterel-technologies.com.[Eur] Chameleon Systems Europe : Chameleon systems europe.http ://www.chameleonsystems.com/.[EV62] Gerald Estrin et C.R. Viswanathan : Organization of fixed-plus-variable structurecomputer for computation of eigenvalues and eigenvectors of real symmetricmatrices. In JACM, volume 9, pages 41–60, 1962.[FFM + 99] T. Fujii, K. Furuta, M. Motomura, M. Nomura, M. Mizuno, K. Anjo, K. Wakabayashi,Y. Hirota, Y. Nakazawa et M. Yamashina H. Itoh : A dynamicallyreconfigurable logic engine with a multi-contxt/multi-mode unified-cell architecture.In IEEE International Solid-State Circuits Conference, February 1999.[Ga98] L. Guerra et al. : A methodologie for guided behavioural level optimisation. InDAC’98, San Francisco, June 15-19 1998.[Ga99] S. C. Goldstein et al. : Piperench : A coprocessor for streaming multimediaacceleration. In ISCA’99, Atlanta, May 2-4 1999.[GKMK96] Maya B. Gokhale, James Kaba, Aaron Marks et Jang Kim : A malleable architecturegenerator for fpga computing. In In SPIE’96, Boston, MA, November1996.176

[GL99] S. A. Guccione et D. Levi : The advantages of run-time reconfiguration. ReconfigurableTechnology : FPGAs for Computing and Applications, SPIE - The InternationalSociety for Optical Engineering, (Proc. SPIE 3844):87–92, September1999.[gro][GS98][Gue97][Gun97][Ha99][HFHK97]CAD group : Sequential interactive synthesis, department of electrical engineeringand computer sciences (cad group) university of california, berkeley (ucb).http ://www-cad.eecs.berkeley.edu/Software/software.html.Maya B. Gokhale et Janice M. Stone : Napa c : Compiling for a hybrid risc/fpgaarchitecture. In Proceedings of the IEEE Symposium on FPGAs for Custom ComputingMachines, page 126. IEEE Computer Society, 1998.H. Guermoud : Architecture reconfigurable dynamiquement dédiées aux traitementsen temps réel des signaux vidéo. Thèse de doctorat, Université Henri Poincaré Nancy1, 1997.B. K. Gunter : Space 2 as a reconfigurable stream processor. In In The proceedingof PART’97 : The 4 th Australasian Conference on Parallel and Real-Time Systems,pages 286–297, September 1997.P.A. Hsiung et al. : Psm : An object-oriented synthesis approach to multiprocessordesign. In IEEE Trans VLSI Systems, March 1999.S. Hauck, T.W. Fry, M.M. Hosler et J.P. Kao : The chimaera reconfigurablefunctional unit. In The 5th Annual IEEE Symposium on FPGAs for Custom ComputingMachines, 1997, pages 87 – 96, Napa Valley, CA USA, April 1997. Dept. ofElectr. Eng. & Comput. Sci., Northwestern Univ., Evanston, IL, USA.[HHHN00] R. Hartenstein, M. Herz, Th. Hoffmann et U. Nageldinger : Kressarrayxplorer : A new cad environment to optimize reconfigurable datapath array architectures.In 5th Asia and South Pacific Design Automation Conference 2000,ASP-DAC 2000, Pacifico Yokohama, Japan, January 25-28 2000.[HK95][HW97]Reiner W. Hartenstein et Rainer Kress : A datapath synthesis system for thereconfigurable datapath architecture. In Proceedings of the 1995 conference on AsiaPacific design automation (CD-ROM), page 77. ACM Press, 1995.J. Hauser et J. Wawrzynek. : Garps : A mips processor with a reconfigurable coprocesseur.IEEE Symposium on Field-Programmable Custom Computing Machines,April 1997.[HWA93] K. HWANG : Advanced computer architecture. 1993.[HYES97] H.Guermoud, Y.Berviller, E.Tisserand et S.Weber : Architecture à base177

Bibliographiede fpga reconfigurable dynamiquement dédiée au traitement d’image sur flot dedonnées. In 16° colloque GRETSI, septembre 1997.[Jac98][JCM00]J. Jacob : Memory interface for the onechip reconfigurable processor. Master ofapplied science in departement of electrical and computer engineering, 1998.Christophe Jego, Emmanuel Casseau et Eric Martin : Interconnect cost controlduring high-level synthesis. In DCIS 2000, 15th Design of Circuits and IntegratedSystems Conference, pages 507–512, Montpellier, France, 21-24 novembre 2000.[JTY + 99] Jack S. N. Jean, Karen Tomko, Vikram Yavagal, Jignesh Shah et Robert Cook :Dynamic reconfiguration to support concurrent applications. In IEEE Transactionson Computers, volume 48, pages 591–602, June 1999.[Ka91][Kea89]D. Knapp et al. : The adam desing planning engine. In IEEE Trans. on CAD,July 1991.T. Kean : Configurable Logic : A Dynamically Programmable Cellular Architectureand its VLSI Implementation. Thèse de doctorat, University of Edinburgh, 1989.[KHN97] R. Kress, R.W. Hartenstein et U. Nageldinger : An operating system forcustom computing machines based on the xputer paradigm. In Eds. Springer-Verlag, éditeur : Lecture Notes in Computer Science 1304 - Field-ProgrammableLogic and Applications, pages 304–313, Berlin, Germany, 1997.[Krea][Kreb][La92]Kressarray : http ://kressarray.de/.Kressarray xplorer : http ://kxplorer.informatik.uni-kl.de/.J. Lopez et al. : Desing assistance for cad frameworks. In EURO-DAC’92, Hamburg,Germany, september 7-10 1992.[Les99] A. Lesea : Frequency synthesis. The Quartly Journal for Programmable LogicUsers. Xcell, 1999.[LS88][LW99][MD96]K.W. Lee et C. Sechen : A new global router for row-based layout. In IEEE,éditeur : International Conference on Computer-Aided Design, pages 180–183, 1988.Huiqun Liu et D.F. Wong : Circuit partitioning for dynamically reconfigurablefpgas. In Proceedings of the 1999 ACM/SIGDA seventh international symposiumon Field programmable gate arrays, pages 187–194, Monterey, California, UnitedStates, February 1999.E. Mirsky et A. DeHon : Matrix : a reconfigurable computing architecture withconfigurable instruction distribution and deployable resources. FPGAs for CustomComputing Machines, 1996. Proceedings. IEEE Symposium on, pages 157 – 166,April 1996.178

[ME95]Larry McMurchie et Carl Ebling : Pathfinder : A negotiation-based performancedrivenrouter for fpgas. In Proceedings of the ACM/SIGDA Third InternationalSymposium on Field-Programmable Gate Arrays, pages 111–117. ACM, February1995.[MKDP03] Yannick Le Moullec, Peter Koch, Jean-Philippe Diguet et Jean-Luc Philippe :Design trotter : Building and selecting architectures for embedded multimedia applications.In IEEE International Symposium on Consumer Electronics (ISCE03),Sydney, Australia, December 3-5 2003.[MO98][MSHD93]T. Miyamori et U. Olukotun : A quantitative analysis of reconfigurable coprocessorsfor multimedia applications. FPGAs for Custom Computing Machines, 1998.Proceedings. IEEE Symposium on, pages 2 – 11, April 1998.Eric Martin, Olivier Sentieys et J.L. Philippe H. Dubois : Gaut : An architecturalsynthesis tool for dedicated signal processors. In Design Automation Conference,Proceedings EURO-DAC’93 with EURO-VHDL’93, pages 14–19, 20-24 Septembre1993.[MSK + 99] A. Marshall, T. Stansfield, I. Kostarnov, J. Vuillemin et B. Hutchings :A reconfigurable arithmetic array for multimedia applications. In Proceeding.ACM/SIGDA FPGA’99, Monterey, February 1999.[MY03][Na95][Nag01]W.-K. Mak et E.F.Y. Young : Temporal logical replication for dynamically reconfigurablefpga partitioning. IEEE Transactions on Computer-Aided Design ifIntegrated Circuits and Systems, 22:952–959, July 2003.L. Nachtergaele et al. : Optimization of memory organization and partitioningfor decreased size and power in video and image processing systems. In IEEEWorkshop on Memory Technology, August 1995.U. Nageldinger : Design-space exploration for coarse grained reconfigurable architectures.Dissertation, Universitaet Kaiserslauten, February 2001.[Nat93] National Semiconductor. Configurable Logic Array (CLAy) Datasheet, 1993.[NRW95][Oa99][Pa89]T. Ngai, J. Rose et S. Wilton : An sram-programmable field configurable memory.In In IEEE Custom Integrated Circuits Conference, pages 499–502, Santa Clara, CA,May 1995.T. Omnès et al. : Dynamic algorithms for minimizing memory bandwidth in highthroughput telecom and multimedia. In Éditions Hermès, éditeur : Techniques deParallelisation Automatique, TSI, 1999.P. Paulin et al. : Algorithms for high-level synthesis. In IEEE Design and Test,December 1989.179

Bibliographie[PB99] Karthikeya M. Gajjala Purna et Dinesh Bhatia : Temporal partitioning andscheduling data flow graphs for reconfigurable computers. In IEEE Transactions onComputers, volume 48, pages 579–590, June 1999.[PIL03] S. PILLEMENT : Séminaire archi’03. Rapport technique, IRISA R2D2, EcoleCNRS, April 2003.[Pro][RLG + 98][RS][RS02]U.C.Berkeley IRAM Project : Online : http ://iram.cs.berkeley.edu.C.R. Rupp, M. Landguth, T. Garverick, E. Gomersall, H. Holt, J.M. Arnoldet M. Gokhale : The napa adaptive processing architecture. In IEEE Symposiumon FPGAs for Custom Computing Machines, pages 28 – 37, Napa Valley,CA USA, April 1998. Nat. Semicond. Corp., USA.José Rolim et Frédéric Schütz : Le nouveau standard aes : Rijndael. Cours ’Cryptographieet Sécurité’. http ://cui.unige.ch/tcs/cours/crypto/crypto4/node5.html.Rahul Razdan et Michael D. Smith : A high-performance microarchitecture withhardware-programmable functional units. In Proceedings of the 27th annual internationalsymposium on Microarchitecture, pages 172–180, San Jose, California, UnitedStates, 2002.[Sal98] Z. Saleeba : A self reconfiguring computer. Phd thesis, University of Monash,1998.[San98][Sha99a][Sha99b][SID][SP95][SR99]A. Sanders : The design and implementation of a context switching fpga. In IEEESymponium on Field-Programmable Custom Computing Machines, April 1998.M. Shand : PCI Pamette user-area interface for firmware v2.0. Compaq ComputerCorporation, 1999.M. Shand : PCI Pamette V1 R2 Schematics,Technical Report. Digital EquipmentCorporation, 1999.SIDSA : http ://www.sidsa.com.A. Stansfield et I. Page : The design of a new fpga architecture. In In Proceedingsof the 5th International Workshop on Field-Programmable Logic and Applications,pages 1–14, 1995.Yaska Sankar et Jonathan Rose : Trading quality for compile time : Ultra-fast placementfor fpgas. In International ACM/SIGDA Symposium on Field-ProgrammableGate Arrays, pages 157–166, February 1999.[SSB + 00] S.C.Goldstein, H. Schmit, M. Budiu, S. Cadambi, M. Moe et R. Taylor :Piperench : A reconfigurable architecture and compiler. In IEEE Computer, volume33, 2000.180

[STB + 02] G. Sassatelli, L. Torres, P. Benoit, T. Gil, C. Diou, G. Cambon et J. Galy :Highly scalable dynamically reconfigurable systolic ring-architecture for dsp applications.In Design, Automation and Test in Europe Conference and Exhibition, 2002(DATE02), pages 553 – 558, 4-8 March 2002.[SV98][Tan01][TBW01]S. Scalera et J. Vazquez : The design and implementation of a context switchingfpga. In In IEEE Symponium on FPGAs for Custom Computing Machines, NapaValley, California, 1998.Camel Tanougsat : Méthodologie de partitionnement applicable aux systèmes surpuce à base de FPGA, pour l’implantation en reconfiguration dynamique d’algorithmesflot de données. Thèse de doctorat, Université Henri Poincaré, Nancy I,octobre 2001.C. Tanougast, Y. Berviller et S. Weber : Intégration microélectronique surarchitecture reconfigurable d’un détecteur de mouvement embarqué dédié à la sécuritéroutière. In Hermès, éditeur : C2I, volume 2, pages 155 – 162, Paris, février2001.[TBWB03] C. Tanougast, Y. Berviller, S. Weber et P. Brunet : A partitioning methodologythat optimises the area on reconfigurable real-time embedded systems.EURASIP Journal on Applied Signal Processing, Special Issue on Rapid Prototypingof DSP Systems, April 2003.[TCE + 95]E. Tau, D. Chen, I. Eslick, J. Brown et A. Dehon : A first generation dpgaimplementation. In In Third Canadian Workshop of Field-Programmable Devices,Montreal, Canada, May 1995.[Tri98] Triscend. Triscend E5 Configurable Processor Family. Datasheet, 1998.[TSC94][Va]M. Thornburg, J. Schewel et S. Casselman : EVC1’S Users Guide. VirtualComputer Corporation, 1994.A. Vandecapelle et al. : Global multimedia design exploration using accuratememory organization feedback. In DAC 1999.[VBR + 96] Jean E. Vuillemin, Patrice Bertin, Didier Roncin, Mark Shand, Hervé H.Touati et Philippe Boucard : Programmable active memories : reconfigurablesystems come of age. In IEEE Transactions on Very Large Scale Integration (VLSI)Systems, volume 4, pages 56–69, March 1996.[Wa94][Wa99]R. Wilson et al. : Suif : An infrastructure for research on parallelizing and optimizingcompilers. SIGPLAN Notices, December 1994.S. Wuytack et al. : Minimizing the required memory bandwidth in vlsi systemrealizations. In IEEE Trans. VLSI Systems, December 1999.181

Bibliographie[WH95][WH96][WH98][Wir97][Wit95][WTS + 97]M. J. Wirthlin et B. Hutchings : Disc : The dynamic instruction set computer. InIn Field Programmable Gate Array for Fast Board Development and ReconfigurableComputing, pages 92–103, 1995.M. J. Wirthlin et B. Hutchings : Sequencing run-time reconfigured hardwarewith software. In In ACM/SIGDA International Symposium on Field ProgrammableGate Array, pages 86–92, 1996.M. J. Wirthlin et B.L. Hutchings : Improving functional density using run-timecircuit reconfiguration. IEEE trans. VLSI Syst., 6 no. 2:247–256, June 1998.M. J. Wirthlin : Improving Functional Density Through Run-Time Circuit Reconfiguration.Thèse de doctorat, Brigham Young University, 1997.R. Wittig : Onechip : an fpga processor with reconfigurable logic. Master of appliedscience in departement of electrical and computer engineering, 1995.E. Waingold, M. Taylor, D. Srikrishna, V. Sarkar, W. Lee, V. Lee, J. Kim,M. Frank, P. Finch, R. Barua, J. Babb, S. Amarasinghe et A. Agarwal :Baring it all to software : Raw machines. IEEE Computer, 30(9):86 – 93, September1997.[Xil96] Xilinx. XC 6200 Field Programmable Gate Arrays. Datasheet, 1996.[Xil98a] Xilinx. The programmable logic databook, 1998.[Xil98b] Xilinx. Xilinx PCI The Core of a GREAT IDEA. Datasheet, 1998.[Xil04a] Xilinx. Virtex II plateform FPGA user guide(UG002 v1.8), April 2004.[Xil04b] Xilinx. Virtex-II Pro—X Platform FPGAs : Functional Description, March 2004.[Xil04c] Xilinx. Virtex-II—Platform FPGAs : Detailed Description, March 2004.[Ye04] Andy Gean Ye : Thesis. 2004.[ZCW00][ZN00]Kai Zhu, Yao-Wen Chang et D. F. Wong : Timing-driven routing for symmetricalarray-based fpgas. In ACM, éditeur : Transactions on Design Automation ofElectronic Systems, volume 5, pages 433–450, July 2000.X. Zhang et K.W. NG : A review of high-level synthesis for dynamically reconfigurablefpgas. In Microprocessors and Microsystems, volume 24, pages 199–211,Elsevier, 2000.182