FR2936626A1

FR2936626A1 - Dispositif de traitement en parallele d'un flux de donnees

Info

Publication number: FR2936626A1
Application number: FR0805369A
Authority: FR
Inventors: Laurent Letellier; Mathieu Thevenin
Original assignee: Commissariat a lEnergie Atomique CEA
Current assignee: Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Priority date: 2008-09-30
Filing date: 2008-09-30
Publication date: 2010-04-02
Anticipated expiration: 2028-09-30
Also published as: US20110273459A1; WO2010037570A1; JP2012504264A; US8836708B2; FR2936626B1; EP2332067A1

Abstract

La présente invention concerne un dispositif de traitement d'un flux de données comprenant K tuiles de calcul (TC) et des moyens (4) d'interconnexion pour transférer le flux de données entre les tuiles de calcul (TC). Selon l'invention, chaque tuile de calcul (TC) comporte : - une unité de mémorisation (UM) permettant de mettre en forme les données du flux, - une ou plusieurs unités de contrôle (UC) permettant de fournir des instructions pour réaliser un traitement sur les données, - au moins une unité de traitement (UT) par unité de contrôle (UC), les unités de traitement (UT) réalisant les instructions reçues des unités de contrôle (UC), - une unité d'entrée/sortie (UES) permettant d'acheminer le flux de données entre les moyens (4) d'interconnexion et l'unité de mémorisation (UM) d'une part, et entre les unités de traitement (UT) et les moyens (4) d'interconnexion d'autre part. L'invention permet une grande modularité dans le traitement du flux de données tout en limitant la consommation d'énergie électrique.

Description

DISPOSITIF DE TRAITEMENT EN PARALLELE D'UN FLUX DE DONNEES L'invention concerne un dispositif de traitement d'un flux de données. Elle se situe dans le domaine des architectures de calcul et trouve une utilité particulière dans les applications embarquées de type multimédia intégrant un capteur vidéo. Il s'agit notamment de la téléphonie mobile, des lecteurs multimédia mobiles, des appareils photographiques et des caméscopes numériques. L'invention trouve également une utilité dans les applications relatives aux télécommunications et, plus généralement, dans toute chaîne de traitement du signal traitant des données numériques à cadence élevée. io Le traitement du signal en général, et le traitement d'images en particulier, demandent des puissances de calcul importantes, surtout depuis quelques années avec l'augmentation rapide de la résolution des capteurs d'images. Dans le domaine des applications embarquées à destination du grand public, de fortes contraintes en termes de coût de fabrication viennent 15 s'ajouter aux contraintes de consommation électrique (de l'ordre de quelques centaines de milliwatts). Pour répondre à ces contraintes, le traitement des images est couramment réalisé à partir de modules de calcul dédiés fonctionnant en mode flot de données. Le mode "flot de données", couramment appelé "data flow" dans la littérature anglo-saxonne, est 20 entendu comme un mode de traitement des données selon lequel les données entrant dans le module de calcul sont traitées au fur et à mesure, à la cadence de leur arrivée, un résultat étant fourni en sortie du module de calcul à la même cadence, éventuellement après un temps de latence. Les modules de calcul dédiés permettent de respecter les contraintes de coût de 25 fabrication du fait de leur faible surface silicium et les contraintes de performance, notamment quant à la puissance de calcul et la consommation électrique. Cependant, de tels modules souffrent d'un problème de flexibilité, les traitements supportés ne pouvant pas être modifiés après la réalisation des modules. Tout au mieux, ces modules sont paramétrables. Autrement, 30 dit, un certain nombre de paramètres liés au traitement peuvent être modifiés après la réalisation. Une solution à ce manque de flexibilité consiste à utiliser des processeurs complètement programmables. Les processeurs les plus couramment utilisés sont les processeurs de traitement du signal, bien connus dans la littérature anglo-saxonne sous l'acronyme "DSP" pour "Digital Signal Processor". Des inconvénients de ces processeurs sont leur empreinte silicium importante et leur consommation électrique les rendant souvent inadaptés aux applications embarquées très contraintes. Des compromis entre les modules de calcul dédiés et les processeurs complètement programmables sont actuellement en cours de développement. Selon un premier compromis, un circuit comprend une unité de traitement des données à mots d'instructions très longs, appelée unité io VLIW pour "Very Long Instruction Word", et une unité permettant d'exécuter une instruction sur plusieurs unités de calcul, appelée unité SIMD pour "Single Instruction Multiple Data". Dans certaines réalisations actuelles, des unités de calcul de type VLIW et/ou SIMD sont implantées dans le circuit en fonction de la puissance de calcul nécessaire. Le choix du type d'unité à 15 inclure dans le circuit, de leur nombre et de leur chaînage est décidé avant la réalisation du circuit par une analyse du code applicatif et des ressources nécessaires. L'ordre dans lequel sont chaînées les unités est fixe et il ne permet pas de changer par la suite l'enchaînement des traitements. De plus, les unités sont 20 globalement assez complexes car le code de contrôle de l'application n'est pas séparé du code de traitement. Ainsi, les opérateurs de traitement de ces unités sont de taille importante, ce qui amène une architecture dont la surface silicium et la consommation électrique sont plus importantes à puissance de calcul égale. 25 Selon un deuxième compromis, un code en langage C peut être transformé en un ensemble d'instructions élémentaires par un compilateur spécifique. L'ensemble d'instructions est alors implanté sur une matrice configurable d'opérateurs prédéfinis. Cette technologie peut être comparée à celle des réseaux prédiffusés programmables par l'utilisateur, mieux connus sous 30 l'acronyme anglo-saxon FPGA pour "Field Programmable Gate Array", le grain de calcul étant plus gros. Elle ne permet donc pas d'obtenir des circuits programmables, mais uniquement des circuits configurables par compilation du code. Si l'on souhaite intégrer des parties de code programme non prévues au départ, il faut alors des ressources de calcul qui ne sont pas présentes dans le circuit. Il devient donc difficile voire impossible d'implémenter ce code.

Un but de l'invention est notamment de pallier les inconvénients précités en proposant une structure de calcul qui soit programmable tout en limitant la consommation électrique. A cet effet, l'invention a pour objet un dispositif de traitement d'un flux de données comprenant K tuiles de calcul et des moyens d'interconnexion pour transférer le flux de données entre les tuiles de calcul. Chaque tuile de calcul comporte : Io - une unité de mémorisation permettant de mettre en forme les données du flux, - une ou plusieurs unités de contrôle permettant de fournir des instructions pour réaliser un traitement sur les données mises en forme, au moins une unité de traitement par unité de contrôle, les 15 unités de traitement réalisant les instructions reçues des unités de contrôle, - une unité d'entrée/sortie permettant d'acheminer le flux de données entre les moyens d'interconnexion et l'unité de mémorisation d'une part, et entre la ou les unités de traitement et les moyens d'interconnexion d'autre part. 20 L'invention présente plusieurs avantages. Un premier avantage est la possibilité de modifier le code à exécuter par les unités de traitement, même après la réalisation du circuit supportant le dispositif. Un deuxième avantage est la possibilité de réaliser en parallèle, soit un traitement 25 identique sur plusieurs données du flux, soit des traitements plus complexes pour un même nombre de cycles d'horloge en profitant de la mise en parallèle des unités de traitement. Un troisième avantage est la possibilité de réaliser une chaîne de dispositifs selon l'invention afin d'exécuter d'autres traitements sur le flux de données. Un quatrième avantage est que le code à 30 exécuter par les unités de traitement ne comprend que des instructions de calcul mais aucune instruction de contrôle ou de calcul d'adresse.

L'invention sera mieux comprise et d'autres avantages apparaîtront à la lecture de la description détaillée d'un mode de réalisation donné à titre d'exemple, description faite en regard de dessins annexés qui représentent : - la figure 1, un exemple de dispositif de traitement d'un flux de données selon l'invention, - la figure 2, un exemple d'unité de traitement comportant un processeur à mots d'instructions très longs, - la figure 3, un exemple de gestion d'un bloc de mémoires de mise en forme, - la figure 4, un exemple de gestion d'un bloc de registres de io voisinage dans un cas où les données du bloc de mémoires de mise en forme sont dans l'ordre, - la figure 5, un exemple de gestion du bloc de registres de voisinage dans le cas où les données du bloc de mémoires de mise en forme ne sont pas dans l'ordre, 15 - la figure 6, un ensemble de chronogrammes illustrant la gestion temporelle d'un bloc de registres de voisinage, - la figure 7, un exemple de réalisation d'une tuile de calcul comprenant plusieurs unités de traitement en parallèle. - la figure 8, un ensemble de chronogrammes illustrant la 20 gestion temporelle d'une unité de mémorisation d'une tuile de calcul comportant deux unités de traitement en parallèle, - la figure 9, un exemple de réalisation d'une unité d'entrée/ sortie, la figure 10, un exemple de mise en oeuvre du dispositif selon 25 l'invention pour des images vidéo, - la figure 11, une représentation schématique d'un filtre de Bayer, la figure 12, un exemple de réalisation d'un opérateur d'insertion. 30 La suite de la description est faite en relation avec une chaîne de traitement d'un flux de données vidéo provenant d'un capteur vidéo tel qu'un capteur CMOS. La chaîne de traitement permet par exemple de reconstruire des images couleurs à partir d'un capteur vidéo monochrome sur lequel est 35 appliqué un filtre de couleur, par exemple un filtre de Bayer, d'améliorer la qualité des images restituées, ou encore de réaliser des opérations morphologiques telles que l'érosion/dilatation ou la partie bas niveau traitant les pixels des applications évoluées telles que la stabilisation d'images, la correction des yeux rouges ou la détection de visages. Cependant, le dispositif selon l'invention peut tout aussi bien convenir au traitement d'un flux de données autres que celles issues d'un capteur vidéo. En particulier, le dispositif peut traiter un flux de données audio ou des données dans l'espace de Fourier.

io La figure 1 représente schématiquement un dispositif 1 de traitement d'un flux de données selon l'invention. Un capteur vidéo 2 génère un flux de données numériques dirigé vers le dispositif 1 de traitement, par l'intermédiaire d'un bus 3 de données. Les données issues du capteur vidéo 2 sont qualifiées de données brutes. Le dispositif 1 traite ces données brutes 15 afin de générer en sortie des données qualifiées de données finales. A cette fin, le dispositif 1 selon l'invention comprend des unités de traitement UT, des unités de contrôle UC, des unités de mémorisation UM et des unités d'entrée/sortie UES regroupées en K tuiles de calcul TC. Le dispositif 1 comprend également des moyens 4 d'interconnexion tels que des bus 41, 42 20 de données. Ces moyens 4 d'interconnexion permettent de transférer le flux de données entre les différentes tuiles de calcul TC. Chaque tuile de calcul TC comporte une unité de mémorisation UM, une ou plusieurs unités de contrôle UC, au moins une unité de traitement UT par unité de contrôle UC et une unité d'entrée/sortie UES. Les unités de mémorisation UM permettent de 25 mettre en forme les données du flux afin de pouvoir être traitées par les unités de traitement UT en fonction d'instructions de code délivrées par les unités de contrôle UC. Les unités d'entrée/sortie UES permettent d'acheminer le flux de données entre les moyens 4 d'interconnexion et les unités de mémorisation UM d'une part, et entre les unités de traitement UT et 30 les moyens 4 d'interconnexion d'autre part. Dans l'exemple de la figure 1, le dispositif 1 comprend 4 tuiles de calcul TC, la première et la quatrième tuile de calcul TC1 et TC4 comportant chacune une unité de mémorisation UM, une unité de contrôle UC, une unité de traitement UT et une unité d'entrée/sortie UES, la deuxième tuile de calcul TC2 comportant une unité de 35 mémorisation UM, une unité de contrôle UC, deux unités de traitement UT et une unité d'entrée/sortie UES, et la troisième tuile de calcul TC3 comportant une unité de mémorisation UM, deux unités de contrôle UC, deux unités de traitement UT par unité de contrôle UC et une unité d'entrée/sortie UES. Chaque tuile de calcul TC permet de réaliser une fonction ou une suite de fonctions à partir d'instructions de code. Dans le cadre d'une chaîne de traitement vidéo, chaque tuile de calcul TC réalise par exemple l'une des fonctions suivantes : correction de la balance des blancs, dématriçage, diminution du bruit, accentuation des contours. La composition d'une tuile de calcul TC dépend notamment de la ou des fonctions qu'elle a à réaliser. En to particulier, le nombre d'unités de contrôle UC composant une tuile de calcul TC dépend du nombre de traitements différents devant être réalisés simultanément par la tuile de calcul TC. Chaque unité de contrôle UC au sein de la tuile de calcul TC pouvant comporter son propre code, une tuile de calcul TC comporte par exemple autant d'unités de contrôle UC que de 15 traitements distincts à réaliser en parallèle sur les données.

Les unités de traitement UT peuvent être plus ou moins complexes. En particulier, elles peuvent comporter soit de simples opérateurs dédiés, par exemple composés de blocs logiques, soit des 20 processeurs. Chaque unité de traitement UT est indépendante des autres et peut comporter des opérateurs ou des processeurs différents. Les opérateurs dédiés sont par exemple des multiplieurs, des additionneurs/ soustracteurs, des opérateurs d'affectation ou des opérateurs de décalage. Avantageusement, les unités de traitement UT ne contiennent que les 25 opérateurs dédiés couramment utilisés pour le traitement envisagé. Une unité de traitement UT peut également comporter un processeur. Dans un premier mode de réalisation, le processeur comprend une seule unité arithmétique et logique. Dans un deuxième mode de réalisation, le processeur est un processeur à mot d'instruction très long, 30 couramment appelé d'après la littérature anglo-saxonne processeur VLIW pour "Very Long Instruction Word". Un tel processeur peut comporter plusieurs unités arithmétiques et logiques. Dans une variante préférée, un processeur VLIW comporte par exemple des décodeurs d'instructions, non plus des unités arithmétiques et logiques mais seulement des opérateurs de 35 calcul, une mémoire locale et des registres de données. Avantageusement, seuls les opérateurs de calcul nécessaires à l'exécution des codes de calcul à réaliser sont implantés dans le processeur lors de sa conception. Ensuite, deux d'entre eux ou plus peuvent être utilisés dans le même cycle pour effectuer en parallèle des opérations distinctes. Les opérateurs non utilisés ne reçoivent pas les signaux d'horloge. La consommation électrique des unités de traitement UT s'en trouve ainsi réduite. Ces caractéristiques avantageuses ont conduit à une forme particulière de réalisation, représentée à la figure 2. Dans cette figure, le processeur VLIW comporte deux voies. Autrement dit, il peut exécuter jusqu'à deux instructions dans un io même cycle d'horloge. Le processeur comporte un premier décodeur d'instructions 21, un deuxième décodeur d'instructions 22, un premier ensemble de multiplexeurs 23, un ensemble d'opérateurs de calcul 24, un deuxième ensemble de multiplexeurs 25, un ensemble de registres de données 26 et une mémoire locale 27. Les décodeurs d'instructions 21 et 22 15 reçoivent des instructions en provenance d'une unité de contrôle UC. En fonction des instructions reçues, les multiplexeurs 23 dirigent des données à traiter sur une entrée de l'un des opérateurs de calcul 24 et les multiplexeurs 25 dirigent les données traitées vers les registres de données 26. Les registres de données 26 contenant les données traitées peuvent être mis en 20 liaison avec des sorties du processeur. La taille des rnots d'instructions très longs est par exemple de 48 bits, soit 24 bits par voie. Les opérateurs de calcul 24 travaillent ainsi en précision 24 bits. Dans le cadre d'un traitement vidéo et plus particulièrement d'une reconstruction d'image à partir de données issues d'un capteur vidéo, les opérateurs de calcul 24 sont 25 avantageusement deux additionneurs/ soustracteurs, un multiplieur, un opérateur d'affectation, un opérateur d'écriture dans la mémoire locale et un opérateur de décalage. Toujours selon une forme particulière de réalisation, l'exécution des instructions peut être conditionnée par un positionnement d'un drapeau. 30 L'instruction peut alors être complétée par un préfixe indiquant la condition d'exécution. Le drapeau est par exemple un bit d'un registre contenant le résultat d'une instruction exécutée durant le cycle d'horloge précédent. Ce bit peut correspondre aux indicateurs de zéro, de signe ou de report (carry) du registre. A chaque instruction, les décodeurs d'instructions 21 et 22 testent le 35 positionnement du drapeau lié à cette instruction. Si ce positionnement est conforme à la condition d'exécution, l'opération est exécutée, sinon elle est remplacée par une instruction de non-opération, appelée NOP. A la fin du cycle de chaque instruction, la valeur du drapeau est envoyée aux deux décodeurs d'instructions 21 et 22 afin de pouvoir tester l'éventuelle condition d'une instruction suivante. Selon une forme particulière de réalisation, chaque mot d'instruction est codé sur 24 bits. Les 3 premiers bits (bits 0 à 2) peuvent contenir la condition d'instruction, les deux bits suivants (bits 3 et 4) peuvent coder le mode d'accès à la donnée, les sixième, septième et huitième bits Io (bits 5 à 7) peuvent coder l'identifiant de l'opération, les quatre bits suivants (bits 8 à 11) peuvent désigner le registre de destination, les quatre bits suivants (bits 12 à 15) peuvent désigner le registre source et les 8 derniers bits (bits 16 à 23) peuvent contenir une constante. Un exemple de programmation utilisant un tel codage est donné en annexe. 15 Le dispositif 1 de traitement d'un flux de données comprend M unités de contrôle UC, M étant compris entre 1 et N, N étant le nombre d'unités de traitement UT. Dans le cas où le nombre M d'unités de contrôle UC est égal au nombre N d'unités de traitement UT, chaque unité de 20 traitement UT peut disposer de sa propre unité de contrôle UC. Dans le cas où le nombre M d'unités de contrôle UC est inférieur au nombre N d'unités de traitement UT, alors au moins une tuile de calcul TC comprend plusieurs unités de traitement UT, comme dans l'exemple de la figure 1 (TC2, TC3). Une unité de contrôle UC de cette tuile de calcul TC fournit alors des 25 instructions à plusieurs unités de traitement UT, ces unités de traitement UT étant dites en parallèle. Une unité de contrôle UC peut comprendre une mémoire permettant de stocker les instructions de code pour la ou les unités de traitement UT qu'elle sert. Une unité de contrôle UC peut également comporter un compteur ordinal, un décodeur d'instructions et un gestionnaire 30 d'adresse. Dans le cadre d'un traitement d'images brutes obtenues par un filtre de couleur, le gestionnaire d'adresse et le compteur ordinal permettent d'appliquer un traitement différent en fonction de la couleur du pixel courant. En particulier, le code peut être découpé en segrnents de code, chaque 35 segment de code comportant des instructions pour l'une des couleurs du filtre. Le gestionnaire d'adresse peut indiquer au compteur ordinal la couleur du pixel courant, par exemple rouge, vert ou bleu. Selon une forme particulière de réalisation, le gestionnaire d'adresse comporte un mot de deux bits permettant de coder jusqu'à quatre couleurs ou natures différentes de pixels dans un voisinage pixel de taille deux par deux. A chaque cycle d'horloge, le compteur ordinal est incrémenté d'une valeur de décalage (offset) dépendant de la valeur du mot. Le compteur ordinal permet alors de pointer sur le segment de code correspondant à la couleur du pixel courant. Les quatre valeurs de décalage sont déterminées à la compilation du code io en fonction du nombre d'instructions de chacun des segments de code. L'utilisation d'un gestionnaire d'adresse et d'un compteur ordinal permet de décharger le programmeur et évite ainsi qu'il détermine lui-même par programme la nature du pixel courant. Cette gestion devient automatique et permet un temps d'exécution plus court et une programmation plus simple. is Dans le cas particulier où les images traitées sont monochromes, les mêmes instructions sont appliquées à tous les pixels. Les valeurs de décalage sont alors égales et déterminées afin que le compteur ordinal pointe la première instruction après le code d'initialisation.

20 Le dispositif 1 de traitement d'un flux de données comprend également K unités de mémorisation UM, K étant compris entre 1 et M. Une tuile de calcul TC peut comprendre plusieurs unités de contrôle UC, comme dans l'exemple de la figure 1 (TC3). Les mêmes données du flux, ou des données voisines, présentes dans l'unité de mémorisation UM peuvent alors 25 être traitées différemment par les unités de traitement UT de la tuile de calcul, chaque unité de contrôle UC fournissant des instructions à au moins une unité de traitement UT. Les unités de mémorisation UM ont pour principale fonction de mettre en forme les données du flux afin de faciliter l'accès des unités de traitement UT à ces données. Plus précisément, les 30 unités de mémorisation UM mettent en forme les données sous forme de voisinages et gèrent l'accès aux données lorsque des unités de traitement UT sont en parallèle. Selon une première forme de réalisation, les unités de mémorisation UM comprennent chacune un nombre de registres de données égal au nombre d'unités de traitement UT situées dans la tuile de calcul TC de l'unité de mémorisation UM considérée. Selon une deuxième forme de réalisation, particulièrement adaptée au traitement d'images vidéo, les unités de mémorisation UM comprennent chacune un premier bloc mémoire appelé bloc de mémoires de mise en forme et un deuxième bloc mémoire appelé bloc de registres de voisinage. Les unités de mémorisation UM étant indépendantes les unes des autres, le dispositif 1 de traitement du flux de données peut comprendre à la fois des unités de mémorisations UM selon la première forme de réalisation et des unités de mémorisation UM selon la deuxième forme de réalisation. La deuxième forme de réalisation permet de réaliser des traitements sur des voisinages de données. Pour une image vidéo, un voisinage peut être défini comme une maille de pixels adjacents, cette maille étant généralement carrée ou au moins rectangulaire. Une maille rectangulaire peut être définie par sa dimension VlxVc où VI est le nombre de pixels du voisinage selon les lignes et Vc est le nombre de pixels du voisinage selon les colonnes. Le bloc de mémoires de mise en forme stocke les données du flux de sorte qu'elles puissent être recopiées de manière systématique à chaque arrivée d'une nouvelle donnée. Le bloc de registres de voisinage permet un accès aux pixels du voisinage courant par la ou les unités de traitement UT de la tuile de calcul considérée. La figure 3 illustre, par un bloc 31 de mémoires de mise en forme représenté à différents pas de temps T, un exemple de gestion du bloc 31 pour des données correspondant à un flux de valeurs de pixels provenant d'un capteur vidéo 32. Le capteur vidéo 32 est de résolution Nc colonnes par NI lignes. La résolution est par exemple VGA (640x480), "HD Ready" (1080x720) ou "Full HD" (1920x1080). Les pixels sont envoyés et stockés au fur et à mesure de leur arrivée vers le bloc 31 de mémoires de mise en forme. Ce bloc 31 est de dimension NcxVI. Autrement dit, le bloc 31 comprend NcxVl cellules mémoire agencées suivant une maille de Nc colonnes et de VI lignes. Des valeurs courantes pour VI sont trois, quatre, cinq, six ou sept. Physiquement, le bloc 31 peut être constitué d'un ou plusieurs modules mémoire. Le bloc 31 peut être géré comme un registre à décalage. Autrement dit, à chaque pas de temps ou cycle d'horloge, les données sont décalées pour laisser place à la nouvelle donnée entrante.

Avantageusement, le bloc 31 est géré comme une mémoire classique de manière à ce que les pixels soient recopiés dans leur ordre d'arrivée. Dans ce dernier cas et dans un premier mode de réalisation, on considère un compteur CPT s'incrémentant à chaque donnée entrante. Chaque nouveau pixel venant du flux de données est alors recopié dans une cellule 33 du bloc 31 de mémoires de mise en forme située à la ligne correspondant à E(CPT/Nc), où E(x) est la fonction renvoyant la partie entière d'un nombre x, et à la colonne correspondant au reste de CPT/Nc. Le compteur CPT est remis à zéro chaque fois qu'il atteint la valeur égale à NcxVI. io Dans un deuxième mode de réalisation, on considère, un compteur CPTC s'incrémentant après chaque donnée entrante et un compteur CPTL s'incrémentant à chaque fois que le compteur CPTC atteint la valeur Nc. Le compteur CPTC est remis à zéro chaque fois qu'il atteint la valeur Nc et le compteur CPTL est remis à zéro chaque fois qu'il atteint la valeur VI. Chaque 15 nouveau pixel venant du flux de données est alors recopié dans la cellule 33 dont le numéro de ligne correspond à la valeur CPTL. et dont le numéro de colonne correspond à la valeur CPTC. La figure 4 illustre un exemple de gestion du bloc de registres de voisinage pour des données provenant du bloc 31 de mémoires de mise en 20 forme. Le bloc 34 de registres de voisinage comprend un nombre de registres de voisinage égal à VlxVc. Ces registres de voisinage sont agencés de la même manière que le voisinage de pixels, c'est-à-dire qu'ils forment une maille de VI lignes et Vc colonnes de registres. La recopie des données du bloc 31 de mémoires de mise en forme vers les registres de voisinage 25 débute dès qu'il y a un nombre de données dans le bloc 31 égal à Ncx(VI- 1)+1. Dans le cas d'un voisinage de dimension 3x3, représenté à la figure 4, la recopie des données débute ainsi lorsque deux lignes de données plus une donnée sont présentes dans le bloc 31. Dans un mode de réalisation, les données sont recopiées à chaque cycle d'horloge par groupes de VI données 30 d'une même colonne. A un pas de temps donné, le numéro de la colonne à recopier est donné par la valeur de CPTC. Cette colonne comprend en effet le dernier pixel arrivé dans le bloc 31. Avantageusement, une colonne 35 de VI registres de données est ajoutée aux registres de voisinage. Cette colonne 35 permet de ne bloquer les accès aux registres du bloc 34 par les 35 unités de traitement UT que pendant un seul cycle d'horloge, celui du décalage des valeurs dans le bloc 34. Autrement, les accès sont bloqués à la fois pendant le décalage des valeurs et pendant la recopie des données à partir du bloc 31. Pendant un premier cycle d'horloge, les données de la colonne du bloc 31 indiquée par le compteur CPTC sont recopiées dans les registres de la colonne 35. Pendant un deuxième cycle d'horloge, toutes les données du bloc 34 et de la colonne 35 sont décalées d'une colonne. Ainsi, pour un voisinage de dimension 3x3, dans un même cycle d'horloge, les données d'une première colonne 341 sont décalées vers une deuxième colonne 342, pendant que les données de cette colonne 342 sont décalées io vers une troisième colonne 343 et que les données de la colonne 35 sont décalées vers la colonne 341. Du fait de la gestion cyclique du bloc 31, les données ne sont pas toujours stockées dans le bloc 31 suivant l'ordre des lignes du capteur vidéo 32. Dans ce cas, les pixels doivent être recopiés dans la colonne 35 ou, le 15 cas échéant, dans la colonne 341 du bloc 34, dans un ordre différent. La figure 5 illustre un tel cas où les dernières données du flux se trouvent stockées sur la première ligne du bloc 31. Dans le cas d'un voisinage de dimension 3x3, la recopie des pixels dans la colonne 35 peut être gérée par les étapes de placement suivantes : 20 - le pixel dernier arrivant va toujours sur la troisième ligne 347 de la colonne 35 des registres de voisinage ; - si le compteur CPTL est égal à zéro, autrement dit si le dernier pixel est arrivé à la première ligne 311 du bloc 31, alors o le pixel de la deuxième ligne 312 du bloc 31 est recopié 25 à la première ligne 345 de la colonne 35, o le pixel de la troisième ligne 313 du bloc 31 est recopié à la deuxième ligne 346 de la colonne 35 ; si le compteur CPTL est égal à un, autrement dit si le dernier pixel est arrivé à la deuxième ligne 312 du bloc 31, alors 30 o le pixel de la première ligne du bloc 31 est recopié à la deuxième ligne 346 de la colonne 35, o le pixel de la troisième ligne 313 du bloc 31 est recopié à la première ligne 345 de la colonne 35 ; si le compteur CPTL est égal à deux, autrement dit si le dernier 35 pixel est arrivé à la troisième ligne 313 du bloc 31, alors o le pixel de la première ligne 311 du bloc 31 est recopié à la première ligne 345 de la colonne 35, o le pixel de la deuxième ligne 312 du bloc 31 est recopié à la deuxième ligne 346 de la colonne 35.

Plus généralement, dans le cas d'un voisinage de taille VcxVI, le pixel du bloc 31 de mémoires de mise en forme situé à la ligne NoLigne et à la colonne indiquée par CPTC est notamment recopié à la colonne 35, ou, le cas échéant, dans la première colonne 341 du bloc 34, à la ligne définie par (CPTL + NoLigne + 1) modulo VI. io Selon un mode particulier de réalisation, la recopie des pixels du bloc 31 dans la colonne 35 de registres n'est pas effectuée simultanément au décalage des pixels dans le bloc 34. Cette forme de réalisation permet aux unités de traitement UT d'accéder aux données présentes dans le bloc 34 de registres de voisinage pendant une plus grande période. La figure 6 15 représente un ensemble de chronogrammes permettant de mettre en oeuvre ce mode de réalisation. Le décalage temporel entre la recopie des pixels et le décalage des pixels dans le bloc 34 peut être réalisé en introduisant, en plus d'une première horloge, appelée horloge pixel 61 et permettant de cadencer le flux de données et la recopie des pixels, une deuxième horloge, 20 appelée horloge pixel décalée 62. Cette horloge pixel décalée 62 peut être à la même fréquence que l'horloge pixel 61 mais décalée dans le temps. Ce décalage correspond par exemple à une période de l'horloge des unités de traitement UT 63. Les données présentes dans le bloc 34 sont alors accessibles pendant toute la période séparant deux coups d'horloge de 25 l'horloge pixel décalée 62. L'accès aux registres de voisinage par les unités de traitement UT peut être réalisé par un port d'entrée/sortie, par exemple intégré à chaque unité de traitement UT, dont le nornbre de connexions est égal au nombre de registres de voisinage multiplié par la taille des données. Chaque registre de voisinage est relié au port d'entrée/sortie. 30 Avantageusement, chaque unité de mémorisation UM comprend un multiplexeur dont le nombre d'entrées est égal au nombre de registres de voisinage du bloc 34 et le nombre de sorties est égal au nombre de données pouvant être traitées simultanément par l'unité de traitement UT de la tuile de calcul TC considérée. L'unité de traitement UT peut alors comprendre un port 35 d'entrée/sortie dont le nombre de connexions est égal au nombre de données pouvant être traitées simultanément multiplié par la taille des données. En l'occurrence, une unité de traitement UT comprenant un processeur VLIW à deux voies traitant des données sur 12 bits peut comporter un port d'entrée/sortie à 24 (2x12) connexions.

Selon un mode particulier de réalisation, une même unité de mémorisation UM fournit des données à plusieurs unités de traitement UT en parallèle. Ce mode de réalisation est possible grâce aux unités de mémorisation UM comportant un bloc 31 de mémoires de mise en forme et un bloc 34 de registres de voisinage. La figure 7 illustre un exemple de tuile io de calcul TC où une unité de mémorisation UM fournit des données à n unités de traitement UT en parallèle, n étant inférieur ou égal au nombre N d'unités de traitement UT du dispositif 1. Les instructions sont fournies aux n unités de traitement UT par une unité de contrôle UC. Selon ce mode de réalisation, le bloc 34 de registres de voisinage est de dimension (n+Vl-1)xVl. is Autrement dit, le bloc 34 comprend (n+Vl-1)xVl registres de données agencés suivant une maille de n+Vl-1 colonnes et VI lignes. Par exemple, pour trois unités de traitement UT en parallèle et un voisinage de dimension 5x5, une maille de 7 (=3+5-1) colonnes et 5 lignes de registres sont nécessaires. De plus, une colonne 35 de VI registres de données peut être 20 ajoutée au bloc 34. Ainsi, l'accès aux registres de voisinage par les unités de traitement UT n'est bloqué que pendant un seul cycle des unités de traitements UT. La recopie des données du bloc 31 vers la colonne 35 de registres débute alors lorsque le bloc 31 de mémoires de mise en forme comporte Ncx(Tv-1)+1 données. Par ailleurs, pour n unités de traitement UT 25 en parallèle, le traitement des données est réalisé lorsque n nouvelles données sont arrivées dans le bloc 31. L'accès aux registres de voisinage par les n unités de traitement UT peut également être réalisé par un port d'entrée/sortie intégré à chaque unité de traitement UT. Le nombre de connexions du port d'entrée/sortie de chaque unité de traitement UT est alors 30 égal au nombre de registres de voisinage auxquels l'unité de traitement UT nécessite un accès multiplié par la taille des données. De même, l'unité de mémorisation UM peut comprendre un multiplexeur dont le nombre d'entrées est égal au nombre de registres de voisinage du bloc 34 et le nombre de sorties est égal au nombre de données pouvant être traitées simultanément 35 par les n unités de traitement UT, chaque unité de traitement UT comprenant un port d'entrée/sortie dont le nombre de connexions est égal au nombre de données pouvant être traitées simultanément par ladite unité de traitement UT multiplié par la taille des données. La figure 8 illustre, par un ensemble de chronogrammes, un exemple de gestion d'une tuile de calcul TC comportant deux unités de traitement UT en parallèle. Un premier chronogramme 81 représente l'horloge des unités de traitement UT de cadence Farchi. Un deuxième chronogramme 82 représente l'horloge pixel de cadence Fp1Xe,. L'horloge pixel fixe la cadence à laquelle arrivent les données du flux, lesquelles sont io envoyées dans le bloc 31 de mémoires de mise en forme. La cadence Farchi peut être égale à pxFp1xe1 avec p un entier positif. Selon la figure 8, la cadence Fp1Xe, est quatre fois supérieure à la cadence Farchi• Chaque unité de traitement UT dispose ainsi de quatre cycles d'horloge par donnée à traiter. Un troisième chronogramme 83 représente une horloge de décalage. Cette 15 horloge génère deux coups d'horloge 831, 832 successifs après un coup d'horloge sur deux de l'horloge pixel. A chaque coup d'horloge de l'horloge de décalage, les données du bloc 34 sont décalées d'une colonne. Un quatrième chronogramme 84 représente l'horloge pixel décalé. La cadence de cette horloge est sensiblement égale à la moitié de la cadence Fpixe,, un 20 coup d'horloge 840 étant généré après les deux coups d'horloge 831, 832 de l'horloge de décalage. De manière générale, la cadence de l'horloge pixel décalée est égale à 1/n fois la cadence Foxe, de l'horloge pixel. A chaque coup d'horloge 840 de l'horloge pixel décalée, les données sont recopiées du bloc 31 vers le bloc 35. L'accès aux registres de voisinage par les unités de 25 traitement UT est possible entre deux coups d'horloge 840 de l'horloge pixel décalée.

Selon une forme particulière de réalisation, les moyens 4 d'interconnexion comprennent un nombre Nb_bus de bus de données. 30 Nb_bus peut être défini par la relation suivante : Nb_bus = Kx(Fp,Xei/Farchi)+1. Cette forme de réalisation permet de connecter les K tuiles de calcul TC les unes aux autres en réalisant un multiplexage spatiotemporel dont le rapport Mux_t de multiplexage temporel est défini par la relation : 35 MUX t = Farchi/Fpixel• Le rapport Mux_t de multiplexage temporel permet de définir un nombre égal d'intervalles de temps, les autorisations d'accès en lecture et en écriture pouvant être définis pour chaque intervalle de temps. Par exemple, pour une cadence Fp1Xe, égale à 50 MHz et une cadence Farchi à 200 MHz, les quatre tuiles de calcul TC de la figure 1 peuvent être chaînées dans un ordre quelconque si les moyens 4 d'interconnexion comportent au minimum deux (4x(50/200)+1) bus de données, les tuiles de calcul TC étant adressées par un multiplexage temporel de rapport quatre (=200/50). Selon cette forme de réalisation, chaque unité d'entrée/sortie UES peut gérer io les autorisations d'accès en lecture et en écriture en fonction du nombre Nb_bus de bus et du rapport Mux_t de multiplexage temporel. En particulier, chaque unité d'entrée/sortie UES peut comporter des registres permettant de déterminer les intervalles de temps pendant lesquels la tuile de calcul TC considérée a une autorisation d'accès en lecture ou en écriture sur l'un des 15 bus de données et, pour chacun de ces intervalles de temps, le bus de données pour lequel l'accès en lecture ou en écriture est autorisé. Une unité d'entrée/sortie UES comporte par exemple, pour la gestion des autorisations d'accès en écriture, Nb_bus registres de taille log2(Mux_t) bits, où log2(x) est la fonction renvoyant le logarithme en base 2 du nombre x et, pour la gestion 20 des autorisations d'accès en lecture, un registre de taille log2(Nb_bus) bits précisant le numéro du bus à lire et un registre de taille log2(Mux_t) bits précisant l'intervalle de temps. Un exemple de réalisation d'une telle unité d'entrée/sortie UES est représenté à la figure 9. L'unité d'entrée/sortie UES comporte deux registres 91 et 92 de 2 bits chacun, le registre 91 gérant 25 l'autorisation d'accès en écriture sur le bus 41 et le registre 92 gérant l'autorisation d'accès en écriture sur le bus 42. Le contenu des registres 91 et 92 est comparé à la valeur de l'intervalle de temps courant, par exemple par des comparateurs 93 et 94 et, en cas d'égalité, l'écriture des données est autorisée sur le bus 41 ou 42 concerné. L'unité d'entrée/sortie UES comporte 30 également un registre 95 de 1 bit précisant le numéro du bus 41 ou 42 à lire et un registre 96 de 2 bits précisant l'intervalle de temps pour la lecture. Le contenu du registre 96 est également comparé à l'intervalle de temps courant, par exemple par un comparateur 97 et, en cas, d'égalité, la lecture des données est autorisée sur le bus 41 ou 42 concerné. Cette forme de 35 réalisation présente l'avantage que chaque unité d'entrée/sortie UES gère individuellement les autorisations d'accès entre les tuiles de calcul TC et les bus 41 et 42. Par conséquent, aucun organe de contrôle centralisé n'est nécessaire. La valeur des registres de chaque unité d'entrée/sortie UES, est fixée au démarrage du système en fonction du chaînage souhaité des tuiles de calcul TC. Une tuile de calcul TC non utilisée pourra avoir les valeurs des registres de son unité d'entrée/sortie UES initialisées de manière à n'avoir aucun droit de lecture ou d'écriture sur le bus 41 ou 42.

Selon une forme particulière de réalisation, représentée à la figure 1, io chaque tuile de calcul TC comprend en outre un bloc série BS comportant autant de registres de données que d'unités de traitement UT présentes dans la tuile considérée, la taille des registres étant de taille au moins égale à la taille des données du flux. Le bloc série BS d'une tuile de calcul TC reçoit en entrée les données provenant de la ou des unités de traitement UT 15 et est connecté en sortie à l'unité d'entrée/sortie UES. Lors d'une autorisation en écriture sur l'un des bus 41 ou 42, les données présentes dans le bloc série (BS) sont envoyées séquentiellement sur ce bus 41 ou 42.

La figure 10 illustre un exemple de mise en oeuvre du dispositif 1 20 de traitement d'un flux de données pour des traitements à réaliser sur des images brutes. Les images brutes sont par exemple issues d'un filtre de Bayer 110, par exemple représenté à la figure 11. Avec un tel filtre, une image couleur est constituée par une mosaïque de pixels de couleurs rouge, vert et bleu. En particulier, la mosaïque est constituée d'une alternance de 25 pixels bleus et verts sur un premier type de ligne et d'une alternance de pixels verts et rouges sur un deuxième type de ligne, les types de lignes étant également alternés de façon à former des diagonales de pixels verts. Le dispositif 1 selon l'invention est particulièrement adapté à de telles données. En effet, pour chaque type de ligne, il est possible de constituer 30 une tuile de calcul TC capable de traiter simultanément plusieurs pixels bien qu'ils soient de couleur différente. Dans un mode de réalisation, représenté à la figure 10, la tuile de calcul TC comporte, d'une part, une première unité de contrôle UC1 fournissant un premier code à une première et à une deuxième unité de traitement UT1 et UT3 et, d'autre part, une deuxième unité de 35 contrôle UC2 fournissant un deuxième code à une deuxième et à une quatrième unité de traitement UT2 et UT4. Le premier code est spécifique à une première couleur de pixel, par exemple rouge, et le deuxième code est spécifique à une deuxième couleur de pixel, par exemple vert. Le code peut également être découpé en segments de code, un gestionnaire d'adresse indiquant alors aux unités de contrôle UC1 et UC2 la couleur du pixel traité. Les unités de traitement UT1, UT2, UT3 et UT4 agissent alors sur les données présentes dans le bloc 34 de registres de voisinage en fonction des instructions qu'elles reçoivent. En l'occurrence, les première et troisième unités de traitement UT1 et UT3 agissent sur des pixels rouges et les io deuxième et quatrième unités de traitement UT2 et UT4 agissent sur les pixels verts. La tuile de calcul permet ainsi de traiter simultanément, mais distinctement, quatre pixels du bloc 34 de registres de voisinage. Dans le cas du filtre de Bayer 110, deux unités de contrôle UC1 et UC2 par ligne suffisent car une ligne ne comporte que deux couleurs différentes. Bien évidemment, 15 les tuiles de calcul peuvent être adaptées en fonction du filtre de couleur appliqué.

Selon une forme particulière de réalisation, les moyens 4 d'interconnexion sont aptes à transférer des données dont la taille est 20 supérieure à celle des données du flux. Le dispositif 1 selon l'invention peut alors comporter un opérateur d'insertion permettant de concaténer chaque donnée du flux avec une donnée complémentaire. La figure 12 représente un tel opérateur d'insertion 120. L'opérateur d'insertion 120 comprend un bus d'entrée 121 relié à une entrée d'un bloc d'insertion 122 dont la sortie est 25 reliée à un bus de sortie 123. L'opérateur d'insertion 120 peut également comprendre une mémoire 124 permettant de stocker la donnée complémentaire. La mémoire 124 est en liaison avec le bloc d'insertion 122 pour permettre le transfert de la donnée complémentaire. La taille de cette donnée doit être inférieure ou égale à la différence entre la taille maximale 30 des données pouvant être transférées par les moyens 4 d'interconnexion et la taille des données du flux. La taille du bus d'entrée 121 doit être adaptée à la taille des données du flux alors que la taille du bus de sortie 123 doit être adaptée à la taille des données du flux concaténées avec la donnée complémentaire. La donnée complémentaire peut être dissociée des 35 données du flux, par exemple par des décalages, et être utilisée par des tuiles de calcul TC afin de réaliser un traitement spécifique sur les données du flux. Dans le cadre d'un traitement d'image vidéo, la donnée complémentaire contient par exemple une valeur représentative d'une correction de bruit ou de gain à appliquer aux pixels. La même correction peut ainsi être appliquée à tous les pixels de l'image. L'opérateur d'insertion peut être inséré sur l'un des bus 41, 42 de données, par exemple entre le capteur vidéo 2 et les tuiles de calcul TC ou entre deux tuiles de calcul TC. Dans un mode de réalisation, l'opérateur d'insertion 120 est réalisé par une tuile de calcul TC. La tuile de calcul TC comprend alors une unité de io mémorisation UM contenant la donnée complémentaire et une unité de traitement UT permettant de concaténer les données du flux avec la donnée complémentaire. La donnée complémentaire est par exemple stockée dans un registre de données de l'unité de mémorisation. Ce mode de réalisation présente l'avantage d'éviter l'insertion d'un composant supplémentaire dans 15 la chaîne de traitement du flux de données. II est rendu possible grâce à la modularité du dispositif 1 selon l'invention. 20 ANNEXE Jeu d'instructions (sur 48 bits : 24 bits par voie) Composition du mot d'instruction sur 24 bits : 5 0..2 - > 3 bits Condition ; 3..4 -> 2 bits Mode d'accès à la donnée 5.. 7 -> 3 bits Identifiant de l'opération 8..11 -> 4 bits Registre Destination 12..15 -> 4 bits Registre Source 10 16..23 -> 8 bits de constante Exécution si flag=1 Exécution si flag=0 Mise a jour du flag sur Carry Mise a jour du flag sur Résultat à ZERO Mise à jour du flag sur Signe (1 si >0, 0 si <0)

Postfix des instructions : 20 Permet de choisir la source r (D, A, B) : R[D] registre destination; R[A] registre source, R[B] registre source c (D, A, C) : R[D] registre destination; R[A] registre source, C Constante v (D, A, V) : R[D] registre destination; R[A] registre source, Voisin[V] Si les 8 bits de l'argument B sont formés de la manière suivante : "10...0<V>" au lieu de "0.. <V>" 25 on prendra comme voisin la valeur stockée par le registre V soit Voisin[R[V]] m (D, A ,M) : R[D] registre destination; R[A] registre source, M adresse Mémoire de la mémoire locale

Utilisation : 30 Le VLIW Permet de travailler sur deux voies OPi(Dm ...) / OPj(Dn) Il faut toutefois que j != i et que m != n Sauf dans le cas des instructions conditionnelles complémentaires : F_OP ; Aucune opération si FLAG = 1 35 NF_OP ; Aucune opération si FLAG = 0 On peut donc écrire sur la même ligne F__OP(Dm...) / NF_OP(Dn...) Puisque quelle que soit la valeur du Flag, une seule sera effectivement exécutée

40 Liste des opérations - NOP PREFIX : F_ NF_ NOP F_NOP 45 NF NOP - LD P R E F I X : F _ NF fZ_ fC fS_ LDr(D, A) : R[D] = R[A] LDc(D, C) : R[D] = C ; C constante signée 50 LDv(D, V) : R[D] = Vois[V] LDv(D, V) ; R[D] = Vois[R[V]] LDm(D, M) ; R[D] = SP[M]

- ADD; SUB; MUL 55 PREFIX : F NF fZ fC_ fS Préfix des instructions : F : NF : fc _ JZ JS Deux additionneurs signés sont disponibles, on a donc ADDO et ADDI utilisables simultanément sans restriction sur la voie. PREFIX : F NF_ fZ fC fS ADDOr(D, A , B) : R[D] = R[A] + R[B] ADDOc(D, A, C) : R[D] = R[A] + C; C constante signée ADDOv(D, A, V) : R[D] = R[A] + Vois[V] ADDOv(D, A, -V) ; R[D] = R[A] + Vois[R[V]] ADDOm(D, A, M) ; R[D] = R[A] + SP[M] IDEM pour les ADDO, SUBO SUBI, et MUL; toutes ces opérations sont signées

- SHIFT PREFIX : F_ NF fZ_ fC _ fS Un opérateur de décalage signé permet de décaler les valeurs à droite ou a gauche selon le signe du décalage Un décalage de 0 équivaut à une affectation SHIFTc(D,A, C) : si (C>O) R[D] = R[A] C si (C<O) R[D] = R[A] C - INV 25 I.TVr(D,A) R[D] = -R[A] IVVc(D, C) R[D] = -C I_NVv(D, V) R[D] = -Vois[V] INVv(D,-V) : R[D] = -Vois[R[V]] INVm(D,M) : R[D] = -SP[M] 30 Exemple de code programme Ce code réalise l'opération suivante : Pour un voisinage 2x2, met RI à la moyenne des pixels du voisinage et met RO à 255 si la valeur de la moyenne est > 128 ; incrémente R2 si le pixel est à 255 (pour avoir le compte des pixels > 128 à la fin 35 du traitement)

1 #include "macros.h" 2 .initcode 3 LDc (R0, 0) ; / NOP 40 4 LDc (R1, 0) ; / NOP 5 LDc (R2, 0) ; / NOP 6 LDc(R3,0); / NOP 7 LDc (R4, 0) ; / NOP 8 LDc (R5, 0) ; / NOP 45 9 NOP / NOP 10 .pixel code 0 11 LDv(R1,VO) / NOP 12 LDv (R2, V1) / ADDOv (R1, R1, V0) 13 ADDOv(R2,R2,V2) / ADDlv(RI,R1,V3) 50 14 ADDO(R1,R1,R2) / NOP SHIFTc (R1 , R1 , -2) / NOP 16 fS SUBc (R7, R1, 128) / NOP 17 F _LDc (R0, 0) / NF LDc (R0, 255) ; dans ce cas exceptionnel on peut appeler 2x LD car 1'un est exécuté et pas 1'autre 55 18 NF ADDOv(R2,R2,1) / NOP 19 NOP /NOP 1520 20 .pixelcodel 21 .pixelcode2 22 .pixelcode3 On pourrait écrire en profitant au maximum des 2 voies du VLIW : .pixelcode0 11 LDv (R1, V0) / NF ADDOv (R2, R2, 1) 12 LDv(R2,V1) / ADDOv (R1 , R1 , VO) 13 ADDOv(R2,R2,V2) / ADD1 v (R1, R1, V3) 10 14 ADDO(RI,RI,R2) ! NOP SHIFTc (R1, R1, -2) / NOP 16 fS SUBc (R7, R1, 128) / NOP 17 F LDc (R0, 0) / NF LDc (R0, 255)

Claims

REVENDICATIONS1. Dispositif de traitement d'un flux de données, caractérisé en ce qu'il comprend K tuiles de calcul (TC) et des moyens (4) d'interconnexion pour transférer le flux de données entre les tuiles de calcul (TC), chaque tuile de calcul (TC) comportant : - une unité de mémorisation (UM) permettant de mettre en forme les données du flux, - une ou plusieurs unités de contrôle (UC) permettant de fournir des instructions pour réaliser un traitement sur les données mises en forme, - au moins une unité de traitement (UT) par unité de contrôle io (UC), les unités de traitement (UT) réalisant les instructions reçues des unités de contrôle (UC), - une unité d'entrée/sortie (UES) permettant d'acheminer le flux de données entre les moyens (4) d'interconnexion et l'unité de mémorisation (UM) d'une part, et entre la ou les unités de traitement (UT) et les moyens (4) 15 d'interconnexion d'autre part.
2. Dispositif selon la revendication 1, caractérisé en ce que des unités de contrôle (UC) comportent chacune une mérnoire dans laquelle est stocké un programme, le programme pouvant être découpé en segments de 20 code, chaque segment de code comportant des instructions différentes pour permettre un traitement différent des données du flux en fonction de leur nature.
3. Dispositif selon la revendication 2, caractérisé en ce que le flux 25 de données provient d'un capteur vidéo (2) délivrant des images de Nc colonnes par NI lignes de pixels, chaque image comportant une alternance de deux types de lignes, chaque type de ligne comportant deux types de pixels, au moins une tuile de calcul (TC) comportant cieux unités de contrôle (UC), le programme de chaque unité de contrôle (UC) étant découpé en 30 quatre segments de code, chaque segment de code correspondant aux différents types de pixels à prendre en compte.
4. Dispositif selon la revendication 3, caractérisé en ce que le type de pixel dépend de sa couleur.
5. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce que des unités de mémorisation (UM) comprennent chacune un nombre de registres de données égal au nombre d'unités de traitement (UT) de la tuile de calcul (TC) considérée.
6. Dispositif selon l'une quelconque des revendications 1 à 4, caractérisé en ce que le flux de données provient d'un capteur vidéo (2) délivrant des images de Nc colonnes par NI lignes de pixels, des unités de io mémorisation (UM) comprenant chacune un bloc (31) de mémoires de mise en forme de dimension NcxVl et un bloc (34) de registres de voisinage de dimension VlxVc, où VI est le nombre de pixels suivant les lignes et Vc est le nombre de pixels suivant les colonnes d'un voisinage. 15
7. Dispositif selon la revendication 6, caractérisé en ce que le bloc (34) de registres de voisinage comprend, en outre, une colonne (35) de VI registres de données.
8. Dispositif selon l'une quelconque des revendications 6 ou 7, 20 caractérisé en ce que des tuiles de calcul (TC) comprennent chacune une unité de mémorisation (UM), une unité de contrôle (UC) et n unités de traitement (UT), l'unité de mémorisation (UM) fournissant des données aux n unités de traitement (UT) et l'unité de contrôle (UC) fournissant des instructions aux n unités de traitement (UT), le bloc (34) de registres de 25 voisinage comprenant (n+Vl-1)xVl registres de données agencés suivant une maille de n+Vl-1 colonnes et VI lignes.
9. Dispositif selon l'une quelconque des revendications 6 à 8, caractérisé en ce qu'il comporte un compteur CPTC et un compteur CPTL, le 30 compteur CPTC s'incrémentant après chaque donnée entrante et étant remis à zéro à chaque fois qu'il atteint la valeur Nc, le compteur CPTL s'incrémentant à chaque fois que le compteur CPTC atteint la valeur Nc et étant remis à zéro à chaque fois qu'il atteint la valeur VI, la donnée entrante étant stockée dans une cellule (33) du bloc (31) de mémoires de mise enforme dont le numéro de ligne correspond à la valeur CPTL et dont le numéro de colonne correspond à la valeur CPTC.
10. Dispositif selon les revendications 7 et 9, caractérisé en ce que la colonne de données du bloc (31) de mémoires de mise en forme repérée par la valeur CPTC est recopiée, à chaque coup d'horloge du flux de données, dans la colonne (35) de VI registres de données puis décalée dans une première colonne (341) du bloc (34) de registres de voisinage. io
11. Dispositif selon la revendication 10, caractérisé en ce que chaque donnée du bloc (31) de mémoires de mise en forme située à la colonne repérée par la valeur CPTC et à la ligne repérée par NoLigne est recopiée dans la colonne (35) de VI registres de données à la ligne repérée par (CPTL+NoLigne+1) modulo VI, où NoLigne prend toutes les valeurs 15 entières positives comprises entre 1 et VI.
12. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce que les moyens (4) d'interconnexion comprennent un nombre Nb_bus de bus de données (41, 42) défini par la 20 relation : Nb_bus = KX(Fp,xeI/Farchi)+1, où Fp1Xe, est une fréquence du flux de données et Farci est une fréquence de fonctionnement des unités de traitement (UT), la fréquence Farchi étant égale à pxFp1Xe, avec p un entier positif. 25
13. Dispositif selon la revendication 12, caractérisé en ce que des unités d'entrée/sortie (UES) comportent chacune Nb_bus registres de taille log2(Mux_t) bits pour gérer les autorisations d'accès en écriture, un registre de taille log2(Nb_bus) bits et un registre de taille log2(Mux_t) bits pour la 30 gestion des autorisations d'accès en lecture, Mux_t étant défini par la relation Mux_t = Farchi/FpixeI.
14. Dispositif selon la revendication 13, caractérisé en ce que les tuiles de calcul (TC) sont adressées par un multiplexage temporel dont le 35 rapport est défini par la relation :MUX_t = Farchi/Fpixel•
15. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce que des tuiles de calcul (TC) comprennent chacune un bloc série (BS) comportant un nombre de registres de données égal au nombre d'unités de traitement (UT) de la tuile de calcul (TC) considérée, chaque bloc série (BS) d'une tuile de calcul (TC) recevant en entrée des données provenant des unités de traitement (UT) de la tuile de calcul (TC) considérée et étant connecté en sortie à l'unité d'entrée/sortie (UES) de ladite tuile de calcul (TC).
16. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce que des unités de traitement (UT) comprennent chacune un processeur comportant deux décodeurs is d'instructions (21, 22), un premier ensemble de multiplexeurs (23), des opérateurs de calcul (24), un deuxième ensemble de multiplexeurs (25), des registres de données (26) et une mémoire locale (27), les décodeurs d'instructions (21, 22) recevant des instructions en provenance d'une unité de contrôle (UC), le premier ensemble de multiplexeurs (23) dirigeant les 20 données à traiter sur une entrée de l'un des opérateurs de calcul (24), le deuxième ensemble de multiplexeurs (25) dirigeant les données traitées vers les registres de données (26) et le processeur pouvant exécuter jusqu'à deux instructions par cycle d'horloge du processeur. 25
17. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend un opérateur d'insertion (120) permettant de concaténer des données du flux avec une donnée complémentaire, des tuiles de calcul (TC) étant aptes à dissocier les données du flux de la donnée complémentaire afin que les unités de 30 traitement (UT) desdites tuiles de calcul (TC) réalisent des instructions sur les données du flux en fonction de la donnée complémentaire.