Proposition d’un NoC dynamiquement adaptable

Proposition d’un NoC dynamiquement adaptable

Introduction

Dans ce chapitre, nous présentons, dans un premier temps, un nouveau mod`ele d’architecture de NoC, permettant de gérer dynamiquement plusieurs flux de données pixéliques en parall`ele. Ces flux parall`eles peuvent provenir de différents capteurs d’image ou peuvent ˆetre générés `a partir d’un seul flux selon l’application. La figure 4.1 illustre le probl`eme `a résoudre pour la conception du NoC avec la présence, par exemple, de trois capteurs d’image différents en entrée, deux afficheurs en sortie et d’un ensemble de PEs réutilisables pour plusieurs applications dans un SoC. Capteurs -3PE -3P1 -3P2 -3 -3P0 -3P5 R3S3AUP  Figure 4.1: Syst`eme avec trois capteurs et deux afficheurs Les capteurs en entrée peuvent ˆetre typiquement ceux présentés au chapitre 2, `a savoir un capteur IR, BNL et couleur. Sur cette figure, nous voyons que toutes les images 82 Proposition d’un NoC dynamiquement adaptable Chapitre 4. Proposition d’un NoC dynamiquement adaptable 83 en sortie de chaque capteur transitent dans le réseau d’interconnexion, dont le rˆole est d’acheminer les images en sortie sur afficheur, apr`es application de traitements définis. Ces traitements sont réalisés par l’association des différents PEs implantés dans le SoC. Le probl`eme `a résoudre se situe alors au niveau du réseau d’interconnexion qui doit ˆetre capable de gérer de multiples flux en parall`ele et de les acheminer correctement vers les unités de calcul selon l’application, qui peut ˆetre modifiée dynamiquement. Se trouve également posé le probl`eme de la distinction de la provenance de chaque flux de données transitant dans le réseau. De ce fait, nous proposons une nouvelle méthode d’identification des paquets de données dans le réseau, particuli`erement adaptée aux applications de vision embarquée. En nous appuyant sur une nouvelle proposition d’architecture de NoC, nous décrivons par la suite une nouvelle méthode de routage des paquets. Il en résulte, au niveau architecturale, une modification dynamique du chemin de données interne au routeur. Ce routage est déterminé en fonction de l’identification des paquets et du séquencement des unités de calcul défini pour exécuter correctement une application. 4.2 Mod`ele d’architecture d’un NoC dynamiquement adaptable

Définition du flux de données

Nous utilisons le terme flux (du latin fluxus, écoulement) pour désigner un ensemble de données évoluant dans la mˆeme direction. Le terme ”ensemble” étant défini, selon la théorie des ensembles, comme une collection d’éléments. Dans le domaine de la vision numérique, nous parlons de flux d’une image pour désigner une collection de valeurs de pixels. Un pixel (de l’anglais picture element) est une unité de surface permettant de mesurer une image numérique. A chaque pixel est associée une valeur d’une composante ` d’intensité (exprimée en bits) dans le cas d’une image monochrome en niveaux de gris, ou plusieurs valeurs de composantes dans le cas d’une image couleur selon l’espace colorimétrique choisi : Red Green Blue (RGB), YCrCb ou Hue Saturation Value (HSV) par exemple. Ainsi, un flux d’une image peut représenter soit un bloc d’image, une image compl`ete ou une séquence d’image.

Choix d’une architecture orientée flux de données

La définition de notre mod`ele d’architecture se base sur le constat que la majorité des unités de calcul optimisées pour réaliser les opérateurs de traitement d’image, présentés au chapitre 2 en section 2.3.5, sont orientées flux de données. Nous avons également remarqué dans ce mˆeme chapitre, que ces opérateurs sont réutilisables entre différentes applications de visualisation d’image, selon les capteurs utilisés. Ainsi, en supposant qu’un syst`eme dispose de l’ensemble des unités de calcul capables de réaliser toutes les applications requises, il serait idéal que le syst`eme d’interconnexion puisse adapter dynamiquement les liaisons entre les unités de calcul en fonction du type de donnée, distingué selon le capteur, et de l’application `a implémenter. Par ailleurs, nous avons vu que la majorité des architectures de vision embarquée privilégie, généralement, au mieux la possibilité de chaîner les unités de calcul sous forme d’un pipeline [127–129] afin d’obtenir un minimum de mémorisation, de pouvoir traiter directement en flot de données et ainsi maximiser la bande passante des canaux de communication avec une latence minimale. Notre mod`ele d’architecture NoC tient compte de cette approche de conception, afin de pouvoir composer plusieurs pipelines d’unités de calcul, dans le but d’approcher les performances d’une architecture cˆablée spécifique mais sans la contrainte de liaisons point-`a-point figées entre les unités.

Proposition du mod`ele d’architecture de NoC

Dans notre NoC proposé, un noeud correspond soit `a un routeur unique ou soit `a l’association d’une unité de calcul (PE) avec son routeur. Plus particuli`erement, nous distinguons deux types de noeuds : les noeuds maîtres (M) et les noeud esclaves (E). La figure 4.2 présente un exemple de mise en oeuvre du NoC dans le cadre de l’exemple précédent avec trois capteurs et deux afficheurs. Sur cette figure, nous voyons que les capteurs et les afficheurs sont connectés au réseau au travers des routeurs maîtres (M), qui permettent de réaliser l’interface avec l’extérieur. Les PEs sont connectés au réseau au travers des routeurs esclaves (E) placés entre les noeuds maîtres.  Figure 4.2: Principe de l’architecture du NoC proposé D’un point de vue syst`eme, nous pouvons voir notre mod`ele comme un réseau indirect de routeurs maîtres qui sont reliés par plusieurs réseaux linéaires directs de routeurs esclaves. Les communications principales du réseau s’effectuent entre les noeuds maîtres et les communications secondaires entre les noeuds esclaves. Un noeuds maître représente une source ou une destination principale pour un paquet de données. En particulier, un routeur maître est caractérisé par des interfaces avec le monde extérieur lui permettant d’acquérir un flux de données entrant et de sortir un flux de données traité. Dans notre mod`ele, les routeurs maîtres sont reliés ou non par un nombre fini de routeurs esclaves auxquels sont connectées des unités de calcul. Le rˆole d’un noeud esclave est d’analyser les paquets de données entrants et de rediriger ces paquets vers leur unité de calcul selon les besoins de l’application `a réaliser. Un noeud esclave est ainsi capable de modifier le contenu des paquets de données transitant entre deux noeuds maîtres. Cette modification est effectuée en fonction du résultat fourni par l’unité de calcul connectée au routeur esclave. La figure 4.3 illustre un exemple de liaison composée de trois routeurs esclaves, sur lesquels sont connectées les unités PE0 `a PE2, entre deux routeurs maîtres 0 et 1. Dans cet exemple, les routeurs maîtres communiquent `a travers deux canaux A et B entrants ou sortants. Un routeur esclave k est relié par deux liaisons unidirectionnelles entrantes FWk−1(A) et FWk−1(B), et deux liaisons sortantes FWk(A) et FWk(B). Le routeur maître 0 est ainsi le seul émetteur possible. Le flot de données entre les noeuds  Figure 4.3: Réseau linéaire de routeurs esclaves entre deux noeuds maîtres maîtres est contrˆolé par des signaux d’acquittement Bp(A) et Bp(B) entre les routeurs esclaves. Le chemin de données alloué pour faire transiter le flot peut ˆetre modifié dans un routeur esclave selon l’utilisation de l’unité de calcul et du séquencement des ces unités défini par l’application `a réaliser.