Les architectures centralisées

Le contrôle centralisé des systèmes dynamiquement reconfigurables sur FPGA a été étudié par plusieurs travaux. Ces travaux peuvent être classés selon le type de l’implémentation du contrôle. Cette implémentation peut être standalone ou par un système d’exploitation (OS). Dans cette section, nous présentons certains travaux dans ces deux catégories.

3.2.1.1 Implémentation standalone

La plupart des travaux sur les systèmes reconfigurables sur FPGA ont proposé une implémentation logicielle du contrôle. Cette implémentation convient bien pour des problèmes de contrôle simples où on n’a pas besoin de services avancés d’un système d’exploitation. L’implémentation logicielle du contrôle des systèmes reconfigurables sur

FPGA peut se faire par un processeur hardcore [61] ou softcore [17]. Dans le cas des sys- tèmes supportant la reconfiguration dynamique partielle et interne (voir section 2.4), le processeur joue deux rôles : 1) la gestion de la commutation des configurations partielles des régions reconfigurables (prise de décision de reconfiguration) et 2) la communication avec le module qui charge les bitstreams partiels (l’ICAP pour les FPGAs Xilinx). La gestion de la commutation entre bitstreams partiels est généralement basée sur des sémantiques de contrôle telles que les machines d’états [58] et les réseaux de Petri [89]. Différentes situations peuvent déclencher la reconfiguration dynamique partielle. Par exemple, dans un système à ressources limitées, la reconfiguration peut être gérée par le graphe des tâches [131] [51] [132]. Dans ce cas, à chaque fois qu’on a besoin d’une tâche qui n’est pas chargée dans le système, le processeur lance une reconfiguration pour la charger à la place d’une autre tâche qui a terminé son exécution. La reconfigu- ration peut être aussi déclenchée par d’autres événements tels que le changement de l’environnement, qui peut nécessiter par exemple l’utilisation d’un filtre différent de détection/suivi d’objets pour un système d’aide à la conduite [48] [24].

Le type du processeur (hardcore ou softcore) utilisé a une influence sur la perfor- mance de la reconfiguration. L’avantage d’un processeur hardcore est que, puisqu’il est implémenté directement sur la puce au lieu d’être implémenté par des slices, il est fait d’une façon personnalisée et optimisée ce qui le rend plus performant qu’un processeur softcore implémenté sur du matériel générique (les slices). L’utilisation d’un processeur hardcore pour lancer la reconfiguration permet donc de diminuer le temps de reconfiguration. Dans [82], la performance du processeur hardcore PowerPC et le processeur softcore MicroBlaze en termes de temps de reconfiguration pour un Virtex-4 a étudiée. L’utilisation de ces deux processeurs pour 5 systèmes différents a montré que le processeur PowerPC peut augmenter la performance de reconfiguration jusqu’à 85% par rapport au MicroBlaze.

Dans [21], un autre type d’implémentation est proposée dans lequel le processeur gère la commutation des configurations partielles alors que la communication avec l’ICAP se fait par un contrôleur matériel. Le processus de reconfiguration se passe comme suit : le processeur envoie des commandes au contrôleur lui indiquant le module qu’il veut utiliser, et contrôleur matériel prend en charge la sélection du bitstream partiel correspondant au module demandé et la communication avec l’ICAP pour charger ce bitstream. L’utilisation du contrôleur matériel a permis d’accélérer la reconfiguration par rapport à une solution entièrement logicielle (un temps de reconfiguration 10 fois plus petit pour un Virtex-II). Cependant, le contrôleur matériel proposé ne présente pas d’interface standard mais une interface dédiée à la communication directe avec le processeur qui n’est pas non plus un processeur standard mais un processeur dont le jeu d’instructions a été étendu pour supporter l’utilisation de coprocesseurs reconfigurables. La gestion matérielle du lancement de la reconfiguration a été également proposée dans [63] permettant une grande réduction du temps de reconfiguration (18,2ms pour une région de 7840 LUTs et flip-flops LUTs, 112 DSP et 28 BRAMs pour un Virtex-5) cependant la gestion de la commutation des configurations partielles n’a pas été étudiée.

3.2.1.2 Implémentation par OS

Que ce soit centralisé ou distribué, l’utilisation d’un système d’exploitation pour le contrôle d’un système reconfigurable a beaucoup d’avantage tels que l’optimisation du partage de ressources entre différentes applications en rendant possible l’exploitation des ressources reconfigurables par différents processus à travers un système multitâche. La différence qu’ont les OSs pour les systèmes reconfigurables sur FPGA par rapport aux systèmes d’exploitation traditionnels est qu’ils doivent gérer l’hétérogénéité des tâches (tâches logicielles et matérielles) à ordonnancer et à faire communiquer. Ces OSs doivent offrir une abstraction de cette hétérogénéité et des services de reconfiguration, du côté de l’application [137]. Dans [117], la séparation entre les codes des applications de l’utilisateur et les processus système pour la reconfiguration a été étudiée. Cela permet de faciliter la réutilisation et la portabilité des codes des applications utilisateur puisque les appels de reconfiguration à haut-niveau qu’ils font ne contiennent aucune information sur l’implémentation à bas niveau du système laissant la gestion de ces détails au système d’exploitation. Dans [40], un OS temps-réel a était étendu pour permettre aux différentes implémentations logicielles et matérielles d’une tâche d’être exécutées d’une manière transparente en offrant aux tâches matérielles des services de communication et de synchronisation similaires à ceux offerts par les systèmes d’exploitation traditionnels aux tâches logicielles. Cela permet la simplification de l’accès à la technologie en faisant une abstraction sur le type des tâches (logicielles ou matérielles) et en virtualisant la communication entre elles.

La gestion de la reconfiguration par OS a été étudiée tant pour la reconfiguration logicielle (changements dans le code exécuté par un processeur) que pour la reconfigu- ration matérielle. Dans [53], le contrôle de la reconfiguration logicielle par un système d’exploitation a été utilisé pour un système multi-processeurs. Le contrôle est implé- menté par un seul processeur. Celui-ci gère à travers le système d’exploitation qu’il implémente des services tels que l’ordonnancement, le transfert des messages entre les autres processeurs et la reconfiguration logicielle pour ces processeurs. Le processeur de contrôle observe les signaux nécessitant le chargement d’une tâche donnée de l’applica- tion et il cherche un processeur inactif parmi les processeurs du système pour charger et exécuter cette tâche. S’il ne trouve pas de processeur inactif, il émet une requête aux processeurs et attend à ce que l’un d’entre eux réponde indiquant que la fonction qu’il était en train d’exécuter n’est plus active. Dans ce cas, la tâche peut être chargée à travers une reconfiguration logicielle du code exécuté par l’un des processeur. L’utilisation d’un système d’exploitation pour la gestion de la reconfiguration matérielle nécessite des services plus complexes afin de gérer efficacement la dynamicité. La plupart des travaux sur les systèmes d’exploitation pour les systèmes reconfigurables sur FPGA ont traité principalement les services d’ordonnancement des tâches logicielles et matérielles et la communication entre ces tâches ainsi que l’allocation et le placement des tâches maté- rielles reconfigurables. Dans ce contexte, les algorithmes d’allocation implémentés visent à minimiser le nombre de refus de chargement des modules requis par les applications utilisateur à cause de l’absence d’espace disponible pour ces modules [137] [117]. Dans ce contexte, le système d’exploitation peut par exemple appliquer une politique d’allo- cation cherchant, pour chaque module matériel requis durant l’exécution, le nombre

minimal des slots consécutifs libres pour le charger afin de minimiser la fragmentation du FPGA [117]. Certains travaux ont aussi proposé des services d’OS pour la génération dynamique de bitstreams [137] [117] pour s’adapter à la dynamicité de la politique d’allocation.

Une approche différente a été proposée dans le projet FOSFOR [87] avec l’utilisa- tion de deux types d’OS pour un même système. L’OS qui gère les tâches logicielles est implémenté en logiciel par les processeurs du système et celui qui gère les tâches matérielles est implémenté en matériel à travers des services distribués placés à côté des régions reconfigurables contrôlées. L’utilisation de l’OS matériel permet de réduire le coût de l’utilisation de l’OS sur la performance globale du système et d’assurer une meilleure synchronisation avec les tâches matérielles contrôlées. Pour la communication entre les tâches logicielles et matérielles, un intergiciel (middleware) a été développé. La communication entre les tâches matérielles est basé sur un réseau-sur-puce personnalisé pour ce type de communication [32]. Cette approche permet donc d’assurer une grande abstraction des tâches en réduisant le coût de l’utilisation d’un OS en termes de temps d’exécution. D’un point de vue prise de décision de reconfiguration des modules maté- riels, la décision est gérée par l’ordonnanceur du système d’exploitation matériel [88]. De ce fait, la distribution dans cette approche concerne plus les services de communication et d’exécution de la reconfiguration alors que la prise de décision de reconfiguration est centralisée par l’ordonnanceur.

Les décisions de reconfiguration gérées par les systèmes d’exploitation dans les travaux présentés ci-dessus sont pour la plupart orientées par l’ordonnancement. L’or- donnanceur dans ce cas, cherche une région vide pour le chargement de la nouvelle tâche à exécuter ou la charge à la place d’une tâche qui a fini de s’exécuter dans un module reconfigurable. L’adaptation des implémentations des tâches à des changements liés à l’environnement ou aux préférences des utilisateurs n’a pas été largement étudiée par les travaux sur le contrôle des systèmes FPGA en utilisant des OSs [40].

L’utilisation des systèmes d’exploitation pour le contrôle des systèmes reconfigu- rables sur FPGA permet d’offrir une grande flexibilité par rapport à une solution stan- dalone à travers des services tels que l’allocation dynamique des tâches aux modules reconfigurables et la virtualisation de la communication entre tâches matérielles et logi- cielles. Cependant, leur coût en termes de temps d’exécution peut être non négligeable surtout s’ils sont implémentés en logiciel[117] [40]. Afin de réduire ce coût, l’implé- mentation matérielle des services de l’OS a été proposée par certains travaux [81] [84] [30] [9] [87]. Cependant, de telles implémentations pourraient aussi avoir un coût non négligeable en termes de ressources utilisées.