Exécution du système

L’évolution du système est suivi par l’hyperterminal. Le niveau de batterie est initialisé à 1.000.000 d’unités de consommation. La figure 6.31 illustre le contenu de l’hyperterminal au début de l’exécution. Elle montre qu’on affiche pour chaque image traitée, les nombres de cycles d’horloge requis pour l’exécution du filtre horizontal, du filtre vertical et de leur somme (le nombre de cycles requis pour l’exécution du redimensionnement d’une image). Le niveau de la batterie est aussi affiché ainsi que les états courants des régions reconfigurables et leurs éventuelles reconfigurations requises. Les nombres de cycles d’horloge sont donnés par un timer. Les instructions d’activation et de désactivation de ce timer sont gérées par le code exécuté par le processeur. La figure 6.31 montre que quand le mode actif dans toutes les régions est le mode 1, le nombre de cycles nécessaire pour le redimensionnement d’une image est aux alentours de 80.100.000 cycles.

Quand le niveau de la batterie se trouve au-dessus du seuil 750000 (voir les automates des figures 6.5 et 6.6), la reconfiguration requise par les modules de reconfiguration des contrôleurs est le mode 2 comme le montre la figure 6.32. Le processeur lance les reconfigurations à travers l’ICAP en utilisant les noms des bitreams correspondants du

FIG. 6.31 – Début de l’exécution de l’application

FIG. 6.33 – Reconfiguration des régions en modes H/V Filter_mode3

FIG. 6.35 – Changement du niveau de performance requis à 2

tableau 6.16. Le nombre de cycles nécessaire pour le chargement de chaque bitstream partiel est presque 64.000.000. Ces cycles incluent la communication avec le compact- Flash pour la lecture du bitsream et son chargement à travers l’ICAP. La reconfiguration des 4 régions demande presque 2s. Ce temps de reconfiguration peut être réduit signi- ficativement en utilisant un module matériel qui gère la communication avec l’ICAP. L’implémentation d’un tel module est étudiée récemment par certains travaux. Dans [63], les auteurs ont montré qu’on peut reconfigurer une région de 7840 LUTs et flip-flops LUTs, 112 DSP et 28 BRAMs en 18,2ms.

En chargeant le mode 2 dans les régions reconfigurables, la performance du downsca- ler diminue et son temps d’exécution augmente à 99.000.000 cycles par image, comme le montre la figure 6.32. Quand le niveau de la batterie descend au dessous de 401785 (seuil des régions implémentant le filtre vertical), la reconfiguration requise par les contrôleurs est le mode 3 comme le montre la figure 6.33. Le processeur lance les reconfigurations requises. La performance diminue et le temps d’exécution augmente à 120.000.000 cycles par image, comme le montre la figure 6.34. Quand le niveau de la batterie atteint 332234, l’utilisateur appuie dur le bouton correspondant au niveau de performance 2, comme le montre la figure 6.35. Aucune reconfiguration n’est requise par les contrôleurs puisque le niveau de batterie n’a pas atteint 437500. Quand ce niveau est dépassé, les reconfigura- tions requises par les contrôleurs ciblent les modes H/V Filter_mode2, comme le montre la figure 6.36. Les figures 6.37 et 6.38 illustre le changement du niveau de performance à 1 et la reconfiguration du système vers la configuration 1 quand le niveau 800000 est dépassé en réponse à la requête de l’utilisateur.

Pour compter le nombre exact d’images traitées pour une batterie initialisée à 1.000.000d’unités de consommation, les affichages sont supprimés du programme du processeur ainsi que les instructions du timer. Avec un système statique implémentant la configuration 1, l’énergie disponible initialement dans la batterie permet de redimen- sionner 230 images. Grâce au contrôle de l’adaptation dynamique, le système devient

FIG. 6.36 – Reconfiguration des régions en modes H/V Filter_mode2

FIG. 6.38 – Reconfiguration des régions en modes H/V Filter_mode1

capable de gérer les exigences de l’utilisateur en termes de performance et d’économiser en même temps de l’énergie. Faisant un compromis entre performance et énergie, le reconfiguration dynamique du système a permis de redimensionner 251 images pour le même niveau de batterie, soit une augmentation de 9,13%. Ce compromis peut être affiné encore plus en explorant d’autres implémentations des filtres de l’application.

6.9

Conclusion

Dans ce chapitre, nous avons validé le modèle de contrôle semi-distribué proposé dans ce travail à travers une application de traitement d’images. La réutilisabilité et la scalabilité de ce modèle ont été évaluées en variant le nombre de contrôleurs distribués considérés dans les systèmes de contrôle modélisés. Les codes générés ont été simulés en utilisant différents scénarios. Les simulations ont montré l’avantage de l’implémentation matérielle des systèmes de contrôle en termes de temps d’exécution. L’évaluation du coût du modèle proposé en termes de ressources matérielles utilisées a été faite en se basant sur les résultats de synthèse pour des systèmes de contrôle ayant des nombres différents de contrôleurs. Cette évaluation a montré que ce coût est acceptable pour un Virtex6- xc6vlx240t (jusqu’à 3% des slice LUTs pour un système composé de 16 contrôleurs et d’un coordinateur). Il peut être beaucoup moins contraignant pour des FPGAs de plus grande taille tels que le XC7V2000T [150] de la famille Virtex-7.

Un système de contrôle composé de 4 contrôleurs et d’un coordinateur a été intégré dans un système reconfigurable pour une implémentation physique sur FPGA. Le flot de conception de ce système a été détaillé dans ce chapitre allant de la création du système dans l’outil EDK de Xilinx, l’association des contrôleurs aux composants recon- figurables et l’intégration du coordinateur, jusqu’au placement physique des régions reconfigurables et la génération des bitstreams. L’exécution du système reconfigurable

implémenté a permis d’exploiter la RDP (Reconfiguration Dynamique Partielle) pour assurer l’objectif du modèle de contrôle semi-distribué pour cette étude de cas, qui est l’adaptation dynamique aux changements liés aux contraintes de performance et de consommation d’énergie du système.

Conclusion et perspectives

7.1 Conclusion générale . . . 209

7.1.1 Un modèle de contrôle semi-distribué . . . 210

7.1.2 Un flot de conception de la modélisation à la génération auto- matique de code . . . 211

7.1.3 La mise en oeuvre du contrôle semi-distribué sur une applica- tion de traitement d’images . . . 212

7.2 Perspectives . . . 213

7.2.1 Optimisation du mécanisme de coordination . . . 213

7.2.2 Implémentation d’autres stratégies du coordinateur . . . 213

7.2.3 Application du modèle de contrôle proposé aux systèmes multi- FPGAs . . . 215

7.2.4 Application du modèle de contrôle proposé aux FPGAs 3D . . 217

7.2.5 Intégration d’autres types de reconfiguration tels que le change- ment de contexte . . . 220

7.1

Conclusion générale

L’objectif de ce travail était de proposer une méthodologie de conception du contrôle des systèmes reconfigurables sur FPGA qui permet d’améliorer la productivité des concepteurs et assurer une implémentation efficace du contrôle. Pour réaliser ces ob- jectifs, cette méthodologie se base sur deux points. Le premier point est un modèle de contrôle semi-distribué assurant la flexibilité, la réutilisabilité et la scalabilité du contrôle. Le deuxième point est un flot de conception automatisant la génération du code à partir d’une modélisation à haut niveau d’abstraction visant une implémentation matérielle du contrôle. Cette méthodologie a été validée en la mettant en oeuvre sur une application de traitement d’images. Dans ce qui suit, ces trois aspects de la méthodologie proposée sont résumés.