Architecture et performance de la Hardware Stream Dynamic Platform 112

Platform

Sur cette plateforme, nous nous concentrons sur l’aspect dynamique des IPs. À cet effet, cette architecture repose sur des cellules purement matérielles, basée sur des IPs existants. La figure 4.13 présente le système avec une configuration comportant deux nœuds, chacun pourvu de trois cellules de calcul.

Nœud Cellule Hôte Système d’exploitation Serveur de données Ordon-nanceur global Réseau Ethernet Bus Ordon-nanceur local Thread Contrôleur de noyau Thread Contrôleur de noyau Gest. de reconfig. logicel Stockage local Zone d’accueil du noyau Contrôleur de noyau Gest. de stockage FARM Gest. de cellule Nœud Cellule Hôte Système d’exploitation Bus Ordon-nanceur local Zone d’accueil du noyau Contrôleur de noyau Thread Contrôleur de noyau Gest. de reconfig. logicel Stockage local Zone d’accueil du noyau Contrôleur de noyau Gest. de stockage FARM Gest. de cellule Cellules de calcul

Figure 4.13 – Vue de la Hardware Stream Dynamic Platform avec deux noeuds.

Elle ne dispose pas du standard MPI, qui n’est pas réellement nécessaire dans cette version dans la mesure où les IPs utilisés disposent de leur propre manière de récupérer et fournir des données, différente de MPI. Cette plateforme est donc moins orientée HPC, et plus flot de données. Elle permet l’exécution d’applications auto-adaptatives par la présence d’un

ordonnanceur local répartissant dynamiquement les instances des noyaux, ou threads, sur les cellules.

Afin d’éviter de reproduire les problèmes de la précédente plateforme, les transferts de données peuvent cette fois emprunter le bus inter-cellules et ne reposent donc plus uniquement sur la mémoire partagée. Ici, le simple serveur de la plateforme précédente est remplacé par un ordonnanceur global, décidant de la répartition des tâches sur les nœuds. La nouveauté est que cet ordonnanceur global est secondé par un ordonnanceur local, qui décide de la répartition des tâches au sein du nœud.

De plus, un serveur de données est ajouté, qui permet de distribuer les différents éléments de l’application, permettant ainsi un fonctionnement indépendant des nœuds. En effet, le serveur de données évite un stockage préalable des éléments de l’application sur chaque nœud, ces éléments étant récupérés dynamiquement sur le serveur de données.

Contrairement à la Software HPC Platform, dont toutes les cellules étaient homogènes, la Hardware Stream Dynamic Platform dispose de cellules dont les ressources peuvent différer. Ainsi, à la répartition figée de la plateforme statique succède une répartition dynamique prenant en compte les spécificités des cellules pour décider de la localisation d’un thread.

Concernant les cellules matérielles, nous devons gérer une dimension supplémentaire, qui se trouve être la reconfiguration partielle des cellules de calcul. Celle-ci s’appuie sur le ges-tionnaire de reconfiguration, qui épaule l’ordonnanceur local en s’occupant de réaliser les ordres de reconfigurations. Ce gestionnaire de reconfiguration est composé de deux parties. La partie logicielle s’occupe de récupérer le bitstream partiel sur le serveur de fichiers, et de le stocker localement. Ainsi, à la différence de Crenne [118], nous stockons localement les bitstreams de manière à ce qu’ils soient déjà disponibles au moment où la reconfiguration doit s’effectuer. Afin de gérer l’encombrement local, les bitstreams sont remplacés à l’aide d’une politique comparable au LRU20 utilisée par les contrôleurs de mémoires caches.

L’autre partie du gestionnaire de reconfiguration est matérielle et utilise l’IP FaRM pré-senté précédemment. Un driver Linux permet de commander l’IP FaRM à partir du gestion-naire de reconfiguration logiciel, transformant les commandes de reconfiguration en charge-ment de bitstreams partiels.

Cette plateforme a été testée à l’aide d’une chaîne de codage/décodage AES. Nous écrivons un descripteur de travail (job descriptor) contenant l’application, à savoir un encodeur AES suivi d’un décodeur AES. Le comportement et les caractéristiques des IPs sont contrôlés par des descripteurs décrits en XML.

La mise en œuvre de l’encodeur AES consomme 2430 LUTs alors que le décodeur AES utilise 2975 LUTs. Cette plateforme, dont une implémentation est présentée sur la figure 4.14, est fonctionnelle du point de vue local, c’est à dire que chaque nœud peut fonctionner indépendamment si nous lui communiquons la description de l’application à exécuter.

L’ordonnanceur global aura pour tâche de découper une application en plusieurs éléments qui seront distribués sur les nœuds, avec pour objectif de minimiser les échanges de données inter-nœud, afin d’éviter les communications lentes. Ces travaux d’ordonnancement global sont actuellement en cours.

Pour finir, l’application a été testée en utilisant notre technique de compression de bit-20. Least Recently Used

Cellule de calcul 1 Cellule de calcul 2 PowerPC, base de la cellule hôte

Figure 4.14 – Implémentation d’un nœud de la Hardware Stream Dynamic Platform contenant deux cellules sur Virtex 5 FX70t.

stream disponible dans FaRM. Les temps de configuration ont été mesurés et sont présentés dans le tableau 4.5.

Tableau 4.5 – Temps de reconfiguration exprimés en cycles d’horloge.

Compression Encodeur Décodeur

oui 79 633 91 232

non 103 295 103 287

4.6 Conclusion

Ce chapitre a abordé la problématique du reconfigurable au sein des systèmes d’exploita-tion : le HwOS centralisé, l’OS FOSFOR et l’approche HPRC et auto-adaptative en utilisant l’OS Linux. Ces contributions sur les architectures reconfigurables dynamiques et partielles sont possibles grâce à la technologie actuelle qui est capable de se reconfigurer partiellement. La première contribution de ce chapitre a proposé de réduire les temps de reconfiguration de ces zones reconfigurables à l’aide d’un IP FaRM qui combine plusieurs techniques comme la compression O-RLE, un contrôleur interne sophistiqué. Ceci a permis d’obtenir une vitesse de reconfiguration très importante par rapport à l’IP de Xilinx, allant jusqu’à 800Mo/s pour FaRM. De plus, nous proposons également un modèle de reconfiguration précis pour le calcul du temps de reconfiguration qui peut être utilisé pour alimenter notre simulateur SystemC et développer des stratégies de placement et d’ordonnancement.

Les deux contributions suivantes ont eu comme objectif de concevoir des systèmes d’ex-ploitation en matériel. Dans le premier cas, l’OS multiprocesseur matériel est centralisé et ne gère pas les tâches matérielles. Quant à l’OS FOSFOR, son objectif est justement d’avoir une approche d’OS multiprocesseur distribué et de pouvoir gérer des tâches matérielles comme des tâches logicielles avec un OS logiciel (RTEMS), un OS matériel (Compatible RTEMS) et une couche d’intergiciel qui fournit des services de haut-niveau aux tâches.

La dernière contribution propose une méthodologie pour les systèmes HPRC et auto-adaptatif. Nous avons détaillé les différents éléments de notre méthodologie destinée à l’im-plémentation d’applications parallèles. Nous avons étudié le flot de conception de l’applica-tion, permettant nativement un codesign logiciel–matériel en ligne des applications. De plus, nous avons vu que ce flot pouvait facilement s’appliquer aux applications existantes désirant profiter de notre méthodologie. Nous avons également abordé les différentes plateformes que nous avons développées pour permettre d’accueillir ces mêmes applications.

Cet axe de recherche a été possible grâce aux projets ANR FOSFOR et ARDMAHN, et à l’aide de deux doctorants qui sont actuellement en 3e année de thèse, et également de stagiaires. Ces travaux ont conduit à 3 revues internationales [5, 6, 8], 2 revues internationales en première soumission [11, 10], 1 revue nationale en première soumission [188], 6 conférences internationales [168, 166, 171, 173, 185, 187], et 5 conférences nationales [189, 190, 192, 194, 199].

Conclusions et Perspectives

5.1 Bilan

Depuis une trentaine d’années, les circuits intégrés, la technologie et les applications ont considérablement évolué. En 1996, lors de mon DEA, je réalisais mes premiers travaux sur microcontrôleur 68332 et circuit programmable xc4010 de la société Xilinx. Quinze ans plus tard, je travaille sur des architectures comportant un ou plusieurs SoPC intégrant de nombreuses portes logiques, de la mémoire, des processeurs, des blocs plus complexes comme des modules Ethernet, PCI-Express, etc. De plus, ces architectures SoPC sont capables de supporter des systèmes d’exploitation embarqués bien plus lourd tels que Linux. C’est à partir de ce constat que j’ai défini un sous-thème traitant de ces problématiques selon 3 axes présentés dans le manuscrit.

Les applications exécutées sur des architectures reconfigurables demandent toujours plus de QoS qui deviennent encore moins évidentes à maîtriser et à garantir, due à la dimension supplémentaire du reconfigurable. Finalement, nous avons une architecture plus flexible, plus dynamique, avec plus de possibilités et de solutions architecturales qui engendre des décisions plus complexes à prendre en ligne. D’une manière générale, la QoS est tributaire de ces décisions en ligne qui peuvent être des modifications : de l’ordonnancement, de la répartition de l’application, du réseaux d’interconnexion et même de l’architecture en elle-même. Si nous ajoutons à ceci que certaines applications demandent des contraintes temps réel dur, cela complique encore plus la prise de décision. Par conséquent, cela remet en cause, dans une certaine mesure, le flot de conception classique, c’est-à-dire les méthodes et les outils hors-lignes de conception et de vérification du couple application/architecture. Il faut donc rechercher de nouveaux moyens pour répondre à cette problématique.

L’architecture reconfigurable évolue et les systèmes d’exploitation doivent également pren-dre en compte ce changement de cap important. Dans nos contributions, nous essayons éga-lement d’y répondre en ajoutant la dimension reconfigurable dans les architectures actuelles distribuées et réparties. Nous avons évalué des solutions pour des systèmes d’exploitation

temps réel qui doivent gérer aussi bien les tâches logicielles que matérielles de manière la plus égalitaire possible. De plus, cette évolution du reconfigurable a donné naissance aux archi-tectures HRPC qui ont l’avantage de prendre en considération cette dimension de flexibilité de l’architecture, mais ainsi pose le problème du modèle de programmation associé (FPGA, GPU et CPU).

D’une façon plus générale, ses contributions répondent à ces problématiques d’application temps réel, de qualité de service, de placement et d’ordonnancement de tâches matérielles et, bien sûr, des systèmes d’exploitation sur des architectures reconfigurables, distribuées et réparties. Ceci nous amène à développer des perspectives de recherche pour envisager de nouveaux travaux dans ce domaine très large des systèmes reconfigurables.