Application de conversion de couleur

Dans cette partie, nous allons tester un traitement simple à base de mppSoC. Une conver-sion de couleur du format RGB à YIQ est implémentée. Elle est expliquée dans la sous section suivante.

5.4.3.1 Présentation de l’application

L’application consiste à convertir les couleurs des pixels RVB (RGB en anglais) vers le modèle YIQ. L’algorithme de compression d’image JPEG, par exemple, convertit les pixels de l’espace RGB vers l’espace YIQ pour séparer les informations de luminance des informa-tions de couleur. En effet, la chrominance sera plus compressée que la luminance, car l’oeil humain est plus sensible aux variations de luminance qu’aux variations de couleur. La base de couleur YIQ est aussi utilisée dans le standard NTSC (National Television Systems Commit-tee) qui est un standard vidéo utilisé aux États Unis d’Amérique. L’équation de la conversion RGB vers YIQ est présentée ci dessous :

  Y I Q  =   0.299 0.587 0.114 0.596 −0.275 −0.321 0.212 −0.523 0.311     R G B   (5.3)

Pour cette application, nous allons varier le nombre de PEs afin de trouver le bon nombre qui nous assure un traitement temps réel. La taille de mémoire varie de même selon les besoins de l’application. L’algorithme codé en C destiné à être exécuté sur le processeur

800 480 (0,0) (0,799) (119,0) (119,799) PE1 PE2 PE3 PE4

FIGURE5.37 – Partitionnement de pixels entre les PEs (cas de 4 PEs)

NIOS est présenté ci dessous. Il convient à une configuration parallèle intégrant 4 PEs pour une image de taille 800x480 :

#include<stdio.h>

#include "nios2.h" ....

#define CMOS_Controller_0 (char*) 0x00009040 #define wrapperACU_0 (char*) 0x00004000 #define wrapperNIOS (char*) 0x00003008 ....

alt_u16 WIDTH = 800 ; alt_u16 HEIGHT = 120 ; int main()

{alt_u32 data ; ....

asm ("addi r7,r7,0 ;" : : : "r7") ; //code séquentiel

if (alt_timestamp_start()<0) { printf ("No timestamp .\n") ; } else { time_start = alt_timestamp() ;

IOWR(CMOS_Controller_0,0,1) ; //Activer la caméra set_mode_mpnoc (3) ; //Configurer le mode PE-périph E/S

time1 = alt_timestamp() ;

asm ("add r7,r7,r0 ;" : : : "r7","r0") ; //code parallèle NIOS2_READ_CPUID(id) ;

for(i = 0 ;i<HEIGHT-1 ; i++) { for(j = 0 ; j<WIDTH-1 ; j++) {

p_mpnoc_rec (data, 0x709) ; //Lecture parallèle de la SDRAM ....

Y= (299*r + 587*g + 114*b)/1000 ; I= (596*r - 275*g - 321*b)/1000 ; Q=(212*r - 523*g + 311*b)/1000 ;

datam = (Y + (I<<8) + (Q<<16)) & 0xffffffff ;

p_mpnoc_send (datam, 0x708) ; } } //Écriture parallèle à SRAM asm ("addi r7,r7,0 ;" : : : "r7") ; //code séquentiel

time_elapsed = alt_timestamp() ;

temps = time_elapsed - time1 ; //calcul de temps return 0 ; }

La fonction spécifique à NIOS "alt_timestamp" est utilisée afin de mesurer le temps d’exécu-tion. Elle fournit en fait le nombre de cycles d’horloges.

Dans cet algorithme, nous n’avons pas besoin d’un réseau de voisinage. Seulement un réseau mpNoC à base de crossbar est utilisé pour les lectures et écritures de données pa-rallèles. Chaque PE fait le traitement de conversion sur ses propres pixels. Une image est partitionnée horizontalement entre les différents PEs telle que montrée dans la figure 5.37 dans le cas de 4 PEs.

5.4.3.2 Génération de mppSoC

Dans ce paragraphe, nous allons décrire la génération d’une configuration mppSoC en utilisant notre chaîne. L’architecture SIMD intègre 32 PEs. Elle est modélisée en utilisant le

5.4 Expérimentation sur FPGA : traitement vidéo temps réel 135

FIGURE5.38 – Spécification du nombre de PE

FIGURE5.39 – Spécification de la taille des mémoires

profil Gaspard. Chaque PE est un processeur miniMIPS réduit lié à sa propre mémoire locale (ayant une adresse de taille 5). La taille de la mémoire d’instructions de l’ACU est fixée à 4096 bytes. Cette architecture ne dispose que d’un réseau mpNoC à base de crossbar. Afin de fixer les paramètres de notre architecture, nous suivons les étapes décrites ci dessous :

1. Fixer le nombre de PE : dans notre architecture nous disposons de 32 PEs. Afin de spécifier cette valeur il suffit de fixer la valeur du tagged value "shape" du stéréotype Shaped qui est appliqué à la classe PU à 32 telle que montré dans la figure 5.38. 2. Fixer la taille des adresses mémoires : à cette étape il suffit de fixer la valeur des

tag-ged values "adressSize" des trois classes stéréotypées "HwMemory", telle que spécifiée

FIGURE5.41 – Spécification du type de processeur

FIGURE5.42 – Spécification du réseau d’interconnexion de mpNoC dans la figure 5.39.

3. Spécifier la méthodologie de conception : la méthodologie de réduction est choisie dans cette configuration. Il suffit alors d’attribuer le stéréotype "HwResource" à la classe Elementary_processor indiquant qu’il s’agit d’un processeur réduit (voir figure 5.40). 4. Indiquer le type de réseau de voisinage à intégrer : notre architecture ne contient pas

de réseau de voisinage. Nous avons alors connecté chaque PU à l’ACU et au réseau mpNoC seulement indiquant l’absence du réseau de voisinage.

5. Spécifier le type de processeur : il faut indiquer le type du processeur dans le champ sourceFilePath du stéréotype CodeFile appliqué à l’artifact PEImpl_codeFile, comme illustrée par la figure 5.41.

6. Indiquer le type du réseau d’interconnexion dans le mpNoC : la dernière étape dans la conception de notre configuration consiste maintenant à définir le type du réseau d’in-terconnexion dans le mpNoC. Nous intéressons à intégrer un réseau de type crossbar. Pour cela nous avons spécifié le champ "crossbar" comme valeur pour le tagged value sourceFilePath relatif à l’Artifact RouterImplem_codefile (voir figure 5.42).

De cette manière, nous avons modélisé à haut niveau notre configuration choisie. Nous pouvons alors générer le code VHDL correspondant qui servira pour effectuer les mesures de performances présentées dans le paragraphe suivant.

5.4.3.3 Mesure de performances

La figure 5.43 montre l’évolution des temps d’exécution et accélérations en fonction du nombre de PEs et du processeur utilisé. Dans la figure 5.43, le nombre 1 de PE indique que la configuration SIMD est constituée seulement de l’ACU pour mesurer le temps d’exécu-tion séquentielle. Pour un nombre N>1, la configurad’exécu-tion est constituée de l’ACU et N PEs. Nous remarquons la réduction du temps d’exécution avec l’augmentation du nombre de

5.4 Expérimentation sur FPGA : traitement vidéo temps réel 137 20000 30000 40000 50000 60000 T e m p s d 'e x é cu ti o n ( µ s) Temps (NIOS) Accélération (NIOS) Temps (miniMIPS réduit) 0 10000 20000 1 4 8 16 32 T e m p s d 'e x é cu ti o n ( µ s) Nombre de PEs réduit) Accélération (miniMIPS) Accélération idéale

FIGURE5.43 – Résultats de simulation de la conversion RGB à YIQ

PEs. Par rapport à la première application, nous avons juste ajouté des opérations de calcul ; les communications à travers le mpNoC sont les mêmes. De ce fait, nous observons que l’ac-célération est presque la même et suit aussi l’évolution de l’acl’ac-célération idéale. La meilleure accélération est obtenue avec le processeur NIOS, de l’ordre de 29 en intégrant 32 PEs dans l’architecture. Nous voyons alors que le processeur NIOS présente les meilleurs résultats. Du fait qu’il est plus performant que le miniMIPS (plus rapide en calcul), les temps d’exécution obtenus avec le NIOS sont réduits d’un facteur 0.78 par rapport au miniMIPS. Il sera alors l’IP processeur choisi pour la prochaine application. Pour assurer l’aspect temps réel, nous avons besoin d’intégrer des configurations mppSoC intégrant 8 PEs ou plus.

D’après ces résultats, nous validons la facilité de tester différentes configurations mpp-SoC en utilisant l’outil de génération développé. Cela nous facilite l’exploration et nous guide dans le choix de la configuration la plus adaptée à une application donnée. Nous montrons de même qu’une architecture SIMD est bien adaptée pour exécuter des applica-tions traitant un flot de données. Intégrer plus de PEs dans l’architecture permet d’accélérer l’exécution surtout en l’absence de communications entre les processeurs. Dans la prochaine sous section, nous testons une application de convolution et nous étudions l’influence de l’ajout de communications de voisinage sur la performance de mppSoC.