Pour le billet du jour, nous allons nous intéresser aux outils de développement.

Le principal outil de développement utilisé dans le cadre de nos expérimentations a été le compilateur aoc. Celui-ci constitue la clef de voûte de ce SDK, nous permettant de générer un design FPGA à partir d’un kernel OpenCL. Il génère également un nombre important de fichiers, contenant des informations sur notre design qui seront d’une grande aide dans le processus d’optimisation.

La compilation avec aoc et Quartus II

Le compilateur aoc nous permet de générer une configuration du FPGA appelée « design », écrit en hardware description language (HDL) à partir du kernel OpenCL et des pragmas ajoutés à son attention. Cette phase représente un travail conséquent qui peut se traduire par une durée de compilation de plusieurs heures : il s’agit ici de mapper l’ensemble des instructions du kernel sur les ressources du hardware (portes logiques, blocs mémoires, digital signal processors …).

Le compilateur aoc génère donc essentiellement un binaire .aocx à partir d’un fichier .cl. Des flags bien utiles peuvent être passés au compilateur afin de pouvoir analyser le design généré, voire l’optimiser par la suite.
Notre ligne de compilation typique, ainsi que l’effet des flags de compilation appelés sont décrits ci-dessous :

>: aoc – v – – board s5phq_d8 – – report – – profile kernel.cl – o design.aocx

A la fin de la compilation, un dossier contenant un grand nombre de fichiers décrivant notre design est produit. L’ensemble de ces fichiers est destiné à être lu par l’outil Quartus II, auquel nous avons eu accès. Cet outil semble être extrêmement riche et nous n’avons pas eu le temps de vraiment nous en servir; néanmoins les fichiers nous paraissant les plus intéressants sont lisibles en clair avec un éditeur de texte quelconque : il s’agit d’un log de la compilation et de l’area report donnant la quantité de hardware utilisée par notre design, sur le board FPGA ciblé. Ces fichiers seront utiles dans le processus d’optimisation, un aperçu de leur contenu « brut » est disponible ci-dessous.

Nous remarquons tout de même que le log de la compilation (en bas à droite de l’image précédente) n’est pas aussi complet que ceux à quoi nous nous attendions, qui était présenté dans la documentation Altera pour les kernels « single-workitem ». Celle-ci consignait des informations pour différentes parties du kernel, indiquant les boucles correctement déroulées (ou non), et des informations sur l’efficacité de nos transactions mémoire.

Nous retrouvons ici l’output du terminal, avec un log qui ne semble pas recéler d’informations intéressantes, nous laissant sur notre faim. Un log bien étoffé serait sans nul doute bien plus pratique pour nous guider dans les phases de profiling et optimisation !

Profiling et optimisation avec aocl

Le flag de compilation – – profile permet de générer automatiquement un fichier profile.mon après le run de l’application FPGA. Ce fichier contient un ensemble d’informations sur l’exécution du kernel , qui peuvent être visualisées à travers une interface graphique invoquée par aocl, de la façon suivante:

>: aocl – – report /path_to_design/file.aocx profile.mon

Les onglets présents dans l’interface contiennent notamment la timeline d’exécution du kernel et l’ensemble des lignes de code du kernel, avec plusieurs métriques attachées.

Dans l’onglet Kernel execution, la timeline présentée est plutôt simpliste comparée aux outils Nvidia sur GPU. Elle donne le temps d’exécution du kernel, et peut préciser les temps de lecture et d’écriture à la mémoire globale si la variable d’environnement ACL_PROFILE_TIMER a été mise à 1 avant le run de l’application.

En revanche, une quantité importante d’informations est disponible dans l’onglet source code, contenant toutes les lignes de code du kernel, auxquelles sont attachées des métriques de performance. Ceci permet de visualiser les instructions associées aux goulots d’étranglement du design (stalling du pipeline, lecture / écriture inefficace en mémoire …).

En particulier, le stall devrait permettre de savoir s’il peut être important de dérouler une boucle ou non, d’optimiser ou reformuler une certaine opération, alors que la bandwidth peut indiquer des transactions mémoire inefficaces / non vectorisées.

Nous poursuivrons dans le prochain billet avec une présentation de l’algorithme de cryptage AES 128-bit, qui sera notre cas pratique guidant le reste de l’étude. A bientôt !

La suite de la série FPGA est disponible ici.

Crédit : Damien DUBUC