Synthèse du NoC et de ses composants

Nous pouvons voir que le NoC occupe entre 30 et 40 % de la surface du FPGA. Un routeur occupe entre 1 et 5% des slices du FPGA. Une NI occupe entre 2 et 4% des slices du FPGA. La surface occupée par le NoC reste donc raisonnable.

110 expérimentations et résultats La fréquence du NoC dépasse les 80 MHz. Ce qui permet sur un lien une bande passante théorique de 32 ∗ 80.106 = 2560.106bits/s soit 320Mo/s.

A taille égale des FIFOs, nous pouvons voir que les NIs occupent une plus grande surface lorsqu’elles intègrent un VC GT qu’un VC BE. Cela est dû à la table des slots TDMA et au mécanisme d’ordonnancement.

Dans les cas 3 et 4, l’utilisation de deux canaux virtuels à un coût important en surface dans les routeurs, ils doublent presque de surface. En revanche les NIs ne voient leur surface augmenter que légèrement.

Dans le cas 5, l’augmentation légère (de 2 à 8) de la taille des FIFOs dans les ports réseau des routeurs et des NIs cause une augmentation de surface du NoC de 4%.

7.2.3 Résultats du test sur la plate-forme

Les tests sur la plate-forme ont été réalisés avec une horloge d’une fréquence de 50MHz. Les placements routages des NoCs présentés précédemment se sont bien déroulés dans quatre des cas, en revanche nous avons rencontré un problème pour réaliser un NoC utilisant simultanément un canal virtuel GT et un canal virtuel BE. La synthèse se passe normalement avec ISE, mais lors de la phase de placement routage, l’outil indique un message d’erreur. Il s’agit d’une erreur interne de l’outil de placement routage dont Xilinx nous dit qu’elle sera corrigée dans les versions futures. Ce genre d’aléa est hélas courant et connu des concepteurs. En considèrent les éléments du NoC séparément, nous avons constaté que ce problème intervient uniquement dans les NIs et que lorsqu’elles utilisent des canaux virtuels GT et BE simultanément. Nous n’avons pas pu mener l’expérience sur la plate-forme pour le cas 3. Des simulations sous ModelSim nous ont tout de même montrés que notre code VHDL et le comportement obtenu sont corrects.

Pour les quatre autres cas, les tests des NoCs ont été effectués sur la plate-forme avec les 3 MicroBlazes et nous ont montrés que les données sont bien transmises et que le contrôle de flux de bout-en-bout fonctionne puisqu’aucune donnée n’est perdue. L’utilisation du canal virtuel par un trafic garanti utilisant le TDMA a également été validée.

Nous avons vérifié que la priorité entre les canaux virtuels fonctionne dans le cas 4 qui utilise simultanément deux canaux virtuels BE. En effet le trafic transporté sur le premier canal virtuel est bien transmis en priorité par rapport au trafic transporté sur le second canal virtuel.

7.2.4 Conclusion

Ce test a permis de valider notre approche de façon complète, c’est à dire en intégrant le NoC en tant que IP, les wrappers pour le connecter à des bus OPB et la couche logicielle dans les MicroBlazes.

Nous avons observé que la surface du NoC est raisonnable (30 à 40% des slices du FPGA). De plus, dans cet exemple, nous avons mis en œuvre tous les types de commu-nications (passage de message, transaction de lecture et d’écriture). Le NoC pourrait être réduit pour n’utiliser que le passage de message (pas de wrapper maître), ou au contraire que les transactions (wrapper esclave avec moitié moins de connections).

7.3 traitement d’image 111

7.3 Traitement d’image

L’application que nous considérons a été développée dans le cadre du projet Epicure [88] dans lequel l’équipe « Codesign » du laboratoire LESTER intervenait pour réaliser l’exploration de l’espace de conception avec l’outil Design Trotter.

Cette application est un système embarqué de caméra intelligente. Ce dispositif réalise la détection d’objets en mouvement dans des images capturées par une camera. Ainsi, cette application intègre différentes tâches de traitement, incluant l’acquisi-tion vidéo, le filtrage d’image, l’extracl’acquisi-tion des objets et du fond, le déplacement des objets et différents contrôles liés à l’affichage (figure 7.2).

Pour notre NoC, nous avons choisi d’utiliser une topologie en grille 2D de 3x4. Nous utilisons les ports situés sur les bords extérieurs de la grille. La figure 7.3 montre la topologie et le placement des composants avec les NIs. Les wrappers ne sont pas représentés.

L’application requière 19 transactions de lecture/écritures. La résolution de l’image est de 320x240 pixels et la contrainte applicative à respecter est une cadence de 25 images par secondes.

Par la technique de dérivation des contraintes, nous avons extrait depuis les con-traintes de l’application, les concon-traintes de bande passante et de latence des commu-nications (figure 7.4).

Certaines des communications n’ont jamais lieu en même temps. Ainsi, nous avons défini des communications mutuellement exclusives.

Notre objectif est ici de déterminer la configuration pour réaliser ces communica-tions par un trafic GT. Nous désirons évaluer différentes configuracommunica-tions afin d’observer l’impact du contrôle de flux de bout-en-bout et de la prise en compte des exclusions mutuelles sur la taille de la table TDMA et le coût en FIFOs dans l’architecture.

7.3.2 Résultats

Ce problème complexe a été résolu à l’aide de notre outil de décision. Les résultats obtenus sont représentés dans le tableau 7.2.

Options choisies Nombre de slots de Somme de la profondeur

la table TDMA des FIFOs dans les NIs

Avec contrôle de flux de bout-en-bout, 5 60

Avec prise en compte des exclusions mutuelles

Avec contrôle de flux de bout-en-bout, 11 65

Sans prise en compte des exclusions mutuelles

Sans contrôle de flux de bout-en-bout, 8 50

Sans prise en compte des exclusions mutuelles

Sans contrôle de flux de bout-en-bout, 5 50

Avec prise en compte des exclusions mutuelles

Tab. 7.2 – Résultats

Nous observons qu’en fonction des options choisies, l’outil est parvenu à des solu-tions avec des tailles de tables TDMA différentes. Nous observons que l’utilisation du contrôle de flux de bout-en-bout implique un coût supplémentaire en profondeur de

112 expérimentations et résultats

Fig. 7.2 – L’application caméra intelligente

FIFO. L’utilisation des exclusions mutuelles permet d’obtenir une solution avec une taille de table de TDMA réduite ce qui peut permettre de réduire le coût en FIFO.

7.3.3 Conclusion

Nous voyons qu’un NoC peut être utilisé pour satisfaire les besoins de communication de l’application. De plus, nous voyons que notre outil de conception automatique est parvenu à trouver des solutions pour les différentes configurations. Ces solutions offrent des tailles de tables de TDMA petites et des coûts en FIFO raisonnables.

7.4 chaîne mc-cdma mc-ss-ma 113

Fig. 7.3 – La topologie de l’application de traitement d’image

Fig.7.4 – Les contraintes de bande passante et de latence des communications Dans le cadre du projet RaaR [89] au LESTER, cette application de traitement d’image est utilisée pour effectuer un partitionnement logiciel/matériel dynamique contrôlé par un RTOS. L’idée est de réguler automatiquement l’utilisation des res-sources en fonction des caractéristiques de l’image (nombre d’objets, bruit, etc) sous contraintes de QoS et d’énergie.

Dans ce contexte, nous voyons qu’un NoC programmable est utile afin d’adapter les communications aux choix effectués en termes d’implantation logicielle/matérielle des différentes tâches et des paramètres de ces tâches.

7.4 Chaîne MC-CDMA MC-SS-MA

Cette application est une chaîne MC-CDMA (Multi-Carrier Code Division Multiple

Access)[90] d’un terminal mobile dans le cadre du futur standard de radio

114 expérimentations et résultats européen 4MORE [1] dans lequel le laboratoire IETR est impliqué. La 4G nécessi-tera un système flexible et capable de supporter différents standards pour permettre l’évolution et la mise à jour du SoC. Ces contraintes font du NoC un bon candidat.

La contrainte de cadence est de 1 symbole OFDM toutes les 20.8µs. Une trame est composée de 32 symboles. La contrainte applicative est donc de tenir la cadence d’une trame tous les 665,6µs. Les figures 7.5 et 7.6 issues de [91], nous montrent les diagrammes du transmetteur (TX) et du récepteur (RX). Les contraintes des commu-nications relatives à la partie transmission et réception nous ont été données et sont représentées dans les tableaux 7.3 et 7.4.

Fig. 7.5 – Diagramme du transmeteur MC-SS DMA

Fig. 7.6 – Diagramme du récepteur MC-CDMA

29 communications unidirectionnelles sont mises en jeu entre les différents éléments du système. Nous pouvons voir que les bandes passantes requises sont variées. Le trafic est prédictible, il est donc tout à fait adapté à l’utilisation du trafic garanti par TDMA. Cependant le flot de données est relativement point à point et orienté. Nous avons donc utilisé un placement des composants permettant de tirer profit des liens dans chaque direction afin d’utiliser le NoC au mieux. Le port d’entrée et le port de sortie

7.4 chaîne mc-cdma mc-ss-ma 115 de chaque composant ont été regroupés en cluster sur une même NI. Nous avons ainsi 28 clusters.

Nous n’avons pas cherché le placement optimal des composants, mais à valider notre flot dans le contexte d’une application de télécommunication qui présente des caractéristiques différentes de celles de l’application de traitement d’image.

Initiator port Target port BW(Bytes/s) Latency (nano sec) RAM 1 Channel coder 288462 665600 RAM 1 MIMO encoder 865385 665600 Channel coder Bit interleaving 576923 665600 Bit interleaving Mapping 576923 665600 Mapping Spreading(CDMA) 3461538 665600 Spreading(CDMA) MIMO encoder 3461538 665600 MIMO encoder FFT 1 4326923 665600 MIMO encoder FFT 2 4326923 665600 FFT 1 BB to RF 1 230769231 665600 FFT 2 BB to RF 2 230769231 665600