Commande de reconfiguration

La reconfiguration dynamique partielle des composants FPGA est soumises à plusieurs règles dépendant des contraintes imposées par l’application (diminution de la consomma- tion, augmentation des performances, gestion des ressources composant disponibles). Dans cette partie, nous allons nous intéresser à la commande de ces reconfigurations.

2.3.1.1 Commande via des contrôleurs matériels internes

Une première solution consiste à commander ces reconfigurations en interne. En effet, une fois les régions dynamiquement reconfigurables ont été définies avec l’outil PlanAhead [44], l’utilisateur pourra implémenter une logique qui commandera les reconfigurations des différentes régions. Cette méthode a un grand intérêt, en effet, une commande purement matérielle présente plusieurs avantages.

Le premier est le faible coût de ce type d’implémentation en terme de ressources maté- rielles, en effet, dans le cadre d’applications simples où les reconfigurations vont dépendre d’équations logiques, la programmation de ces dernières se fera plus aisément via les outils disponibles.

Le second concerne la consommation de ce type d’implémentations qui sera faible en conséquence direct de la faible occupation des équations logiques sur le composant FPGA. Enfin, le troisième avantage sera le déterminisme de cette implémentation, en effet les équations étant "câblées matériellement", le temps de passage sera identique à chaque ité- ration permettant ainsi de respecter des contraintes temps-réel qui pourraient être imposées dans le cadre du développement d’une nouvelle application.

2.3.1.2 Commande via des contrôleurs externes

Dans le cadre de développement d’architectures s’appuyant sur des composants hété- rogènes (CPU, GPU, DSP, FPGA, etc.), les commandes de reconfiguration dynamique pourront se faire depuis un composant extérieur au FPGA.

Pour ce faire, la décision se fera depuis un cœur de calcul distant du composant FPGA et sera communiqué par un médium de communication liant ces deux composants.

C’est dans ce cadre que les auteurs de [42] proposent une architecture sur laquelle le composant FPGA sera reconfiguré par une interface distante communiquant via le bus PCIe. En effet, l’acteur de commande distant envoie à travers le bus disponible la configu- ration souhaitée à un IP "Configuration Control" situé sur la puce qui agira directement sur la région reconfigurable sur le composant.

Le contrôle distant est également utilisé par les auteurs [11] dans le cadre de la TMR (Triple Modular Redundancy), les performances du bus de communication permettent une réactivité optimale du système global.

Ces solutions décrites ci-dessus permettent d’envisager la supervision globale d’une architecture composée de plusieurs puces FPGAs par un cœur de calcul distant et relié par un bus de communication.

2.3.1.3 Commande via des systèmes systèmes d’exploitations

Une autre solution possible est d’utiliser un système d’exploitation pour la commande des reconfigurations du composant FPGA.

Une des solutions existante est ReconOS [48] (Re-Configurable and Extensible Opera- tive System) un environnement d’exécution proposant l’utilisation de threads logiciels et

matériels permettant au système d’utiliser au mieux les ressources logicielles et matérielles disponibles. Dans [25], les auteurs proposent plusieurs implémentations de cette solution sur différents systèmes d’exploitation (Linux, eCOS) sur différent processeurs (Power PC sur Virtex 2 et 4, MicroBlaze sur Virtex 4). Cette flexibilité laisse une grande liberté d’uti- lisation aux développeurs. Cette solution permettra la gestion d’exécution d’applications ainsi que la commande de reconfiguration partielle et dynamique des composants FPGAs. Une autre solution existante est R3TOS [16] (Reliable Reconfigurable Real-Time Ope- rating System), un ROS (Reconfigurable Operating System). Gordon Brebner [29] a été le premier a proposer ce type de système d’exploitation dans le but de coordonner l’exé- cution des différentes tâches matérielles afin d’utiliser au mieux les ressources disponibles. Ces ressources sont virtualisées [36] permettant à l’application utilisateur de les exploiter afin d’augmenter la puissance de calcul disponible. Ce type de service doit être fourni avec une API permettant l’adressage des ressources matérielles disponibles. C’est ce que pro- pose l’API de R3TOS avec des appels systèmes similaires à ceux définis par la famille de standards POSIX. Dans [17], les auteurs proposent une implémentation de ce système dans un Picoblaze n’utilisant que 96 slices du composant FPGA. Une telle implémentation ne consommant que peu de ressources permet d’obtenir un système temps-réel minimaliste gérant la globalité du composant matériel.

Le projet ANR FOSFOR [26] (Flexible Operating System FOr Reconfigurable plat- form) a pour but de reconsidérer la structure purement logicielle du RTOS visant à le rendre flexible, distribué avec une interface homogène du point de vue de l’application. L’objectif sera de reconsidérer les trois services fondamentaux d’un système d’exploitation, l’ordonnancement, les entrées-sorties et la gestion de la mémoire disponible afin que les tâches composant l’application puissent s’exécuter sans connaissance de leur nature maté- rielle ou logicielle. Ce dernier point est très intéressant, en effet, un niveau d’abstraction permettant de traiter les tâches indépendamment de leur implémentation sur le support matériel global permet une gestion plus simple de l’application globale.

Ces solutions offrent un grand intérêt dans le cadre de développement d’applications embarquées sur des composants FPGAs. Dans le cadre de notre projet, nous envisageons d’utiliser le composant FPGA dans un contexte de calcul reconfigurable à haute perfor- mance afin de satisfaire les besoins requis par le domaine d’application. Notre contribution vise à commander la ré-allocation hétérogène des tâches composant l’application de test depuis une machine hôte reliée au composant matériel par un bus de communication rapide.