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
| -v | verbosité (succès / échec des différentes phases du processus de compilation) |
| --board | désigne l'architecture ciblée (ici une board Stratix V, s5phq_d8) |
| --report | génère un fichier précisant les optimisations réalisées sur le kernel, donne une estimation de l’utilisation du hardware durant la compilation |
| --profile | instrumente le design pour pouvoir le timer et le profiler |
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 …).
| Attribute | Informations sur la zone mémoire ciblée par l'opération (globale, locale, read/write, DDR/QDR, etc) |
| Stall % | Pourcentage du temps durant lequel l'instruction ralentit / bloque le pipeline |
| Occupancy % | Pourcentage du temps durant lequel l'instruction est exécutée par au moins un workitem |
| Bandwidth | Bande-passante utilisée par l'opération de read / write, et efficacité de celle-ci |
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.
Le compilateur aoc constitue la clef de voûte de ce SDK et produit un nombre important d'informations accompagnant le design FPGA généré à partir du kernel OpenCL.Ces informations (utilisation de la board, log de la compilation…) peuvent être visualisées avec l'outil Quartus II, mais en tant que néophytes, nous sommes submergés par l'information et n'avons pas eu le temps de nous pencher sur ses capacités réelles. De plus, nos essais par la suite ne nous ont pas permis d’obtenir un log de compilation aussi détaillé que celui présenté dans la documentation Altera, ce qui aurait été bien utile.
Le processus d'optimisation est indissociable de la compilation, permettant d'instrumenter le design et de fournir des métriques à l'instruction prêt, mais aussi de visualiser la timeline d'exécution du kernel à travers une GUI appelée par aocl.
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.
