Architectures reconfigurables à gros grain – État de l’art

Architectures reconfigurables à gros grain – État de l’art 

De nos jours, les architectures reconfigurables s’imposent comme une cible potentielle pour accélérer des applications embarquées de par le compromis flexibilité/performance qu’elles proposent. Cette tendance se traduit, dans la recherche comme dans l’industrie, par de nombreuses contributions destinées à être intégrées dans des produits de grande consommation. Ces architectures modernes sont composées de nombreuses unités de calcul, homogènes ou hétérogènes, pouvant être spécialisées pour un domaine, une classe d’applications, voire pour une seule application.

Architectures reconfigurables

Origines et définitions 

Aujourd’hui encore, le terme reconfigurable est associé aux « circuits logiques programmables » et surtout au type d’architecture qui l’a popularisé, le FPGA (Field Programmable Gate Array). Introduit sur le marché au milieu des années 80 par l’un des leaders mondiaux actuels (Xilinx), le FPGA est formé de trois différents éléments de base : la table de correspondance ou LUT (Look Up Table) ou encore CLB (Configurable Logic Bloc) selon le fabricant, le multiplexeur et la bascule. A noter que la notion de reconfigurable, telle qu’on la connaît aujourd’hui, est bien plus ancienne et pourrait être attribuée à Estrin qui présente dans son papier de 1960 (récemment évoqué dans [39]) une architecture hybride composée d’un processeur standard et d’une matrice matérielle « reconfigurable ».

Définition 1.1 : Une architecture reconfigurable est une architecture capable de modifier son comportement par la modification du schéma de connexion entre ses éléments de base.

Évolutions

Les architectures reconfigurables ont énormément évolué ces dernières années pour satisfaire des besoins applicatifs toujours croissants. Une des évolutions est apparue comme incontournable pour exploiter pleinement la flexibilité apportée par les FPGA; il s’agit de la reconfiguration dynamique. En effet, avant cette évolution, il fallait arrêter toute activité sur le composant avant de pouvoir en modifier son comportement et obtenir ainsi une nouvelle fonctionnalité. C’est à la fin des années 90 que la reconfiguration dynamique partielle est apparue sur les composants Xilinx notamment, permettant d’améliorer le compromis performance/flexibilité.

Parmi ces évolutions, on trouve aussi l’apparition de différents niveaux de reconfiguration : du plus petit (niveau bit) au plus gros (unité fonctionnelle), on parle de granularité ou de grain de reconfiguration. Les caractéristiques d’une architecture reconfigurable varient selon la granularité à laquelle elle peut être reconfigurée. On distingue communément trois niveaux de reconfiguration : logique, fonctionnel et système.

Reconfiguration au niveau logique (grain fin)

La reconfiguration au niveau logique appelée aussi reconfiguration à grain fin est typiquement représentée par les systèmes FPGA . Leur reconfiguration se fait au niveau bit ce qui permet une grande flexibilité, comme notamment d’adapter la largeur des données en fonction des besoins. Mais à ce niveau, certains désavantages apparaissent.

Tout d’abord, on observe qu’une grande partie de la surface d’un circuit FPGA est occupée par les multiplexeurs et les bascules utilisées pour réaliser le câblage entre éléments logiques réalisant la fonctionnalité souhaitée et que ces derniers n’occupent qu’une faible surface. De plus, les outils de placement et de routage (P&R) utilisés pour configurer un FPGA sont très complexes et peu efficaces car le problème de P&R est connu pour être difficile à résoudre. Cela l’amène même à être considéré comme « nuisible » par Hartenstein qui écrit : « Avec de sévères difficultés, les FPGA commercialisés routent dans la plupart des designs moins de 80-90% des LUT disponibles et même dans certains cas seulement environ 50% » [52]. Le coût global de la reconfiguration est un autre désavantage majeur. En effet, la mémoire utilisée pour stocker les différentes configurations, le temps et l’énergie nécessaires pour effectuer une reconfiguration (importants transferts de données de configuration) sont loin d’être négligeables dans la conception d’un système sur FPGA.

Parmi les solutions proposées pour pallier ces désavantages, les architectures reconfigurables à un plus gros grain ont fait leur apparition.

Reconfiguration au niveau fonctionnel (gros grain)

Ce niveau de reconfiguration, nommé aussi reconfiguration à gros grain, permet d’améliorer la surface, la consommation et la performance des systèmes comparés aux FPGA tout en en maîtrisant la perte de flexibilité pour ne pas la rendre pénalisante. Selon [41], on peut observer deux principales familles d’architecture : les architectures orientées chemin de données et celles orientées instructions. Dans la première famille, la fonctionnalité des unités de calcul est fixée par une étape de configuration et le flot de données entre ces unités est organisé par un contrôle spécifique sur les interconnexions. Dans la seconde, chaque élément exécute une suite d’opérations définies par un élément de contrôle à partir d’une instruction. Il existe aussi des architectures pouvant supporter les deux types de fonctionnement.

Reconfiguration au niveau système

Les architectures reconfigurables au niveau système, communément appelées processeurs programmables, sont des architectures purement orientées instructions. Plusieurs modèles, plus ou moins anciens, ont été proposés en fonction de la manière dont sont définies et traitées les instructions. On différencie ainsi principalement les processeurs dont le jeu d’instructions est réduit (RISC – Reduce Instruction Set Processor ) ou complexe (CISC – Complex Instruction Set Processor); ceux dont on sépare le flot d’instructions et de données comme le modèle d’architecture Harvard des processeurs de traitement du signal (DSP – Digital Signal Processor ) dans lequel sont physiquement séparées les mémoires d’instructions et de données ainsi que les bus associés ; ou encore les processeurs qui adressent plusieurs unités fonctionnelles en parallèle dans la même instruction, exploitant ainsi le parallélisme d’instructions (processeurs VLIW – Very Long Instruction Word) ; enfin ceux qui comportent des mécanismes matériels complexes permettant une exécution concurrente des instructions (processeurs superscalaires) et ceux qui sont capables d’exécuter des instructions vectorielles (processeurs vectoriels).

Reconfiguration à plusieurs niveaux
Certaines architectures supportent plusieurs niveaux de reconfiguration comme c’est le cas de l’architecture DART présentée plus loin (1.4.1) qui combine l’utilisation d’un bloc FPGA pour les traitements logiques et de plusieurs blocs reconfigurables à gros grain pour les traitements arithmétiques.

Remarque
Plusieurs classifications ont été proposées concernant les architectures reconfigurables, permettant ainsi de mieux appréhender leur diversité. Le lecteur souhaitant élargir son champ de connaissance sur la diversité des architectures reconfigurables peut se référer à la taxonomie publiée par Radunovic [90] qui sert souvent de référence.

Table des matières

Introduction
1 Architectures reconfigurables à gros grain – État de l’art
1.1 Architectures reconfigurables
1.1.1 Origines et définitions
1.1.2 Évolutions
1.2 Architectures reconfigurables à gros grain
1.2.1 Couplage Processeur – CGRA
1.2.2 Principales caractéristiques d’une CGRA
1.3 Problématiques de conception d’une CGRA
1.3.1 Prétraitement
1.3.2 Génération d’architecture
1.3.3 Méthodologie de déploiement
1.4 Sélection de CGRA pour les applications multimédia
1.4.1 DART
1.4.2 Montium
1.4.3 ADRES
1.4.4 Silicon Hive
1.5 Synthèse
2 La programmation par contraintes : une nouvelle approche pour la conception et la compilation pour architecture reconfigurable à gros grain
2.1 Bases de la programmation par contraintes
2.1.1 Problème de satisfaction de contraintes
2.1.2 Contraintes
2.1.3 Algorithme de réduction de domaine
2.1.4 Mécanisme de propagation
2.1.5 Mécanisme de recherche de solutions
2.1.6 Modélisation
2.2 Application à la conception et à la compilation pour architectures embarquées
2.3 Application à la conception et à la compilation pour architectures reconfigurables
2.3.1 Modélisation d’une application
2.3.2 Modélisation d’une architecture
2.3.3 Notre méthodologie
2.3.4 UPaK et DURASE deux systèmes pour la conception et l’utilisation d’extensions reconfigurables pour ASIP
2.4 Conclusion
3 Modèle de contraintes pour la fusion d’unités fonctionnelles reconfigurables 
3.1 État de l’art sur la fusion de chemins de données dans le cadre de la synthèse d’architecture matérielle
3.1.1 Algorithme basé sur la recherche d’une clique de poids maximum
3.1.2 Concept de contournement d’opérateur
3.1.3 Positionnement de la contribution au regard de l’état de l’art
3.2 Modèle de contraintes pour la fusion de chemins de données
3.2.1 Aperçu de l’algorithme
3.2.2 Intégration et généralisation du concept de contournement d’opérateur
3.2.3 Conditions de compatibilité entre appariements
3.2.4 Modèle pour la recherche de clique de poids maximum
3.2.5 Modèles pour le problème d’augmentation du chemin critique
3.3 Résultats
3.3.1 Comparaison avec l’approche de Moreano
3.3.2 Résultat sur un ensemble d’applications multimédia
3.4 Conclusion et perspectives
4 Modèles de contraintes pour le déploiement d’applications sur CGRA
4.1 Introduction
4.2 Contexte : Architecture ROMA
4.2.1 Applications ciblées
4.2.2 Architecture ROMA
4.2.3 Adéquation application, architecture et CP
4.2.4 Déploiement pour l’exploration de l’espace de conception
4.3 Modélisation de CGRA
4.3.1 Modèle d’architecture pour l’exploration de l’espace de conception
4.3.2 Modèle d’architecture pour la génération de configurations
4.4 Déploiement d’une application avec optimisation du temps d’exécution
4.4.1 Modèle de contraintes
4.4.2 Résultats
4.5 Déploiement d’une application sur un modèle d’architecture pipelinée
4.5.1 Modèle d’architecture pipelinée
4.5.2 Problématique
4.5.3 Exemple illustratif
4.5.4 Couverture de l’AG avec des motifs de calcul
4.5.5 Modèle de contraintes
4.5.6 Exemple détaillé
4.5.7 Résultats
4.6 Génération de configurations
4.6.1 Fichiers de configurations
4.6.2 Génération d’adresses
4.6.3 Gestion des déclenchements des configurations
4.6.4 Validation du flot complet
Conclusion

Télécharger le rapport complet