Améliorations futures

Tout au long du développement de ce projet, nous avons identifié plusieurs améliorations qui seraient intéressantes pour le système H.264. Cette section détaillera les principales étapes restantes afin de produire une implémentation d’un système H.264 sur puce FPGA.

6.2.1 Système H.264

Lors du développement initial, nous nous sommes seulement attardés aux paramètres d’en- trée et de sortie utilisés par les modules matériels. Or, il serait encore possible de réduire ceux-ci. Pour diminuer la quantité de données véhiculées entre les modules, il faut réduire la trace du contrôle en passant seulement les paramètres qui changent d’un macrobloc à un autre. Les modules matériels auraient alors une initialisation pour les paramètres standards reliés à une trame et une fois celle-ci faites, il suffit de passer les données liées à chaque macrobloc et réinitialiser les paramètres standard lors d’une nouvelle trame.

Lors du développement du projet h.264, nous avons ajouté plusieurs fonctionnalités tierces au module principal MainEncoderTask. C’est le cas des fonctions de validation (CRC), du calcul des performances et de la journalisation (logging). Toutes ces tâches externes au système et prises en charge par le module principal devront être déplacées dans des modules séparés. Nous voulons libérer la tâche d’encodage de ce fardeau, réduire l’impact sur les per- formances de l’encodeur et spécialiser les modules du système.

Suite au nettoyage des modules matériel et logiciel, il sera important de se concentrer sur la plus grande limitation de notre implémentation. Comme mentionné préalablement, le flot de données du système est sous optimal. Tout d’abord, nous l’avons conçu de manière à devoir transférer des images complètes vers la zone mémoire partagée à chaque nouvelle trame à encoder. Si nous conservons cette architecture mémoire, il serait nécessaire de déléguer ces transferts à un module spécialisé afin de différer les opérations mémoires pour limiter l’impact des communications sur l’encodage d’une trame. Comme nous avons fait pour les données en entrée avec le module InputAdapter. Il serait aussi possible d’utiliser un tampon double afin de charger plusieurs trames à la fois. Si l’on opte pour modifier le flot de données, il serait préférable d’utiliser un tampon de type « line buffer » partagé par les modules IME/FME et éliminer le dédoublement des trames entre la section logiciel et matériel. De cette façon, nous gagnons en vitesse en réduisant le délai de communication mémoire à l’aide du « buffering ». Nous réduisons aussi l’espace mémoire en conservent en mémoire partagé uniquement les pixels nécessaires plutôt que les trames complètes. Ceci permettrait de réduire à environ 960 Ko les deux tampons mémoires présentement utilisés. Avec le processeur ARM Cortex A9, il est possible d’atteindre une meilleure performance des communications mémoires en utilisant la DDR du Zynq et le bus ACP qui utilise la cohérence de cache et le partage de la mémoire centrale avec le processeur. Par contre, comme nous devons utiliser un processeur « softcore » ces accélérations ne sont pas disponibles.

La figure 6.1 illustre l’architecture finale du système incluant un flot mémoire optimisé et la spécialisation des modules logiciels du système.

Une fois le flot de données révisé, l’architecture de la plateforme virtuelle sera à changer. Le système est actuellement exécuté sur un processeur ARM sous Linux et ne représente pas la plateforme cible. Il sera nécessaire de traduire l’application vers le système d’exploitation microC (uC) afin d’être en mesure d’utiliser les processeurs « softcore » tels que uBlaze ou RISK-V comme convenu.

Une fois ces modifications effectuées, les modules matériels devront être passés dans un outil HLS afin de produire des fichiers HDL pour éventuellement synthétiser tout le système sur puce FPGA. Cette étape risque de prendre plusieurs itérations afin de produire un module fonctionnel, car les outils de synthèse peuvent avoir de la difficulté à interpréter correctement le code de ces modules. La capacité du synthétiseur à bien inférer l’architecture matérielle à

OutputAdapter NAL Encoder Nal Buffer TCP/IP UDP 2x4(Cr/ Cb) Inv Qte/ Rescalling Inv Transform Deblocking filter Picture (MB) Buffer Entropic Decoding CABAC CAVLC 4x4 8x8 (Y) Inv DC Transform (Hadamard) 4x4 2x2(Cr/_Cb) Intra Prediction + Entropic coding DC Transform (Hadamard) Quant/ scalling Transform Motion Compensation 4x4 8x8 (Y) CABAC CAVLC 4x4 2x2(Cr/ Cb) 2x4(Cr/ Cb) IME FME - InputAdapter Receiver MainEncoderTask FMEModule IMEModule CPB

Coded Picture buffer

Frame Extraction

Picture conversion

Figure 6.1 Architecture incorporant le nouveau flot de données

partir du logiciel indiquera la cadence possible du système. L’utilisation de bus haute vitesse HP0, les adaptateurs et les fifo de SpaceStudio, les tampons mémoires interne et les énoncées conditionnelles utilisées à profusion dans le code C peuvent tous causer problème aux outils HLS. Le code conditionnel produit des MUX à l’intérieur du circuit et augmente les délais des signaux. La mémoire peut elle même être multiplexée et cela produit des délais encore plus longs. Lorsque nous utilisons le bus HP0 sous SpaceCodesign, les adaptateurs instanciés produisent un lien entre le bus et le signal de réinitialisation trop long pour respecter le délai de 10ns. La méthode de développement SystemC afin de produire un code aisément synthétisable par un outil HLS devra être détaillée dans la méthodologie.

Finalement, afin d’aller chercher plus de performance il sera nécessaire d’augmenter le paral- lélisme du traitement des macroblocs. Chaque bloc matériel opère sur un macrobloc et n’a besoin que de l’information sur celui-ci. Ils ne partagent pas d’état ou de mémoire avec les tâches logicielles. Ceci rend l’opération des coprocesseurs atomique et le résultat de ceux-ci

est donné à la sortie de leur traitement. Les coprocesseurs ne produisent aucun effet de bord (side effect ou symptôme) sur le reste des données. La difficulté d’introduire le parallélisme au système «Proxy» provient de l’architecture logicielle de la librairie. Plus précisément de la fonction WelsMdInterMbLoop(). Après le traitement de chaque macrobloc, des sta- tuts globaux, des pointeurs et d’autres structures sont modifiés. Il faut alors vérifier s’il est possible de rendre indépendante chaque itération de cette boucle de traitement. Si cela est possible, il serait intéressant de produire une grappe de coprocesseur IME/FME afin d’en- coder plusieurs macroblocs en parallèle et produire une courbe de Pareto afin de trouver le meilleur compromis entre la performance de l’encodeur, la surface utilisée et la consommation du FPGA.