Technologie FPGA, Evolution et Projections

 Technologie FPGA, Evolution et Projections 

Le marché de la conception d’application à base de FPGA intéresse de plus en plus les éditeurs traditionnels de CAO. Jusqu’à une époque récente, la conception d’un système sur puce (SOC) n’était accessible qu’aux sociétés de grande taille, du fait des multiples exigences qu’elle induisait (complexité et diversité des compétences requises, coûts élevés des outils de développement matériel et logiciel, et forts volumes nécessaires pour justifier le coût de conception d’un ASIC). Aujourd’hui, deux événements ont changé la donne : l’avènement des dernières générations de FPGA et la disponibilité des blocs de propriété intellectuelle (IP), utilisable notamment sur ces matrices programmables, mettent la technologie SOC à la portée d’un public nettement plus large. Ainsi, cette technologie, qui ciblait principalement les domaines : public, médical, télécommunication et automobile, devient intéressante pour des applications plus simples et portant sur des volumes moins importants. Et ceci particulièrement depuis que les FPGA sont proposés à un prix très faible (0.0001dollar par porte). De plus, l’offre en propriété intellectuelle pour ces circuits, à présent est très variée et performante. Mentionnons simplement la richesse des cœurs des processeurs : des microcontrôleurs 8 et 16 bits aux microprocesseurs et DSP 32 bits de haute performance, grâce notament à l’architecture VLIW (Very Large Instruction Word). Pour mettre en œuvre ces applications SOC, les concepteurs doivent disposer d’outils de CAO électronique et de développement de logiciels enfouis. Dans les PME, les premiers systèmes sur puce remplacent généralement des produits existants réalisés à l’aide de plusieurs composants (microcontrôleur, périphériques, etc.). Afin de mener à bien leurs projets, ces sociétés ont besoin d’un jeu de blocs IP fonctionnant ensemble et d’un fournisseur capable de garantir cette interopérabilité, et non d’une méthodologie générique de conception SOC. Les cœurs IPs et les périphériques choisis pour ces systèmes sont souvent des copies de composants discrets associés à des outils de développement logiciel, de haute qualité et de prix modique, mais proposés par des firmes différentes.

Limites de FPGA

L’emploi de FPGA est devenu, à juste titre, une solution privilégiée pour produire rapidement des circuits. Pourtant, la complexité croissante des plus grandes matrices engendre de graves problèmes à l’étape de routage. Entre les ASIC et les FPGA de haute complexité, la durée du procédé de placement-routage sous contrainte temporelle varie beaucoup avant de converger vers la solution optimale .

Les FPGA ont certes de nombreux atouts, mais les concepteurs de systèmes ont tendance à se tourner, par habitude, vers cette solution sans regarder si elle répond correctement aux objectifs de performances et de coût, voire si elle s’inscrit bien dans le calendrier de développement de leurs projets. Pourtant, les FPGA de forte complexité induisent des limitations sévères qui peuvent pénaliser le bon déroulement d’une conception. Certaines applications, dans le domaine des réseaux et communications notamment, exigent des fonctions complexes et un nombre élevé de broches, ceci assorti de performances toujours croissantes. De ce fait, les plus grands réseaux logiques programmables choisis pour réaliser ces projets sont fréquemment employés au-delà de leurs possibilités physiques, des limitations inhérentes à leurs architectures. Avec de tels FPGA, il faut souvent plusieurs mois avant de converger vers un routage satisfaisant au niveau des performances temporelles (Figure 2.3). Dans ce cas, la convergence vers un timing optimal est presque toujours un procédé long, imprévisible, onéreux, et extrêmement laborieux.

Au niveau des FPGA de forte complexité, la difficulté d’utilisation de ces matrices dans des applications de hautes performances réside dans le principe d’interconnexions programmables pour le routage des signaux. Et ceci n’est pas entièrement dû au fait que la quantit é de ressources de routage disponibles est plus faible dans les FPGA basés sur des points SRAM que dans les technologies concurrentes. Entre en jeu également le retard substantiel, de type R-C, inhérent à ces circuits programmables par SRAM (Figure 2.4 : Chaque point d’aiguillage consomme au moins cinq transistors pour la Ram et un transistor interrupteur de grande taille). Ce délai de propagation rend les performances du composant hautement sensibles au moindre changement dans un chemin de routage .

Technologie FPGA du Xilinx

Dès l’origine, les FPGA, tels que Xilinx les a inventés, avaient la réputation de mettre à disposition de l’utilisateur une conception rapide, fiable et simple. Les progrès technologiques ont permis d’accéder à des matrices logiques programmables de plusieurs millions de portes. Cette complexité actuelle reste absolument gérable et permet la réalisation d’applications très performantes moyennant une bonne connaissance des ressources offertes et le respect d’une méthodologie de conception.

Les principales caractéristiques de ces trois familles sont :
♦ Complexités allant de 1500 à plus de 8 millions de portes.
♦ Faible consommation.
♦ Grande souplesse d’utilisation des entrées/sorties avec adaptation d’impédance (Virtex-II) et configuration en mode différentiel (Spartan-IIE, Virtex-E et Virtex-II).
♦ Fonctions mémoire (distribuée et blocs de Ram).
♦ Dispositifs de gestion des horloges (DLL et DCM).
♦ Multiplieurs câblés (Virtex-II) .

FPGA Virtex-II Pro

Xilinx a mis depuis peu sur le marché, une nouvelle technologie de circuits FPGA intégrants de nouvelles fonctionnalités, ces derniers permettent la réalisation d’architectures qui auparavant s’avéraient très compliquées à entreprendre. Parmi ces nouveaux circuits, le VIRTEX-II PRO (Figure 2.11) qui est un composant FPGA intégrant un cœur de processeur PowerPC 405 de chez IBM pouvant fonctionner à plus de 300MHz. Afin de rendre le co-design plus simple à réaliser, la famille de composant Virtex-II-Pro possède plusieurs atouts tel que :
♦ l’intégration d’un ou deux cœurs de processeur powerPC405
♦ un grand nombre de slices pouvant atteindre 44.096 unités permet d’implémenter des algorithmes dont la complexité les rend gourmand en consommation des ressources logiques
♦ des blocs de mémoire de 18Kb sont aussi disponible ce qui diminuera l’accès vers des ressources externes et ce qui peut être fatal pour le circuit surtout du point de vue consommation d’énergie
♦ des multiplieurs 18×18 bits, des DCM (Digital Clock Manager).

Pour cela Xilinx fourni des IPs soft (Figure 2.12) écrites en langage VHDL qui permettent d’exploiter le PowerPC405 et de lui fournir tous les périphériques nécessaires à son fonctionnement. Les premières IPs à implémenter autour du processeur sont le PLB « Processor Local Bus » et le «On Chip Memory Controller», la première constitue le bus de communication sur lequel viennent se greffer d’autres IPs, quant au «On Chip Memory Controller » il permet de connecter le PowerPC405 avec les Bram’s du FPGA ou bien avec des RAMs externes où sera logé le code à exécuter.

Table des matières

INTRODUCTION
CHAPITRE 1 : CONTEXTE GENERAL DE LA THESE ET MOTIVATIONS
1.1 Conception des systèmes embarqués
1.2 Contribution
1.3 Plan du mémoire
CHAPITRE 2 : SYSTEME SUR PUCE
2.1 Technologie ASIC, Evolution et Projection
2.2 Technologie FPGA, Evolution et Projections
2.2.1 Introduction
2.2.2 Limites de FPGA
2.2.3 Technologie FPGA du Xilinx
2.2.4 La famille FPGA Xilinx Virtex-II
2.2.5 FPGA Virtex-II Pro
2.2.6 Flot de conception FPGA
2.2.6.1 Vue Générale
2.2.6.2 Conception et Synthèse
2.2.6.3 Design Hiérarchique
2.2.6.4 Schématiques
2.2.6.5 Les éléments des Librairies
2.2.6.6 Outil de Génération de Cores
2.2.6.7 HDL et synthèse
2.2.6.8 Simulation fonctionnelle
2.2.6.9 Contraintes
2.2.6.10 Translation en NetList
2.2.6.11 Implémentation
2.2.6.12 Mapping
2.2.6.13 Placement et Routage
2.2.6.14 Génération de flot de bits
2.2.6.15 Vérification
2.2.6.16 Analyse temporelle statique
2.2.6.17 Vérification sur le circuit
2.3 Module ADM-XRC-II
2.3.1 Présentation de la plateforme ADM-XRC-II
2.3.2 Spécifications techniques du module ADM-XRC-II
2.3.3 Signaux du bus local
2.3.4 Fonctions de commande plateforme
2.4 Méthodologies de Conception SOC et IPs
2.4.1 Les composants réutilisables
2.4.2 Méthodologie de réutilisabilité
2.4.3 Les composants virtuels IPs
2.5 IPs Paramétrables et SOPC
2.6 Reconfigurabilité dynamique
2.7 Conclusion
CHAPITRE 3 : ALGORITHMES EVOLUTIONNAIRES MONO ET MULTIOBJECTIFS
3.1 Optimisation difficile
3.2 Métaheuristiques
3.3 Capacité des métaheuristiques à s’extraire d’un minimum local
3.4 Fonction d’objectif et fonction d’adaptation
3.5 Optimisation monobjectif
3.5.1 La méthode du recuit simulé
3.5.2 La méthode de recherche avec Tabous
3.5.3 Algorithme génétique
3.5.3.1 Introduction à l’AG
3.5.3.2 Algorithme génétique simple « AGS »
3.5.3.3 Algorithme Génétique Canonique « AGC »
3.5.3.4 Principe de l’AGC
3.5.3.5 Reproduction
3.5.3.6 Croisement
3.5.3.7 Mutation
3.5.3.8 Les paramètres de l’AG
3.5.3.9 Génération d’une nouvelle population
3.5.3.10 Elitisme
3.5.3.11 Etat de l’art de la convergence de l’AGC
3.6 Optimisation multiobjectifs
3.6.1 Objectifs multiples avec la méthode d’agrégation
3.6.2 Méthodes non-agrégatives
3.6.2.1 Pareto Archived Evolution Strategy « PAES »
3.6.2.2 Strength Pareto Evolutionary Algorithm « SPEA »
3.6.3 Objectifs multiples avec le critère de Pareto
3.7 L’algorithme NSGA-II
3.7.1 Classification des individus
3.7.2 Préservation de la diversité
3.7.3 Opérateur de comparaison Crowded
3.7.4 Boucle principale de l’algorithme NSGA -II
3.7.5 Convergence et diversité des solutions des algorithmes multiobjectifs
3.7.6 Implémentation de NSGA -II
3.7.7 Distribution du calcul des performances
3.8 Conclusion
CHAPITRE 4 : EXPLORATION ARCHITECTURALE
4.1 IPs Processeurs et Microarchitecture
4.2 Evaluation des Performances
4.3 Evaluation de la consommation d’énergie
4.3.1 Techniques employées pour la réduction de la consommation d’énergie
4.3.2 SimplePower
4.4 Evaluation de la surface silicium
4.5 Exploration de l’espace architectural à base de simulation
4.5.1 Le Simulateur SimpleScalar
4.5.2 Paramètres de simulation
4.5.2.1 Paramètres caches
4.5.2.2 Paramètres de Pipeline et les unités fonctionnelles
4.5.3 Représentation chromosomique: codage d’individus
4.5.4 Décodage de la solution
4.5.5 Résultats de la simulation
4.6 Exploration à base d’Emulation
4.6.1 IP de processeur Leon
4.6.2 Caractéristiques configurables du Leon
4.6.2.1 Utilisation du processeur
4.6.2.2 Utilisation du compilateur
4.6.2.3 Processeur et mémoires
4.6.3 Intégration de l’IP Leon sur le FPGA
4.6.3.1 Structure Hard
4.6.3.2 Compilation d’une application pour initialiser la ROM
4.6.4 Le processeur Leon dans la bocle d’exploration
4.6.4.1 Objectif
4.6.4.2 Architecture HARD de la plateforme d’émulation
4.6.4.3 Structure Soft côté PC
4.6.5 Résultats de l’émulation
4.6.5.1 Exploration exhaustive
4.6.5.2 Exploration avec l’algorithme NSGA-II
4.7. Conclusion
CONCLUSION

Télécharger le rapport complet