Optimisation de l’architecture

La figure 2.2 présente l’architecture du contrôleur d’ICAP de Xilinx [1], dans sa version AXI, le nouveau standard de bus ARM [25]. On remarque que le contrôleur est simplement un périphérique esclave qui doit être commandé par un microprocesseur, par exemple un MicroBlaze ou un PowerPC. Les données sont alors stockées dans une FIFO contrôlée par une machine à états finis. La fréquence d’horloge recommandée pour l’ICAP étant 100 MHz avec un bus de 32 bits de données, le débit théorique de cette macro est de 400 Mo/s. Le fait de devoir transférer les données une à une via des écritures de registres sur le bus constitue un premier goulot d’étranglement au niveau des performances ce qui mène à des performances très éloignées du débit théorique. Les auteurs de [26] présentent un dépôt de bitstreams hiérarchique fonctionnant sur le principe de la mémoire cache. Au niveau le plus proche de l’ICAP, lorsque les bitstreams sont stockés localement, les auteurs ont développé une architecture basée sur DMA (Direct Memory Access, en français accès direct à la mémoire) couplé à une RAM afin de répondre au problème mentionné ci-dessus.

Une approche similaire est proposée en [2], où les auteurs comparent différentes architectures, utilisant ou non le cache du processeur ou un DMA (voir figure 2.3). alors indépendant du processeur pour les transferts de données. Cette version est la plus efficace en termes de transfert de données à l’exception de la version BRAM_HWICAP, atteignant presque le débit théorique de l’ICAP de 400 Mo/s qui utilise une BRAM pour stocker intégralement le bitstream. Cette version atteint ses limites avec le test 4 qui demande le transfert d’un bitstream d’environ 80 ko qu’il n’a pas été possible de stocker intégralement en BRAM sur un FPGA Virtex-4 FX20. Même si les FPGA embarquent de plus en plus de mémoire, la granularité de reconfiguration tend à grandir également et stocker l’intégralité d’un bitstream n’est donc pas la solution la plus sobre pour un contrôleur de reconfiguration. Les mêmes auteurs présentent dans [27] leur utilisation de configurations virtuelles pour réduire le temps de reconfiguration. Cette méthode consiste à implémenter plusieurs contextes : un contexte actif contenant les données de configuration courantes du FPGA et un ou plusieurs contextes latents qui peuvent être modifiés à volonté sans interrompre le fonctionnement du contexte actif. Cette solution est parfaitement adaptée aux FPGA multi-contextes, qui bénéficient nativement de contextes de configuration séparés [28, 29, 30]. Néanmoins, dans le cas de FPGA mono-contexte comme c’est le cas des FPGA Xilinx, l’implémentation nécessite de mémoriser autant de données de configuration qu’il y a de contextes latents, ce qui peut rapidement faire exploser le coût mémoire de la solution.

Compression des bitstreams

Comme précisé dans le préambule, compresser les bitstreams permet d’une part de diminuer les besoins en stockage mémoire du système mais également de réduire la taille des données à transférer à l’ICAP. Les auteurs à l’origine de DAGGER [3] comparent différents algorithmes de compression reconnus comme ZIP, GNU Zip (GZIP) et RLE (Run Length Encoding, en français codage par plages) à leur propre algorithme basé sur RLE et Lempel- Ziv-Welch (LZW) (voir la comparaison des tailles de bitstream en octets obtenus après compression en figure 2.4). Dans cette étude, les auteurs donnent uniquement les tailles des bitstreams après compression et non les tailles des fichiers originaux. On ne peut donc pas connaitre le taux de compression réalisé par leur algorithme. Toutefois, on peut le comparer aux autres algorithmes évalués : celui-ci semble donc être meilleur que le RLE (qui donne étonnamment de très mauvais résultats) mais donne des résultats très éloignés des algorithmes comme ZIP. Il faut toutefois garder à l’esprit que même si le taux de compression s’avère excellent (réduisant ainsi les transferts depuis la mémoire), il faut pouvoir garantie une chaîne de décompression efficace puisque la décompression doit être effectuée en ligne pour envoyer les données décompressées à l’ICAP. Les algorithmes comme ZIP perdent donc de leur intérêt. Il faut également noter que ces bitstreams programment une couche virtuelle du FPGA et peuvent donc ne pas être représentatifs des résultats qui seraient obtenus pour des bitstreams natifs. Les travaux présentés en [4] sont plus exhaustifs vis-à-vis de l’évaluation des algorithmes de compression. En effet, les auteurs n’ont pas uniquement observé le taux de compression obtenu mais aussi des métriques comme le débit obtenu et la quantité de ressources nécessaires à la décompression.

Les auteurs de [5] présentent UPaRC (Ultra-Fast Power-aware Reconfiguration Controller, un contrôleur de reconfiguration ultra-rapide utilisant à la fois une architecture optimisée à base de BRAM et un algorithme de compression de bitstreams (voir figure 2.6). Utilisant une solution très similaire à la nôtre, les auteurs vont toutefois plus loin dans l’optimisation des performances. Ils utilisent ainsi un algorithme de compression open source très efficace, X-MatchPRO [31], réalisant des taux de compression de près de 75% en moyenne. Toutefois, ces performances se font à l’encontre de la complexité de l’algorithme, dont la partie décompression doit être implantée sur le FPGA nécessite un nombre non négligeable de ressources (environ 1000 slices) pour obtenir un débit correct (1 Go/s, soit un mot de 32 bits par cycle à 250 MHz). Concernant la partie architecture, les auteurs ont réussi à élever la fréquence d’horloge de l’ICAP, initialement prévue pour fonctionner à 100 MHz, jusqu’à 362.5 MHz ce qui leur permet d’annoncer un débit maximal de 1433 Mo/s pendant la reconfiguration.

Modélisation avec UML

UML (Unified Modeling Language) [37] est un langage de modélisation graphique et orienté objet, initialement dédié à la modélisation logicielle. Néanmoins, UML est désormais largement utilisé pour modéliser des systèmes matériels ou mixtes, en grande partie grâce aux nombreux outils supportant le langage ainsi que son mécanisme d’extension qui le rend très flexible pour personnalisation des modèles. En particulier, la modélisation de systèmes embarqués est facilitée par l’extension MARTE (Modeling and Analysis of Real-Time Embedded systems) [38]. MARTE étends les capacités de modélisation d’UML pour les systèmes embarqués et temps-réel mais ne supporte pas nativement la reconfiguration dynamique. Les travaux présentés en [6, 39] étendent les capacités de MARTE en utilisant le framework GASPARD2, un environnement de développement intégré pour la co-modélisation de SoC qui permet notamment la génération de code en différents langages à des fins de validation (Lustre), de simulation (SystemC) ou de synthèse (RTL). La figure 2.7 montre un exemple de modélisation avec MARTE d’un système reconfigurable dynamiquement. On remarque que certains paramètres ont été ajoutés comme le champ areatype qui définit une entité comme statique ou reconfigurable dynamiquement. À notre connaissance, cette approche ne permet pas de développer et valider d’algorithme d’ordonnancement.

Ces travaux sont actuellement poursuivis dans le cadre du projet ANR FAMOUS (Flot de modélisation et de conception rapide pour les systèmes dynamiquement reconfigurables) dans le but de livrer l’extension RecoMARTE. Toujours dans le cadre du projet ANR FAMOUS, les auteurs de [40] présentent un contrôle événementiel de la reconfiguration dynamique. La modification d’une zone reconfigurable n’est plus décidée par un algorithme d’ordonnancement mais par une machine à états finis définie lors de la description du modèle qui donne lieu à la génération automatique d’un contrôleur adapté. La reconfiguration dynamique est utilisée pour modifier le comportement d’un module ayant une fonctionnalité prédéfinie : il n’est pas question ici de mutualisation de ressources entre deux tâches différentes sur une même zone reconfigurable. C’est le point faible de cette approche, qui ne prend en compte qu’une partie des aspects de la reconfiguration dynamique. Une autre approche utilisant MARTE est présentée dans [41, 7], issue du projet MoPCoM (Modeling and specialization of platform and components MDA) qui définit une méthodologie de co-design basée sur l’architecture dirigée par les modèles (en anglais MDA, Model Driven Architecture). La modélisation est séparée en trois niveaux, depuis un modèle indépendant de la cible jusqu’à un modèle spécifique à l’architecture (voir figure 2.8). Le processus de développement part d’un modèle abstrait qui définit le modèle de calcul (en anglais MoC, Model of Computation) pour y intégrer au fur et à mesure les contraintes liées à l’architecture cible. Finalement, le modèle alloué du dernier niveau doit être suffisamment détaillé pour fournir du code d’implémentation des parties matérielles et logicielles de la plate-forme. À chaque niveau, on retrouve une approche en Y qui sépare le modèle de l’application, le modèle de l’architecture cible et les fusionne pour former un modèle alloué. La prise en compte de la reconfiguration dynamique intervient au niveau du modèle alloué. Dans ce cas, plusieurs composants du modèle applicatif sont assignés à un seul composant du modèle architectural.