WO2010037570A1

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

Info

Publication number: WO2010037570A1
Application number: PCT/EP2009/057033
Authority: WO
Inventors: Laurent Letellier; Mathieu Thevenin
Original assignee: Commissariat A L'energie Atomique
Priority date: 2008-09-30
Filing date: 2009-06-08
Publication date: 2010-04-08
Also published as: JP2012504264A; US20110273459A1; EP2332067A1; US8836708B2; FR2936626A1; FR2936626B1

Abstract

La présente invention concerne un dispositif de traitement d'un flux de données provenant d'un dispositif générant des matrices de NI lignes par Nc colonnes de données. Le dispositif de traitement 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). Selon l'invention, au moins une tuile de calcul (TC) comporte : - une ou plusieurs unités de contrôle (UC) permettant de fournir des instructions, - n unités de traitement (UT), chaque unité de traitement (UT) réalisant les instructions reçues d'une unité de contrôle (UC) sur un voisinage de Vl lignes par Vc colonnes de données, - une unité de mémorisation (UM) permettant de mettre les données du flux sous forme de voisinages de Vl lignes par (n+Vc-1 ) colonnes de données, l'unité de mémorisation (UM) comprenant un bloc (31 ) de mémoires de mise en forme de dimension VIxNc et un bloc (34) de registres de voisinage de dimension Vlx(n+Vc-1 ), - 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 parallèle d'un flux de données

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. 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 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 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 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, 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é 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é à 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 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.

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 l'acronyme anglo-saxon FPGA pour "Field Programmable Gâte 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. Selon un troisième compromis, les données sont traitées par une architecture dite parallèle. Une telle architecture comprend plusieurs tuiles de calcul reliées entre elles par un bus d'interconnexion. Chaque tuile de calcul comprend une unité de mémorisation permettant de stocker localement les données, une unité de contrôle fournissant des instructions pour réaliser un traitement sur les données stockées, des unités de traitement réalisant les instructions reçues de l'unité de contrôle sur les données stockées et une unité d'entrée/sortie acheminant les données soit entre le bus d'interconnexion et l'unité de mémorisation, soit entre les unités de traitement et le bus d'interconnexion. Cette architecture 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 de l'architecture. En outre, le code à exécuter par les unités de traitement ne comprend généralement que des instructions de calcul mais aucune instruction de contrôle ou de calcul d'adresse. Un deuxième avantage est la possibilité de réaliser en parallèle, soit un traitement identique sur plusieurs données, 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 que les tuiles de calcul peuvent être chaînées selon les traitements à réaliser sur les données, le bus d'interconnexion acheminant les données entre les tuiles de calcul dans un ordre configurable. De plus, l'architecture parallèle peut être étendue en ajoutant des tuiles de calcul supplémentaires, de manière à adapter ses capacités de traitement aux traitements à réaliser. Cependant, la gestion des données dans les tuiles de calcul est complexe et nécessite généralement des ressources mémoires importantes. En particulier, lorsqu'une tuile de calcul effectue un traitement sur un voisinage de données, elle doit disposer simultanément de toutes les données de ce voisinage, alors que les données arrivent sous forme d'un flux continu. L'unité de mémorisation de la tuile de calcul doit alors stocker une partie importante des données du flux avant de pouvoir effectuer un traitement sur un voisinage. Ce stockage et la gestion des données stockées nécessitent une optimisation afin de limiter la surface silicium et la consommation électrique de l'architecture parallèle tout en offrant des performances de calcul adaptées au traitement d'un flot de données. Un but de l'invention est de proposer une structure de calcul qui soit programmable et adaptée au traitement d'un flux de données, notamment lorsque des traitements doivent être réalisés sur des voisinages de données. A cet effet, l'invention a pour objet un dispositif de traitement d'un flux de données provenant d'un dispositif générant des matrices de NI lignes par Nc colonnes de données. Le dispositif de traitement comprend K tuiles de calcul et des moyens d'interconnexion pour transférer le flux de données entre les tuiles de calcul. Au moins une tuile de calcul comporte :

- une ou plusieurs unités de contrôle permettant de fournir des instructions,

- n unités de traitement, chaque unité de traitement réalisant les instructions reçues d'une unité de contrôle sur un voisinage de Vl lignes par Vc colonnes de données,

- une unité de mémorisation permettant de mettre les données du flux sous forme de voisinages de Vl lignes par (n+Vc-1 ) colonnes de données, l'unité de mémorisation comprenant un bloc de mémoires de mise en forme de dimension VIxNc et un bloc de registres de voisinage de dimension Vlx(n+Vc-1 ),

- 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 les unités de traitement et les moyens d'interconnexion d'autre part.

Un avantage de l'invention est que l'unité de mémorisation d'une tuile de calcul dans laquelle est réalisé un traitement sur un voisinage de données est particulièrement adaptée à un tel traitement, notamment en termes de dimensionnement des registres mémoire et de gestion des accès aux registres mémoire par les unités de traitement.

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 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,

- 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 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 œuvre du dispositif selon l'invention pour des images vidéo,

- la figure 1 1 , une représentation schématique d'un filtre de Bayer,

- la figure 12, un exemple de registres de format permettant le découpage des données du flux,

- la figure 13, un exemple de mécanisme permettant l'accès à un registre contenant des métadonnées,

- la figure 14, un exemple de réalisation d'une tuile de calcul comportant plusieurs unités de traitement, les unités de traitement recevant des instructions spécifiques en fonction de métadonnées,

- la figure 15, un exemple de réalisation d'un opérateur d'insertion.

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 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. Le dispositif peut par exemple traiter un flux de données audio ou des données dans l'espace de Fourier. De manière générale, le dispositif présente un intérêt particulier pour le traitement de données qui, bien qu'étant acheminées sous forme d'un flux, possèdent une cohérence dans un espace à deux dimensions.

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 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 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 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 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 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 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 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 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 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, 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 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 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 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 liaison avec des sorties du processeur. La taille des mots 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 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. 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 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 (bits 5 à 7) peuvent coder l'identifiant de l'opération, les quatre bits suivants (bits 8 à 1 1 ) 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.

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 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 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 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 segments de code, chaque 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 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. 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.

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 ê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.

Selon une première forme de réalisation, une unité de mémorisation UM comprend 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, une unité de mémorisation UM met en forme les données sous forme de voisinages et gère l'accès aux données lorsque des unités de traitement UT sont en parallèle. Une telle unité de mémorisation UM peut comprendre 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 des différentes tuiles de calcul TC é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 VIxVc où Vl 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 dispositif générant des matrices de NI lignes par Nc colonnes de données, tel qu'un capteur vidéo 32. Le capteur vidéo 32 est de résolution Nc colonnes par NI lignes de pixels. La résolution est par exemple VGA (640x480), "HD Ready" (1080x720) ou "FuII 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 avantageusement de dimension VIxNc pour permettre de générer des voisinages de dimension VIxVc. Autrement dit, le bloc 31 comprend VIxNc cellules mémoire agencées suivant une maille de Vl lignes et de Nc colonnes. Des valeurs courantes pour Vl 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(CPTVNc), 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 à VIxNc. 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 Vl. Chaque 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 forme. Le bloc 34 de registres de voisinage comprend par exemple un nombre de registres de voisinage égal à VIxVc. 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 Vl 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 débute dès qu'il y a un nombre de données dans le bloc 31 égal à (VI-1 )xNc+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 Vl données 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 Vl 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 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 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 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 : - 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 31 1 du bloc 31 , alors o le pixel de la deuxième ligne 312 du bloc 31 est recopié à 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 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 pixel est arrivé à la troisième ligne 313 du bloc 31 , alors o le pixel de la première ligne 31 1 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 VIxVc, 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 Vl. NoLigne prend toutes les valeurs entières positives comprises entre 1 et Vl de manière à permettre la recopie des pixels pour toutes les lignes du voisinage.

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 représente un ensemble de chronogrammes permettant de mettre en œuvre 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, 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 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 nombre 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. 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 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. Autrement dit, le dispositif 1 de traitement comporte une tuile de calcul TC comprenant plusieurs unités de traitement UT. Ce mode de réalisation utilise avantageusement les 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. Cependant, la dimension du bloc 34 de registres de voisinage nécessite d'être adaptée. La figure 7 illustre un exemple de tuile 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 ou plusieurs unités de contrôle UC. Selon ce mode de réalisation, le bloc 34 de registres de voisinage est de dimension Vlx(n+Vc-1 ). Autrement dit, le bloc 34 comprend Vlx(n+Vc-1 ) registres de données agencés suivant une maille de Vl lignes et n+Vc-1 colonnes. 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 Vl registres de données peut être 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 (VI-1 )xNc+1 données. Par ailleurs, pour n unités de traitement UT 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 é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 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 F_archi- Un deuxième chronogramme 82 représente l'horloge pixel de cadence F_piXΘ|. L'horloge pixel fixe la cadence à laquelle arrivent les données du flux, lesquelles sont envoyées dans le bloc 31 de mémoires de mise en forme. La cadence F_archi peut être égale à pxF_piXθι avec p un entier positif. Selon la figure 8, la cadence F_piXθι est quatre fois supérieure à la cadence F_archi- 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 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 F_piXθι, un 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 F_piXθι 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 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. Nb_bus peut être défini par la relation suivante :

NbJ⁾US = Kx(Fpi_XΘ|/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 : MUXJ = Farchl/Fpixβi.

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 F_piXθι égale à 50 MHz et une cadence F_archi à 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 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 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ù Iog2(x) est la fonction renvoyant le logarithme en base 2 du nombre x et, pour la gestion 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 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 é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 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 , 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 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 œuvre du dispositif 1 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 1 10, par exemple représenté à la figure 1 1. 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 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 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 troisième unité de traitement UT1 et UT3 et, d'autre part, une deuxième unité de 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 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 1 10, deux unités de contrôle UC1 et UC2 par ligne suffisent car une ligne ne comporte que deux couleurs différentes. Bien évidemment, les tuiles de calcul peuvent être adaptées en fonction du filtre de couleur appliqué.

Selon une forme particulière de réalisation, les données en transit sur les moyens 4 d'interconnexion peuvent contenir la donnée à traiter, mais aussi des informations supplémentaires, appelées métadonnées. Ces métadonnées peuvent être utilisées pour le transport de différentes informations associées aux données. Dans le cadre d'un traitement d'image vidéo, où les données sont relatives à des pixels, une métadonnée 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. Les métadonnées peuvent également concerner les trois valeurs R, G et B (Rouge, Vert et Bleu), des résultats intermédiaires à associer à un pixel, ou encore des informations permettant de contrôler le programme en fonction des caractéristiques du pixel. L'utilisation de ces métadonnées permet de découper aisément les algorithmes en plusieurs parties et de les exécuter sur différentes tuiles de calcul TC en mode multi- SIMD. Les données en transit peuvent être découpées selon différents formats. Le format de découpage est spécifié dans des registres de format M_ri, comme représenté sur la figure 12 (au nombre de quatre dans ce cas particulier M₁-O, M_r1 , M_r2, M_r3). Dans le cas présenté sur la figure 12, un mot de données de 24 bits a été scindé en trois parties 121 , 122, 123 alors qu'un découpage jusqu'à quatre était possible. Ces registres de format sont définis pour une tuile de calcul TC et leur valeur respective est fixée lors du chargement du programme. Les accès aux données sont ensuite systématiquement réalisés par un mécanisme tel que présenté sur la figure 13, composé de multiplexeurs 131 a, 131 b, 131 c, 131d, de registres à décalage 132a, 132b et de portes logiques 133a, 133b, 133c, 133d, 137. Sur cette figure 13, on retrouve les registres de format M_ri 134 associés à des registres de position D_ri 135. Ces registres D_ri 135 sont déduits des registres M_ri 134 par le logiciel de chargement des paramètres du programme. Ils permettent d'obtenir la position de début de la métadonnée considérée. Seuls les registres de format M_ri 134 sont donnés par le programmeur, les registres de position D_ri 135 étant automatiquement obtenus à partir des registres de format M_ri 134. Dans l'exemple de la figure 13, M₁-O est associé à D_r0=0, M_r1 est associé à D_r1 =8, M_r2 est associé à D_r2=16 et M_r3 est associé à D_r1 =24. Une réalisation possible d'un mécanisme de lecture et d'écriture des métadonnées dans un registre de 24 bits 136, permettant l'accès au réseau de communication, est donnée figure 13. Pour la partie lecture des métadonnées, les registres de format 134 sont reliés par un multiplexeur 131 b commandé par la position courante à récupérer CMr à une cellule de ET logique 133d permettant de mettre à zéro les bits du registre 136 qui ne sont pas concernés par la position définie, puis les registres de position 135 sont reliés à un registre à décalage 132b qui permet de décaler le résultat précédent du bon nombre de fois afin de disposer d'une valeur calée à droite qui est la valeur finale à récupérer pour la position considérée. Pour la partie écriture des métadonnées, la donnée à écrire Val est décalée à la bonne position grâce au registre de position 135 relié à un multiplexeur 131 c commandé par la position courante à écrire CMw, multiplexeur 131 c lui- même relié à un registre à décalage 132a. Seuls les bits concernés ne sont pas mis à zéro grâce à une cellule de ET logique 133a reliée au multiplexeur 131 a qui donne les bits à masquer grâce au registre de format 134. Enfin ces bits sont concaténés avec ceux déjà présents dans le registre de destination 136. Pour cela, le registre de format 134 est inversé par une cellule de NON logique 137 puis un ET logique est réalisé par une cellule 133b entre le registre de format inversé et la valeur du registre 136, permettant ainsi de fabriquer un nouveau masque qui attaque une cellule OU logique 133c permettant d'associer la nouvelle donnée au registre 136 sans toucher les bits non concernés.

Avec cette gestion des métadonnées, le calcul de nombres complexes ou à virgule fixe se trouve grandement facilité. Le dispositif de traitement selon l'invention peut ainsi être avantageusement utilisé pour les traitements dans le domaine de Fourier (fréquentiel) par exemple. Le dispositif de traitement selon l'invention peut également être adapté pour accélérer l'émulation de nombres à virgule flottante à l'aide d'opérateurs à virgule fixe. Dans une architecture multi-SIMD, les métadonnées peuvent être utilisées pour déterminer les instructions à transmettre aux processeurs. En effet, les informations complémentaires (métadonnées) peuvent indiquer le traitement spécifique à exécuter sur les données auxquelles elles sont associées. Il suffit d'extraire l'information nécessaire du mot de données dès son entrée dans la tuile de calcul TC, illustrée par l'exemple de la figure 14, et de la transmettre à l'unité de contrôle UC qui gère les unités de traitement UT en mode multi-SIMD. En l'occurrence, la métadonnée peut être extraite lorsque le gestionnaire de voisinage organise les données pour les transmettre aux unités de traitement UT via des multiplexeurs 141. Une communication supplémentaire 142 entre l'unité d'entrée/sortie UES et l'unité de contrôle UC permet le transfert de la métadonnée, comme représenté sur la figure 15.

Afin de permettre le transfert des métadonnées, les moyens 4 d'interconnexion peuvent être adaptés en termes de capacité. En particulier, la taille des bus 41 , 42 de données peut être augmentée en fonction de la taille des métadonnées. De plus, le dispositif 1 selon l'invention peut comporter un opérateur d'insertion permettant de concaténer chaque donnée du flux avec une métadonnée. La figure 15 représente un tel opérateur d'insertion 150. L'opérateur d'insertion 150 comprend un bus d'entrée 151 relié à une entrée d'un bloc d'insertion 152 dont la sortie est reliée à un bus de sortie 153. L'opérateur d'insertion 150 peut également comprendre une mémoire 154 permettant de stocker la métadonnée. La mémoire 154 est en liaison avec le bloc d'insertion 152 pour permettre le transfert de la métadonnée. La taille de cette donnée doit être inférieure ou égale à la différence entre la taille maximale 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 151 doit être adaptée à la taille des données du flux alors que la taille du bus de sortie 153 doit être adaptée à la taille des données du flux concaténées avec la métadonnée. L'opérateur d'insertion 150 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 150 est réalisé par une tuile de calcul TC. La tuile de calcul TC comprend alors une unité de 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 UM. Ce mode de réalisation présente l'avantage d'éviter l'insertion d'un composant supplémentaire dans la chaîne de traitement du flux de données. Il est rendu possible grâce à la modularité du dispositif 1 selon l'invention.

ANNEXE

Jeu d'instructions (sur 48 bits : 24 bits par voie)

Composition du mot d'instruction sur 24 bits : 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 16..23 -> 8 bits de constante

Préfix des instructions : F_ : Exécution si flag= 1 NF_ : Exécution si flag=0 fC : Mise a jour du flag sur Carry fZ : Mise a jour du flag sur Résultat à ZERO fS : Mise à jour du flag sur Signe (1 si >0, 0 si <0)

Postfix des instructions : 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>" " 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 : Le VLIW Permet de travailler sur deux voies :

OPi(Dm ...) /OPj(Dn)

II 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 NF_OP ; Aucune opération si FLAG = 0

On peut donc écrire sur la même ligne FjOP(Dm...) /NFjOP(Dn...)

Puisque quelle que soit la valeur du Flag, une seule sera effectivement exécutée Liste des opérations - NOP

PREFIX : F_ NF_

NOP

F_NOP NF_NOP

- LD

PREFIX : F_ NF_ fZ_ fC_ fS_

LDr(D, A) : R[D] = R[A]

LDc(D, C) : R[D] = C ; C constante signée 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 PREFIX : F NF fZ fC fS 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 SUB1, 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 > 0)

R[D] = R[A] « C si (C < 0)

R[D] = R[A] » C - INV INVr(D,A) : R[D] = -R[A]

INVc(D, C) : R[D] = -C INVv(D, V) : R[D] = -VoIs[V] INVv(D,-V) : R[D] = -VoIs[R[V]] INVm(D,M) : R[D] = -SP[M]

Exemple de code programme Ce code réalise l'opération suivante :

Pour un voisinage 2x2, met R1 à 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 du traitement)

1 #include "macros ;.h"

2 . initcode

3 LDc (RO, 0) ; / NOP

4 LDc (Rl, 0) ; / NOP

5 LDc (R2, 0) ; / NOP

6 LDc (R3, 0) ; / NOP

7 LDc (R4, 0) ; / NOP

8 LDc (R5, 0) ; / NOP

9 NOP / NOP

10 .pixelcodeO

11 LDv(Rl, VO) / NOP

12 LDv (R2, Vl) / ADDOv (Rl, Rl, VO)

13 ADDOv (R2,R2 ,V2) / ADDIv(Rl, Rl, V3)

14 ADDO (Rl, Rl, R2) / NOP

15 SHIFTc (Rl, Rl, -2) / NOP

16 fS_SUBc(R7, Rl, 128) / NOP

11 F_LDc (RO, 0) / NF_LDc (RO, 255) ; dans ce cas exceptionnel on peut appeler 2x LD car 1 'un est exécuté et pas 1 'autre 18 NF_ADD0v (R2,R2, 1) / NOP 19 NOP /NOP 20 .pixelcodel

21 . pixelcode2

22 .pixelcode3 On pourrait écrire en profitant au maximum des 2 voies du VLIW

10 .pixelcodeO

11 LDv (Rl, VO) / NF_ADD0v(R2,R2, 1)

12 LDv (R2, Vl) / ADDOv (Rl , Rl , VO)

13 ADDOv (R2,R2,V2) / ADDIv (Rl, Rl, V3) 14 ADDO (Rl, Rl, R2) / NOP

15 SHIFTc (Rl, Rl, -2) / NOP

16 fS_SUBc (Rl₁Rl, 128) / NOP

17 F_LDc (RO, 0) / NF_LDc (RO, 255)

Claims

REVENDICATIONS

1. Dispositif de traitement d'un flux de données provenant d'un dispositif générant des matrices de NI lignes par Nc colonnes 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), au moins une tuile de calcul (TC) comportant :

- une ou plusieurs unités de contrôle (UC) permettant de fournir des instructions,

- n unités de traitement (UT), chaque unité de traitement (UT) réalisant les instructions reçues d'une unité de contrôle (UC) sur un voisinage de Vl lignes par Vc colonnes de données,

- une unité de mémorisation (UM) permettant de mettre les données du flux sous forme de voisinages de Vl lignes par (n+Vc-1 ) colonnes de données, l'unité de mémorisation (UM) comprenant un bloc (31 ) de mémoires de mise en forme de dimension VIxNc et un bloc (34) de registres de voisinage de dimension Vlx(n+Vc-1 ),

- 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.

2. Dispositif selon la revendication 1 , caractérisé en ce que le bloc (34) de registres de voisinage comprend, en outre, une colonne (35) de Vl registres de données.

3. Dispositif selon l'une des revendications 1 et 2, caractérisé en ce qu'il comporte un compteur CPTC et un compteur CPTL, le 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 Vl, la donnée entrante étant stockée dans une cellule (33) du bloc (31 ) de mémoires de mise en forme dont le numéro de ligne correspond à la valeur CPTL et dont le numéro de colonne correspond à la valeur CPTC.

4. Dispositif selon les revendications 2 et 3, 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 Vl registres de données puis décalée dans une première colonne (341 ) du bloc (34) de registres de voisinage.

5. Dispositif selon la revendication 4, 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 Vl registres de données à la ligne repérée par (CPTL+NoLigne+1 ) modulo Vl, où NoLigne prend toutes les valeurs entières positives comprises entre 1 et Vl.

6. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce que des unités de contrôle (UC) comportent chacune une mémoire dans laquelle est stocké un programme, le programme pouvant être découpé en segments de 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.

7. Dispositif selon la revendication 6, 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, 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 deux unités de contrôle (UC), le programme de chacune de ces unités de contrôle (UC) étant découpé en quatre segments de code, chaque segment de code correspondant aux différents types de pixels à prendre en compte.

8. Dispositif selon la revendication 7, caractérisé en ce que le type de pixel dépend de sa couleur.

9. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce qu'au moins une tuile de calcul (TC) comporte : - une unité de mémorisation (UM) permettant de stocker des données du flux,

- une unité de contrôle (UC) permettant de fournir des instructions pour réaliser un traitement sur les données stockées, - plusieurs unités de traitement (UT), chaque unité de traitement

(UT) réalisant les instructions reçues de l'unité de contrôle (UC) sur une partie des données stockées,

- 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'unité de mémorisation (UM) comprenant un nombre de registres de données égal au nombre d'unités de traitement (UT).

10. 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 relation : Nb_bus = Kx(Fpiχ_θ|/F_archi)+1 , où Fpiχ_θι est une fréquence du flux de données et F_archi est une fréquence de fonctionnement des unités de traitement (UT), la fréquence F_archi étant égale à pxF_piXθι avec p un entier positif.

1 1 . Dispositif selon la revendication 10, 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 gestion des autorisations d'accès en lecture, Mux_t étant défini par la relation MuX_t = Farchi/Fpiχ_θ|.

12. Dispositif selon la revendication 1 1 , caractérisé en ce que les tuiles de calcul (TC) sont adressées par un multiplexage temporel dont le rapport est défini par la relation : MUXj = Farchl/Fpixβi.

13. 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).

14. 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 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 données à traiter sur un ou deux opérateurs de calcul (24) de l'ensemble des opérateurs disponibles, 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.

15. Dispositif selon l'une quelconque des revendications précédentes, caractérisé en ce que des données du flux sont concaténées 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 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.

16. Dispositif selon la revendication 15, caractérisé en ce que la concaténation de données du flux avec une donnée complémentaire est réalisée par un opérateur d'insertion (120) inséré sur les moyens (4) d'interconnexion.