Virtualisation

En tant que couche d’abstraction placée entre l’application et le FPGA, l’overlay permet de virtualiser les ressources du FPGA, afin de faciliter leur exploitation dans un contexte Cloud. Historiquement, la virtualisation de ressources matérielles reconfigurables de type FPGA a été considérée dans la recherche depuis une vingtaine d’années, mais les overlays n’ont pas tout de suite été considérés comme solution de virtualisation. Les premiers concepts de virtualisation adressent la limitation en ressources reconfigurables et en entrées/sorties des FPGAs [14, 15]. Ils proposent d’exploiter la capacité de reconfiguration des FPGAs afin de charger et extraire des modules matériels dans/depuis un FPGA de manière similaire à la pagination de la mémoire par un système d’exploitation (SE), où des segments mémoires sont échangés entre la RAM et le disque dur. Le but est de donner aux applications une vue virtuelle du FPGA, comme ayant un nombre illimité de ressources et étant entièrement dédié à chaque application. D’autres travaux [16, 17, 18] vont dans ce sens de la gestion des ressources FPGA par un SE, en partageant le FPGA spatialement et dans le temps. Les FPGAs récents proposent la fonctionnalité de reconfiguration partielle dynamique (DPR), permettant de reconfigurer dynamiquement différentes zones du FPGA indépendamment les unes des autres, c’est-à-dire que la reconfiguration d’une zone ne perturbe pas l’exécution des autres zones. Ainsi, la DPR peut être utilisée pour partager spatialement le FPGA, et configurer différents modules au cours du temps. Cependant, un point clef pour un partage efficace de ressources est la capacité de préemption,

c’est-à-dire de suspendre l’exécution d’un module afin de libérer la ressource au profit d’un autre, pour la reprendre plus tard. En plus de la capacité de reconfiguration, le mécanisme de préemption nécessite donc aussi de pouvoir sauvegarder et restaurer l’état d’exécution des modules. Cependant, les FPGAs ne possèdent pas nativement un tel mécanisme de sauvegarde et restauration. Différentes approches existent [19] : relire le bitstream pour extraire les informations d’état, ou instrumenter le circuit applicatif pour permettre le chargement et l’extraction d’état [20]. Les travaux cités ci-dessus traitent la virtualisation des FPGAs par leur partage temporel et spatial, ce qui permet à un système d’exploitation de donner aux applications une vue virtuelle du FPGA physique. Une approche différente pour la virtualisation de ressources FPGA est le concept de FPGAs virtuels. Les FPGAs virtuels ont été introduits par Lagadec et al. [21] comme des architectures FPGA synthétisées sur des FPGAs physiques, c’est-à-dire des overlays. Lagadec et al. ont exposé les avantages d’une telle approche comme étant la portabilité des circuits applicatifs et la possibilité d’expérimenter avec de nouvelles architectures FPGA. Ils ont aussi souligné des désavantages tels que le surcoût en ressources physiques, la diminution de la fréquence d’horloge, et le besoin d’outils de synthèse ciblant l’architecture du FPGA virtuel. Notons que le concept de d’overlay n’est pas incompatible avec l’approche de virtualisation par un système d’exploitation (partage temporel et spatial). Au contraire, du fait que les architectures overlays ne sont pas contraintes par les architectures des FPGAs hôtes, il est possible de concevoir des overlays qui implémentent des mécanismes de sauvegarde et de restauration de contextes permettant la préemption des applications, et ainsi faciliter la gestion des overlays par un système d’exploitation. Ainsi, les overlays se prêtent bien à une exploitation dans un cadre Cloud, qui nécessite une exploitation dynamique des ressources.

Portabilité

Dans le contexte d’un datacenter, différentes générations de ressources sont exploitées simultanément. Il est donc nécessaire de pouvoir supporter l’hétérogénéité des ressources de calcul. Pour l’exécution logicielle, l’hétérogénéité des ressources informatiques est bien supportée : la majorité des processeurs utilisés dans les datacenters partagent le même jeu d’instruction (le x86), et des mécanismes tels que les machines virtuelles permettent d’exécuter un système d’exploitation depuis un autre. Cependant, dans le cas des FPGAs, l’hétérogénéité des FPGAs fait obstacle d’une part à la gestion homogène des ressources, et d’autre part à la productivité des concepteurs applicatif (les clients du Cloud). En apportant la portabilité applicative sur FPGA, les overlays sont à même de faciliter l’exploitation dans le Cloud de FPGAs différents. Il n’y a pas de compatibilité binaire entre différents FPGAs. Le bitstream d’une application est le fichier binaire de configuration permettant de configurer un FPGA pour implémenter une application donnée. Chaque bit du bitstream participe à la configuration d’un élément configurable du FPGA. Ainsi, même si deux FPGAs d’une même famille partagent le même format de bitstream, un bitstream produit pour un modèle de FPGA ne peut pas configurer un FPGA d’un modèle différent. Or, dans le contexte d’un datacenter, où différentes générations de matériel son exploitées simultanément et présentent donc un ensemble hétérogène de ressources, la non-compatibilité des binaires applicatifs avec certaines ressources de l’infrastructure fait obstacle à une gestion efficace de cette infrastructure. Les FPGAs n’offrent pas non plus de compatibilité au niveau des sources applicatives. Suivant leur modèle et leur constructeur, les FPGA présentent différentes spécificités, telles que le fonctionnement, l’interface et les possibilités offertes par les blocks DSP et les blocks mémoires qu’ils intègrent. D’une part, ces différences entre FPGAs rendent le portage d’une application d’un FPGA à un autre non trivial, et peut demander jusqu’à re-concevoir entièrement l’application. D’autre part, ces incompatibilités entre FPGAs nuisent au “design reuse” sur FPGA, et donc à la productivité des concepteurs d’applications.

Kirchgessner et al. adressent le problème de la portabilité des sources en introduisant VirtualRC [22]. VirtualRC est une couche d’abstraction qui agit comme un “wrapper” : le concepteur écrit son circuit dans une entité “top level”, l’interface de laquelle fournit des connexions à des mémoires, des multiplieurs et des canaux de communication. VirtualRC est portée sur différents FPGAs, implémentant selon les spécificités de chaque FPGA les mémoires, multiplieurs et canaux de communication, tout en gardant une interface fixe pour le “top level” offert au concepteur. Le code applicatif écrit dans le top level de VirtualRC n’instancie pas directement de composants spécifiques au FPGA et est donc portable tel quel sur tous les FPGAs pour lesquels le framework VirtualRC a été porté, quel que soit l’outil de synthèse constructeur utilisé. Cette approche résout le problème de la portabilité des sources : l’effort de portage est mutualisé sur le portage de du framework et non sur chaque application. Cependant, cette approche ne répond pas au problème de l’incompatibilité binaire entre différents FPGAs. L’overlay étant une architecture reconfigurable placée entre l’application et le FPGA hôte, il apporte son propre modèle d’exécution (cf figure 1.1) et isole l’application du FPGA sous-jacent ; l’application ne voit que l’overlay.

L’application doit donc se conformer au modèle d’exécution de l’overlay, et non à celui du FPGA hôte. Par conséquent, l’overlay apporte par nature la portabilité au niveau des sources sur tous les FPGAs pour lesquels il a été synthétisé. Au-delà de la portabilité des sources applicatives, l’overlay apporte aussi la compatibilité binaire entre différents FPGAs hôtes. En effet, le mécanisme de configuration de l’overlay est implémenté dans l’overlay lui-même, donc le rôle de chaque bit de configuration du bitstream ciblant l’overlay est propre à l’overlay et est indépendant du FPGA sous-jacent. Ainsi, si une application est synthétisée pour un overlay, alors elle peut être exécutée de manière transparente sur tout FPGA supportant l’overlay, sans nécessiter de re-synthétiser l’application. L’effort de portage et donc mutualisé sur le portage de l’overlay d’un FPGA à un autre, et non des applications. Par exemple, dans [23], les auteurs ont démontrés la compatibilité binaire apportée par leur overlay grain fin Zuma entre un FPGA Xilinx et un FPGA Altera. Finalement, l’overlay apporte l’indépendance par rapport aux outils de synthèse constructeur. Effectivement, l’architecture de l’overlay étant indépendante de celle du FPGA hôte, l’outil de synthèse ciblant ce dernier ne peut pas être utilisé pour synthétiser des applications sur l’overlay. Il est donc nécessaire d’obtenir un outil de synthèse adapté à l’architecture de l’overlay ciblé [21]. En revanche, cet outil est indépendant des outils constructeurs, et le même outil peut être utilisé pour synthétiser sur overlay quel que soit le constructeur et le modèle du FPGA hôte. Dans le contexte du Cloud, les overlays permettent donc de présenter un environnement de développement applicatif uniforme, quels que soient les FPGAs hôtes physiques présents dans l’infrastructure des datacenters.