• Aucun résultat trouvé

Gestion d’un acc´ el´ erateur flot de donn´ ees

3.2.1

Probl`ematique

G´en´eralement, les processeurs de voisinage sont utilis´es de mani`ere assez standard juste apr`es un imageur pour r´ealiser quelques corrections sur l’image, car cette derni`ere est souvent bruit´ee en sortie du capteur. Le processeur est donc utilis´e dans une mode flot de donn´ees pure o`u il n’est pas possible de r´einjecter en entr´ee les calculs sortant du flot. Ce mode de fonctionnement est adapt´e `a la mise en place d’op´erations simples d’am´elioration des images, mais dans notre cas, nous ciblons plutˆot une utilisation de l’acc´el´erateur pour des traitements plus complexes.

Une application de traitement d’images peut ˆetre difficilement d´eployable dans sa to- talit´e sur un flot de processeurs pour plusieurs raisons. Premi`erement, l’application peut faire appel `a une tr`es grande quantit´e d’op´erateurs et n´ecessiterait ainsi une surface de silicium beaucoup trop importante si elle ´etait d´eploy´ee totalement dans un flot profond d’op´erateurs. Deuxi`emement, la d´ependance entre les donn´ees et en particulier l’utilisation d’op´erateurs de r´eduction rend impossible le d´eploiement mat´eriel complet d’une appli- cation. Un exemple est donn´e en figure 3.1 o`u la n´ecessit´e de calculer le maximum et le minimum global sur l’image nous contraint de casser le flot de calculs. Il n’est pas possible de mettre en œuvre cette application sans stocker une image interm´ediaire, car le calcul du maximum global est prˆet uniquement lorsque tous les pixels ont ´et´e envoy´es. L’op´erateur utilisant ce r´esultat global ne peut donc pas fonctionner en pipeline rendant impossible la mise en place compl`ete de l’application dans un seul flot d’op´erateurs.

Fig. 3.1:Normalisation d’images : le flot de calcul est interrompu par la pr´esence d’op´erations de r´educ- tion

La mise en place d’un acc´el´erateur type flot de donn´ees avec la possibilit´e de r´ealiser des stockages interm´ediaires est donc imp´erative. Il faut ainsi pr´evoir l’int´egration de l’acc´el´e-

rateur dans un syst`eme plus g´en´eral que l’on appellera hˆote et qui est capable d’amorcer des transferts vers et depuis une m´emoire de stockage des images interm´ediaires.

3.2.2

Int´egration dans un syst`eme sur puce

La gestion de l’acc´el´erateur dans un syst`eme sur puce (SoC) est un moyen simple et efficace d’int´egrer un flot de processeurs de voisinage. On dispose ainsi, dans le mˆeme circuit, d’un processeur g´en´eraliste, de contrˆoleurs m´emoires et pourquoi pas de p´eriph´eriques de captures d’images autorisant une utilisation optimale de l’acc´el´erateur. En effet, un tel syst`eme ´elimine les probl`emes de gestion du flot de donn´ees cit´es dans le section pr´ec´edente et permet le rebouclage des traitements.

Nous avons envisag´e deux architectures fonctionnelles d´ecrites ci-apr`es. La premi`ere permet une int´egration simple, mais conduit `a une surcharge du bus principal du circuit et la seconde est plus complexe, mais permet des performances plus ´elev´ees tout en ne monopolisant pas le bus principal du processeur. En effet, la congestion du bus principal par les DMA peut ˆetre probl´ematique surtout si le processeur acc`ede `a ses instructions et ses donn´ees en m´emoire principale sans cache ni tampon.

3.2.2.1 Int´egration simple

L’objectif ici est d’int´egrer l’acc´el´erateur de la mani`ere la plus standard possible en l’interfa¸cant directement sur le bus principal du SoC et o`u l’on retrouve les composants de ce dernier : processeurs, DMA, contrˆoleur m´emoire...

La figure 3.2 pr´esente la vue fonctionnelle du circuit. On retrouve le processeur g´en´era- liste avec ses m´emoires statiques d’instructions et de donn´ees. Cette derni`ere est de faible taille et doit ˆetre uniquement consid´er´ee comme une zone de travail temporaire o`u l’on peut stocker uniquement que quelques lignes d’une image. Le stockage des images com- pl`etes est assur´e par la m´emoire dynamique externe au circuit et deux composants sur le bus autre que le processeur g´en´eraliste peuvent y ´ecrire des donn´ees : le DMA et la logique d’acquisition de signaux vid´eo.

Une application d´eploy´ee sur cette architecture se d´eroule de la mani`ere suivante : une image est automatiquement acquise sur ordre du processeur g´en´eraliste et est stock´ee en m´emoire externe. Une interruption est d´eclench´ee lorsque cette op´eration est termin´ee. Le processeur g´en´eraliste peut alors programmer les op´erations `a r´ealiser dans l’acc´el´erateur et orchestrer la programmation des DMA pour transmettre avec un flux le plus tendu possible l’envoi et la r´eception des images dans l’acc´el´erateur. Les FIFO permettent une bonne synchronisation des donn´ees `a traiter par le flot de processeurs lorsque plusieurs images sont n´ecessaires `a une op´eration. D`es lors que tous les pixels sont ressortis de l’acc´el´erateur et sont stock´es en m´emoire externe, le processeur peut soit passer `a l’´etape suivante de l’application soit demander l’acquisition d’une nouvelle image si toutes les op´erations sur une trame ont ´et´e r´ealis´ees.

On remarque que ce mode de fonctionnement n’est pas optimal, car il n’est pas possible de recevoir une image venant d’une cam´era et dans le mˆeme temps utiliser l’acc´el´erateur, et ce, pour deux raisons : la m´emoire externe est partag´ee entre l’acc´el´erateur et le syst`eme d’acquisition vid´eo et le bus du SoC est ´egalement partag´e entre tous les p´eriph´eriques. Un

CHAPITRE 3. CHAˆINAGE DE PROCESSEURS DE VOISINAGE

Fig. 3.2:Int´egration simple d’un acc´el´erateur type flot de processeurs dans un SoC

tel syst`eme trouve son int´erˆet si, d’une part, les contraintes en termes de temps de calcul des applications cibl´ees ne sont pas fortes et, d’autre part, si le coˆut du syst`eme est un facteur important, comme c’est dans le cas des applications automobiles.

3.2.2.2 Int´egration avanc´ee

Une int´egration plus complexe peut ˆetre r´ealis´ee en reprenant la structure simple et en y ajoutant une m´emoire pouvant contenir plusieurs images locales `a l’acc´el´erateur. Cette structure est pr´esent´ee en figure 3.3. Ainsi lorsque toutes les ´etapes d’une op´eration sur une mˆeme image n’ont pu ˆetre r´ealis´ees compl`etement en une passe dans l’acc´el´erateur, il est possible de stocker la ou les images en m´emoire locale pour r´eit´erer une nouvelle passe dans le flot de processeurs. Pendant ce temps le processeur g´en´eraliste est libre de l’utilisation du bus et peut tr`es bien demander l’acquisition d’une nouvelle image sans perturber la deuxi`eme passe de calcul dans l’acc´el´erateur.

Cette structure est plus coˆuteuse `a la fois mat´eriellement, car il est n´ecessaire d’ajou- ter une deuxi`eme m´emoire externe ainsi que toute la logique de contrˆole suppl´ementaire, mais ´egalement logiciellement, car l’ordonnancement des calculs sur l’acc´el´erateur devient beaucoup plus complexe afin de parall´eliser les acquisitions d’images et les traitements. On expose alors le parall´elisme de gestion des images `a l’utilisateur et on pourrait chercher `a optimiser automatiquement cette fonction un peu comme est g´er´e le pipeline logiciel dans les processeurs VLIW.

3.2.3

Synchronisme et gestion logicielle

La gestion logicielle d’un acc´el´erateur type flot de donn´ees est une tˆache assez fine d`es que plusieurs flots de donn´ees en parall`ele doivent ˆetre pris en compte. En effet, les composants de l’acc´el´erateur situ´es aux mˆemes ´etages du pipeline fonctionnent de mani`ere

Fig. 3.3:Int´egration avanc´ee d’un acc´el´erateur type flot de processeurs dans un SoC

synchrone et doivent traiter les pixels de mˆemes indices aux mˆemes instants. Ceci n’est vrai que si des ´echanges de flux doivent ˆetre effectu´es entre les composants dispos´es en parall`ele, dans le cas contraire la gestion est assez simple et peut ˆetre consid´er´ee de la mˆeme fa¸con que lors de l’acheminement d’un flot unique de donn´ees o`u finalement aucune FIFO en entr´ee n’est n´ecessaire.

La figure 3.4 illustre, pour une architecture capable de traiter deux flots de donn´ees en parall`ele, le cas o`u il est n´ecessaire de synchroniser les flux avant l’acheminement vers l’acc´el´erateur et le cas o`u cette synchronisation n’est pas n´ecessaire. En effet, dans l’acc´e- l´erateur 1, la pr´esence d’un op´erateur de soustraction reli´e aux deux branches parall`eles r´ealisant une ´erosion et une dilatation impose que les flux pr´esent´es aux entr´ees E0 et E1 soient parfaitement synchrones. De mani`ere duale, il n’est pas n´ecessaire pour l’acc´el´erateur 2 de pr´esenter des flux synchronis´es aux entr´ees E1 et E2 puisqu’il n’existe pas d’op´erateurs mettant en jeu des calculs `a partir des flux des deux branches d’op´erateurs.

CHAPITRE 3. CHAˆINAGE DE PROCESSEURS DE VOISINAGE

Nous allons maintenant nous placer dans le cas o`u plusieurs flots de donn´ees doivent ˆ

etre envoy´es et re¸cus en parall`ele puisque nous ne faisons pas d’hypoth`ese sp´ecifique quant `

a la structure interne des acc´el´erateurs et nous consid´erons alors le pire cas. Une barri`ere de synchronisation est n´ecessaire avant les entr´ees de l’acc´el´erateur pour garantir le synchro- nisme des flots de donn´ees avant l’acc´el´erateur. Nous supposons en outre que l’acc´el´erateur ne d´esynchronise pas en interne les flots de donn´ees. Chaque entr´ee de l’acc´el´erateur doit ˆ

etre pr´ec´ed´ee d’une FIFO stockant quelques centaines de pixels et informant le contrˆoleur de l’acc´el´erateur de leurs niveaux de remplissage. En effet, d`es qu’une des FIFO en entr´ee est vide il est n´ecessaire de geler l’acc´el´erateur. Il est ´egalement imp´eratif de placer des FIFO en sorties de l’acc´el´erateur pour stocker momentan´ement les r´esultats des calculs. Ces derni`eres doivent permettre ´egalement au contrˆoleur de geler l’acc´el´erateur lorsqu’elles sont pleines. Nous mettons donc en place un verrou global qui g`ele l’acc´el´erateur d`es qu’une FIFO d’entr´ee ou de sortie est pleine. La figure 3.5 pr´esente l’architecture de contrˆole du synchronisme autour de l’acc´el´erateur.

Fig. 3.5:Controleur d’un acc´el´erateur multiflot de donn´ees

Ce verrou mat´eriel simplifie grandement la gestion logicielle d´edi´ee `a l’alimentation des acc´el´erateurs en donn´ees puisqu’il est possible d’acc´eder aux FIFO directement depuis un DMA programm´e pour envoyer ou recevoir quelques lignes d’une image. On peut donc ´ecrire et lire alternativement par paquet de lignes dans les FIFO sans risquer de d´esynchroniser les flux de donn´ees vers l’acc´el´erateur. Le processeur g´en´eraliste se charge du contrˆole et ordonne les transferts DMA pour minimiser les p´eriodes d’inactivit´e de l’acc´el´erateur. Le contrˆoleur tient inform´e le processeur soit par un m´ecanisme d’interruption mat´erielle soit en changeant l’´etat de registres de statut que le processeur vient consulter `a intervalle r´egulier.