Implémentation du système dans PlanAhead

Au cours de cette phase, le résultat de synthèse de la partie statique est donné comme entrée à l’outil PlanAhead. Dans cet outil, les modules h f ilterPRR et v f ilterPRR sont considérés comme des partitions auxquelles on associe le résultat de synthèse des différentes versions implémentées pour ces modules. On obtient donc un système avec le résultat de synthèse de la partie statique et trois versions différentes de synthèse (implémentant trois modes différents) pour chacune des 4 partitions du système. 6.8.4.1 Placement des régions reconfigurables

Les régions reconfigurables sont ensuite placées sur le FPGA dans l’outil PlanAhead. La figure 6.28 montre que les tailles des régions implémentant le même type de filtre sont identiques. Celles implémentant le filtre vertical sont plus grandes puisqu’elles né- cessitent plus de ressources. Les tableaux 6.11 et 6.12 donnent les ressources disponibles

région1 hfilter_0.hfilterPRR région2 hfilter_1.hfilterPRR région3 vfilter_0.vfilterPRR région4 vfilter_1.hfilterPRR

FIG. 6.28 – Placement des régions reconfigurables dans l’outil PlanAhead

dans les régions reconfigurables et celles requises pour les différentes implémentations des modules reconfigurables pour les régions implémentant le filtre horizontal et le filtre vertical, respectivement. Les valeurs contenues dans ces tableaux sont liées aux blocs physiques de Virtex6-xc6vlx240t, ce qui permet de donner plus de détails par rapport aux résultats de synthèse qui sont plus abstraits. Les tailles et les emplacements des régions reconfigurables doivent être choisis de manière à couvrir toutes les ressources requises tout en évitant les risques de congestion à cause de régions pas assez grandes. Xilinx recommande que les ressources requises représentent au maximum 80% des ressources disponibles dans une région reconfigurable [43]. Comme le montre les tableaux 6.11 et 6.12, les pourcentages des ressources occupées par le mode le plus consommant en ressources (mode 1) pour les deux filtres ne dépassent pas les 79%.

6.8.4.2 Implémentation des différentes configurations du système

Après le placement des régions reconfigurables, l’implémentation des différentes configurations du système peut être lancée. Elle suit les phases Translate, MAP et PAR (expliquées dans le chapitre 2). Dans cette étude de cas, on a besoin à la fin du flot d’un bitstream complet implémentant la configuration globale 1 et de trois bitstreams partiels par région reconfigurable. Pour assurer la compatibilité du contenu des régions reconfigurables avec le la partie statique, indépendamment de leurs modes actifs, il faut

Type de ressource Ressources Ressources Ressources Ressources

disponibles requises requises requises

dans la région par le mode 1 par le mode 2 par le mode 3

LUT 4480 3315 (74%) 1853 (42%) 1097 (25%)

FD_LD 8960 1846 (21%) 1097 (13%) 733 (9%)

SLICEL 700 518 (74%) 290 (42%) 169 (25%)

SLICEM 420 311 (75%) 174 (42%) 102 (25%)

RAMBFIFO36E1 14 1 (8%) 1 (8%) 1 (8%)

TAB. 6.11 – Ressources disponibles et requises pour les régions reconfigurables implé- mentant le filtre horizontal

Type de ressource Ressources Ressources Ressources Ressources

disponibles requises requises requises

dans la région par le mode 1 par le mode 2 par le mode 3

LUT 5120 3995 (79%) 2218 (44%) 1343 (27%)

FD_LD 10240 2221 (22%) 1317 (13%) 865 (9%)

SLICEL 800 625 (79%) 347 (44%) 210 (27%)

SLICEM 480 375 (79%) 208 (44%) 126 (27%)

RAMBFIFO36E1 16 1 (7%) 1 (7%) 1 (7%)

TAB. 6.12 – Ressources disponibles et requises pour les régions reconfigurables implé-

mentant le filtre vertical

lancer l’implémentation pour une configuration donnée du système et faire la copie du résultat de l’implémentation de la partie statique, pour l’intégrer directement lors du lancement des autres implémentations du système. Pour cela, l’implémentation du système en activant le mode 1 pour toutes les régions a été lancée en premier. Cela servira après pour la génération d’un bitstream complet pour la configuration initiale du système et 4 bitstreams partiels pour le mode 1 des régions. Il reste ici de générer deux bitstreams partiels par région implémentant le mode 2 et le mode 3. Pour ceci, il suffit de lancer deux implémentations en activant pour la premières le mode 2 pour toutes les régions et pour la deuxième le mode 3 pour toutes les régions. Les bitstreams complets de ces deux implémentations ne seront pas utilisés ici car on a juste besoin de celui de la configuration initiale. D’autres scénarios d’implémentations peuvent être envisagés en activant des numéros de modes différents entre les régions. L’essentiel est qu’en total, pour chaque mode d’une région donnée, il y a au moins une implémentation qui l’active.

Les figures 6.29(a), 6.29(b) et 6.29(c) illustrent le résultat de l’implémentation de la première, la deuxième et la troisième configuration du système respectivement. Les blocs remplis en bleu clair sont ceux utilisés dans l’implémentation. Comme le montre ces figures, la partie statique reste la même pour les trois configurations, alors que le contenu des régions reconfigurables change selon la configuration active. Le tableau 6.13 donne l’occupation en ressources des différentes implémentations du système. Ce ta- bleau montre bien que la différence en nombre de ressources occupées dépend bien

(a) Résultat de l’implémentation de la première configuration du système (b) Résultat de l’implémentation de la deuxième configuration du système (c) Résultat de l’implémentation de la troisième configuration du système

FIG. 6.29 – Résultats de l’implémentation du système reconfigurable

Type de ressource Implémentation 1 Implémentation 2 Implémentation 3

Register 21924 (7%) 17834 (5%) 15768 (5%) LUT 27241 (18%) 21503 (14%) 18558 (12%) Slice 9867 (26%) 8287 (21%) 7458 (19%) IO 118 (19%) 118 (19%) 118 (19%) RAMBFIFO36E1 42(5%) 42(5%) 42(5%) RAMBFIFO18E1 10 (1%) 10 (1%) 10 (1%) DSP48E1 3 (1%) 3 (1%) 3 (1%) MMCM_ADV 2 (16%) 2 (16%) 2 (16%)

TAB. 6.13 – Ressources occupées par les différentes implémentations du système

des modes actifs des régions reconfigurables. Le tableau 6.14 illustre la différence entre les implémentations du système en termes de consommation de puissance dynamique. Cette différence est due aux différences de consommation des modes des régions recon- figurables. Ces résultats sont donnés par l’outil Xpower Analyzer de Xilinx.

La fréquence FMax (fréquence du chemin critique) dans les trois configurations est 76,278MHz (après PAR). Pour évaluer le coût de la dynamicité sur la fréquence d’horloge, nous avons implémenté le même système en version statique (les modules h f ilterPRRet v f ilterPRR implémentent le mode 1). La fréquence FMax après PAR était de 85,092MHz. Le coût de la dynamicité dans ce cas est une dégradation de 10, 36% de la fréquence d’horloge, ce qui est prévu par Xilinx [43]. L’impact du système du contrôle sur la fréquence FMax est aussi évalué en implémentant le même système reconfigurable sans les contrôleurs et le coordinateur. La fréquence FMax de ce système est 80MHz. Le système de contrôle a donc dégradé légèrement la fréquence FMax (4, 65%).

Implémentation Consommation de puissance (mW)

Implémentation 1 589

Implémentation 2 583

Implémentation 3 580

TAB. 6.14 – consommation de puissance des différentes implémentations du système

hfilter_0.HFilterController hfilter_1.HFilterController

vfilter_0.HFilterController vfilter_1.HFilterController

coordinator

(a) Emplacement du système de contrôle dans le FPGA

(b) La communication entre contrôleurs et coordi- nateur

FIG. 6.30 – Résultats de l’implémentation du système de contrôle

planAhead a placé chaque contrôleur de façon à mettre une partie de chacun d’eux proche du coordinateur, afin de minimiser la longueur des connexions entre les contrô- leurs et le coordinateur. Pour les ressources des contrôleurs qui ne communiquent pas avec le coordinateur, elles sont placées plus loin selon l’espace libre et la stratégie du placement. Les connexions entre les contrôleurs et le coordinateur sont colorés en vert clair dans la figure 6.30(b).

6.8.4.3 Génération des bitstreams

Après l’implémentation des différentes configurations du système, la génération des bitstreams peut être lancée. Cette étape permet de générer pour chaque implémentation du système, un bitstream total et des bitstreams partiels selon les versions activées des régions reconfigurables. Le tableau 6.15 donne les tailles des bitstreams générés. Il

Bitstream Taille bitstream total 8,80 Mo bitstream partiel 300 Ko

TAB. 6.15 – Taille des bitstreams

Région1 Région2 Région3 Région4

H/VFilter_mode1 h_1_1.bit h_2_1.bit v_1_1.bit v_2_1.bit H/VFilter_mode2 h_1_2.bit h_2_2.bit v_1_2.bit v_2_2.bit H/VFilter_mode3 h_1_3.bit h_2_3.bit v_1_3.bit v_2_3.bit

TAB. 6.16 – Noms des bitstreams partiels

montre que tous les bitstreams ont la même taille. C’est parce que toutes les régions ont la même largeur, ce qui correspond au même nombre de trames de configurations. La hauteur d’une trame est marqué par des traits verticaux en bleu dans la figure 6.28 par exemple. Comme le montre cette figure, toutes les régions occupent 2 trames en hauteur. Ayant la même largeur, les régions occupent donc le même nombre de trames au total, ce qui fait qu’ils ont la même taille de bitstreams. Le tableau 6.16 illustre les noms donnés pour chaque bitstreams partiels. Ces noms seront utilisé par le processeur pour charger ces bitstreams à travers l’ICAP.

Le bitstream total est ensuite fusionné avec l’exécutable de la partie logicielle de l’application (le programme qui sera exécuté par le processeur MicroBlaze). Le bitsream résultant est converti dans un format ACE pour qu’il puisse être lu du compact flash et chargé dans le FPGA. Pour l’exécution, le compactFlash doit donc contenir le fichier ACE, les bitstreams partiels et la vidéo à traiter.