Flux de conception CPU plus FPGA pour les développeurs de logiciels :une nouvelle réalité tangible

Récemment, Brian Bailey a organisé une table ronde qui a abouti à un article en deux parties intitulé Supporting CPUs Plus FPGAs . Les experts ont discuté de la réalité évolutive de la conception de systèmes basés sur des FPGA et des CPU. Cette discussion aborde les développements récents dans le flux de conception et comment l'utilisation de nouvelles technologies peut aider les développeurs de logiciels à atteindre un délai de mise sur le marché plus rapide pour les plates-formes CPU et FPGA.

Présentation
Au vu de l'intérêt croissant pour l'intelligence artificielle (IA), de l'émergence des objets connectés (IoT) et de la tendance à l'accélération des centres de données, tout nous amène à nous demander :quel est le dénominateur commun entre les trois ?

Les développeurs de logiciels sont au centre de toutes ces tendances et ils cherchent à accélérer leur programmation et leurs calculs. Les dernières avancées technologiques, notamment une faible latence de communication entre les FPGA et les CPU, associées à la consommation d'énergie relativement faible des FPGA actuels, font des systèmes basés sur FPGA et CPU le bon choix pour atteindre les performances souhaitées. Au centre de cette convergence, cependant, les développeurs de logiciels sont gênés par la complexité sous-jacente de la technologie FPGA.

Au cours des dernières années, les outils de synthèse de haut niveau (HLS) se sont considérablement améliorés en ce qui concerne la complexité des systèmes actuels et le raccourcissement des délais de mise sur le marché. Cependant, les outils HLS se concentrent avant tout sur les blocs IP (c'est-à-dire qu'ils sont centrés sur l'IP). Il existe un large éventail de décisions/d'optimisations au niveau du système qui ne peuvent pas être prises en charge par les outils HLS pour répondre aux exigences. Certaines de ces exigences incluent la recherche du bon équilibre entre les tâches logicielles et les accélérateurs matériels, la comparaison du pipeline par rapport à l'exécution parallèle, l'obtention de la granularité des données souhaitée, l'évaluation des mécanismes de communication et bien d'autres.

Afin de construire ces systèmes complexes, les développeurs de logiciels ont besoin d'un flux de conception qui offre une prise en charge conjointe du matériel et des logiciels. Un tel flux doit être suffisamment simple pour justifier son utilisation (comme le flux des développeurs de logiciels) et son adoption par les développeurs de logiciels. Le flux doit également fournir des informations pertinentes sur les choix d'optimisation disponibles pour atteindre les objectifs de performances requis. Certaines entreprises ont récemment ouvert la voie pour faciliter la tâche des développeurs de logiciels en faisant abstraction des détails technologiques du flux de conception matérielle. Ces entreprises s'inspirent des approches de conception au niveau du système décrites dans Modèles ESL et leur application :conception et vérification au niveau du système électronique en pratique .

Comprendre la méthodologie du flux de conception au niveau du système
La conception au niveau du système se concentre sur des problèmes de niveau d'abstraction plus élevé. Bien qu'il soit nécessaire de se concentrer sur une vue d'ensemble, divers niveaux d'abstraction sont utilisés pour valider, vérifier, affiner et intégrer différentes parties du système avant qu'il ne soit réellement développé. Même si la communauté des ingénieurs ne s'accorde pas sur un langage commun à utiliser, la majorité des ingénieurs de conception commencent au niveau algorithmique. Les concepteurs valident les spécifications système non fonctionnelles et fonctionnelles en créant des modèles d'exécution écrits dans des environnements C/C++/SystemC, MATLAB, Simulink et LabVIEW. Ces langages de haut niveau sont utilisés pour modéliser le comportement de l'ensemble du système.

Pour les besoins de cette discussion, nous nous sommes concentrés sur un flux de conception au niveau du système basé sur les spécifications C/C++ (Figure 1). Le premier bloc est divisé en trois étapes. La première de ces étapes représente le profilage d'application (c'est-à-dire le partitionnement matériel-logiciel) où des morceaux de code C/C++ (fonctions, boucles, etc.) sont considérés comme étant déplacés dans le matériel (FPGA). L'étape suivante est la spécification de la plate-forme CPU/FPGA (par exemple, ARM53/FPGA, POWER8/FPGA) et la configuration des éléments de la plate-forme matérielle (horloge système, cache du processeur, interconnexions, etc.). L'étape suivante consiste à mapper les tâches de l'application (en fonction de l'application profilée) entre le matériel et le logiciel (c'est-à-dire le processeur dur et/ou logiciel) et, à la toute fin, la génération d'une architecture exécutable.

Figure 1. Flux de conception type au niveau du système pour CPU/FPGA
(Source :Space Codesign Systems, Inc.)

Le deuxième bloc de la figure 1 concerne l'optimisation de l'architecture (également appelée exploration architecturale ou vérification des performances). Ceci est décrit plus en détail dans la figure 2.

Figure 2. Le processus d'optimisation de l'architecture
(Source :Space Codesign Systems, Inc.)

Le processus d'optimisation de l'architecture aborde les estimateurs suivants :

• Estimation du matériel évalue les métriques de partitionnement matériel (c'est-à-dire le code C/C++ déplacé sur le FPGA). Il peut être décomposé par ressources, performances (par exemple, latence de boucle) et estimations de puissance. L'estimation du matériel est pilotée par les outils HLS (synthèse de haut niveau).
• Estimation du logiciel évalue les métriques du code de partition C/C++ exécuté sur le processeur (c'est-à-dire le processeur dur et/ou logiciel). Ce processus est complémentaire à l'étape d'estimation matérielle. Des exemples de mesures de performances sont la charge du processeur, le changement de tâche et les échecs de cache.
• Estimation du transfert de données consiste à modéliser les interfaces (c'est-à-dire les interfaces de mappage de mémoire et de streaming) par lesquelles le matériel et le logiciel communiquent. Des exemples de métriques collectées sont les performances du bus (par exemple, la latence et le débit), la file d'attente et l'utilisation de la mémoire.

Ces estimations sont agrégées dans une base de données et une analyse des performances du système est présentée au développeur pour évaluer si les exigences du système sont satisfaites. Les architectures qui satisfont aux exigences passent au processus de mise en œuvre de l'architecture ; sinon, des tentatives d'optimisation supplémentaires au niveau du système sont traitées.

Le dernier bloc de la figure 1 concerne la mise en œuvre de l'architecture où les architectures système sont converties en flux binaire (pour la mise en œuvre FPGA) à l'aide d'outils de mise en œuvre tels que Xilinx Vivado ou Intel Quartus Prime pour la génération finale et complète du système à exécuter sur la plate-forme physique spécifique. Cette étape doit produire un code de qualité et doit être transparente pour le développeur du logiciel.

Optimisation au niveau du système
Le manque d'outils automatisés pour l'optimisation architecturale a longtemps été perçu comme une faiblesse majeure de l'informatique basée sur FPGA. Le développement de tels outils a été difficile en raison de la complexité et des défis impliqués.

Pour illustrer ces défis, la figure 3 montre un processus d'optimisation typique au niveau du système lors d'une exploration architecturale pour une application de traitement d'images composée de six fonctions (parties de code C/C++) à implémenter sur une plate-forme Zynq-7000. Ici, nous listons huit architectures potentielles pouvant être implémentées sur la plate-forme. Le time-to-market ne permettant pas la mise en œuvre de chaque architecture, la meilleure à mettre en œuvre doit être rapidement déterminée. Cette séquence d'optimisations peut être difficile, même pour les concepteurs de matériel expérimentés.

Figure 3. Exploration de l'architecture avec les décisions au niveau du système affichées en bleu
(Source :Space Codesign Systems, Inc.)

Les outils de développement de logiciels FPGA tels que SDSoC/SDAccel (Xilinx), Merlin Compiler (Falcon Computing Solutions) et SpaceStudio (Space Codesign Systems) sont des solutions commerciales qui aident les développeurs de logiciels dans la conception de systèmes FPGA/CPU tout en réalisant une optimisation au niveau du système. Ces outils adoptent un flux similaire à celui décrit dans les figures 1 et 2, et - par là - ils démontrent l'existence d'une nouvelle génération d'outils au niveau du système avec des approches différentes.

SDSoC estime les performances du système selon une approche en deux étapes. Initialement, SDSoC estime les latences pour les fonctions matérielles (à partir des outils HLS) et la caractérisation interne (c'est-à-dire le transfert de données) de la plate-forme physique ciblée et de ses interfaces de communication. Plus tard, cette estimation est comparée à une version uniquement logicielle de l'application s'exécutant sur la plate-forme physique.

Merlin Compiler propose une transformation de source à source. L'objectif de la transformation source à source est de réduire ou d'éliminer l'écart d'abstraction de conception entre le développement de logiciels/d'algorithmes et les flux de conception HLS existants. Le compilateur Merlin s'appuie sur quatre pragmas pour déduire des conceptions FPGA spécifiques. En plus des quatre optimisations majeures déclenchées par les pragmas explicites, le compilateur Merlin contient également diverses optimisations implicites (c'est-à-dire les passes de transformation du compilateur) qui sont effectuées avec les pragmas pour aider à améliorer les résultats du pipeline et de la parallélisation.

SpaceStudio génère de manière transparente une plate-forme virtuelle (VP) exécutable pour chaque architecture candidate (mapping). Un VP typique est composé de simulateurs de cœur de processeur connectés à divers modèles de bus, de contrôleurs de mémoire et d'autres modèles de périphériques de données. Il modélise la plate-forme ciblée ainsi que les transferts de données dans un environnement co-simulé spécifiquement adapté à l'application. Cela signifie que l'exécutable VP permet une prédiction des performances et une validation des algorithmes plus précises de l'application. Il intègre également des capacités de surveillance et d'analyse pour un profilage des performances non intrusif des fonctions matérielles et des tâches logicielles. VP s'appuie sur des outils HLS pour les estimateurs matériels, tandis que les retards (par exemple, les latences) des fonctions mappées matériellement sont automatiquement annotés pour augmenter la précision du processus de simulation. Le VP peut être inspecté par le développeur du logiciel pour comprendre comment les tâches d'optimisation sont mises en œuvre. Ces commentaires aident le développeur de logiciels à réaliser la conception prévue pour les optimisations appliquées spécifiques.

Une façon de visualiser l'écosystème commercial
La figure 4 propose une vue de l'écosystème commercial gravitant autour du monde de la conception de CPU et de FPGA basés sur des plates-formes. La première case (supérieure) présente l'entrée de conception principale au niveau de l'algorithme. La deuxième boîte contient des environnements prenant en charge la synthèse algorithmique (c'est-à-dire de l'algorithme à l'implémentation). Les outils marqués en gras prennent en charge l'entrée de conception C/C++ et effectuent des optimisations au niveau du système. La troisième case représente les outils utilisés pour réaliser l'implémentation architecturale, principalement les outils des fournisseurs de FPGA qui effectuent la synthèse de bas niveau et la génération de flux binaire. Au bas de la figure, des exemples de plates-formes CPU/FPGA sont illustrés.

Figure 4. Écosystème commercial pour les plates-formes CPU/FPGA
(Source :Space Codesign Systems, Inc.)

De plus, le tableau 1 répertorie certains des principaux outils commerciaux utilisés dans la conception de plate-forme CPU/FPGA.

Tableau 1. Outils d'automatisation commerciaux (*Remarque :Une liste est proposée dans cette revue)

Conclusion
Le but ultime est de démocratiser le développement de plates-formes CPU plus FPGA à une population plus large d'utilisateurs, telle que la communauté des développeurs de logiciels. En regardant l'analogie des langages de programmation, il a fallu plus de 50 ans à l'industrie informatique pour que les langages de programmation évoluent vers des langages conviviaux tels que Python ou, plus récemment, Swift. Un processus d'évolution similaire se produit dans l'industrie de la programmation FPGA. L'acceptation des outils HLS a pris un certain temps avant d'être approuvée par les concepteurs de systèmes. Aujourd'hui, avec l'avènement des solutions de niveau système pour les développeurs de logiciels, nous entrons dans une nouvelle phase. Des outils commerciaux tels que SpaceStudio, SDSoC et Merlin Compiler témoignent de ce processus d'acceptation. Pourtant, beaucoup de travail reste à faire afin d'avoir un processus entièrement automatisé et optimisé à travers les compilateurs ciblant les plates-formes CPU et FPGA.

Guy Bois, ing., PhD est le fondateur de Space Codesign Systems et professeur au Département de génie logiciel et informatique de Polytechnique Montréal. Guy a participé à de nombreux projets de R&D en collaboration avec des leaders de l'industrie tels que STMicroelectronics, Grass Valley, PMC Sierra, Design Workshops Technologies et Cadabra Systems. L'expertise de recherche de Guy dans le domaine de la conception de code matériel/logiciel a conduit à la commercialisation de la solution et à la création de SpaceStudio de Space Codesign Systems Inc.